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

91–100 of 181 posts

Re: Four ways to build web apps

#91

Post by glutamate »

ZephyrBlu wrote: post #88
glutamate wrote: post #86

Earlier quoted context omitted.

> The "underlying technologies" are constantly changing, unless you are using an extremely outdated stack So will also constantly change their behaviour in the edge cases. Thank you for giving me another reason for not using that crap. I'll stick with my extremely outdated stack.

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 question is how do they behave when you are pushing the tools outside the intended core use cases. Can you then really trust services that change their core implementation constantly will work for your workflow?

TBH i would probably trust a CDN because I have a fairly simple use for such a service. If I were really pushing these tools, like running a video broadcast service or whatever, I would be much more worried.

Re: Four ways to build web apps

#92

Post by cbzoiav »

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…

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 and be up and running in minutes.

Same with Spring/Java or .NET/ASP.NET Web API.

And you can still run a VPS or container that can handle significant traffic for free on many of the cloud platforms + migrating it is much much simpler.

Re: Four ways to build web apps

#93

Post by ZephyrBlu »

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…

I find it really hard to believe that you would run into rough edge cases with most platforms. If you have a small app a lot of platforms do deploys directly from GitHub repos. If you have a more complex app cloud platforms support things like managed Kubernetes and such.

What does something "outside the intended use case" even look like for a deployment and hosting platform?

If you're only using them for hosting and deployment there isn't really any lock-in either. That only occurs if you're using their other cloud services, and even then there are many platforms with similar services.

Re: Four ways to build web apps

#94

Post by ZephyrBlu »

cbzoiav wrote: post #92
ZephyrBlu wrote: post #85

Earlier quoted context omitted.

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…

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: https://www.youtube.com/live/hWjT_OOBdOc?feature=share&t=765.

Re: Four ways to build web apps

#95

Post by hathawsh »

crabmusket wrote: post #52
NikolaNovak wrote: post #46

Earlier quoted context omitted.

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)?

Yeah, that's a better way to put it. #3 is a static arrangement of a small number of servers.

Re: Four ways to build web apps

#96

Post by glutamate »

ZephyrBlu wrote: post #93
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…

I find it really hard to believe that you would run into rough edge cases with most platforms. If you have a small app a lot of platforms do deploys directly from GitHub repos. If you have a more complex app cloud platforms support things like managed Kubernetes and such. What does something "outside the intended use case" even look like for a deployment and hosting platform? If you're only using them for hosting and…

I agree that paid/cloud does not necessarily equal lock-in. I mean, an Ubuntu VPS is identical-enough (usually) across clouds. Managed databases? Maybe? what about available Postgres extensions etc.

There are lots of cases where deployment needs some kind of customisation. This usually happens either around persistent state or around building in CI. E.g. in one project some years ago, we wanted to test in CI against a subset of the production database. So there has to be a script to appropriately subset this, not easy if you have complicated foreign key relationships, and you have to make sure confidential data did not make it across. We were not the only people to do this I've seen this elsewhere.

Other example, my previous project: the main framework is Django with a React front end. The admin interface is django html templates. But one of those templates has an embedded additional react component because on that admin page we needed more interactivity. So that has to be built. And all of this has to be tested in CI.

What does non-standard deployment look like? Here is one example. For my current project I use wildcard domains so users can create their own tenants on their own subdomain. This would not work on e.g. heroku or similars, at least i don't know how.

All of this could probably be done in Kubernetes but also much simpler with bash scripts and systemd units.

Re: Four ways to build web apps

#97

Post by acomjean »

psyklic wrote: post #24
glutamate wrote: post #3

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.

Not sure why the author insists on "exactly one" server. You can easily also host a SQL server in the same datacenter (or even run a SQL server on the same server!). This was how most web apps were built before the other options existed. It is trendy nowadays to just use SQLite for a single server claiming speed advantages, but there are disadvantages as well. In my last startup, our SQL server was not directly conne…

In my experience this is pretty common for databases only to be accessed via local host. We had our office ip whitelisted, but now some database clients (datgrip, dbeaver…) can ssh tunnel to access. Plus phpmyadmin is still no uncommon..

Re: Four ways to build web apps

#98

Post by phist_mcgee »

dgb23 wrote: post #81
FinalBriefing wrote: post #68

Earlier quoted context omitted.

Gotta disagree with you here. Modern PHP is quite great, especially when paired with Laravel or Symphony. They had to introduce breaking changes to move the language forward, but I don't recall anything huge after 7.0 or so. There's a huge ecosystem of packages to do just about anything web-related, and the documentation and community resources are way better than anything I've seen with say, Java/Spring. Laravel is…

We’re not disagreeing though. I was contrasting using something like Laravel with just PHP. And it’s not just documentation and ecosystem. You also get a stable, nice foundation with a clear upgrade path that protects you from a wonky foundation.

Kinda like saying that people shouldn't use vanilla JS these days unless you're a glutton for punishment.

Re: Four ways to build web apps

#99

Post by 2h »

DangitBobby wrote: post #76
2h wrote: post #56

Earlier quoted context omitted.

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

Consider creating a tunnel with Cloudflare Argo (think more sophisticated ngrok). I just finished deploying a toy app from a local machine about 15 minutes ago.

I read this entire page, and it doesn't offer what I am wanting at all. I have a localhost server, that I want to deploy so it's publicly accessible, like option 3 in the original article.

https://www.cloudflare.com/products/argo-smart-routing/

Post reply on HN