5 ms·

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

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.

stavros 2y ago
What kind of web app doesn't require a server running 24/7?
- mianos 2y ago
  '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.
  - halfcat 2y ago
    > 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/ https://sst.dev/ [2] https://keda.sh/ https://keda.sh/
    - ledgerdev 2y ago
      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.
  - righthand 2y ago
    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.
    - jamesfinlayson 2y ago
      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.
      - thanksgiving 2y ago
        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.
        jamesfinlayson 2y ago
        Hey, me too! AWS or nothing is the way to run things.
      - righthand 2y ago
        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.
mattmanser 2y ago
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.
- MattGaiser 2y ago
  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?
  - SpecialistK 2y ago
    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.
  - Nextgrid 2y ago
    > 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).
halfcat 2y ago
> 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.
oefrha 2y ago
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.
- fareesh 2y ago
  agreed, this is a genuine problem - I tend to dismiss this as a skill issue on my part, hence putting them all together
zwnow 2y ago
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.

stavros 2y ago

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

mianos 2y ago
'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.
- halfcat 2y ago
  > 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/ https://sst.dev/ [2] https://keda.sh/ https://keda.sh/
  - ledgerdev 2y ago
    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.
- righthand 2y ago
  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.
  - jamesfinlayson 2y ago
    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.
    - thanksgiving 2y ago
      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.
      - jamesfinlayson 2y ago
        Hey, me too! AWS or nothing is the way to run things.
    - righthand 2y ago
      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.

mattmanser 2y ago

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.

MattGaiser 2y ago
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?
- SpecialistK 2y ago
  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.
- Nextgrid 2y ago
  > 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).

halfcat 2y ago

> 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.

oefrha 2y ago

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.

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

zwnow 2y ago

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.