[deleted]
Four ways to build web apps
51–60 of 181 posts
Re: Four ways to build web apps
#52Earlier quoted context omitted.
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...
Maybe it's "on the order of a single server", or conveys that the servers are "statically" arranged and/or manually managed rather than automatically (auto scaling, service discovery)?
Re: Four ways to build web apps
#53> 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
Do you know how they make this work?
Re: Four ways to build web apps
#54Re: Four ways to build web apps
#55Blog 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 much better than the article.
Re: Four ways to build web apps
#56I agree with this, except I would take 3 out of the list.
3 is the most attractive option to me. I have a tiny localhost server I wrote, and have been looking for a simple way to deploy
Re: Four ways to build web apps
#575th option:
Webflow, airtable, whalesync.
I could recreate one of his examples (https://oldgames.win/) in 10-20 minutes off just a CSV file... And I could use something like https://simplescraper.io/ to scrape that data + find imagery.
Re: Four ways to build web apps
#58Earlier quoted context omitted.
Free, for now. Once the higher interest rate environment becomes more normalized, I would not be surprised to see many services become paid.
They may cut the extent of a free offering, but I suppose they won't drop it. An ability to make a quick proof of concept, to just try something and play with it, is very important for bringing in paying customers. People tend to buy with more confidence things they already know and comfortable with. People tend to pay for things that are widely known, with tons of examples and explanations online; free services gene…
That might be true but it really depends how many can convert. Recently Heroku dropped their free tier as well as Fly.io having a credit card only free trial in order to deter scammers.
Re: Four ways to build web apps
#59Surprised not to see Render.com listed under option 4 despite that being an option discussed often here with comparable simplicity of deployment to Heroku
Re: Four ways to build web apps
#60Earlier quoted context omitted.
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
Do you know how they make this work?
For example, with containers on AWS ECS:
https://docs.aws.amazon.com/AmazonECS/latest/userguide/task-...