4 ms·

But the whole modern development it's a nightmare as I see, or at least the advertised modern serverless development, you need to depend on: - Some serverless

But the whole modern development it's a nightmare as I see, or at least the advertised modern serverless development, you need to depend on: - Some serverless hosting - Some database provider - Some auth provider - Some other service, etc In the past you just rented a simple VPS or shared hosting, setup all by yourself and have just one provider for everything, nowadays I read that auth it's very hard and you should not do it and instead use some auth provider (Auth0, etc). I remember the good old days with php, just upload your file and it worked, now they try to replicate that experience but with dozens of providers.

fabian2k 3y ago
The non-serverless version still works fine, even in modern JS land. The simple approach still works if you have some knowledge around setting up a server and configuring a few things. I also think that the advice around Authentication is often misguided. For simple cases it's not that hard to add authentication without a separate service. There is too much scaring the newbies around that topic, when they are probably about as likely to mess up authentication when they try to configure an excessively complex library compared to implementing basic session authentication with the tools their framework provides.
WorldMaker 3y ago
Even in the good old days you still had a database provider (often PHP plus MySQL in the classic LAMP stack) and in some cases an Auth provider (especially if you consider classic tools like Wordpress and Drupal as Auth providers). (Relatedly, the advice about Auth is best "don't roll your own auth" and that doesn't mean that you have to use an Auth provider, but at least use a library vetted by others. I also tend to add "don't keep passwords in your database" because that is a [legal/accounting] liability issue [more than being "hard", though it can seem hard to do right], which does make it good advice to find a third-party Auth provider you trust if you must support password-based workflows. Luckily some new options and libraries for password-less Auth are becoming slowly more common.) The great big irony here is just that "serverless hosting" is just an extremely silly new name for "shared hosting". The basic economics are the same: instead of paying for a whole server, pay for what you use, then share the remaining resources with other sites. The new serverless hosts aren't just trying to replicate the "good old days" experience, in some cases they've inherited it. They've also just had the bad luck of hindsight from past shared hosting model problems: insecure FTP is dead (so there's much less of a feeling of "just copy the files over"), allowing direct crontab editing is known to be dangerous in shared hosts so serverless options need their own (often extremely custom) timed kickoff DSLs, hosting static files and application files in the same place is known to cause accidents so there's a greater separation in static hosting and serverless applications, and so forth. A lot of those same complications happened to a lot of the "classic" shared hosts, too. (Which is why many of those entrenched to specialize in known applications over time, cPanel anything you want as long as it is Wordpress or Drupal or one of the other six blog apps the host vetted. The disappearance of "shared hosting" wasn't just that modern development got complicated but that modern shared machine security got harder.)
- meterthusquite 3y ago
  "Serverless" is one of those names that kinda-sorta-almost makes sense: It's that your code runs "on no server (in particular)" rather than "on no server (at all)". Someone stripped off that nuance in trying to come up with a concise buzzphrase for code that expects ephemeral access to an arbitrary server.
0xblinq 3y ago
We can still do that. It still works. You can still just use rails or Laravel and deploy to heroku. Or just a single php file. The only reason we don’t do it anymore in the cases where that would be enough and instead overengineer everything is because others will look us down.

fabian2k 3y ago

The non-serverless version still works fine, even in modern JS land. The simple approach still works if you have some knowledge around setting up a server and configuring a few things. I also think that the advice around Authentication is often misguided. For simple cases it's not that hard to add authentication without a separate service. There is too much scaring the newbies around that topic, when they are probably about as likely to mess up authentication when they try to configure an excessively complex library compared to implementing basic session authentication with the tools their framework provides.

WorldMaker 3y ago

Even in the good old days you still had a database provider (often PHP plus MySQL in the classic LAMP stack) and in some cases an Auth provider (especially if you consider classic tools like Wordpress and Drupal as Auth providers). (Relatedly, the advice about Auth is best "don't roll your own auth" and that doesn't mean that you have to use an Auth provider, but at least use a library vetted by others. I also tend to add "don't keep passwords in your database" because that is a [legal/accounting] liability issue [more than being "hard", though it can seem hard to do right], which does make it good advice to find a third-party Auth provider you trust if you must support password-based workflows. Luckily some new options and libraries for password-less Auth are becoming slowly more common.) The great big irony here is just that "serverless hosting" is just an extremely silly new name for "shared hosting". The basic economics are the same: instead of paying for a whole server, pay for what you use, then share the remaining resources with other sites. The new serverless hosts aren't just trying to replicate the "good old days" experience, in some cases they've inherited it. They've also just had the bad luck of hindsight from past shared hosting model problems: insecure FTP is dead (so there's much less of a feeling of "just copy the files over"), allowing direct crontab editing is known to be dangerous in shared hosts so serverless options need their own (often extremely custom) timed kickoff DSLs, hosting static files and application files in the same place is known to cause accidents so there's a greater separation in static hosting and serverless applications, and so forth. A lot of those same complications happened to a lot of the "classic" shared hosts, too. (Which is why many of those entrenched to specialize in known applications over time, cPanel anything you want as long as it is Wordpress or Drupal or one of the other six blog apps the host vetted. The disappearance of "shared hosting" wasn't just that modern development got complicated but that modern shared machine security got harder.)

meterthusquite 3y ago
"Serverless" is one of those names that kinda-sorta-almost makes sense: It's that your code runs "on no server (in particular)" rather than "on no server (at all)". Someone stripped off that nuance in trying to come up with a concise buzzphrase for code that expects ephemeral access to an arbitrary server.

0xblinq 3y ago

We can still do that. It still works. You can still just use rails or Laravel and deploy to heroku. Or just a single php file. The only reason we don’t do it anymore in the cases where that would be enough and instead overengineer everything is because others will look us down.