Do I need a backend framework with Next JS?

Verifying webhook headers like from Stripe or Slack require some changes like disabling their inbuilt body parser.

You might face is with finding tutorials for certain things like Websockets which are a bit different in next js api routes as opposed to express.

I'm using Next.js for my SaaS at https://emojiresponse.com and I'll be honest, I've been having some weird issues that I just never had when using an Express API service previously.

I'm going all in on the Vercel stack — Next Auth, SWR, NextJs, and Vercel hosting, and there's so many weird issues with session handling, certain API endpoints taking ~5s for small queries, sporadic 500 errors caused by getServerSideProps, etc.

All frameworks come with problems, so I'm not necessarily expecting perfection or anything. But I may decide to move to a proper backend service if stability & performance becomes a problem at scale.

Eventually, yes.

I find that backend frameworks often have a lot of functionality backed-in and solve a lot of future problems.

You can think of it as Django vs Flask. Sure, Flask is easy and simple. But, Django is opinionated to help you write better code and has everything you need—databases, authentication, scaffolding, testing, versioning, large communities, and more. Why reinvent the wheel?

I currently use NestJS and am playing around with KeystoneJS—I find being able to avoid context switching between languages and sharing code between the frontend and backend to be beneficial.

With some finagling, you can still put just about everything on a Lambda function with serverless anyway. I, personally, am hesitant to be locked into the Vercel hosting platform too.

Not really.

I have been working with it for over a year now and so far I have noticed absolutely 0 drawbacks or limitations as compared to a standard Express app.
Middlewares were probably the only one I thought it lacked but it is supported now.

If you host on Next.js on Vercel then it is even more amazing(if you are into the serverless architecture).

Regarding the SEO benefits, make sure your site is rendered on the server side.

Moreover soon we'll also have server-side React component loading too so the website will be shipped with no JS(AFAIK I understand it).

But as with all projects, choosing the right framework initially can save you from a lot of headaches down the line.

Feel free to drop any questions you may have.

I'm using Next.js for https://www.swipewell.app and using API routes as the backend for the web app, a WIP mobile app, and a chrome extension. For most basic operations, API routes work really well.

I've run into several limitations, like not being able to use puppeteer because of the max lambda size limit. There are tradeoffs between serverless and other backend architectures. That being said, there are plenty of companies building complex products using serverless, so it's absolutely possible.

I think for most micro-saas products, it'll work great.

I think POCs, MVPs and small projects it is definitely worth it but I would go the classical Express or NestJS way for building stable versions of SaaS.
I have always been a fan of seperation of concerns, modularity and stuff and I felt like mixing your backend in your Next project breaks a lot of this.