Next.js API (The FullStack)

Why Nextjs

I have been listening to bunch of videos/streams for big chads like ThePrimeAgen and TheoT3(the big yapper in town) getting around React, theo always supporting the conceptual base of why react team did the thing, while theprime consistenly on react-sucks-btw side.

I LOVE having both front and back logic separated anyway (but I also love what gets things done quick & safe for me without involving my feelings too much). But hear me out there is so much going on back and forth between the regular (separated) front and back teams. the front guy request minor modifications on some endpoint on 3AM random Tuesday and the back guy is like "I can't do that, I'm on a lunch break, I'll do it later". I am not a big fan of this kind of situation, but it is what it is. I have been trying to find a way to make this situation better, it is not easy. I will share my experience with you in this blog post.

Vercel came up with Vercel Functions where you can write your code in a serverless way, and it will be deployed to a cloud provider (AWS, GCP, Azure, etc) and you can call it from your front end. Vercel also has a Vercel Edge Functions which is a bit different, it is a function that is deployed on the edge of the internet, so it is faster and cheaper than a normal function. I will talk about Vercel Functions in another blog post.

But the main thing to note is that they also made Next.js, a mainly-backend-designed-in-my-opinion framework that declares it is full stack. well, it IS fullstack let us go thru how.

The Usuals

we can start with the usuals (app routing, layouts, streaming, SEO), just keep in mind some things: - the (app) dir hasRSC components onlywhere each child dir is a route segment itself (file-system based routing)

with the ability to do dynamic routes (like`/posts/[postSlugID]`) too- The React team got something nice (Suspense), which btw is not for showing some loadingSkeleton until some data is fetched (well not that simple)

I like to think of it that way → managing stale content while fresh content is loading and Preventing already revealed content from hiding- One more usual thing to follow is to always have as a front dev (really gonna love this one)react-queryin your project, OK uidotdev and theo talked about it thought well enough. it is pretty cool.

Now we go slightely edger with (middleware, api routes, auth, etc), of course we have been talking about the app-dir based nextjs app (better than the old stinky pages dir and ALOT flexible & maintainable). now we have the option to modify the request made to the backend endpoints before actually processing it. we can do this by using the api folder inside app router, assume purposes like middlewares, auth, defining and redefining some schema.

Just look at this, it is a beautiful way to have both front and back logic in one place handled and separated in the same time.

Source Code

NextJs /api suitable for serious back-end projects?

There absolutely isn’t enough information at all to answer that question. And the answer has nothing to do with Next itself. Next “/api” are justserverless lambda functions.The question is if you need a long running server or if serverless functions work better. To answer that there’s like hundreds of questions. “Backend heavy” doesn’t mean anything. What type of database are you using and how are you connecting to it? Are your backend functions doing a lot of computation? How are you handling longer running computation? Do you need to have long running connections to the client?

Even after all that, is the cost of serverless going to be an issue? If you’re using serverfull, how much will it cost to maintain the servers (do you have the bandwidth or budget for a person to manage it?)

This is just so debatable, but let me tell you about tRPC and how NICE to have integrated your backend with (like create.t3.gg is doing under the hood)best dx i ever had with nextjs. ok so what exactly is tRPC? well your back and front are in the same project codebase, tRPC is what glues them together. if something wrong with your front, you got a type-safe api that is easy to maintain and easy to use.

that is why it has so much tech shit going on and the debate will remain forever instead of just being settled for a traditional REST api documented on swagger and here you go html buddies. (this is very good too but we talking non-legacy tech here)