Why I'm Using Express Instead of NextJS

next JS is a full stack framework some people argue and you know what damn right it is and it is a pretty good one at that so why am I not using it as such in the current side project I'm building I feel like a broken record at this point I'm using express.js instead of the built-in nexjs API rods Josh why are you doing that a lot of people ask me and the answer is for this use case even if you wanted to use nexjs API rods you couldn't you could be sitting screaming and kicking in front of your computer you just couldn't do it and there are three things as to why not to be specific there are three main limitations of the serverless architecture that nexjs has under the hood and what serverless means is just instead of hosting a 24 7 server that is always responsible for managing your requests for example on Heroku or in digital Ocean or on a virtual private server that you're hosting what serverless means is even though the name might suggest there are no servers there are definitely still servers but now instead of hosting it all the time you just pay for the time it takes to execute your functions on someone else's infrastructure so for example somebody is calling your next JS API endpoint you would be paying for sale for the two seconds it takes to run that function and there are three problems with serverless you cannot solve that originate from the very idea of them being serverless number one they time out you cannot run a serverless function for more than mostly a couple of seconds for example I think an AWS Lambda the default timeout is three seconds and then you could bump that up to something like 15 minutes whereas if you Deploy on versus the default execution time is only 10 seconds until the functions time out and if you're on the paid Pro Plan then I think it's about 30 seconds that you can execute you can run your function 4 until they time out nothing longer than than that can be done if you wanted to do something with web scraping for example that usually takes quite some time because you need to make a request to their server and scrape the information and send it back and so on so with the timeout that means you couldn't really do it if it takes longer than 10 seconds on the free plan second one you cannot have stateful connections like web sockets what websockets are is it's a connection to the server that stays open it's not one HTTP request and the response it's a connection that's open all the time that's what the WSS handshake is for you cannot have that with serverless because after your function is done running on the server it's done you know the serverless function stops you cannot keep a connection open to something that is not online all the time like a serverless function and what that forces you to do is instead of being able to handle something in memory on the server for example you get a request into one API route you put that in memory for example which clients you're currently serving on your server you can put that in memory inside of an object in JavaScript on your regular node.js Express server and then in another function also have access to that data with server dysfunction you cannot have stateful connections which forces you there's no way around that to use something external for for example in memory management something like redis and those two points were the main limitations for my app I need a long time to serve the user because I'm streaming back the response in real time and it takes quite a lot of time this is a block article generator to write a blog article with gpd4 there's one more disadvantage and that is a cold start problem you might have heard about this it means that the first time your function is being called in a certain time interval be that half an hour or two hours or a day the first time it's called the underlying infrastructure that hosts your function needs to First spin up an instance and the first time it's called that will take way longer than the subsequent requests will in extreme cases the function cold starts can be up to one or two seconds you have to wait for the first just the first request that you're making to the end point especially with replicate and the open source software the image to all generator I've built in the past with replicate as the underlying provider those code starts were way more extreme up to and now sit down strap yourself in two minutes it took up to two minutes for a request to this endpoint to be served which is absolutely ridiculous and no user will ever stick around that long but again this is a very specific issue just with this provider and you won't have that in regular next JS if I could I would have done it with Nexus actually it's more cost effective because you just pay for the time you actually use and it scales way better you don't really need to worry about infra in the first place whereas if you host your own node.js Express server you kind of do even though many tools already make it way more easy for example Amazon elastic compute ec2 you don't have to do too much but it's just way easier to do it with serverless functions but I can't those are the reasons I really hope you enjoyed and learned something new and then I'll see in the next one have a good one and bye bye

Channel: Josh tried coding

Views: 71,631

Keywords: express, expressjs, react, nextjs, nextjs full stack, nextjs api, nextjs api routes, nextjs 13 api routes, nextjs api route handlers, nextjs 13 api route handlers, express api, expressjs api, nextjs vs nodejs, nodejs, node express, josh tried coding, joshtriedcoding

Id: 6xvLUWpCSFM

Length: 5min 22sec (322 seconds)

Published: Fri Apr 28 2023