Hacker News Reader

Comment by dfee | Hacker News Reader

On the NodeJS / React ecosystem - no one really wants you to do monoliths.

NextJS, for example, doesn’t let you manage service lifecycle methods (unless you write a custom server - which they explicitly warn you against). NextJS wants to be special, that’s dumb and it sucks (well, in the context of using it to drive your SaaS platform, it’s pretty smart).

Remix, for example, wants to control your client/server API calls, so you’re hard pressed to use other tools like GraphQL, and incur the risk for growing into microservices if you need it. Same story as NextJS about being special and probably driving SaaS platform sales.

Amazon just makes you manage an alphabet soup worth of products, which are all pretty expensive - unless you want to just lambda it… meaning custom runtimes and … back to microservices.

Point: microservices aren’t just driven by your org anymore, they’re pushed by vendors.

View on HN

Hey, Lee from Vercel. I lead the Next.js community. We do encourage folks to use monoliths, if they'd like! That's partially why we believe in Turborepo so much (happy to share more on that if you'd like).

Are there specific lifecycle methods you want to tap into with Next.js? Open to feedback there. The reason the "custom server" is not recommended (it's poorly named, I'd argue it's an "ejected server") is because the main use cases folks were ejecting for have since been merged into Next.js core (like internationalization).

Hey Lee – imagine that I've got a database I need to initialize on startup / teardown on shutdown. Where can I do this? It's inherently an async concept. There are no hooks.

The docs for Custom Servers [0] begin with a bunch of language and warnings strongly encouraging you to forego this route. The consequence? I don't know – it feels like it's not maintained, and maybe won't be there between major versions.

[0] https://nextjs.org/docs/advanced-features/custom-server

What are you looking to do on server start and shutdown?

Isn't an average next app pretty much a monolith? It gets split into lambdas when you deploy it, but the development experience feels monolithic to me.

If I want to use some function, I often just import it and call it directly, instead of calling one serverless function from another over http. That means the function gets bundled into a few lambdas, but so far, I've had no issues with that. The monolith abstraction hasn't really leaked for me.

I'm all for a monorepo – or to a lesser degree, utility functions that are re-usable across components. That's not what I'm talking about.

Running NextJS as a handful of lambdas is fine, but you still likely need to initialize other services in the background (like databases)... otherwise you have a monolithic front-end... as in: "my monolithic front end talks to my monolithic back end, so I really have two micro/macro services", and maybe I should investigate breaking the FE/BE down into smaller components".

sure, you can use pgbouncer, etc. but it becomes sorta cost prohibitive to run a few apps.

Monolith + a database, that's always implied, isn't it?

How you make the database connection work with serverless connection requirements seems like a minor issue. I haven't used it but it seems like next + prisma (+ tailwind lol) is the default stack of tutorial writers these days.

"How you make the database connection work with serverless connection requirements seems like a minor issue."

It's really not. See... databases like PostgreSQL aren't designed for an infinite number of simultaneous connections (doing things like, checking for a logged in user, and auth). This is where something like pgbouncer comes in – that at least takes care of transaction boundaries – because we're a monolith, remember?

Now you're also setting up the state of your application as global variables. Seems like a pretty poor choice, and now you also need to figure out the gotchas with HMR here.

Let's not even get into the fact that a lot of code isn't meant to be (or cannot be) bundled by webpack. So now you're resorting to a custom Webpack config to exclude certain modules. [0]

On AWS, pgbouncer is called "RDS Proxy" and runs you $11.16/mo. [1]

That's not even getting into the cognitive overhead of just "rolling out an app over a weekend" now being a weekend adventure in and of itself – again managing an alphabet soup of services either all within AWS or between AWS and Vercel.

[0] https://nextjs.org/docs/api-reference/next.config.js/custom-...

[1] https://aws.amazon.com/rds/proxy/pricing/?nc=sn&loc=3

NextJS is an elaborate advertisement for Vercel's "serverless" cloud. I really can't feel sorry for anyone at this point that gets suckered into their sham. As a framework, it's also going to force you into a specific pattern.

Skip Next and go straight for Express. NextJS does nothing useful that you can't easily do yourself, and only makes life difficult down the road.

> they’re pushed by vendors

yes, Apollo with GraphQL, Vercel, etc. It's a huge cottage industry. But this is how IT has always worked. Just look at some of the garbage Oracle and IBM have been pushing since the '80s. If your org is falling for a slick sales pitch or the latest Google cargo cult, then that's on them. If you're in IT, then it's your responsibility to educate the execs on what they actually need. If they would rather listen to the sales guy over at Oracle than you (often likely), then it's time to move on.

Hey, Lee from Vercel – I lead the Next.js community and am focused on making sure Next.js works great self-hosted (e.g. Node.js server, Docker app, etc) with support for all features. I've written docs[1] about it as well as made videos[2]. Open to any feedback you have on how we could make this more clear!

[1]: https://nextjs.org/docs/deployment#self-hosting

[2]: https://www.youtube.com/watch?v=Pd2tVxhFnO4

Yes, corporate-funded OSS has a way to make things work well on their paid product.

But Next.js is also just a well-built framework that won some hearts and minds because it's ...a good framework, not because of some extremely slick salespeople.

And if being a technical contrarian is interesting, you can always use it with one of Vercel's biggest competitors: https://www.netlify.com/with/nextjs/

I'm not a huge fan of Next and/or vercel. I'm in particular pissed off by the shady "call home metrics" thing they intentionally make it difficult to disable.

But suggesting that you can use express instead of Next, to me, is a clear indication you have absolutely no idea what Next is.

Remix seems to be a counter-example. The jokes app tutorial [1] is as monolithic as they come.

[1]: https://remix.run/docs/en/v1/tutorials/jokes

Monolithic – yes. However, my concerns with Remix are that it intentionally doesn't align well with the premise of GraphQL – for better or worse. However, that's a very common pattern when you do need microservices.

I.e. Remix doesn't have a good story for off-boarding from a monolith – so it's inherently risky to build on top of.

GraphQL really isn't that hard, and if I'm going to build an API anyway, why not just start with a piece that's going to eliminate the endless refactoring of data-stitching when the needs of my pages (or underlying components) change?

Reply on news.ycombinator.com