Why I'm Using Express Instead of NextJS
Вставка
- Опубліковано 27 кві 2023
- NextJS is a full-stack framework. True! Its API routes are convenient and scale well. Also true! Why am I still using ExpressJS instead?
My links
My GitHub: github.com/joschan21
Discord: / discord - Наука та технологія
Was aware you could self-host NextJS, what I didn't know is that it would just act like a regular nodejs server then. Thanks for sharing, you learn something new every day
Can’t wait to see more of your stuff!
Great job, keep going 💪
I would assume the package has to be installed via NPM or something similar.
Although resolved , I highly agree on your points , good video bro.
You can, but I think the API routes are still separately scoped, so you'll still need Redis if you want to persist data across different routes.
What does self hosting actually mean? Deploying it to a VPS?
@@manchao1416 an an actual machine, like heroku or digitalocean, and then you don’t have any execution timeout in your api endpoints
I recently ran a poll on the NextJS Subreddit and the majority of people were using a separate server. One big reason there was simple separation of concerns.
Grüße aus Deutschland btw
Interesting, thanks for sharing. Would've actually expected that, the web is not actually moving as fast as it might seem from Vercel. Cheers, Grüße zurück :)
That would indeed also be my main reason.
one big reason there was code sharing and type safse from BE to FE
In actual production you would almost always have dedicated api services via express, spring, .NET, etc that are vertically or horizontally scaled, fronted by api gateways and waf, distributed and or edge cacheing, observable via open telemetry and application logging, alerts via pager duty.This concept of having production grade APIs within SSR ui frameworks is a concept pushed by cloud providers like vercel that maintain these frameworks to have you put everything into cloud functions. Just because you can put an api into a ssr framework doesn’t mean you should.
Your approach is definitely common practice in production. However I see nothing wrong with a production app using NextJS built in API routes, many things are done right, scaling is easy and it’s also worked well for me in the past
True
I would like to point out that you can still use Nextjs and express together. Yes Nextjs is a full stack framework but that doesn’t mean you can’t use both here(unless you don’t have a front end). Virtually you would be running react but now you still get all the file base routing system, hosting ……etc you’ll just hit the express backend routes instead of the server less routes problem solved. Hell you could even use a hybrid approach and use Nextjs for all of your light request and express for your heavy request.
Great explanation. The latter hybrid approach is exactly what I'm doing, just offloading the heavy, long-lasting tasks to express and handling everything else over serverless. Its working very well, thanks for sharing
just regard next js as backend for frontend to call express endpoint
@@domw2391 Can you elaborate what you said?
@@domw2391 ok
@@joshtriedcodingI just jumped into NextJS 13.4 from a MERN stack. Yesterday I fired up Next on Node in a docker container with sleep infinity. But I still notice odd I assume caching issues even when my server is continuously running it seems like there is a cold start when I navigate to different resource, even some that are a basic page with no props. The computing resource it currently has available are more than I would like to pay for at Digitalocean. I still assume I have screwed something up in config.
i start watching your videos recently and they are very useful, keep going we support you👏
I’m using NextJS for the frontend with an Express backend and two Express microservices but using the NextJS routes as a proxy to the backend services so I can hide API keys in server-side environment variables. I am going to have a mobile app hitting the backend too so definitely can’t have the backend and web frontend on one server for that.
NextJS API routes are just good for simple web apps, but in most cases I will do the same express backend or nest js.
I had this exact issue of stateless function calls while working on a dashboard for a startup as a contractor. I ultimately deployed a standalone go server, same difference. Nice video!
What issues? The time for the first call?
In my opinion and like you mentioned in video you have to use whats best for the current project or what the client requests 😅. For my current project some sort of portfolio combined with booking or request system for photographer i started to use api routes. For my last project I had to use Spring boot due to legacy system restrictions. Honstly a simple express server would be more and sufficient and for my upcoming project i will use nestjs. So you see its important to stay open and learn new frameworks and not restrict to one technology. Altough nestjs is a good fullstack framework its not the tool for all use cases. Same goes for other tools like express, angular and so on. If you are familiar with the basic concepts you wont have much problems to switch and learn new things. At the end these are just tools you have to pick the best/most suited for the current project. Thats the point which seperates "good" from "bad" developer. The ability to stay flexible, learn new cocepts and adopt the concepts if nessecary
I can definitely relate to this, down here in Africa where the internet is quite slow in so many places, building a fully NextJS powered ecommerce website may not be user-friendly. The servers usually time out before all the information is retrieved for the user..
Could you clarify for me, you needed a stateful deployment because you’re running replicate on the machine itself, or are you just interacting with the replicate api which is taking too long?
Just interacting with their API, not self hosting it. It works super well for subsequent requests, the first ones sometime take exceptionally long though
@@joshtriedcoding that’s strange, their api must dynamically spin up a machine for your use or something and tear it down later. Not sure why it would take so long
I'm coming to a similar point of realisation now as I want to integrate GPT-4 into my app at some point in the future. I've got two possible solutions:
1. Using Next api routes for requests that you know will be quick and an express server for requests that will take a while.
2. If the slow request is done based on a user input (like requesting to generate a blog) then why not fetch on the frontend, that doesn't have a timeout limit?
The bigger issue for me is that I need to treat the back end and front end differently. I need to scale them differently, my clients need to deploy them to different logical zones, and I need to have different security policies for the front end and back end. I'll use the Next routes for "locally convenient" things for my application, but most of the functionality must be separate.
Hey Josh! Could you explain in a Video what kind of Stack you will use then primary? Because React doenst give any official stuff anymore for stand alone if i understand right?
I was under the impression you could just self-host a NextJS server and have those routes available 24/7, can someone clarify for me?
yes you can, I've done it before. using NextJS doesn't necessarily mean you have to use it as serverless, you can just use it in a "server-full" way, you're going to need a server for running the Express server anyway. but if you want to keep everything else serverless, then I can understand why you might want to go for something like this.
You impressing is right, they’re available 24/7. What he meant in the video, is each time any of your endpoints get hit, it can run as much as 60 second PER request(in the pro plan)
Agreed! I have A NextJS app with an Express server to handle Web Sockets and it's working perfectly. Can't host on Vercel, however.
That's possible, the Vercel team has instructions on how to achieve that. As far as I know, all you need is a node server and you're golden
@@Zihad It doens't even need to be an Express erver, you can use a plain Node server.
If we use express, should we go with pages routes or app router? Does it even matter?
But shouldn’t NextJS be agnostic of what type of backend infra are you using? Like you could dockerize the NextJS app and deploy to something else different than Vercel/AWS?
this mean using Nextjs and to write an backend
Well the first 2:
- Timeout: I think most serverless funct providers limits this. The time is higher if you pay more. I'm not saying that this vercel time is good, just that is a common concern if you plan to use serverless anyway and it depends on your code exec time.
- The industry is using a lot of REST and that's supposed to be stateless. It's also a known limitation of serverless but it's great for REST
Now for the third one, cold starts. If you have a server that gets a request every hour you won't probably want to pay the whole hour for that, so you'll probably choose a cheap plan and those could include cold starts as well. So it's basically a providers/money thing
I am using AWS for websockets, works really well, data which I need to keep like connections etc is just store with a TTL in dynamodb
No web sockets so that’s the reason I can’t send a blob url from a audio input to the api in nextjs and try to read/convert it to a file to send it elsewhere?????
I think people don't know what NextJS truly is when talking about Backend. It's a BFF (Backend For Frontend) and should not be a primary API for the product.
Why?
I've seen many people base their core API around Next API endpoints and don't see anything wrong with that. Just depends on what you expect from you API and what it should handle
@@joshtriedcoding Modeling core API based on your frontend framework is a terrible choice. You might need to add another frontend like mobile, desktop or browser extension. Or maybe you will redesign your frontend entirely. It is easier to rewrite frontend and harder to rewrite backend for a running real business.
I would say the only way writing your API around Next could be viable is for a weekend side-project or youtube tutorial 🤣
@@dyto2287 I always use next API endpoints but not for the core logic of my application but rather to hide my database url's and api keys e.t.c.. SO it acts like middleman/reverse proxy to the real API.
The coupling that exists between an API and the frontend depends on implementation. If you commit to returning only domain data from your Next.JS API routes, you don't lose the ability to serve multiple front end clients.
I think this video should've been titled "Why I Don't Use NextJS API Routes For This Project". Express doesn't handle WebSockets either...
Then there wouldn't be as many views as with this title, it's all marketing, but people like you make it much better, at least you're making corrections a beginner like me would never know, I am a complete novice at MERN stack and all these details are learnt during live projects, which are very difficult to find when you're unemployed, thank you for pointing out the facts
Express can handle websockets. I once worked on a project with that.
Express is powerfull and adptable to anything.
Huh? Yeah it can handle websockts?
Websockets aren’t some magic thing. They’re just a type of http upgrade.
It can't handle WebSockets on it's own, you have to use an extra package. I don't count this as handling WebSockets since it's the other package doing it.
Nextjs doesn’t allow you get images uploaded to the public directory after running next build. I learnt this the hard way after building an e-commerce application that required new product image uploads. I later had to completely delete the api routes and moved the entire database to an express server and that worked superbly through api calls in the next is app, all newly uploaded images didn’t get 404 errors when being fetched.
Hey josh, do you have next express-js basic app structure?
Next tries to be a jack of all trades with its API routes, and Vercel is pushing hard to turn entire stacks into just Next and nothing else. However, I think a lot of devs are calling Next out on this and are realizing that Next really isn't that great for backend at all. I personally think Next is great to increase performance by using SSR/SSG, but you should almost always make your backend in a separate project.
yes its also good for maintainance. kind of some microservices pattern, i think next follow monolithic
Im doing the frontend in nextjs and the backend in django, there is a database of the chat history and store messages on postgre on the backend, how could I connect a database made on postgre with nextjs, maybe with vercel ?
@@rodrigopolanco8434you dont connect it. You just fetch the data in next
@@rodrigopolanco8434 Did you try prisma?
@@whatyoumissed9994 Most "microservice" and separate backends I've seen around are actually just distributed monoliths that are actually much _worse_ to maintain. I think a whole bunch of projects would've been a lot easier to deal with and probably a whole lot cheaper too if devs just stopped clinging to their favorite "stacks" so much and just started to keep things simple.
Josh this is a really good explanation 👏
I also created my own fastAPI backend in python. I think it's also good in terms of separation of conerns.
I think you’re confusing deployment infrastructure with framework capabilities. You can 100% use NextJs and websockets.
NextJs api does build to severless functions by default but you can containerized NextJs and host it on a PaaS and still get all the benefits you mentioned.
Interesting, didn't know that. Thanks for sharing
@@joshtriedcoding Perhaps we can see the self hosted version as a video soon... ;)
yes you still can use nextjs for infrastructure and not use serverless functions but i wont recommend it nestjs will be a better choice
@@aizensoskue3880 I agree there’s better alternatives for sure. NextJs is a lightweight backend to vs more dedicated frameworks like NestJs. I was more so addressing the idea that you “can’t” do it along with the other things he mentioned. Severless cold starts have less to do with the development framework and more to do with the infrastructure of the application as a whole.
you can, but should you? I think it's easier, more maintainable and potentially more performant to just have a separate backend and avoid any backend logic in NextJS.
Hi Josh, what camera are you using now versus your first video? Nice screen background btw :)
It’s the same actually. Just tweaked some settings, it’s the Nikon D750. It’s not meant for video at all tho
Do route handlers not take care of these issues? I was under the impression that of Next 13 route handlers in API routes could help with web hooks, web sockets, or SSE. I have not tired it however.
You can use edge functions and stream responses for generating blog post articles.
Yeah, if the response takes too long they’ll time out tho
The websocket issue was the reason why I had to move over from using Nextjs to express for one my favourite personal projects.
Yeah that’s a solid reason to switch. It’s possible through serverless if you’re fine with paying someone else for their infrastructure, but there’s something nice about managing websockets yourself too
@@joshtriedcoding Yeah, I felt like I had more control and was easier to work with Socket outside of the serverless environment.
I agree that handling Websocket solutions yourself has a nicer feel to it.
However, scalability could become an issue.
You'll have concurrent connections limits, possibly memory leak issues and a few other big headaches...
All problems that are solvable, sure, but they take time, expertise and infrastructure.
The paid realtime technology services aim for those headaches to bring to them, not you.
hi, Josh, which one is more popular, nextjs full stack or MERN?
Can you share that blog generator project?
Do you have any resources on integrating Express js backend with Next js 13 and adding authentication (w/o Next Auth, the tokens, etc. is generated on Express backend
Did you find anything useful to solve this issue?
Do mention if you found it
as for the timeout why not just push the job to queue and poll it ?
Great. Explanation. Thanks josh!
cheers man
You can deploy NextJS to Digital Ocean and it wouldn't be a serverless deployment while still having access to the API routes.
it really depends on the use cases
what about express vs fastify?
Why don’t you use redux for state management? There’s plenty of good libraries to use next and express.
I started learning NestJS a couple days ago and I am really liking it compared to Express
Also trying it out for small tool at work, seems good - reminds me of Django
@@jonasls yeah I've done quite django, flask, fastapi. The method directives remind me of Flask and FastAPI.
The reason I like it is because it has a good structure and is opinionated. Unlike express which is un opinionated
I like fastify
I am to, im using it for my capstone project in my coding bootcamp(Flatiron school), it seems really cool, love how it is built in with Typescript and fully compatable, and I really like the structure and architecture, makes me feel more organized with my backend, especially since I want to potentially scale this project.
@@radimhof That's nice too. But I like Nest because it is much opinionated. Also I use Nest with Fastify
Shall we expect a nextjs frontend and express backend project from u soon?
What do you use for user authentication if you choose to use express?
Passport js is a great package for handling user authentication
could you pls make a project video on express + next.js
Curious if you used NestJS and what you think about it.
Haven't used it yet
i just stomped my head with the size limit on cloud functions whilst using puppeteer and an aws lambda adapter :(( wouldve been great to come across this video earlier today lol
ok, regarding your points:
1. the first one I have nothing to add on, yeah the timeout sucks.
2. here you said you should use something like in memory DB like Redis, this is an awful solution. In the docs Next suggest that you use a 3rd third service for real time communication(e.g your WebSockets) like Pusher. Pusher solves your 2nd point.
3. cold start sucks, this is why It's recommended to move into the new Edge runtime. It has no cold starts with better performance and less expansive. Notice that when I say Edge I don't mean the location of Edge, this can stay regional (as it should if it communicates with a DB), I only talk about the RUNTIME.
I've talked about the edge infrastructure with Theo and he released a new video about it couple days ago.
Why would I pay for websockets?
Does edge handle websockets?
@@vim55k no, you can think of it as “steroid lambdas”, but they don’t even run on node
@@vim55k because of the same reason you might pay for auth providers, hosted CDN’a, cloud infrastructure, external load balancer(e.g Redis from upstash)
@@vim55k it’s your deal to what to pay for, but usually SaaS are worth, and the time you spend managing all your websockets infra in your express up(maybe you want to add encryption to it) might not be worth it relative to using something easy and reliable as Pusher
I think aws has server less web sockets for like 15 minutes.
Excellent video thanks for the info.
Cheers dude
can you present how to combine React with Express server? In specially SSR part.
did you find a solution? i'm stuck with the same.
@@Bruno-ke1uh no
Hey why you dont use nextjs with a custom server which serves nextjs and api
You don't have to use NextJS serverless, though?
Another great video Josh! A lot of people just use a particular tech blindly without comparing the use cases and the pros and cons for a particular use case.
Btw, edge functions have lesser cold start durations, don't they? I remember Theo mentioning something about this on his latest video.
I think we should only doing frontend with next js 😂
Use netlify functions?
Is it possible to use express and next together
I love NextJs but for backend I prefer Laravel or Express....
What about edge?
Also bandwidth on vercel is expensive
haven't worked with nextjs. can't you just serve your nextjs project on a classic server, just as you would do with express, php or ruby?
If you self-host it, yes
If we use express for backend, then what’s the point of using nextjs for frontend instead of pure reactjs?
SSR for example
Why not fastify tho?
Hi Josh, why don't you use fastify instead of express?
Hi sad, instead, can you say why do you use fastify?
@@el.bromas I started because of performance, most benchmarks stated that its 3-4 times faster than express... but I ended up liking it for the ecosystem since integrating useful feature is low effort thanks to official and community plugins like autoload, oauth2, rate-limit and so on.
But tbh I don't know how the express ecosystem compares to fastify's one at the moment, I have not been using it for a while.
@@el.bromas and please, refer to me as kebab thank you uwu
@@el.bromas it's faster than express, and express hardly receives any updates
Looked into it just recently. Doesn't seem too different syntactically so I'll probably give it a good shot in the future
Hello Sir, how do you know about this can you give me a tip thankyou
so why don't you host the app yourself instead of using Vercel?
This content with comments about a real product you're building are really useful. Great!
Very happy to hear that. Thank you man
this video is about infra/host providers limits, not next js limits
yeah that is right
Then you have to deploy express apps am I right!?
how can use
nextauth with express
Documentation
the three things blurred made me angry. even if you didnt blur that I would keep listening for the reasons you know
This is only true if not using self-hosted services right?
Title: why i am using express; Him: he went on to explain server side function
Great points. Developers should always get on the hyped train. I spent a few weeks learning it and decided to stick with React/Express combination.
so, you can do it with nextjs, but you need to deploy it on different place - not vercel
nextjs != vercel
Thanks for that useful content
NestJs? Anyone?
Me... absolutely me... I have all of my projects built with Nest
@@jaroslavhuss7813I implore you to give strapiCMS a try as well 😊
@@breezycodes strapiCMS limited role
Why use nestjs for personal projects? Isnt it bloated?
@jakub3914 I know it looks that way from the outside. Once you give it a try, you will see that it takes like an hour to get your Middleware and endpoints created in vanilla Expressjs... but only minutes in nestjs. Plus they have a CLI that is awesome for scaffolding API resources etc... sockets, authorization is a breeze to setup.. things that would take hours in expressjs takes just minutes in nestjs.. btw, nestjs uses expressjs/fastify under the hood
Thank you for this insight
Use the edge! Timeout is 30 seconds and streaming time is infinite.
I don’t use the NextJS API because of modularity
Please refrain from developing an AI-powered blog generator.
Creating an AI blog generator may seem appealing, as it promises to save time and effort in content creation. However, there are several reasons to reconsider this idea.
Blogs are meant to express personal thoughts and opinions in an authentic way. By relying solely on AI, the content may lack the human touch that readers value. Human-authored blogs establish deeper connections with the audience, fostering engagement and relatability.
An AI blog generator could contribute to the proliferation of low-quality or irrelevant content. Without human oversight, the generated articles may lack accuracy, coherence, and originality. Maintaining the integrity of the blogosphere requires human judgment and expertise.
Building a successful blog involves nurturing a loyal readership and fostering a community. AI cannot respond to comments, engage in discussions, or adapt to readers' needs. Human interaction is essential for a vibrant and engaged readership.
Ethical concerns surround the use of AI in content generation. There is a risk of propagating biased or misleading information. Adhering to ethical guidelines, respecting privacy, and avoiding plagiarism requires human judgment.
In conclusion, prioritize human creativity, authenticity, and meaningful engagement in blogging. Embracing unique perspectives, insights, and interactions fosters a valuable blogging community. Avoid relying solely on AI for content generation.
🤣
Yeah next js is not for everything... people think every time a new framework is popular everyone needs to be using them.
And express is going to fix this… how?
Do you use NestJs?
did you delete my comment or is youtube doing something funny?
i cant see me previous comment anymore.
I think the best title should be “why i shouldnt use vercel”?
Why can't we use node js for this
so u mean MERN is better? I'm sorry just talking not enough so better show us an example please bro for people beginners like me I got confused bro so I'm ok with NextJS and MERN but not professional yet but now I do not know what u talking about how u use Express and where so better by tutorial so I'm on tutorial hell anyway I love it 🙂
There problem I have with nextjs is this, hosting a nextjs app on another plattform other than vercel may require you to create a custom server. This is not very good. Doing so will remove some of NextJs very important features like Automatic static optimization. So pages a no longer pre rendered and others. Meanwhile, all these features are what make NextJs this popular. I find this as a huge red flag cuz am force to stick with vercel.
josh !! what this is about
I don't understand. So you're saying use Express instead of NextJs because you can use Express with a serverless environement? Using Express still doesn't fix the issue of web sockets you were describing though. Not sure what this has to do with Express vs NextJs
Real developers use api routes, express and cms at the same time. 😎
My opinion is that I "serverless/edge" makes me confused¹ and I just want to have a client and an api, that separation is just way easier for me.
I can deploy my client on Vercel/Netlify and an api on a few dollar vps.
¹I don't have enough knowledge about serverless functions (or whatever that is, what happens when you deploy api routes to vercel) it makes me feel powerless and I want to know exactly what I'm doing. I'm also scared of limits or pricing, like getting spammed and having to pay a few thousand dollars cuz it was scaling /infinitely/, but the price of scaling is 400x higher, because Vercel.
TLDR: me dum dum, I do everything primitive, because feel safe
Real devs dont use JS in the backend. PHP all the way!!! 😎😂
@@FranzAllanSee realer devs do everything in assembly 👨💻
@@FranzAllanSee PHP is making a come back.
I guess you run out of arguments and you are making things up still my man
pm2 start npm -- start
No?
This should be titled “I’ve never actually looked into nextjs and think Vercel is the only host” 🤦♀️
You don’t need to use Vercel.
You don’t need to use serverless.
You can use websockets.
If you need to stream data you can still use sse for serverless.
Still can use next api. Just don't run on the edge
It's not about the runtime, more so the fact that I assumed NextJS to always be serverless
@@joshtriedcoding haha
Next jw serverless Just making things complicated 😔.
So you are comparing a server-based Express.js to a serverless Next.js instead of a server-based Next.js ? Hmm. 🤔 Since your channel is called 'Josh Tried Coding,' I can forgive it
are you really comparing a full blown framework with express? very bad comparison
Bro confused "deployment" with "framework". If you don't host on Vercel, you're not limited to those things. So, yeah, you could very well use Nextjs here.
I have a containerised NextJS app running on AWS App Runner, is it running serverless or is it not?
@@manchao1416 I believe it’s not serverless. To run nextjs as serverless you need to deploy it in a specific way like vercel does.
I think it's best to delete this video. It's quite misleading (not intentionally), but still.
I've actually learnt a lot on the debate that this video generated. I don't think deleting but probably responding with another short video summarizing the debate
@@matiastika1329 same
too spesific
express is dead... why use a dead better solution???
30 million downloads a week is the opposite of dead