4 ms·

It's a lot more work than say Next.js and Vercel, but I suppose it costs a lot less to maintain in cash (trading cash for time).

iLoveOncall 4y ago
It does not look like a lot of work at all? A few days of initial setup and that's it.
- criley2 4y ago
  I can go from a blank folder to deploying a git hosted next.js app on vercel in about 5 minutes, so comparatively, it is to me.
  - matsemann 4y ago
    Quite weird to compare infrastructure of a static frontend to a backend with db and stuff?
    - reducesuffering 4y ago
      Quite weird to rebuke the assessment with an objectively wrong statement. Next.js isn't a static frontend. You can statically generate pages w/ or w/o a DB, and server side render dynamically. A DB is literally 3 clicks and a secret string away (starting for free) with Planetscale or Railway. I've setup Django + Postgres on a VPS and Next on Vercel w/ hosted DB. Next is leagues simpler and faster to spin up. Here's Django Postgres on Digital Ocean: https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-22-04 https://www.digitalocean.com/community/tutorials/how-to-set-... Next on Vercel is: 1. npx create-next-app 2. Click button for DB spinup 3. Copy secret string to .env 4. git push
      - cutler 4y ago
        Comparing Digital Ocean to Vercel is apples to oranges. One is an app platform, the other isn't.
        reducesuffering 4y ago
        My comment is on a thread debating the speed-to-deliver and complexity of this traditional VPS Python deployment vs. other options. For many people on Hacker News trying to deliver a product fast, that's very relevant.
        matsemann 4y ago
        Except that the time it takes to set up the project is negligible compared to actually developing it. So if it takes you 5 minutes and me 5 hours to have a new project up & running, that doesn't really matter in the end.
        reducesuffering 4y ago
        I’ve done a 1 month MVP on each of these stacks, it’s not just the initial deployment. React is better integrated in Next, and you can get more done faster and simpler. DRF has poor async and is not an ergonomic practice in 2022, Flask requires lots else to build and maintain with weaker integration / community, and if you’re arguing why HTML templates are just as good, well, Fortune 500 and every HN startup has left it behind for good reason.
        matsemann 4y ago
        In one instance you're talking about "HNers making a quick product", and the other you're talking about fortune500s. Two vastly different things with different needs. I'm also not arguing about the specific tech. It's irrelevant. If I know tech X, choosing tech Y because it's hipper or "faster to set up" helps nothing if it's slower because it's unknown to me.
        criley2 4y ago
    - criley2 4y ago
      >Quite weird to compare infrastructure of a static frontend to a backend with db and stuff? I suppose you don't know what you're talking about, but Next.js is a backend and frontend supporting a wide variety of data sources. I personally like using Prisma and postgres with my Next.Js deployments. I'm literally rolling out a full stack database connected react app in minutes that includes a full functional API that can be accessed by a variety of clients.
      - matsemann 4y ago
        But then you suddenly have complexity again. In your various comments here you're talking about ten different tools and concepts being woven together. It's only fast for you because you've done it before. Not inherently faster than OP's approach. Like, I can spin up a k8s cluster faster than I can even understand what parts of Nextjs I should use. Doesn't mean that me selecting k8s is the best choice for all problems.
      - criley2 4y ago
        What are you talking about? That's not complexity, those are out of the box features that come with a single script run (create next app or create t3 app) Vercel will even launch that for you without a script, just a button click. Five minutes to launch with my preferred stack, though. And if we're really racing, Railway.app can spin up deployments AND databases in under 60 seconds. If I tried a speed run, I could get the time down. If OP can hand configure a python app running on ngnix in manually managed DO droplets in 5 minutes... good on them! The greatest devops of our era. Also -- I guarantee that a newbie developer can launch a nextjs app faster than hand rolling some DO droplet with python and other technologies. I guarantee I can have a newbie in a bootcamp with a working app on day1 (since it's literally a button click, if we want), while I doubt you could get that newbie out of a bootcamp on his stack at all.
        matsemann 4y ago
        Why so hostile in your comments? It's not a competition about being the fastest. If anything, it only shows immaturity on your part. Time spent setting up a project is negligible compared to other things surrounding it. You're anyways missing my point. Nextjs isn't a silver bullet, nothing is. And that how long it takes to set up a project is a function of familiarity with the stack. Edit: thanks for deleting all your personal attacks on me. But also remember, I'm not the one claiming to know everything here (as you wrote in your now deleted post), you're the one that critiqued OP.
rsanheim 4y ago
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.

iLoveOncall 4y ago

It does not look like a lot of work at all? A few days of initial setup and that's it.

criley2 4y ago
I can go from a blank folder to deploying a git hosted next.js app on vercel in about 5 minutes, so comparatively, it is to me.
- matsemann 4y ago
  Quite weird to compare infrastructure of a static frontend to a backend with db and stuff?
  - reducesuffering 4y ago
    Quite weird to rebuke the assessment with an objectively wrong statement. Next.js isn't a static frontend. You can statically generate pages w/ or w/o a DB, and server side render dynamically. A DB is literally 3 clicks and a secret string away (starting for free) with Planetscale or Railway. I've setup Django + Postgres on a VPS and Next on Vercel w/ hosted DB. Next is leagues simpler and faster to spin up. Here's Django Postgres on Digital Ocean: https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-22-04 https://www.digitalocean.com/community/tutorials/how-to-set-... Next on Vercel is: 1. npx create-next-app 2. Click button for DB spinup 3. Copy secret string to .env 4. git push
    - cutler 4y ago
      Comparing Digital Ocean to Vercel is apples to oranges. One is an app platform, the other isn't.
      - reducesuffering 4y ago
        My comment is on a thread debating the speed-to-deliver and complexity of this traditional VPS Python deployment vs. other options. For many people on Hacker News trying to deliver a product fast, that's very relevant.
        matsemann 4y ago
        Except that the time it takes to set up the project is negligible compared to actually developing it. So if it takes you 5 minutes and me 5 hours to have a new project up & running, that doesn't really matter in the end.
        reducesuffering 4y ago
        I’ve done a 1 month MVP on each of these stacks, it’s not just the initial deployment. React is better integrated in Next, and you can get more done faster and simpler. DRF has poor async and is not an ergonomic practice in 2022, Flask requires lots else to build and maintain with weaker integration / community, and if you’re arguing why HTML templates are just as good, well, Fortune 500 and every HN startup has left it behind for good reason.
        matsemann 4y ago
        In one instance you're talking about "HNers making a quick product", and the other you're talking about fortune500s. Two vastly different things with different needs. I'm also not arguing about the specific tech. It's irrelevant. If I know tech X, choosing tech Y because it's hipper or "faster to set up" helps nothing if it's slower because it's unknown to me.
      - criley2 4y ago
  - criley2 4y ago
    >Quite weird to compare infrastructure of a static frontend to a backend with db and stuff? I suppose you don't know what you're talking about, but Next.js is a backend and frontend supporting a wide variety of data sources. I personally like using Prisma and postgres with my Next.Js deployments. I'm literally rolling out a full stack database connected react app in minutes that includes a full functional API that can be accessed by a variety of clients.
    - matsemann 4y ago
      But then you suddenly have complexity again. In your various comments here you're talking about ten different tools and concepts being woven together. It's only fast for you because you've done it before. Not inherently faster than OP's approach. Like, I can spin up a k8s cluster faster than I can even understand what parts of Nextjs I should use. Doesn't mean that me selecting k8s is the best choice for all problems.
    - criley2 4y ago
      What are you talking about? That's not complexity, those are out of the box features that come with a single script run (create next app or create t3 app) Vercel will even launch that for you without a script, just a button click. Five minutes to launch with my preferred stack, though. And if we're really racing, Railway.app can spin up deployments AND databases in under 60 seconds. If I tried a speed run, I could get the time down. If OP can hand configure a python app running on ngnix in manually managed DO droplets in 5 minutes... good on them! The greatest devops of our era. Also -- I guarantee that a newbie developer can launch a nextjs app faster than hand rolling some DO droplet with python and other technologies. I guarantee I can have a newbie in a bootcamp with a working app on day1 (since it's literally a button click, if we want), while I doubt you could get that newbie out of a bootcamp on his stack at all.
      - matsemann 4y ago
        Why so hostile in your comments? It's not a competition about being the fastest. If anything, it only shows immaturity on your part. Time spent setting up a project is negligible compared to other things surrounding it. You're anyways missing my point. Nextjs isn't a silver bullet, nothing is. And that how long it takes to set up a project is a function of familiarity with the stack. Edit: thanks for deleting all your personal attacks on me. But also remember, I'm not the one claiming to know everything here (as you wrote in your now deleted post), you're the one that critiqued OP.

rsanheim 4y ago

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.