Lumen – A micro-framework by Laravel

> What Rails is to Laravel, Sinatra is to lumen. Nothing more than another copycat idea from the ruby/rails world.

I must be misunderstanding your point, because the way I read what you wrote, you are insinuating that incorporating good ideas already implemented in a different incompatible technology stack is worthless.

E.g. making a good text editor for windows is worthless because vim/emacs exists, or making a python library for parsing HTML is worthless because there is already a perl one?

> Has the experience remained the same?

Yes and no. The PHP language and run-time continue to value backwards compatibility and, ultimately, a PHP application is still just a collection of PHP files sitting on a web server somewhere. If you want to work like it's 2006 you can.

However -- Modern PHP (Laravel included) bring a few winkles to the table and most deployments will have extra complications for folks expecting to just "FTP a file" (also, I hope you meant SFTP a file (-:)

For example, Laravel (similar to rails) has migrations for creating and updating your database schema. You don't need to use migrations, but if you do your deployment becomes a bit more complicated.

Also -- although PHP namespaces have come a long way, they're still not up-to-par with (or, in PHP group-speak "have different goals than") ruby or python's module system. The Composer packaging system has stepped in to fill this gap, but this means a modern PHP deployment needs to

1. Generate composer autoload cache files 2. Fetch, download and install any updated composer packages (i.e. third party libraries)

Again, there's nothing stopping you from working locally and SFTPing or rsyncing all your local files (composer packages/autoload files included) to the server, but most teams develop a more formal deployment process than that.

How you host your PHP application is going to effect how you deploy. There's still many, many PHP hosting companies offering `mod_php` based hosting, but there's also a large number of projects who use a Fast-CGI/FPM approach (either with Apache or nginx). The difference in process models brings a different in the unix permissions model, and that often means there's extra steps needed to ensure file based cache system can write to their storage engines.

And speaking of caching, 20% of any "serious" PHP developer's time is spent sorting out the various framework level caching systems, as well as PHP based opt-code caching. I mention this here mainly to point out that some sort of cache refresh and/or warming is common in signifigant/long-standing PHP systems.

Deployment's still easier in PHP than in other frameworks, but if you're expect a wild west "just edit files on the server and you're good to go", expect push-back from your modern, professional, PHP developers :)

This. It really depends how you use it.

In some ways they've introduced some powerful features bringing it on par with other languages, but the reality is that performance varies wildly in the real world because opcaches are finicky dependent on the data/request type/frequency and automated GC/circular-reference optimization is far from perfect.

Between HHVM (to effectively make memory growth linear vs logarithmic when approaching higher request concurrency) and sensible opcache tweaks you can make that runtime a bit less stochastic at scale, however if you don't know what you're doing PHP makes it so easy to go in the complete opposite direction without any indications you're running toward a cliff...

I guess if the micro service is using a bunch of shared code from a Laravel project (maybe just interfacing with the database) or if your team is large and already using Laravel, then the first step of optimizing a service into a 'micro service' is to use Lumen. Then step two (if Lumen isn't going fast enough) is to go raw PHP as you described.

But if your service is getting that popular, memory leaks are going to be a problem, maybe moving to HipHop (or whatever it's called now) or Node or something is a better idea.

Sounds like you're having fun!

Drupal 8 is based on Symfony -- things are really moving in the right direction.

Personally, I was a huge fan of Zend Framework + Doctrine, but these frameworks are all mature and great to use.... almost as good as Rails (lol, OK, OK, don't mention Ruby within earshot of PHP fans ;)

[edit] down voted for my opinion! Argh my tiny karma is depleted -- damn you ruby, damn you to hell!