[iamcasen]

This article isn't the best, but I'm glad it is attempting to foster a conversation about the future of JAMstack.

I've been developing with React for 10ish years now. My most recent startups have been a mixture of React front-ends that call to a variety of backend services. Most recently using Vercel and Next.js to host our frontend codebase.

One of our lead engineers setup an NX monorepo. We deploy an API to AWS and our front-end to vercel. This has honestly added so much unnecessary complexity, I really regret it. Here's the main issue as I see it:

Conflating a fullstack web application, with a decoupled UI and a standalone API.

It's the same old conversation about "microservices" and knowing where to draw the boundaries. In my experience "frontend" and "backend" are not really good boundaries.

Sometimes there needs to be a high degree of coordination between frontend and backend. In this case, they should probably be part of a fullstack deployment like Rails or Django, or my personal favorite: Remix.

Personally, I think all web applications should start out with the assumption they are a monolith. Only after the product is starting to reach maturity, and weaknesses in the monolith are revealed, should a backend api or a decoupled front-end be split off.

Vercel and Netlify (among others) try and avoid the basic necessity of databases and other backend complexities as if a front-end developer can exist in some shining, pretty land free of that yucky backend stuff.

[moojd]

> Vercel and Netlify (among others) try and avoid the basic necessity of databases and other backend complexities as if a front-end developer can exist in some shining, pretty land free of that yucky backend stuff.

They are creating the disease and selling you the cure. You see less monoliths in the node community because it's the only ecosystem where the attempting to build a monolith takes you off of the happy path. Most tools and frameworks not-so gently nudge you in the SPA + back-end-as-a-service direction and make the simple thing hard.

[lagrange77]

> You see less monoliths in the node community because it's the only ecosystem where the attempting to build a monolith takes you off of the happy path.

As i understand you guys, you're talking about the difference between writing an API server vs writing a web app, that delivers the view, instead of an API. What exactly makes one leave the happy path? Using a template language?

[moojd]

I'm not making a value judgement on rendering strategies, spa, etc. I'm arguing that for most js frameworks, building a full stack app with your own database, auth, etc without third party services is not the happy path. These are table stakes in php, ruby, and python. There are exceptions like remix. I'm just deriding a general trend.

[cosmojg]

So, would you recommend that newer startups just stick with a good old-fashioned full-stack monolith deployed on any old VPS?

[iamcasen]

Yes absolutely. I've been very impressed that Rails has managed to stay relevant all these years later.

I hope the NodeJS world can turnout something as turnkey and well-supported as Rails, but I haven't really seen it yet.

The choice of stack really just depends on the project, and the skillsets of developers in that community + the available tools in that community.

[kodisha]

Yo clearly missed all of the Next is now PHP/Rails and Next.js as PHP and Rails logo [1] memes :)

[1] https://www.reddit.com/r/nextjs/comments/139j19t/shall_we_co...

[JSavageOne]

> One of our lead engineers setup an NX monorepo. We deploy an API to AWS and our front-end to vercel.

I don't understand where the complexity is in your setup that you're unhappy with.

[iamcasen]

NX with a Nest.js backend, and Next.js front-end. These tools just aren't very nice to jam together into a fullstack app. I'm really not a fan of NX itself. Lots of people love it, but I think it's way too much for most use-cases.

Furthermore, in our case, the front-end and backend are really coupled, so having these as separate systems is just a big headache. All of the web app's views are tied into specific backend functionality, and our API doesn't really stand on it's own without the front-end.

Yes this is poor architecture. I'm just pointing out a case where JAMStack was a mistake. Rails (or similar) would have been a smarter choice.

[JSavageOne]

Ok I've never used Rails, but personally I've enjoyed my experience with a monorepo (pnpm workspaces) consisting of a Node.js API server and Next.js frontend server. You could try doing everything in Next.js, but I prefer keeping my backend separate. Love having everything in a monorepo though.

If you want more coupling, perhaps you could try something like ts-rest to add API types to your frontend. Or if you're feeling more adventurous, GraphQL or tRPC, though I personally prefer to avoid being tied to overly experimental frameworks.

[iamcasen]

Thanks! Yes, pnpm workspaces and turborepo are both far superior to NX IMO. They hit that sweet spot of providing the nice aspects of a monorepo without all the nightmarish configurations and complexities.

Next.js has saddened me since the move to SSR. I think remix is light-years ahead to be honest.

I will give ts-rest a look-see.

[redact207]

Sounds like your lead engineer setup NX too soon. we made it about 5 years in to our monorepo before having to use tools like that. Once we were at a point where our codebase included multiple products, apis, frontends was when build and test times became unbearably slow and only then did we add NX to conditionally build changes and their dependants. I wouldn't recommend starting a new project with it by any means.

[iamcasen]

Agreed. I think NX is a big powerhouse of a tool that should only be used in mature engineering orgs with complex codebases and deployments. A seed-stage company is not the right fit.

[zengid]

>> Personally, I think all web applications should start out with the assumption they are a monolith.

By 'monolith' are you still talking about a Rails/Django/Remix/(Next.js?) app? (Or ASP.NET for my dotnet homies out there).

[tacker2000]

There are lots of ways to build a monolith that runs great and needs little maintenance and has only a few moving parts. See PHP with Symfony or Laravel for example…