Lumen – A micro-framework by Laravel | Hacker News Reader

Lumen – A micro-framework by Laravel

laravel-news.com

226 pointsericbarnes110 comments

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!

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!

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 ;)

I'm a php dev (amongst others) and I use it everyday at work but if I'm getting to the point where lumen or something like it is the bottleneck I'd just dump PHP altogether and go to a compiled language.

There is a niche I think for faster than laravel but not incredibly optimised, its another tool not the tool.

Bingo.

At that point you've hit on the essential purpose/elegance of static types and a compiler :)

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

Can you expand upon that or provide a link with more info? Why would it lead to memory leaks?

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.

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!

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.

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.

Which project reuses laravel components?

Laravel is built on Symfony components, and much of Laravel can be used outside of Laravel.

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.

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.

Have you ever tried Flight, 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.

Curious, but why don't your docs request that the install be done with Composer? Manually downloading a tarball isn't the best solution for managing an application dependency.

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

Official blog post on Lumen on the Slim Framework website:

http://www.slimframework.com/2015/04/14/lumen.html

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

I hope they add React-PHP.

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.

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.

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.

Any experience with HHVM yet?

We haven't been/won't be using it. Most of our traffic is anonymous, so we can optimize other parts of our stack. We'd rather not have to debug weird shit that comes up because of HHVM incompatibility.

Do you use an off the shelf framework or CMS?

We use Drupal.

Well, there you go.

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.

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've talked to people doing large-scale deployments in PHP that complain about things like memory-leaks, etc in the language

What does it mean for a language to have memory leaks? Are you talking about a problem specific to the PHP runtime or common PHP idioms that lead to leaky code? A specific example would be helpful as I've never known PHP to be particularly vulnerable to memory-leak bugs (at least not any more than any of the other popular imperative scripting languages).

Also, what's the substance behind the "etc" in your comment? I'm not really sure what naturally follows in the sequence of "memory-leaks and so on...."

Your comment seems to simply cast doubt without much substance.

> What does it mean for a language to have memory leaks?

I'm not embroiled in the PHP-world, so I don't know how many alternate PHP runtimes exist, but I presume that the default PHP runtime itself was being referenced. Seeing as for a long time there was a single runtime paired with the language (I'm 99% sure that PHP4 didn't have alternate runtimes), I think that equating bugs in the runtime with bugs in the language is something that happens even if technically they are separate things.

> Your comment seems to simply cast doubt without much substance.

And your comment seems needlessly defensive. I made a comment about general sentiment that I've gotten from people that have actual working knowledge of large-scale PHP deployments. I'm sorry that in the middle of the conversation I didn't start immediately interrogating these people asking why they haven't filed bug reports if there are memory leaks.

Also, is it devoid of substance if I'm basically stating that I've talked to people "in the trenches" (and presumably know what they are talking about) who don't have the opinion that PHP is some beautiful, but misunderstood language that gets a bad rap?

> Also, what's the substance behind the "etc" in your comment? I'm not really sure what naturally follows in the sequence of "memory-leaks and so on...."

Maybe I should have phrased that as "(e.g. memory leaks)" to show that memory leaks weren't the only complaint, but my memory fails me on what the other complaints were.

I'd say writing off an entire language with a vague anecdote is worth at least a little scrutiny or clarification.

People have been doing that with PHP for years.

Yes, it's true that there's a ton of really bad code out there. But that's a measure of it's popularity.

There's also a ton of bad C and Java out there.

And yet, no one dismisses those languages because of that.

As far as I can tell, anecdotes, social proof, and familiarity play far more a role in the reputations of almost every language/tool than most engineers seem prepared to admit.

(But don't worry, dear reader -- you're probably the exception!)

PHP gets singled out for a bit of extra abuse (some perhaps justifiably, some not so much), but it's far from the only language whose popular conception is not so much based on thoughtful evaluation.

> I'm not embroiled in the PHP-world, so I don't know how many alternate PHP runtimes exist, but I presume that the default PHP runtime itself was being referenced.

So are you talking about the default PHP 4 runtime or the default PHP 5.3 runtime or the default PHP 5.4 runtime etc? These versions are very different beasts, so levying a vague "memory leak" criticism at PHP without substantiating it via code or even a version makes the criticism pretty meaningless.

> I think that equating bugs in the runtime with bugs in the language is something that happens even if technically they are separate things.

I asked for clarification because I was unsure what you were referring to. For example, about a month ago I was tasked with debugging a memory leak in a legacy Ruby application where I eventually discovered that the developer had used a proc in such a way that it prevented the GC from freeing variables that had been referenced in the closure. It was an issue somewhat similar to the examples described in this blog post:

http://victorarias.com.br/2013/08/13/leaky-ruby.html

I wouldn't attribute this memory leak to the Ruby langauge but more to a Ruby idiom that developers should take care to avoid. That's the type of clarification I'm looking for, but it appears that you don't really have anything to offer the discussion in this regard.

> And your comment seems needlessly defensive. I made a comment about general sentiment that I've gotten from people that have actual working knowledge of large-scale PHP deployments. I'm sorry that in the middle of the conversation I didn't start immediately interrogating these people asking why they haven't filed bug reports if there are memory leaks.

I have no emotions tied up in this discussion, I'm trying to make a point that your criticism is just anecdotal hearsay without any way for someone to verify if what you're saying is actually true. I didn't suggest that you ask your colleagues to file bug reports, I was simply pressing you for more details since your vague anecdote runs counter to my own experiences with PHP as I relate it to the rest of the imperative scripting landscape.

