replacing external API in nextjs website project
Unanswered
Woodwasp posted this in #help-forum
WoodwaspOP
hey, I have this (image 1) and don't like that the api and website are separate.
For simplicity and code reuse, i want to move my api into my nextjs app router project (image 2).
It uses websockets, apparently nextjs doesn't work well with this? do I have to abandon sockets and use the route handlers?
https://nextjs.org/docs/app/building-your-application/routing/route-handlers
For simplicity and code reuse, i want to move my api into my nextjs app router project (image 2).
It uses websockets, apparently nextjs doesn't work well with this? do I have to abandon sockets and use the route handlers?
https://nextjs.org/docs/app/building-your-application/routing/route-handlers
9 Replies
@Woodwasp hey, I have this (image 1) and don't like that the api and website are separate.
For simplicity and code reuse, i want to move my api into my nextjs app router project (image 2).
It uses websockets, apparently nextjs doesn't work well with this? do I have to abandon sockets and use the route handlers?
https://nextjs.org/docs/app/building-your-application/routing/route-handlers
to my knowledge it's quite a pita to handle websocket in nextjs. i would have a separate service (server) to handle websocket
WoodwaspOP
ok thx
@Woodwasp
I recently came across this hosting service
https://fly.io/javascript-journal/websockets-with-nextjs/
I recently came across this hosting service
https://fly.io/javascript-journal/websockets-with-nextjs/
check out this blog, you should be able to use websockets in your next.js project
The reason websockets doesn't work with Next.js natively is because serverless functions of Next.js is designed be spun up and spun down as fast as possible and don’t accommodate long-running connections while websockets requires connection to be open until someone hangs up.
When deploying your app on Fly.io, your app runs as a traditional server, and thus WebSocket implementation is very straightforward; no third-party tools necessary.
if you don't like this, you can look for third parties (assuming this is not what you want)
@Woodwasp what do you think?
WoodwaspOP
thanks thats nice to know, but I think I'll just keep them seperate as it seems to be the most common and robust approach