
Lumen – A micro-framework by Laravel - ericbarnes
https://laravel-news.com/2015/04/lumen/
======
j42
As someone who develops/maintains many high-IO requirement PHP microservices
(as part of a service-oriented architecture, or, SOA), I'm torn on this one.

Laravel is one of my favorite frameworks, especially since 5.0 given its noble
attempt to adhere to contract-first/interfaced development and many best
practices that in some ways prevent the "worst" kinds of code from being
written. It's not static typing, but it's a step in the right direction.

This seems like it's heavily optimized over the Laravel base, and if high
speed and concurrency is important enough that you'd choose Lumen, then it
seems like you'd still be stopping halfway in a bit of a "if you have a hammer
everything seems like a nail" situation. Unless I'm missing something Lumen
still requires resources to be bootstrapped on request, and ultimately that
(in the context of a framework) will lead to memory leaks in a loosely-typed
language; no way around that.

Also because disk writes will quickly become the bottleneck before your
network capacity does, the two most relevant performance enhancements are to
use a non-blocking event-loop (with expensive writes deferred to a tick cycle)
and to completely avoid any unnecessary per-request bootstrapping--best done
with raw PHP and ideally kept simple. This, combined with an optimized TCP
configuration and split-per-process nginx LB at the head will give me r/s
10-50x the purported benchmarks. As much as 1000x when introducing intelligent
edge-caching rules.

Is there a situation where this would be the right tool for the job/more ideal
than the base framework but not worthy of a "roll-your-own" solution?

Either way +1 for Taylor Otwell as a developer and the general quality of his
code/releases--Laravel is an ambitious project, and as a developer quite
enjoyable to work with!

~~~
monk_e_boy
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!

~~~
j42
Yes! Haha I realized that when I'm working double the hours without noticing,
because the challenges are finally unique enough to be interesting :)

I think you hit the nail on the head again too, since frameworks as a
philosophy don't intrinsically value shared-nothing (SN) principles which is
the other 'dimension' to scalable concurrency--from a devops perspective,
anyway.

And while there's never _complete_ isolation, minimizing that interdependence
makes your builds that much more environment-agnostic, and easy to provision
dynamically.

Honestly what I'd love to see is a kernel-up PHP environment/container that
doesn't focus on runtime in isolation, but the entire TCP stack from syscntl
to the webserver (h2o?) and maybe even with some experimental support to
extract frequent commands to compiled modules with C headers.

But by that point you'd probably just be using Go or Haskell because that's
what compiled, statically-typed languages are for ;)

------
dustinlakin
PHP frameworks have come a long way, and so has the language. The big thing
that stands out, is that three of the best frameworks in the space (Laravel,
Symfony and Slim) work together and feel a friendly/healthy sense of
competition. They are reusing each others components and building a much more
promising future for PHP.

~~~
monk_e_boy
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!

~~~
imaginenore
Drupal is becoming more and more insane with each release (especially 6 -> 7).
The database structure is really getting out of hand. It's becoming harder and
harder to deal with the performance issues.

~~~
monk_e_boy
Yeah... I don't know what to think about performance. We tend to be careful
with page design and cache everything so once the cache is built the site
flies.

But developing a drupal site is painful. Clearing the cache every few minutes
takes forever.

------
hising
Looks nice, I really like Slim Framework, this looks a lot like Slim from what
I could tell. Gonna be interesting to see how (if at all) this will effect
some performance focus from the Slim developers.

~~~
jonkiddy
I completely agree. I've used Slim in lieu of Laravel for a number of small
API projects. I'm excited about porting them over to Lumen.

