Where would you host a container based Node API that connects to a non-public Postgres database?
AWS Fargate connecting to RDS
Four ways to build web apps
41–50 of 181 posts
Re: Four ways to build web apps
#42I agree with this, except I would take 3 out of the list.
Re: Four ways to build web apps
#43So sad. So the choice is closed source platform lock-in, a single Linux server with SQLite as database, or kubernetes? -an old man yelling at the cloud.
Not sure why the author insists on "exactly one" server. You can easily also host a SQL server in the same datacenter (or even run a SQL server on the same server!). This was how most web apps were built before the other options existed. It is trendy nowadays to just use SQLite for a single server claiming speed advantages, but there are disadvantages as well. In my last startup, our SQL server was not directly conne…
> Not sure why the author insists on "exactly one" server.
I believe the assumption is, if you need more than one server, using containers (option #4) is a better solution in general. Obviously this is not exactly true for your 1 server for app, 1 server for SQL server scenario, but might make sense for most setups.
Re: Four ways to build web apps
#44Earlier quoted context omitted.
Option #4 will give you autoscaling without having to deal with k8s. IIRC all of the options listed still involve writing a Dockerfile, though. Render.com, Cyclic.sh, and Railway.app are also in that category(ish) but will automate the build more like Heroku. (this is off the top of my head, please correct if I misremembered anything)
fly.io can construct the dockerfile and shenanigans for your source code tree, last i saw.
Yes, it can autodetect your framework and generate a basic Dockerfile.
Writing a Dockerfile is not harder than deploying to a bare metal server anyway.
Re: Four ways to build web apps
#45I guess the title should have been "Four Ways to Deploy Web Apps", not "build" them. Granted, option #2 (functions) is a different beast, but all others can be built the same way but deployed differently. For example
- You can develop a static (Hugo) web site then deploy it on Fly.io using containers.
or
- You can develop a container based web site, then deploy it on a bare Linux server (k8s is not necessary for a few containers).
Re: Four ways to build web apps
#46Earlier quoted context omitted.
I read it differently. It looks like a good outline of 4 basic approaches to building and hosting web sites. I would word them as: 1. Stateless static site. There is a variety of ways to build it (such as React or Svelte or purely by hand) and a variety of ways to host it (such as a directory of HTML files hosted by nginx). 2. Function services like Cloudflare workers, AWS Lambda, Google Cloud Functions, Azure Functi…
I can't have my database on a separate Linux box? Seems odd to insist on either precisely one server or go straight to container orchestration. That said, I agree with you about the other generalisations! EDIT: actually, where do PaaSes fit into this taxomony? I'd argue that level 2 is actually the PaaS level. You might choose an edge PaaS (Workers), distributed (Fly.io), or centralised (Elastic Beanstalk) depending…
I assumed that option 3 was a "Fermi estimation", I. E. "single handed number of servers"
I'm used to 3 tier legacy apps (web / app / dB) but I assumed that would fit into number 3 the best, I could be wrong...
Re: Four ways to build web apps
#47Blog posts like this always strike me as…weird. This seems like “how to build a web app for a very tiny subset of people who don’t want to learn about deploying web apps”. Maybe I’m in a bubble? It seems like 99% of the people I know actually running profitable companies have an infrastructure that roughly matches to “some Linux server somewhere”, and then upward from there it all just moves to AWS/azure, but it’s st…
I read it differently. It looks like a good outline of 4 basic approaches to building and hosting web sites. I would word them as: 1. Stateless static site. There is a variety of ways to build it (such as React or Svelte or purely by hand) and a variety of ways to host it (such as a directory of HTML files hosted by nginx). 2. Function services like Cloudflare workers, AWS Lambda, Google Cloud Functions, Azure Functi…
This is a much better outline of the article than the article's own table of contents. Makes much more sense, even if it's still incredibly narrow in scope.
Re: Four ways to build web apps
#48Blog posts like this always strike me as…weird. This seems like “how to build a web app for a very tiny subset of people who don’t want to learn about deploying web apps”. Maybe I’m in a bubble? It seems like 99% of the people I know actually running profitable companies have an infrastructure that roughly matches to “some Linux server somewhere”, and then upward from there it all just moves to AWS/azure, but it’s st…
I read it differently. It looks like a good outline of 4 basic approaches to building and hosting web sites. I would word them as: 1. Stateless static site. There is a variety of ways to build it (such as React or Svelte or purely by hand) and a variety of ways to host it (such as a directory of HTML files hosted by nginx). 2. Function services like Cloudflare workers, AWS Lambda, Google Cloud Functions, Azure Functi…
It's not obvious but you can host an entire website or simple web app on AWS Lambda (as simple as a single function).
Re: Four ways to build web apps
#49Where would you host a container based Node API that connects to a non-public Postgres database?
Google CloudRun with direct serverless VPC access of a CloudSQL instance with no public IPs
Re: Four ways to build web apps
#50> Eliminate the need to manage and inject API tokens into containers and servers and instead authorize containers and servers to perform those operations. What does this look like in practice? Can someone provide example scenarios that this is describing?
Example: you don’t need AWS keys to write to SQS because the EC2 instance has an identity (“principal”) applied to it, and SQS has been configured trust requests from said identity for some set of queues. It’s typically cloud-specific in the implementation and the resources being requested
This. To state it a slightly different way, instead of "create me an instance and inject the following AWS credentials in it" and then having the application running on that instance know where to look to get the AWS credentials, you go "create me an instance and assign it an IAM Role of 'webserver'" and then you write access policy that says "any of my instances with the role 'webserver' can access this bucket/database/queue." The magic is your app uses the SDK to say "assume the 'webserver' role" and it does this under the covers by going out and finding ephemeral keys that AWS injects into your instance via the metadata service. No shared keys == goodness.