> Also, is it devoid of substance if I'm basically stating that I've talked to people "in the trenches" (and presumably know what they are talking about) who don't have the opinion that PHP is some beautiful, but misunderstood language that gets a bad rap

Yes, that is pretty much the definition of "devoid of substance". "In the trenches" is a subjective description that doesn't mean anything. You presume they know what they're talking about, but maybe they actually don't, but we'll never know either way because all you've done is recount nebulous secondhand generalizations. You're not even asking me to take your word for it, you're asking me to take your word for their word. Can't you see why that's a little dubious?

PHP the runtime was built with a reload on every page load in mind, so a lot of cleaning up simply didn't need to happen. If it's in the runtime or how it's used doesn't matter.

It was a big deal when transitioning to the FPM runtime. That's why persistent PHP runtimes like FPM still have the option to completely reinitialize itself after a set number of pageviews. It's a bit like fixing leaks by rebooting, but it's fast enough not to be noticeable.

Admittedly, the "restart server process after N connections" method of dealing with memory leaks is not specific to just PHP.

It's also present in Apache, and thus mod_rails and mod_wsgi, by default[1], is an option in Gunicorn[2], and a gem is also available to provide the same in Unicorn.[3]

1 http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxrequ...

2 http://gunicorn-docs.readthedocs.org/en/latest/settings.html...

3 https://github.com/kzk/unicorn-worker-killer

I wouldn't be surprised if those memory leaks were due to an older version of PHP (GC was recently improved a lot to clean up circular references) or a poorly-written framework, which most of them are. Some people also don't understand that arrays of large data have to be wrapped in objects or explicitly passed by reference in many situations to avoid duplicating them in memory.

I've used PHP a few times in the past for some long-running, complex cron jobs, and I never had memory leaks. I've also never noticed it for short-running HTTP responses, and some of those have been really awful and messy because I'm more of a PHP doctor than someone who starts projects with it.

Anyway, everyone is going to benefit from HHVM. If Facebook uses it in production, you can be sure that it won't have any common memory leaks for long.

> Some people also don't understand that arrays of large data have to be wrapped in objects or explicitly passed by reference in many situations to avoid duplicating them in memory.

IIRC arrays are always passed by reference and only duplicated if you modify the data inside the called function (if not passed with '&' of course) ?

Correct. The runtime uses a copy-on-write implementation when you pass an array by value.

Duplicating an array in memory every time it is passed to or from a function would be awful.

> Duplicating an array in memory every time it is passed to or from a function would be awful.

This might be because I originally learned PHP about 16 years ago, but I could swear this used to be the case. There's definitely a reason PHP has the reputation it has, although many of those glaring issues have since been fixed.

I started with PHP3 and also didn't know or care about that for a long time. Then Doctrine with its hydrators and PHP daemons became a thing in the workplace and all of sudden you have to be a bit more careful with data size and memory management.

Call-time pass-by-reference (passing with '&') has been either deprecated or removed. It has to be done in the function signature.

> only duplicated if you modify the data inside the called function

I did not know that. Because I've observed the duplication behavior, I assumed that it was never a reference. I guess that's a "feature" when you don't really have any fine-grained, explicit control over pointers or references.

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.

This is a serious advantage to other frameworks if this principal holds true. I think anyone working in PHP has had their tails burnt a little too often with all the framework churn.

This is definitely a very cool feature and makes this a very good candidate for MVP's or prototypes. I'm not a huge Laravel fan, but this feature alone might sway my decision.

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/

I've used "Silex" and "Slim" in various small projects and API's. Then I found PhalconPHP.com I prefer using Micro+Volt now. New version 2.0 will be released on April 17th, 2015 So check it out, you may like "volt" template engine more :-)

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.

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

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.

Benjamin Eberlei argues for the same approach here: http://www.whitewashing.de/2014/10/26/symfony_all_the_things...

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... ...Also I've found it much easier to learn and use than ones like laravel.

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.

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.

How many lines of code should a micro framework have?

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.

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.

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

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.

Yes, and even more so with https://envoyer.io/ - according to the website a Laravel product.

How is this different from Laravel Forge? https://forge.laravel.com/

Taylor Otwell have replied to a similar question here before: https://laracasts.com/discuss/channels/general-discussion/en...

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

Forge does server provisioning and Envoyer does deployment of PHP web applications. So not quite the same at all.

you can still do that.

Nobody uses FTP for deployment anymore, but the idea is still the same: just get the file to the server.

You mean that you think it's not hip to use FTP? Because people definitely still do this.

No, I mean that using FTP is the wrong/insecure/slow way to do it. SFTP at a minimum, please.

Do you always twist your words or just sometimes

I wish I could say that's true, but it's not.

> 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 :)

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.

The framework's author addressed this on reddit: http://www.reddit.com/r/PHP/comments/32kajb/lumen_php_microf...

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

Thanks!

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.

Any thoughts on how this will compare to Silex?

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?

The routing engine is NikiC's excellent 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...

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.

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.

Lumen is not micro, is a Slim-Laravel.

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

Laravel itself uses these components. https://github.com/laravel/framework/blob/513960ff768c3bbe9d...

Really the biggest drawback to PHP is the lower salaries

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

looks good, only 7 years late to the game.

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

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

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

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.

Reply on news.ycombinator.com