~~~
mcao
Have you ever tried Flight, [http://flightphp.com](http://flightphp.com)? It
has a smaller footprint than Slim but still has the ability to drop in PHP
components. Disclaimer, I'm the author of Flight.

~~~
nodesocket
We ([https://commando.io](https://commando.io)) use Flight for our API and
love it. Super minimal, but provides all the functionality we require. The
ability to map custom functions into the Flight namespace is great.

------
bhauer
I've just created an issue [1] in our FrameworkBenchmarks project to solicit
an implementation of our tests on Lumen. If anyone here is willing to
contribute such an implementation, it would be greatly appreciated. The
promise of performance caught my eye!

Incidentally, Round 10 is arriving soon.

[1]
[https://github.com/TechEmpower/FrameworkBenchmarks/issues/15...](https://github.com/TechEmpower/FrameworkBenchmarks/issues/1530)

~~~
imaginenore
I hope they add React-PHP.

------
seandavidfisher
Looks really interesting. PHP may not be the "hip" language to use (although
it's getting better), but it's so popular and accessible that disregarding it
as a legitimate option for new projects is myopic.

~~~
pyre
I've talked to people doing large-scale deployments in PHP that complain about
things like memory-leaks, etc in the language, so I'm not entirely convinced
that PHP is really an excellent language (and runtime) that just happens to
get a bad rap.

~~~
cweagans
I'm a PHP developer that works for a major media company. We do large scale
deployments, and I'd like to say that PHP is a terrible language that gets a
bad rap. It's getting better, and it's already 1000000x better than the PHP4
days, but it's still not a nice language. It's not a nice runtime. The only
thing nice about it is that a zillion people and their dogs all know it and
it's relatively easy to deploy.

~~~
look_lookatme
Do you use an off the shelf framework or CMS?

~~~
cweagans
We use Drupal.

~~~
Gigablah
Well, there you go.

~~~
cweagans
Are you suggesting that off-the-shelf frameworks/CMSes are somehow inferior to
writing everything from scratch? That seems pretty myopic. We gain a lot from
using Drupal.

------
wesray
The drop in functionality right into the full framework is fantastic. Really
like the ability to write API's with much less overhead, which was a factor
that came into play for me recently. Nicely done Mr. Otwell.

~~~
xrstf
The same holds true for Silex[1], the Symfony Components-based micro
framework. Silex and Lumen look very similar (not only because Laraval/Lumen
use Sf Components as well), not only because both use (just as Laravel) Sf
Components. Slim 3 seems to move in the same direction of modern PHP
frameworks, where you _return_ a response from your controller, instead of
setting up some global state (the main thing I don't like about Slim 1 & 2).

For now, Silex is still my favorite, as it has the temporary bonus of having
more providers available to integrate 3rd party libraries. Sure, I can drop-in
whatever library I like, but having someone do the setup (configuring Twig
alone can be a burden if you want to get it right) just makes it easier for me
;)

[1] [http://silex.sensiolabs.org/](http://silex.sensiolabs.org/)

~~~
conradfr
I've done some projects with Silex and it's not bad but I've found myself
losing quit a bit of time because you can never really use most components
exactly like in the Symfony standard distribution but the docs mostly show you
that way.

Also you have to be careful with dependencies version or you're quickly in
Composer hell (because Symfony moves forward so fast).

Always wanted to compare it with Slim but didn't take the time.

~~~
acomjean
>you can never really use most components exactly like in the Symfony standard
distribution

I'm glad its not just me. The documentation gave me problems. I started
wondering why I didn't just use symfony in the first place.

~~~
conradfr
Hehe, I'm in fact switching my two ongoing side projects from Silex to
Symfony.

It also helps me keeping current with the framework since it's currently all
the rage in the (French) PHP job market.

------
quaffapint
For a micro framework, highly recommend FatFreeFramework - You can see in the
upcoming benchmarks how incredibly well it performs for a drop-in (non-
compiled) framework...
[http://www.techempower.com/benchmarks/previews/round10/#sect...](http://www.techempower.com/benchmarks/previews/round10/#section=data-r10&hw=peak&test=query&l=sg)
...Also I've found it much easier to learn and use than ones like laravel.

------
fideloper
Also interested to see what projects use this as a core "micro framework"
service or with an SOA architecture. Seems like good flexibility between
framework power and lightweight.

------
Beatus
I've just created a project with lumen to have a look at it and lumen and all
its vendor packages (with --no-dev and without tests) contain 1522 files and
102449 lines of code – according to cloc.

Am I doing something wrong or why does it call itself a "micro-framework". A
newly created Slim project contains 7417 lines of code.

~~~
pan69
How many lines of code should a micro framework have?

~~~
Beatus
It should be near other PHP micro-frameworks:

\- BulletPHP: 3946 lines of PHP code

\- Slim: 7329 lines of PHP code

\- limonade: 3669 lines of PHP code

\- Lumen: 95'220 lines of PHP code

You can't call it a micro framework if it's more than ten times bigger than
all the other ones.

~~~
pan69
Lines of code is obliviously not a benchmark to rank a micro framework.

The term "mirco" refers to the amount of functionality the framework exposes.
Often a micro framework is just a router decorated with some other useful
stuff. Who cares about lines code, especially when you count "all"
dependencies in vendor.

------
debaserab2
Where's the source for the benchmarks that are displayed as the first item on
the project page for this?

------
sergiotapia
How painless is deploying a Lumen/Laravel application? I used to use PHP back
in 2006 and I remember deploying was as easy as pushing a .php file via FTP.

Has the experience remained the same? PHP was incredibly simple to deploy.

~~~
mmmm
Yes, and even more so with [https://envoyer.io/](https://envoyer.io/) \-
according to the website a Laravel product.

~~~
jonkiddy
How is this different from Laravel Forge?
[https://forge.laravel.com/](https://forge.laravel.com/)

~~~
mmmm
Taylor Otwell have replied to a similar question here before:
[https://laracasts.com/discuss/channels/general-
discussion/en...](https://laracasts.com/discuss/channels/general-
discussion/envoyerio-forge)

> They really aren't similar at all. Forge manages sub-domains, Nginx, Cron
> jobs, SSL certificates, queue daemons, recipes, etc. Envoyer does none of
> those things. Envoyer is solely focused on deploying PHP applications to
> multiple servers with zero downtime.

------
JimmaDaRustla
They compare it to Slim 3, which isn't completed yet, sitting in a development
branch...

Slim 3 will also be PSR-7 compliant, I don't see anything about that anywhere
in these Lumen docs.

~~~
giaour
The framework's author addressed this on reddit:
[http://www.reddit.com/r/PHP/comments/32kajb/lumen_php_microf...](http://www.reddit.com/r/PHP/comments/32kajb/lumen_php_microframework_by_laravel/cqc1hml)

~~~
JimmaDaRustla
Interesting. I guess he/she is implying that Lumen is PSR-7 compliant than by
the last sentence?

Thanks!

~~~
giaour
Lumen uses the same request and response objects as Laravel, which extend
Symfony's request and response objects, on which PSR-7 is based. If Lumen
isn't PSR-7 compliant once that standard is finalized, it will be shortly.

------
0x0
Any thoughts on how this will compare to Silex?

------
pearjuice
If Lumen can use all Laravel its components, can't Laravel use Lumen its
routing engine or whatever makes it that fast? What's the key difference that
Lumen is considered "fast and micro" over a standard Laravel installation?

~~~
McGlockenshire
The routing engine is NikiC's excellent FastRoute:
[https://github.com/nikic/FastRoute](https://github.com/nikic/FastRoute)

My understanding is that the majority of the advertised speed increase has to
do with lazy initialization of the request/response stuff and the need to
expressly ask for things like session support.

e: Here's an explanation from reddit,
[http://www.reddit.com/r/PHP/comments/32kajb/lumen_php_microf...](http://www.reddit.com/r/PHP/comments/32kajb/lumen_php_microframework_by_laravel/cqbzp32)

~~~
noir_lord
Pretty much.

Laravel's strength is that it is batteries included but for some stuff this
can be a weakness, API's where that 30-40ms load time matters for example.

I've spent a couple of years working with and on laravel projects and mostly I
like it a great deal but it is a sledgehammer when sometimes you need a
ballpein.

------
EGreg
I'm sure this is great, but can I see some benchmarks?

I think many frameworks allow you to include the "basic" subset of the
framework, without running all the usual Inversion of Control bootstrapping.

------
evoratec
Lumen is not micro, is a Slim-Laravel.

------
ing33k
glad to see use of symfony/http-kernel and symfony/http-foundation .

~~~
jbrooksuk
Laravel itself uses these components.
[https://github.com/laravel/framework/blob/513960ff768c3bbe9d...](https://github.com/laravel/framework/blob/513960ff768c3bbe9d19c4923e3564de3dff745c/composer.json#L35-36)

------
adaml_623
Really the biggest drawback to PHP is the lower salaries

~~~
mildweed
Market salaries are for rank and file coders. Build something that's wildly
successful, and it won't matter what the language was.

------
crazychrome
looks good, only 7 years late to the game.

~~~
arenaninja
Well, consider that Silex and Slim have been out for a while already and no,
not really. I think it's about having options more than anything else at this
point

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

~~~
makeitsuckless
This attitude, the illusion that RoR is year zero in software development is
the #1 reason why Rails has become toxic for many companies.

Hordes of hipster RoR developers making the same mistakes all over again
because they refuse to learn from mistakes already made by others. Turning
project after project into an unmanageable mess with a marginal life
expectancy because they believe their superior elegant language and one-size-
fits-all opinionated framework means they don't have to think about
architecture and design.

In all my years I've never seen a developer movement piss away its initial
success so rapidly as the Rails community.

