Hacker News new | past | comments | ask | show | jobs | submit login

> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing.

Except in reality once you want to use non /whatever/file.php as urls - you're back to implementing a router

> PHP files can be deployed independently, swapped out or updated live. Intuitive, simple, powerful. Can be as easy as editing a php file in notepad and dropping it on a ftp server. Deployed.

Except in reality, you don't want to deploy directly after editing a file since it's like deploying to production, you're gonna have a bad time.

> A single layer as opposed to 'modern architecture' where there's client side back/front end layers, api layer, logic, validator, data access, and ORM layers.

Except in reality, that just leads to a bunch of spaghetti code with no separation of concerns and impossible to maintain.

> Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?)

Except in reality, this only works with php apps that have an integrated package manager and even then it leads to problems when a version is incompatible both in php or plugin dependency.

> Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again.

Except in reality, serverless lambda is a terrible idea:

1. lock in to a specific platform with limited visibility tools and a dependency on a 3rd party when shit doesn't work

2. when functions change you run into function incompatibility chaos and no smart way to handle that mess

3. the "scalability" win is a lie, it's just deferred to whatever data storage service you are using - which ends up blowing up because while serverless scales, the db doesn't

4. addendum to 3, the statelessness of lambda means you can not use local caches to increase your throughput - increasing your hardware requirement

> Compiling/deploying an entire system to change a single endpoint feels backwards after using PHP.

Except in reality, you are notified of a bunch of potential bugs right there and then, instead of "maybe" finding out about them at runtime especially since PHP will by default consider a non defined variable just an empty string and display it as such on the page, and it's not until Joe User notices it that you'd ever find out.




1. lock in to a specific platform with limited visibility tools and a dependency on a 3rd party when shit doesn't work

The logging analysis tools are excellent and it’s quite easy to tie your lambda logging to whatever tool you are using.

As far as “lock-in”, there is an Amazon provided framework in every supported language to just add a proxy that allows you to use your standard framework (Node/Express C#/ASP.Net, etc) and you cab deploy to Lambda or your traditional web server with no code changes.

2. when functions change you run into function incompatibility chaos and no smart way to handle that mess

What???

3. the "scalability" win is a lie, it's just deferred to whatever data storage service you are using - which ends up blowing up because while serverless scales, the db doesn't

Serverless Aurora (Mysql) and DynamoDB both have autoscaling. You can also auto scale Read Replicas fast with traditional Aurora.

4. addendum to 3, the statelessness of lambda means you can not use local caches to increase your throughput - increasing your hardware requirement

Again not true, if you are calling an endpoint frequently, the instance stays warm for up to around 15 minutes and can maintain state.


Regarding (4) Lambda and friends are not actually stateless between requests; the process is initialized once and then potentially reused many times for hours, so you can cache between requests, both in memory or in the filesystem (AWS Lambda provides 512MB in /tmp).




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: