[Lumen] Future of Lumen vs Laravel?

[barryvdh]

I haven't used Lumen in a while, but is there still a place for Lumen? What are the big advantages for it currently? It's supposed to be speed, but is that really still the case? If so, can't we focus on bringing the performance to Laravel?

As I remember, one of the benefits was a different Router (https://github.com/nikic/FastRoute), which was also the biggest pain when converting routes. But with Symfony4, the Symfony Router (in Laravel) is supposed to be even faster.. https://symfony.com/blog/new-in-symfony-4-1-fastest-php-router

For example, would it be possible to create different configurations within Laravel, even more drastically then just using middleware? For example, an api.php besides index.php, which loads config/api.php for ServiceProviders etc, instead of config/app.php. (Eg. don't load views, sessions etc)

(Not sure how realistic benchmarks like http://www.phpbenchmarks.com/en/comparator/framework are, but it does show that Laravel might be lacking some API performance, compared with Symfony 4)

Ref: https://medium.com/@laurencei/lumen-vs-laravel-performance-in-2018-1a9346428c01

Personally I think that most project with an API will mostly reach a point where just Lumen isn't sufficient, but that might just be me..

EDIT 2019-07-05: Just to be clear, I'm not saying Laravel is slow. But if performance is a non-issue, Lumen might be not required at all. See https://github.com/laravel/ideas/issues/1631#issuecomment-506859306

[ludo237]

Lumen can be good as companion for micro services that can coexists with the main laravel application

[barryvdh]

Yeah but in my experience you're mostly building the API together with your package? Or is everyone building microservices and sharing models etc?

[martinbean]

The company I work for started building an API in Lumen and it’s painful, mainly because it doesn’t have much of the “useful” features Laravel has. The router, form requests, route–model binding, etc.

[CupOfTea696]

But Lumen does provide a robust starting point, after which you can pull in everything you need on top of it, without having a lot of other things that you wouldn't be using. All of the view related stuff is completely irrelevant if you're building an API.

[martinbean]

@CupOfTea696 Yes, but lots of other helpful things—that may apply to an API—aren’t present. Like, route–model binding is a godsend for controller actions that just return a model. But it’s not in Lumen, so you have to query your models in your actions instead of getting a model instance injected.

Having tried using Lumen for APIs in the past, I’d still use Laravel if starting from scratch. You can disable service providers for services you don’t need (i.e. Blade).

[CupOfTea696]

Yeah but most of those things are still available, or have unofficial packages for them. E.g. for route model binding, there's this one: https://packagist.org/packages/mmghv/lumen-route-binding

[martinbean]

@CupOfTea696 But what’s the point of having a “slimmed down” framework if you just have to then re-install components to make it useful again?

[barryvdh]

My point exactly, if the basis of Lumen is just 'less service providers enabled', then it would be more easy to create a seperate config for just the API routes :P

[CupOfTea696]

Because you can only install the things you actually need, rather than bloating your project with things you don't?

[barryvdh]

If that's a problem, it would make more sense to separate Laravel packages into own projects (like horizon, telescope etc), where you only require them if you actually need them (for example, broadcasting, views, sessions), or require those by default with Laravel, but not create a whole different framework.

[mattstauffer]

I don't have a really strong opinion--I never use Lumen anymore--but just FWIW, it's not just about components loaded, but actually a different bootstrap and number of files loaded and included.

I can't say I know exactly how much it is of each, but just so everyone has that foundational knowledge.

[chay22]

I leave Lumen alone when I remember it was built for speed and mostly used for serving API and realized I have to load bloated services (session, eloquent?, etc) in order to make it to work happily when using Laravel Passport. Not to mention the number of other packages beside auth purpose to load.

[xtrasmal]

Well I just rediscovered Lumen and I am happy it is still around. @barryvdh Telescope and a lot of(most) Laravel packages focus on Eloquent. For the last 3 years I have been using laravel-doctrine, so I missed many of the cool things lately. I do play with the it, but can't use it in my production applications. Now I am setting up Lumen as a forefront, API Gateway with CircuitBreaker and Passport. It will have facillities for JSONSchema response and request validation for it's internal publi api all connected aggregated services, which will be automatically discovered after talking to consul.io's api. I think Lumen, in this case is a perfect choice. Nice and lean, also focussed.

[mfn]

From the POV of Laravel package authors:

It's already quite some investment to properly maintain a package only for Laravel.

Lumen comes along on top of it, adds additional complexity especially around routing where certain interfaces work differently etc.

However OTOH I'm surprised how many people do use Lumen based on issues I see.

So there's that.

Personally before going for Lumen I always picked Laravel and stripped it down. It's easier to later "upgrade" missing parts, should the project scope expand.

[xtrasmal]

Y'all probably right.

[xtrasmal]

...meaning that we could try to remove all unneeded providers during bootstrap and add more when you need to.

[halaei]

I have never used Lumen and always advised against it. I am glad I am not the only one. It seems Lumen was mostly a way to boost performance. But with advances in what Laravel is based on, e.g. Symfony Router and the coming-soon Preloading of PHP 7.4, in my opinion, Lumen soon has to be obsolete.

One thing I have against Lumen, is that parts of it's code is a copy of laravel/framework or laravel/laravel. So chances are a bug gets fixed or something gets improved in Laravel but not in Lumen.

[georgeboot]

We use Lumen for some micro services and it works somewhat nice. Especially when you call lots of internal micro services, the 30% response time increase can mean a lot.

However, I find myself installing a bunch of extra tools to get it fully working to my taste. This could be because I'm so used to the "it just works" from Laravel, that I expect Lumen to do the same.

My biggest annoyance is the incompatibility between Lumen and Laravel. Lots of external packages pull in illuminate/support and the helpers.php from that one clashes with the helpers.php provided by Lumen.

Idea

Wouldn't it make much more sense if Lumen was a real stripped-down version of Laravel? If you disable all of your service providers in Laravel, it won't work.

It would be truly amazing if Lumen would be the base framework with minimal options installed, and Laravel the same thing, but then with all the extra goodies included.

[barryvdh]

Yeah that would be nice, but it would'nt so much be 'Lumen', just 'Laravel Light' ;) Which is a good thing, as long as packages work with it and it's easy to upgrade to the full Laravel. Changing how the router works etc would be a breaking change for Lumen though (but for the better probably)

[kostaspt]

That would be a great change and it's actually what Symfony 4 currently does with flex. It gives you an option to generate a minimal project and then you extend it only with the functionality you need. But there is still an option to make a full the installation if you need it.

I think something like that makes more sense than having to maintain two separate projects.

[barryvdh]

So it's explained a bit in https://blog.laravel.com/laravel-snippet-14

To hopefully sum it up correctly:

• the framework itself should be fast enough already (Taylor states 3.5ms om his machine)
• The framework shouldn't be the bottleneck, and mostly is never so (db scaling is more of a problem)
• Lumen is 'finished' so doesn't really need much love, but also it shouldn't necessarily be required.

While I don't get the same numbers (I think my production framework time is more like 15ms or so), it still shouldn't be the bottleneck and application code/db calls are mostly more costly.

So I get the feeling that Lumen is mostly because people 'think they need it' and keep asking. And while it's good to cater to people, maybe in this case Lumen shouldn't be promoted. I personally wouldn't start a new project with it anyway ;)

Conclusion: Lumen doesn't get much attention anymore probably, Laravel Performance is good enough so it doesn't warrant to much changes to the core.

[mfn]

… and testing for Library authors is really a PITA because it's not supported by https://github.com/orchestral/testbench

(though I wrote already about the testing issues, back then it wasn't apparent to me it's not supported at all).

[dugajean]

I agree with @georgeboot here, except where the name Lumen has to be kept around. I don't really see a point for that. It should just be Laravel where you can setup a base installation with something like laravel new my-project --mode=skeleton or something among these lines. Without mode you just get the good old Laravel installation.

Having a separate name for Lumen just adds extra overhead to package developers and marketing itself - needing to address Lumen separately all the time, when everything could just be pointed towards Laravel directly.

[chrisbbreuer]

I agree with the approach of @dugajean. Similar to how the Adonis framework handles it laravel new my-project --api would be a quick and handy command.

We tried building out a very feature-rich Lumen app and after halfway through the development process, we realized the speed tradeoff wasn't worth it. Even when expecting "massive" traffic. So we migrated back to Laravel.

[martinbean]

We tried building out a very feature-rich Lumen app and after halfway through the development process, we realized the speed tradeoff wasn't worth it. Even when expecting "massive" traffic. So we migrated back to Laravel.

@Chris1904 I’m hoping my employer comes to the same conclusion soon 👀 Developing in Lumen—when we could do with the things that come out of the box with Laravel—is painful.

[taylorotwell]

Not really a concrete "idea".

[barryvdh]

Well with 6.0 coming up, the concrete idea could be to deprecate/stop supporting Lumen and focus entirely in Laravel itself, to make the ecosystem easier to maintain.

[crynobone]

I been avoiding to comment on this but here's my take on this issue.

I been using Laravel and Lumen for 2-3 years and it works well for our environments for what's it offers. Seeing 100ms reduction for a feature that was duplicated in Lumen vs Laravel (A reverse geolocation query to a microservice using reactphp with JSON-RPC) on our development instance so I'm not complaining.

Which ecosystem becoming hard to maintain? As far as I seen in the Laravel development nothing much are influenced by Lumen current state. Package developers has complete control whether they want to support or ignore Lumen.

Testbench for Lumen was an idea but I don't think I can build something that are stable for package developer to have tests against Laravel and Lumen without adding dependencies that might pollute the test environment. Laravel and Lumen for example does have different router deps.

[mfn]

That exactly the problem package mainainers have.

IDK people expect libraries to work in both of them and sometimes the adoptions seem easy but when you realize you have no tests for this and none of the package maintainers uses Lumen, it's a weird situation.

Not a Lumen user but try to please the users of it if I can. Publishing assets is also different or: nonexistent. You have to roll your own.

To have some testing I went lengths to create a CI job which actually installs Lumen, adds the library and does its best to test something useful via the PHP builtin web server 🤷‍♀️ but I rather would not have to do that.

[crynobone]

Not a Lumen user but try to please the users of it if I can. Publishing assets is also different or: nonexistent. You have to roll your own.

I feel this where the problem begin, when developers see that's it is possible to have it done in Lumen it will become an options for them to consider.

And overtime they will start to have bad experience working with Lumen because of lack of support by the package maintainer because they don't use it themselves but they want to get more users.

To have some testing I went lengths to create a CI job which actually installs Lumen, adds the library and does its best to test something useful via the PHP builtin web server

This is not a clean installation, I would guess the package would have already installed laravel/framework for testing the package for Laravel. Lumen only requires a subset of illuminate deps. While your tests may be green it might not be a clean installation for the users if the package developer not being careful. Here's why I stop trying to build Testbench for Lumen.

[mfn]

This is not a clean installation

It is, because it installs Lumen standalone and uses composers symlink feature to add the checked out library. There's no interference.

But: I'm not arguing for Lumen here, so reading your statements I get the impression we're on the same "side" anyway?

Btw, I was given the PoV of a package maintainer.

[barryvdh]

I been using Laravel and Lumen for 2-3 years and it works well for our environments for what's it offers. Seeing 100ms reduction for a feature that was duplicated in Lumen vs Laravel (A reverse geolocation query to a microservice using reactphp with JSON-RPC) on our development instance so I'm not complaining.

Is that with recent Laravel? (Eg. Laravel 5.8 with route/config caching, PHP 7.1+ with opcache etc?) That seems quite a big difference.

[crynobone]

Laravel 5.8 latest, Laravel with route caching, PHP 7.3.5

devs@ip-10-2-1-18:~$ php -v
PHP 7.3.5-1+0~20190503094000.38+jessie~1.gbp60a41b (cli) (built: May  3 2019 10:05:49) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.5, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.5-1+0~20190503094000.38+jessie~1.gbp60a41b, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v2.7.0beta1, Copyright (c) 2002-2018, by Derick Rethans

[xelyos94ro]

On my local Vagrant homestead the results with Postman and API are (time to finish the request): Lumen: 300ms Laravel 1100ms All have debug false, production local in env file. Same model (just make a model for each frameworks with same code inside), same database, same query. I think Laravel is not so great to build fast applications, or i made a mistake somewhere?

[barryvdh]

Well it should be optimized for production (eg. opcache enabled with stat disabled, route+config cached), but that seems slow.

[martinbean]

I don‘t really get these benchmarks. They’re not indicative of actual applications whatsoever.

• Try both a Lumen application and a Laravel application with controllers, models, business logic.
• Try a Laravel application with production optimisations as @barryvdh mentions (cached routes, config, etc).

[barryvdh]

Yeah as I said on Twitter (https://twitter.com/barryvdh/status/1147547152366874628) The boot from Laravel itself is only a few ms, but database/views/logic and netork latency etc are slower. But for an API that just does 1 tiny thing, it might be better still. But you can disable things from Laravel also if you never need them.

[xelyos94ro]

Hmm, i will build a Laravel and a Lumen application (just a table with 150 rows and a query for show them as a json response) and i will made some tests with op cache enabled and production optimizations. I will post the results here if someone are curious.

[xelyos94ro]

In production with op cache seems they both have 70ms response time, that make me thinking about. Maybe split application in two (backend Laravel and api lumen) is not so great ideea. I think i will go with Laravel for both API + Backend.

Configuration: Server 1CPU 1GB RAM Op cache enabled Composer install command: composer install --no-dev --no-interaction --prefer-dist --optimize-autoloader

Github projects: https://github.com/redLineColor/laravel-api-test https://github.com/redLineColor/lumen-api-test

[martinbean]

Maybe split application in two (backend Laravel and api lumen) is not so great ideea.

It usually never is 🙂

On a serious note though, I’d never advise splitting applications in “front” and “back” end like this. Whilst it’s a nice idea in theory, it means you now how two applications to maintain, update, provision servers for, etc. It also introduces the problem of how do you go about sharing your business logic with both applications? A shared package? That then requires a third codebase to maintain, and keep up to date in two consuming applications.

[georgeboot]

But you can disable things from Laravel also if you never need them.

I find this to be very hard. My initial thought was to just disable a bunch of service providers (as one might expect) but more than once they depend on each other.

The ones you can disable without breaking a simple page:

• BroadcastServiceProvider
• MailServiceProvider
• PasswordResetServiceProvider

[m-elewa]

I totally agree with you, I think Lumen is just the big confusion for all the new Laravel developers. I think ending Luman support would be appreciated by all the Laravel developers because then we can all focus on the main Laravel framework and make it the best fit for all cases

[stephenjude]

My pain point which is the major reason I stopped using Lumen for APIs is that lots of Laravel packages does not have a good landing spot for Lumen. In most cases I end up going back to use Laravel for my APIs.

[EthraZa]

I'm new to the scene so I'm confused as well. If Lumen can get in the way, if I only want to make a back-end script, how about laravel-zero?

[ujingene]

Whatever led me this article just changed my view on lumen. We are to go microservices way and would have easily picked node but was contemplating on using lumen thinking we could use some laravel features out of the box coming from a background of using Laravel more but now will have to consider this again.

The one issue that poses itself is what's the guarantee that switching off unrequired services in laravel to lighten it up will not affect the overall performance of the app. I have some reservations on this unless someone who has done this to provide those features they disable without breaking the system.