Four ways to build web apps
tomhummel.com
Four ways to build web apps
1–10 of 181 posts
Re: Four ways to build web apps
#2This is a nice little overview that is not afraid of being opinionated.
It leaves out some of the affordances that CF Pages, Vercel and Netlify provide. (Discussed as option 1 in the article). Those are of course moving targets that provide more stuff every few months.
Re: Four ways to build web apps
#3So 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.
Re: Four ways to build web apps
#4> 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?
Re: Four ways to build web apps
#5So 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.
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)
Re: Four ways to build web apps
#6Well there's also another, more oldschool, option - distribution via floppies and CDs. Lot of good zines were distributed this way. Just joking.
On a more serious note - it is good to be aware and track how much we are tied to a given service. Because we might end up being taken hostage by the Cloud provider who can extort us for a long time before we manage to migrate.
Re: Four ways to build web apps
#7So 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.
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)
I quite like Docker. It solves the "it works on my machine" problem by being reproducible-enough. And I can still run it locally.
My argument is not against innovation but against mindshare capture by platform capitalism.
Re: Four ways to build web apps
#8So 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.
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.
Re: Four ways to build web apps
#9> 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
Re: Four ways to build web apps
#10Well there's also another, more oldschool, option - distribution via floppies and CDs. Lot of good zines were distributed this way. Just joking. On a more serious note - it is good to be aware and track how much we are tied to a given service. Because we might end up being taken hostage by the Cloud provider who can extort us for a long time before we manage to migrate.
you could also just `apt install nginx docker.io postgresql` then `docker --restart=always ...`