5 ms·

I'm sure everyone's mileage will vary based on experience / comfort with the particular stack here... but in my experience shipping a monolith (Python, Ruby, wh

I'm sure everyone's mileage will vary based on experience / comfort with the particular stack here... but in my experience shipping a monolith (Python, Ruby, whatever) to a VPS is vastly simpler than a comparable Next/Vercel setup, especially for a CRUD app as the OP is talking about. Dealing with the details of things like SSR vs client side, Apollo caching (cuz w/ Next you are _probably gonna go w/ GQL, and so you probably use Apollo), and monitoring/observability in the Next/Vercel world is hard. You don't have these problems with a simple monolith, and you can sprinkle in your front end magic with whatever lean JS approach you want as you need it. And to be fair Vercel has some logging and datadog integration, but it is very limited compared to what you can get and can configure as-needed with real agent based monitoring. I'm increasingly feeling like the 'benefits' of server-side rendering in all its flavors for the big JS frameworks are just a boondoggle and not worth the complexity and cost for _most_ apps, even ones where the cost of an SPA are worth it.

criley2 4y ago
- SSR vs client side: NextJs does this automatically. https://nextjs.org/docs/basic-features/pages https://nextjs.org/docs/basic-features/pages - GQL: the only case where I'd use GQL is where he would likely want to too: building native mobile apps. Otherwise, I'd use tRPC and have fullstack type safety. This is included in my 5 minute estimate because I'd use create t3 app, which has this configured out of the box https://trpc.io/ https://trpc.io/ https://github.com/t3-oss/create-t3-app https://github.com/t3-oss/create-t3-app - monitoring/observability: not quite sure what you mean, but it's only a few clicks in vercel to have a logdrain or metric drain and configure alerts and dashboards in your tool of choice. And if I wanted to roll the whole thing myself... that's what he did. Rolled it all custom by hand. The difference is I have the option of not reinventing the wheel. At the end of the day I can get into composing a docker image that is configured just like his prod servers if I need that access, and there's likely already a docker image pre-done that has 99% of what I need, including metrics/monitoring. At which point I could launch my service on any number of hosts that allow direct pushing of built docker images, if my build process goes there. To each their own, but I think my solution requires far less time to setup and maintain, but costs more, as I said. Manually engineering each system yourself might be fun to you, but it's not to me.
- rsanheim 4y ago
  > SSR vs client side: NextJs does this automatically. https://nextjs.org/docs/basic-features/pages https://nextjs.org/docs/basic-features/pages Uh-huh. Do some simple stackoverflow searches for how to configure a real Next/Vercel app with error-handling, passing thru cookie/session state, or how to wire up third party services or components. Or check out next.js issue search for "window undefined" - https://github.com/vercel/next.js/search?q=window+undefined&type=issues https://github.com/vercel/next.js/search?q=window+undefined&... -> 1667 issues right now. Even if you discount 3/4 of those as duplicates, developer error, etc, you have a ton of issues where figuring out server vs client state is confusing for many folks. It sounds like has worked great for you out of the box, which is great! But that isn't the case for many other developers. This is not my definition of "automatic". > I'd use tRPC This looks pretty compelling if you are all-in with TS everywhere, including your server/data access layer. Which doesn't apply in the OP's post, since it's a traditional CRUD app with python in front of good ole' PSQL DB. > monitoring/observability: not quite sure what you mean, but it's only a few clicks in vercel to have a logdrain or metric drain We are using Vercel routing its logs to datadog right now. It works fine but is extremely limited. Want to wire up full-stack transactions w/ the rest of your app, or modify _what_ it logs? Good luck. Also, trying to use a real APM (Datadog, Scout, open source, whatever) is a complete non-starter. You need a persistent process running somewhere to take the data, buffer, and transport it _somewhere_, and so far you can't do that with Vercel's custom server support. You _can_ do this with just NextJS (no vercel), but it requires some frightening hacks I would not be comfortable adding to apps I maintain: https://jake.tl/notes/2021-04-04-nextjs-preload-hack https://jake.tl/notes/2021-04-04-nextjs-preload-hack. I get that Vercel provides a very quick setup and a smooth dev experience, especially if you are in their sweet spot of something like a static site or blog engine. It just seems more trouble than its worth for most CRUD apps, especially anything that isn't 100% in the javascript/typescript world.
  - criley2 4y ago
    I don't think that the prescence of stack overflow questions is a bad thing, quite the opposite, that demonstrates that there is a community and you'll likely find every answer to each problem you have Comparing that to a completely bespoke web app you stitiched together with various things you've liked over the years... I bet there are very few stack overflow questions that cover his stack. To me, that's a very bad thing. The fact that you can quickly list out shortcomings in nextjs but not his bespoke stack demonstrates how much bigger the community is and how many more people are working on those problems. I prefer known problems to unknown problems, personally. >This is not my definition of "automatic". And a completely bespoke app is? Come on. Obviously a framework backed by thousands of apps, tens of thousands of developers and contributors, and multiple corporations, is going to be more automatic than "this bespoke thing I made". >I get that Vercel provides a very quick setup and a smooth dev experience, especially if you are in their sweet spot of something like a static site or blog engine. It just seems more trouble than its worth for most CRUD apps, especially anything that isn't 100% in the javascript/typescript world. I just can't disagree more. I do agree that as a web app grows in complexity you can outgrow Vercel -- but I'd MUCH rather be in the position of spending a few minutes pointing my repo at one of the dozen other services that scale with complex webapps better, or composing a simple docker setup and pushing that. The alternative of having some bespoke app on a VPS... you're looking at a total rewrite to scale, imo. That bespoke app has a hard ceiling. That or you just keep stitching new stuff to the side of your frankenapp. Meanwhile Netflix, Hulu, Twitch, Uber, Nike, McDonalds, Apple and many others are launching massive scale web apps on nextjs, demonstrating that the technology is primarily for interactive full stack react web apps. The idea of using nextjs and launching a full react app for your static site sounds very over-engineered. Just do something on Github Pages or Jekyll. I would go the exact opposite as you: playing around with your bespoke stack on a VPS is great for a static site or a very simple app, but the second you have any complexity at all, any real business logic, any real work being done... your bespoke app will turn into a nightmare, and nextjs is proven around the industry to do just fine!
ajgrover 4y ago
I definitely agree that there’s less magic going on with a traditional style deployment, but I think you’re strawmanning Next a bit with this comment. Not everyone uses graphql, and a vanilla Next API route is similar in complexity to a vanilla node http server. For a basic CRUD app, especially for a solo dev, the monitoring story on Vercel is sufficient and it’s hard to say that their single repo push to deploy setup is more complex than the traditional alternatives.

criley2 4y ago

- SSR vs client side: NextJs does this automatically. https://nextjs.org/docs/basic-features/pages https://nextjs.org/docs/basic-features/pages - GQL: the only case where I'd use GQL is where he would likely want to too: building native mobile apps. Otherwise, I'd use tRPC and have fullstack type safety. This is included in my 5 minute estimate because I'd use create t3 app, which has this configured out of the box https://trpc.io/ https://trpc.io/ https://github.com/t3-oss/create-t3-app https://github.com/t3-oss/create-t3-app - monitoring/observability: not quite sure what you mean, but it's only a few clicks in vercel to have a logdrain or metric drain and configure alerts and dashboards in your tool of choice. And if I wanted to roll the whole thing myself... that's what he did. Rolled it all custom by hand. The difference is I have the option of not reinventing the wheel. At the end of the day I can get into composing a docker image that is configured just like his prod servers if I need that access, and there's likely already a docker image pre-done that has 99% of what I need, including metrics/monitoring. At which point I could launch my service on any number of hosts that allow direct pushing of built docker images, if my build process goes there. To each their own, but I think my solution requires far less time to setup and maintain, but costs more, as I said. Manually engineering each system yourself might be fun to you, but it's not to me.

rsanheim 4y ago
> SSR vs client side: NextJs does this automatically. https://nextjs.org/docs/basic-features/pages https://nextjs.org/docs/basic-features/pages Uh-huh. Do some simple stackoverflow searches for how to configure a real Next/Vercel app with error-handling, passing thru cookie/session state, or how to wire up third party services or components. Or check out next.js issue search for "window undefined" - https://github.com/vercel/next.js/search?q=window+undefined&type=issues https://github.com/vercel/next.js/search?q=window+undefined&... -> 1667 issues right now. Even if you discount 3/4 of those as duplicates, developer error, etc, you have a ton of issues where figuring out server vs client state is confusing for many folks. It sounds like has worked great for you out of the box, which is great! But that isn't the case for many other developers. This is not my definition of "automatic". > I'd use tRPC This looks pretty compelling if you are all-in with TS everywhere, including your server/data access layer. Which doesn't apply in the OP's post, since it's a traditional CRUD app with python in front of good ole' PSQL DB. > monitoring/observability: not quite sure what you mean, but it's only a few clicks in vercel to have a logdrain or metric drain We are using Vercel routing its logs to datadog right now. It works fine but is extremely limited. Want to wire up full-stack transactions w/ the rest of your app, or modify _what_ it logs? Good luck. Also, trying to use a real APM (Datadog, Scout, open source, whatever) is a complete non-starter. You need a persistent process running somewhere to take the data, buffer, and transport it _somewhere_, and so far you can't do that with Vercel's custom server support. You _can_ do this with just NextJS (no vercel), but it requires some frightening hacks I would not be comfortable adding to apps I maintain: https://jake.tl/notes/2021-04-04-nextjs-preload-hack https://jake.tl/notes/2021-04-04-nextjs-preload-hack. I get that Vercel provides a very quick setup and a smooth dev experience, especially if you are in their sweet spot of something like a static site or blog engine. It just seems more trouble than its worth for most CRUD apps, especially anything that isn't 100% in the javascript/typescript world.
- criley2 4y ago
  I don't think that the prescence of stack overflow questions is a bad thing, quite the opposite, that demonstrates that there is a community and you'll likely find every answer to each problem you have Comparing that to a completely bespoke web app you stitiched together with various things you've liked over the years... I bet there are very few stack overflow questions that cover his stack. To me, that's a very bad thing. The fact that you can quickly list out shortcomings in nextjs but not his bespoke stack demonstrates how much bigger the community is and how many more people are working on those problems. I prefer known problems to unknown problems, personally. >This is not my definition of "automatic". And a completely bespoke app is? Come on. Obviously a framework backed by thousands of apps, tens of thousands of developers and contributors, and multiple corporations, is going to be more automatic than "this bespoke thing I made". >I get that Vercel provides a very quick setup and a smooth dev experience, especially if you are in their sweet spot of something like a static site or blog engine. It just seems more trouble than its worth for most CRUD apps, especially anything that isn't 100% in the javascript/typescript world. I just can't disagree more. I do agree that as a web app grows in complexity you can outgrow Vercel -- but I'd MUCH rather be in the position of spending a few minutes pointing my repo at one of the dozen other services that scale with complex webapps better, or composing a simple docker setup and pushing that. The alternative of having some bespoke app on a VPS... you're looking at a total rewrite to scale, imo. That bespoke app has a hard ceiling. That or you just keep stitching new stuff to the side of your frankenapp. Meanwhile Netflix, Hulu, Twitch, Uber, Nike, McDonalds, Apple and many others are launching massive scale web apps on nextjs, demonstrating that the technology is primarily for interactive full stack react web apps. The idea of using nextjs and launching a full react app for your static site sounds very over-engineered. Just do something on Github Pages or Jekyll. I would go the exact opposite as you: playing around with your bespoke stack on a VPS is great for a static site or a very simple app, but the second you have any complexity at all, any real business logic, any real work being done... your bespoke app will turn into a nightmare, and nextjs is proven around the industry to do just fine!

ajgrover 4y ago

I definitely agree that there’s less magic going on with a traditional style deployment, but I think you’re strawmanning Next a bit with this comment. Not everyone uses graphql, and a vanilla Next API route is similar in complexity to a vanilla node http server. For a basic CRUD app, especially for a solo dev, the monitoring story on Vercel is sufficient and it’s hard to say that their single repo push to deploy setup is more complex than the traditional alternatives.