Hacker News Reader

Comment by fareesh | Hacker News Reader

Building simple CRUD apps are often a single code-generation command in Phoenix/Rails/Laravel, and adding common features like Auth, Queues, Emails, File Uploads, etc. are similar.

The downside is that this is a stateful monolithic approach that requires a server running 24x7 and can break without some effort to cache and reduce the load on the database. They are also often memory-hungry frameworks.

The tradeoff for productivity is worth it in my view, for the vast majority of cases where it's just a small team of 1-3 developers.

View on HN

> The tradeoff for productivity is worth it

Yes, and most often we don’t fully understand the problem without partially solving it, which is perfect for these monolithic, batteries included frameworks.

I find building apps in Django, with the prescribed convention to box me in, helps tremendously to stop me from overthinking and just experimenting with the problem space.

I’ve even started using Django for apps that aren’t web apps, just because it has whatever I will eventually need, whether it’s database, auth, caching, admin portal, tools for building out CLIs, it’s all there.

A server running 24/7 costs a coffee a month.

And can run multiple apps.

That's not a disadvantage unless you failed at life.

I'm sick of reading threads where people disparage normal application architecture for completely stupid reasons.

I don’t condone the language, but agree with the sentiment.

What are people doing where rewriting tens of thousands of dev hours of work from scratch makes more sense than spending money on servers?

I also agree with the sentiment, although two "but..."s did come to mind so I'll play Devil's Advocate:

1: does this contribute to the inefficiency and bloat we see on the web and applications nowadays? Of course everyone complains about Discord and Teams and other Electron apps (which aren't a direct comparison) but one I deal with regularly is the Microsoft Power BI Gateway application, which allows access to on-prem data for reports and automations. I'm sure it does a little more than just establish connections to Azure and send data, but it's a 672MB download! That's larger than the ISO for Windows XP. Throwing more hardware at a problem becomes less effective when the application has fundamental inefficiencies.

2: although server hardware is affordable compared to western salaries, a lot of the world has far less purchasing power and server hardware prices aren't as regional as labor costs. So some developers may have more time than money for more silicon. I haven't run any numbers on this and doesn't mean that rolling your own "everything" is worthwhile.

Edit: fixed grammar in last paragraph.

> What are people doing where rewriting tens of thousands of dev hours of work from scratch makes more sense than spending money on servers?

1) "spend money on servers" is a boring solution. This is no good if you are a career software engineer and your career, salary and prestige within the company depends on writing code.

2) thanks to the cloud, server/infrastructure is now priced with ~100x margins, so "spend money on servers" is a significant investment, with these (stupid) moves to serverless/etc being seen as a cost-saving measure (that of course just like with the cloud itself supposedly being cheaper will never actually materialize).

What kind of web app doesn't require a server running 24/7?

'lambda' apps.

Do people still use them for full production systems? We use them a bit for ancillary things but TBH, if you have some k8s or similar, solution, it's maybe not worth it to not use a standard container deployment environment that everyone knows.

> lambda apps

Yes, SST [1] uses lambdas heavily but makes it more seamless and less visible, just the place your code runs.

I’ve also found Azure Container Apps to hit the right balance. It’s kubernetes under the hood, which you don’t have to mess with at all, except that it can use KEDA [2] scaling rules to scale your containers to zero, then scale up with any of the supported KEDA scalers like when a message hits a queue.

[1] https://sst.dev/

[2] https://keda.sh/

Except when you scale to zero, you get a 23+ second cold start time on .net apps. Google cloud run pulls some black magic to get ~3 second cold starts on .net apps, and ~500ms for golang/python/native apps.

I inherited some lambdas on my team and the amount of effort I have to go through to:

- make them testable locally

- planning/qa-ing yaml configs with devops team, because they only grant me readonly access on their precious over engineered helm chart stack, they don’t even offer running my unit tests in their pipeline for me

- painful debugging process because everything that touches a lambda is another aws service config somewhere

I honestly don’t know why anyone wastes their time. We will be deprecating these aws lambdas for traditional api on our next version of our app. Serverless is garbage way to deploy code and is designed to tax you/charge you fees at every turn. It is for people who want to deploy poorly thought out code and rewrite it later, and explain the bill later.

Yes, I inherited a Lambda code-base too, and it is an absolute knot - Lambdas sending requests to other Lambdas, Lambdas sending messages and other Lambdas reading the messages, Lambdas reading and disregarding messages due to poorly thought-out queues etc.

And of course, no easy way to test locally.

I remember at one job, they were talking about the overall architecture of code at the company and when I asked how can I run this on my computer, they said well you can just run it but I pushed... How can I run this whole thing on my computer to interact with everything else and it was met with silence.

I can understand having to stub out external calls to vendors and clients but this is ridiculous. There is no local story.

Hey, me too! AWS or nothing is the way to run things.

Oh yeah I have a lambda that needs another lambda to complete before running. The first is on a Cloudwatch event interval. So the data in the second can be stale, but the one saving grace of the situation is that no one cares enough to make me fix it, not even me.

I wouldn't equate the lambda UX with "serverless" at large. I work on a serverless system that runs the same code you upload (e.g, python). You write it as a traditional API then upload it to the cloud and done.

One thing that makes it possible is that "orchestration" is embedding in your code, using a library (https://github.com/dbos-inc/dbos-transact-py). With lambdas you need step functions which is not exactly easy to test locally.

Also no need for "layers".

There are a bunch of gotchas outside of UX, that make them just as awful. Like if you need secrets you have to find a way to cache them so that aws.secretsmanager doesn’t ding your bill every request. Depending on how your devops team requires you to load secrets this can make the code worse in operation and review.

But the main point why serverless is garbage is that the old stack does everything better.

I worked on a system built on FAAS for a few months and it was (already when I arrived) one of the more well-tested systems I ever worked with, so it is clearly doable.

I took the system from dev to prod and much of it was boring in the very best sense of boring (also helped that I had a good team, although they were new to it as well).

I had one major gripe with it (and everything Azure) afterwards:

On dev there are absolutely no guarantees: components might go down half a workday and they don't care.

And when you go to production the prices goes absolutely through the roof (IIRC $9000/year for the most basic message broker I could configure that wouldn't have the risk of being offline half a day, and every component is like this).

So while it was really cool to work on a cloud native system if someone ever asks me to design one for them, that design will be presented with a price tag for what it will cost to take it to production.

I really enjoy laravel currently. It's just fun that I can focus on my app instead of the stuff that's just tedious. Also not relying on some 3rd party Auth is a huge bonus for me.

As someone who has written a few experimental apps with Phoenix, with and without LiveView, and later had to deal with many inscrutable errors when attempting to upgrade from Phoenix 1.16 to 1.17 with basically no help whatsoever around the web, putting it next to Rails and Laravel is kinda laughable. HN-darling-that-will-bite-in-the-ass alert! Be warned. Use something boring instead.

agreed, this is a genuine problem - I tend to dismiss this as a skill issue on my part, hence putting them all together

Reply on news.ycombinator.com