Nuxt.js: API routes

[egoist]

What problem does this feature solve?

Automatically populate pages/api/**/*.vue as API routes so that:

• Custom server becomes unnecessary
• Better DX, you don't need to start a nodemon process for API
• The possibility to optimize your API routes for serverless environment

What does the proposed changes look like?

Reference implementation: https://nextjs.org/docs/api-routes/introduction

[pi0]

Already in roadmap ;)

[egoist]

@pi0 Any ETA? Is it already in progress or do you need contributions?

[pi0]

@egoist I hope until Mar. We are still doing internal discussions if you are interested to contribute, that would be awesome!

[ankitarora05]

https://gamecom.app/

I created a website on nuxt and have a infinite loader on the feed on the landing. Gives me great performance using vue and server render. Any thoughts?

FYI you have to login to enjoy the feed :-p

[PandaWhisperer]

I just started using Nuxt and would like to see support for this as well. Happy to contribute if someone could show me where to start.

FWIW I like how Sapper handles server-side routes: basically, any .js file in the pages directory gets turned into a server route, according to the same routing rules that apply to component pages.

In other words, there is nothing special about server routes (i.e. no magic api directory like in Next). Any file in pages gets routed the same way, except if it's a component, it's routed on the client and the server, but if it's a plain JavaScript file, it's routed only on the server.

Also, Next's approach only allows one default export per file, if you want to respond to different HTTP methods, you have to manually inspect req.method. Sapper uses named exports instead, so in order to respond to the GET request, you export a function named get, for a POST request, you export a function named post, etc.

Makes a lot more sense to me than Next.js.

[brillout]

How about doing RPC, e.g. something like Wildcard API?

[jozsefsallai]

Any new progress/ETA on this?

Also, it would be very nice if we could easily implement multiple HTTP methods (unlike Next where you'd have to manually check what the method of the request is). Svelte/Sapper does it in a very good way: https://sapper.svelte.dev/docs#Server_routes