5 ms·

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 wa

by kall 4y ago

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.

dfee 4y ago
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.
- kall 4y ago
  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.
  - dfee 4y ago
    "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-webpack-config https://nextjs.org/docs/api-reference/next.config.js/custom-... [1] https://aws.amazon.com/rds/proxy/pricing/?nc=sn&loc=3 https://aws.amazon.com/rds/proxy/pricing/?nc=sn&loc=3

by kall 4y ago

dfee 4y ago

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.

kall 4y ago
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.
- dfee 4y ago
  "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-webpack-config https://nextjs.org/docs/api-reference/next.config.js/custom-... [1] https://aws.amazon.com/rds/proxy/pricing/?nc=sn&loc=3 https://aws.amazon.com/rds/proxy/pricing/?nc=sn&loc=3