Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Four ways to build web apps

tomhummel.com

Post reply on HN
Print view View original

101–110 of 181 posts

Re: Four ways to build web apps

#101

Post by nicbou »

arsome wrote: post #70

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. It'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'll have very limited con…

Nginx is not relatively simple. It's not easy. It's an unintuitive, poorly documented minefield.

I agree with you in principle, but in practice mthese services replace dozens of hours of banging your head against software that's one misstep from blowing your legs clean off.

Sometimes, you have better things to do than tweaking nginx configs using the average of a dozen tutorials and docs that might as well be written in middle English.

I don't have better things to do, which is why I bothered. I'm not sure if it was really worth it. Cloudflare took 5 minutes to set up.

Re: Four ways to build web apps

#102

Post by chr15m »

arsome wrote: post #70

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. It'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'll have very limited con…

If you want the best of both worlds install Dokku or Piku. You get a PaaS-like experience on your own VPS.

Re: Four ways to build web apps

#103

Post by [deleted] »

nicbou wrote: post #101
arsome wrote: post #70

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. It'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'll have very limited con…

Nginx is not relatively simple. It's not easy. It's an unintuitive, poorly documented minefield. I agree with you in principle, but in practice mthese services replace dozens of hours of banging your head against software that's one misstep from blowing your legs clean off. Sometimes, you have better things to do than tweaking nginx configs using the average of a dozen tutorials and docs that might as well be written…

[deleted]

Re: Four ways to build web apps

#104

Post by tbran »

dzink wrote: post #73

Why recommend lock-in vendors when there are better options in between? There was no mention of Heroku which is easy and scalable. 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. Go has fant…

Uh, I think you are confused about Hugo unless I'm missing something.

It's a static site generator and is nothing like Wordpress. I've run Hugo sites behind nginx, caddy, and netlify with nary a problem.

Re: Four ways to build web apps

#105

Post by rhodysurf »

glutamate wrote: post #91
ZephyrBlu wrote: post #88

Earlier quoted context omitted.

Uh, what? Your product Saltcorn uses Webpack, React, Express, Docker and probably many more modern technologies. Those were just the ones I found looking at the repo for 5min. Cloud and serverless platforms are similarly modern tech, except for deployment and hosting. Do you really think that e.g. AWS and Cloudflare "constantly change their behaviour in the edge cases"?

yes, but I control all those dependencies with a lock file and pinned dependencies. We have tests for their behaviour including a test script in CI that boots up the service locally and connects to it, making various assertions. I think there is a difference here between the core behaviour and the edge case behaviour. I guess I would trust that in the core behaviour they do not change on a day-to-day basis but the qu…

You can just deploy docker containers to many of these services and the versions are pinned just like you are used to. I’m not sure what you are expecting side effects to be here

Re: Four ways to build web apps

#106

Post by omnibrain »

nicbou wrote: post #101
arsome wrote: post #70

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. It'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'll have very limited con…

Nginx is not relatively simple. It's not easy. It's an unintuitive, poorly documented minefield. I agree with you in principle, but in practice mthese services replace dozens of hours of banging your head against software that's one misstep from blowing your legs clean off. Sometimes, you have better things to do than tweaking nginx configs using the average of a dozen tutorials and docs that might as well be written…

> Nginx is not relatively simple. It's not easy. It's an unintuitive, poorly documented minefield.

And that's why I use Caddy.

Re: Four ways to build web apps

#107

Post by d-z-m »

ZephyrBlu wrote: post #85
arsome wrote: post #70

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. It'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'll have very limited con…

1) Almost all of these services have generous free tiers. Even if you're running a relatively high traffic site your bill will be practically $0. 2) These technologies are stable and usually not that complicated. You are missing out on a lot of productivity by not looking into them. Understanding the "real underlying technologies" is a myth. The "underlying technologies" are constantly changing, unless you are using…

There is a difference in abstraction between hooking API Gateway to a Lambda function, and writing and deploying an API on a Linux VM.

One is closer to the metal, so to speak, and provides a better basis for understanding how these cloud services (Lambda, etc) actually work behind the scenes. In this case, understanding the underlying technologies is not a myth.

Re: Four ways to build web apps

#108

Post by zoomzoom »

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!

Feel free to ping hn@withcoherence.com if we can answer any questions or help you get running…

Re: Four ways to build web apps

#109

Post by cbzoiav »

ZephyrBlu wrote: post #94
cbzoiav wrote: post #92

Earlier quoted context omitted.

Your link is a guy saying people get so good with the old technologies that there is no point trying to compete with them. That only happens if they don't change much... If you time traveled someone from a decade ago that knows how to configure an Apache or NGinx server to today they would likely still be able to. It may not follow latest best practice, but at worst they'll use something retired, have to google it an…

I don't understand what you're trying to say. My point is that you could make the whole "underlying technologies" argument for Apache back in the day when it was new. Why use Apache when I can understand the "underlying technologies"? Things evolve over time and new tech slowly becomes so integrated into the stack that it is the underlying technology. He even references webservers like Apache as part of this process:…

The underlying technologies very rarely change and offer very stable APIs. Apache has been around nearly 30 years. NGinX nearly 20. Both offered major advantages over existing solutions, but also interfaced with the rest of your codebase using a standard mechanism (CGI) so you could easily migrate to or from them.

A single vendors solution will not (at least very much should not) become a standard underlying technology, so this isn't moving to the next underlying technology. You're just tying yourself in to one vendor.

If it gets standardized across vendors or open sourced then it becomes a different story, but until then its a massive gamble to assume it will and the standard chosen will derive from your current vendors solution. Then what happens when the vendor decides to double prices and kill the free tier (also known as being acquired by Oracle)? deprecate it? Goes bust? etc.

Re: Four ways to build web apps

#110

Post by glutamate »

rhodysurf wrote: post #105
glutamate wrote: post #91

Earlier quoted context omitted.

yes, but I control all those dependencies with a lock file and pinned dependencies. We have tests for their behaviour including a test script in CI that boots up the service locally and connects to it, making various assertions. I think there is a difference here between the core behaviour and the edge case behaviour. I guess I would trust that in the core behaviour they do not change on a day-to-day basis but the qu…

You can just deploy docker containers to many of these services and the versions are pinned just like you are used to. I’m not sure what you are expecting side effects to be here

To the extent that you can put your functionality as a dependency in a container, that's not what I'm talking about. If you can do that then we are all hunky dory.

The problem is with functionality that is only available as a remote API, because for whatever reason we wanted to be cloud native rather than rely on free and open source libraries. I cannot pin that dependency version, as best I can choose which version of the API I am talking to, but if they have changed the underlying implementation then I can't request them to roll that back just for me.

Post reply on HN