[HN Gopher] Four Ways to Build Web Apps
___________________________________________________________________
Four Ways to Build Web Apps
Author : tphummel
Score : 76 points
Date : 2023-02-20 17:51 UTC (5 hours ago)
(HTM) web link (tomhummel.com)
(TXT) w3m dump (tomhummel.com)
| dgb23 wrote:
| This 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.
| razor_router wrote:
| Thank you for your informative comment! I'm glad you found the
| article to be opinionated. It is definitely true that the
| options discussed in the article are moving targets and they
| are providing more services and features every few months. I
| agree that this article didn't cover every single detail, but I
| hope it still provided a good overview of some of the main
| features and differences between the platforms.
| rexreed wrote:
| Why not PHP on a shared or dedicated hosted server?
| arcturus17 wrote:
| I could do this, or I could just throw good old React or a
| derivative framework at whatever UI I have to build and be done
| with it.
| omarfarooq wrote:
| How does that solve for backend? This mentions web apps.
| margorczynski wrote:
| Well 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.
| glutamate wrote:
| you could also just `apt install nginx docker.io postgresql`
| then `docker --restart=always ...`
| glutamate wrote:
| So 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.
| paulgb wrote:
| 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)
| glutamate wrote:
| 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.
| jjtheblunt wrote:
| fly.io can construct the dockerfile and shenanigans for your
| source code tree, last i saw.
| mpeg wrote:
| Cloudflare open sourced workerd, the workers runtime. [0]
|
| Of course there is more to the platform than just that, but
| your code isn't exactly unportable anyway.
|
| [0]: https://blog.cloudflare.com/workerd-open-source-workers-
| runt...
| thepasswordis wrote:
| Blog 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 still just
| some Linux machines maybe with a load balancer in front of them.
|
| If you're writing software and don't seem covered by this blog
| post, don't feel like you're out of the loop on something. I
| think this author is just writing about the subset of the ways
| that he knows about.
|
| I mean honestly "HUGO static sites"...how about a directory of
| html files hosted by nginx or Apache?
| dgb23 wrote:
| > I mean honestly "HUGO static sites"...how about a directory
| of html files hosted by nginx or Apache?
|
| Whether you put HTML files on the mentioned services or have a
| build step with a static site generator is not the point.
|
| Where does your nginx server run, how do you keep it up and
| running, how you do provision it, how do your files end up on
| the server?
|
| You can write a bunch of shell scripts and do all of this on a
| cheap VM for 5 bucks. Or you can get it for free on some of
| these services with git integration, global caching, web hooks,
| previews, cheap storage, image optimization etc. You get
| unlimited or at least a lot of sites and it's all automatic. On
| some you can even just drag and drop a directory into their web
| interface and the website is there in a couple of seconds.
|
| It's basically a different layer of abstraction that's
| free/cheap and works nicely for simple use cases or as a
| specialized part of a more complex deployment architecture.
|
| I have personally recommended netlify, cloudflare etc. to
| people who have the technical ability to write HTML/CSS or use
| a static site generator. Those things are very easy to use and
| carry around less risk than having to provision and configure a
| web server yourself.
| satvikpendem wrote:
| Free, for now. Once the higher interest rate environment
| becomes more normalized, I would not be surprised to see many
| services become paid.
| [deleted]
| bertjk wrote:
| > 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?
| linux2647 wrote:
| 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
| acedTrex wrote:
| So really we are just recreating windows auth
___________________________________________________________________
(page generated 2023-02-20 23:00 UTC)