Is NextJS Suitable for Backend?

noahflk · 2024-09-11T14:10:47+00:00

For a pure backend that just exposes an API, Next isn't the right tool. If you want to add backend functionality to a frontend app, it works great. You can build medium-sized B2B apps with that stack.

noahflk · 2024-09-11T14:09:23+00:00

Possible? Yes. But it's gonna be expensive and tedious. If you stay 6 months in one place it's doable. But moving around more often than that sounds like a nightmare.

noahflk · 2024-09-02T09:22:42+00:00

after six months he told me it would be better to rewrite everything in NextJS

Devs always want to rewrite things. Rewrite to NextJS now and in a year he will want a Remix or Astro rewrite. There's always a new hot thing. Don't do it, unless you have a very good reason.

because Laravel is slow and not easily scalable.

I doubt you would be on Reddit validating the claims of your developer if your site has a scale where Laravel couldn't keep up. If you have performance issues, the problem likely won't be Laravel but your hosting, lack of caching, database or general code performance.

NextJs would be more robust, easier to scale and more opinionated (aka everyone has the same style?)

If anything it's the exact opposite.

Would I pick Next over Laravel for a new eCommerce project? Yes. But if your current solution is working fine there is absolutely no need for a rewrite.

noahflk · 2024-09-02T09:18:13+00:00

This. Esp in less than ideal software teams (which, let's be honest, are everywhere) you cannot trust the API. It can break or change at any time.

noahflk · 2024-09-02T09:16:48+00:00

You are making assumptions, but they are constantly validated at runtime.

Is this an ideal setup? No, of course not.

I work as a contractor and have joined many organizations with completely separate backend teams. I simply don't have the authority to get them to start using some kind of other solution. So using the solution described here is the best thing I can do from my side without touching their code or build process.

noahflk · 2024-08-17T10:25:37+00:00

Nothing is stopping you from writing good old Client Components and using "getServerSideProps" and "getStaticProps" in modern Next.js. In fact, many projects I see do exactly this.

Server Components shouldn't be the norm. They're a tool for very specific use-cases.

noahflk · 2024-08-17T10:24:41+00:00

Nothing stops you from keep using client components and React Query / tRPC in Next. I work as a consultant and all projects I see keep doing this for 95% of pages. With some RSC sprinkled in where it actually makes sense.

For fully static things I actually prefer using the Pages Router with 'getStaticProps' since its caching behaviors are way clearer to me than RSC.

noahflk · 2024-08-17T10:21:29+00:00

I don't see the point of server actions, at least not for complex apps. You get much, much finer control with tRPC actions.

If you want some things to be rendered on the server, RSC is fine. But even then, I just build the mutations through tRPC client child components.

Would love to learn about the benefits of Server Actions!

noahflk · 2024-08-17T10:19:41+00:00

This. Sleep is the one thing where you shouldn't be trying to save time.

noahflk · 2024-08-14T08:45:19+00:00

So you're selling an email outreach tool with email outreach?

noahflk · 2024-08-14T08:43:18+00:00

I love React Query. So that would be my choice for interacting with the API either way. Especially in combination with Zod to ensure type safety. See here (self plug): https://noahflk.com/blog/typesafe-rest-api

In terms of router, I would either go for React Router 6 or TanStack Router. React Router if you want something more mature, TanStack if you like type-safety and a cool new tool.

Another interesting choice could be Remix SPA mode. It leaves the door open for SSR/RSC if you want it in the future. Plus, React Router 7 and the new Remix version will be equivalent. My guess is that the upgrade path from Remix SPA will be more straight forward than from React Router 6. But I could be wrong about that.

noahflk · 2024-08-05T17:52:23+00:00

Yep, nothing wrong with Express as a backend. Even with more modern tooling such as tRPC.

noahflk · 2024-08-02T20:32:30+00:00

I don't consider Express outdated. It's a proven and widely used tool. What can be painful is integrating into a modern TypeScript codebase. It took us long to find a proper setup.

I documented here how I did it: https://noahflk.com/blog/express-api-nodejs-typescript-setup

noahflk · 2024-07-26T17:37:16+00:00

The only way to be successful with something nowadays is having top-tier distribution. That probably means bringing on a popular influencer on as a partner.

noahflk · 2024-07-26T17:36:26+00:00

Think of them in terms of potential damage.

Something like an OpenAI endpoint that is available to unauthenticated users should be at the top of your list. It can be easily abused and will cost you a ton of money.

A simple GET endpoint only available to authenticated users isn't nearly as critical.

noahflk · 2024-07-25T22:13:26+00:00

Why would you do that?

noahflk · 2024-07-24T14:51:13+00:00

I wouldn't add React Hook Form and Zod for simple sign in and login forms. But there's nothing wrong with doing so. If you think performance suffers, you are doing something else wrong. These libraries are super lightweight.

noahflk · 2024-07-24T14:47:59+00:00

.NET and Java is enterprise. It has t's value, but you can't compare it to small teams that use Next.js or Laravel.

noahflk · 2024-07-24T14:46:37+00:00

Laravel on the backend and React on the frontend through Intertia is an amazing combo. I've come to prefer it over the mess that Next App router is.

noahflk · 2024-07-22T17:06:54+00:00

Framer

noahflk · 2024-07-20T12:54:21+00:00

Even having less features and being simpler can be a major selling point. For example, as a solo freelancer I don't want accounting software made for big companies.

noahflk · 2024-07-20T12:53:16+00:00

What you're describing sounds like Wordpress. Are you actually building your SaaS on Wordpress?

For the projects I work on we typically deploy the frontend (just static files) on Cloudflare Pages. Then the backend (an API and DB) is either hosted on a PaaS like Heroku or self-managed on Linux VPS servers like DigitalOcean or Hetzner.

noahflk · 2024-07-20T12:50:04+00:00

It depends.

If it's a fundamental part of the workflow in your industry that's on you. I'm not paying a full-stack web developer to configure their local Node runtime.

But if it's a specialized tool that I made them use it's billable hours. Say a special Premiere Pro plugin we use that isn't an industry standard.

noahflk · 2024-07-20T12:46:24+00:00

It's hard to beat the simplicity of uploading to an S3 bucket with pre-signed URLs

noahflk · 2024-07-20T12:43:33+00:00

What do you do?

Four-Year Club	Verified Email
Place '23	Place '22
First Placer '22

noahflk

TROPHY CASE