Four ways to build web apps

Learning dozens specific cloud services and shelling out money everywhere I go is way less appealing to me than buying a cheap dedicated server and firing up exactly what I need.<p>It&#x27;ll take me far longer to figure out what FarGate and Cloudflare Pages and all these are and infinitely longer to keep up with the latest and greatest because it keeps changing constantly. And even once I get it, I&#x27;ll have very limited control or understanding of my stack, and migration? I&#x27;m screwed. I&#x27;m not interested in playing games like that.<p>nginx is comparatively simple, run it, it serves. Config is easy, learn it once, run it anywhere, it doesn&#x27;t get a dozen new features and breaking changes every month, just does its job.<p>I guess I&#x27;d just rather understand the real underlying technologies than some crappy commercial wrapper for them that will differ every time someone tries to rip me off.

I guess the title should have been &quot;Four Ways to <i>Deploy</i> Web Apps&quot;, not &quot;build&quot; them. Granted, option #2 (functions) is a different beast, but all others can be built the same way but deployed differently. For example<p>- You can develop a static (Hugo) web site then deploy it on Fly.io using containers.<p>or<p>- You can develop a container based web site, then deploy it on a bare Linux server (k8s is not necessary for a few containers).

5th option:<p>Webflow, airtable, whalesync.<p>I could recreate one of his examples (<a href="https:&#x2F;&#x2F;oldgames.win&#x2F;" rel="nofollow">https:&#x2F;&#x2F;oldgames.win&#x2F;</a>) in 10-20 minutes off just a CSV file... And I could use something like <a href="https:&#x2F;&#x2F;simplescraper.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;simplescraper.io&#x2F;</a> to scrape that data + find imagery.

Why recommend lock-in vendors when there are better options in between? There was no mention of Heroku which is easy and scalable.<p>Hugo is wonderful, until a deployment bug or misconfiguration exposes all of your server settings in a page that should be serving a 404 instead. Wordpress, Hugo and others also get constant attacks from hackers who can exploit each bug found on thousands of sites all at once.<p>Go has fantastic server examples and plenty of starter templates you can use to build your own server, and deploy to Heroku and scale to millions of users far cheaper in engineering and financial terms.

Seems overly complicated.<p>Easier way &gt; HTML + CSS + Javascript (vanilla or framework) + Server side language of choice.<p>Deploying is not building.

This is a nice little overview that is not afraid of being opinionated.<p>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.

Why not PHP on a shared or dedicated hosted server?

0th way: php scripts on shared web hosting. it still exists.

A particular application of #2 which works well as an extension of #3 is to have your workers implement a lightweight backend-for-frontend layer in between your frontend and more traditional API<p>This approach works pretty well when you have a pre-existing API and need to, say, minimize # of round trips to fetch data without wanting to couple your frontend(s)&lt;-&gt;backend too tightly.

&gt; Eliminate the need to manage and inject API tokens into containers and servers and instead authorize containers and servers to perform those operations.<p>What does this look like in practice? Can someone provide example scenarios that this is describing?

Surprised not to see Render.com listed under option 4 despite that being an option discussed often here with comparable simplicity of deployment to Heroku

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.

Another option is to use S3 + Cloudfront + SPA with your services running as web socket lambdas.

Where would you host a container based Node API that connects to a non-public Postgres database?

I agree with this, except I would take 3 out of the list.

Blog posts like this always strike me as…weird.<p>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”.<p>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&#x2F;azure, but it’s still just some Linux machines maybe with a load balancer in front of them.<p>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.<p>I mean honestly “HUGO static sites”…how about a directory of html files hosted by nginx or Apache?

So sad. So the choice is closed source platform lock-in, a single Linux server with SQLite as database, or kubernetes?<p>-an old man yelling at the cloud.

Well there&#x27;s also another, more oldschool, option - distribution via floppies and CDs. Lot of good zines were distributed this way. Just joking.<p>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.

His ordering is all wrong. Lambda-like websites are significantly more difficult to program and manage than a monolithic linux server. Graduating from the lambda to the linux server? No thanks.

In bucket number four, there’s also the option of a PaaS experience in your own cloud. Of course there are always trade-offs on control and complexity, but if you want to deploy to fargate or Google Cloud Run, without getting bogged down in writing pipelines and infra as code, and you want to get the Vercel-level developer experience that we all are getting used to - check out this category of tools. Including one where I’m a cofounder - withcoherence.com!<p>Feel free to ping hn@withcoherence.com if we can answer any questions or help you get running…

My Web site is designed and programmed and runs as intended. I was delayed by independent events, beat those back, and now am collecting some initial data.<p>But from the original post (OP) about &quot;Four Ways&quot; here, apparently I made a really big mistake, nope several biggies: I wrote the software using Windows 7 Professional, Visual Basic .NET, ASP.NET, ADO.NET, and SQL Server. What a user receives is old HTML and some CSS with little, maybe no, JavaScript. I didn&#x27;t write any JavaScript at all, but ASP.NET wrote a little for me.<p>At one point, I wanted a <i>key-value</i> store so used two instances of one of the .NET collection classes instead of Redis. That was a biggie mistake?<p>So, apparently my work is none of the &quot;Four Ways&quot; of the OP. Biggie mistakes, right???<p>I don&#x27;t get it: Looks to me like for some decades now, all around the world, people have been able to build (program, develop, etc.) Web sites using Windows 7, .NET, SQL Server.<p>E.g., as I recall, Markus Frind developed a Web site using those tools, had the usage grow, ..., and sold the site for $500+ million. He did something wrong?<p>Now there are some rules I don&#x27;t know about, rules that say I must just junk my code, 100,000 lines of typing, and start over?????<p>Those &quot;Four Ways&quot;, they include something for my use of collection classes as simple versions of Redis? Or they include Redis?<p>Oh, at it&#x27;s core, my Web site has some original applied math -- those &quot;Four Ways&quot; have that already?<p>I didn&#x27;t get the memo that I can&#x27;t use Windows 7, .NET, and SQL Server!!!<p>What am I supposed to do, use better than Windows 7 Professional, .NET, SQL Server, and my applied math code????