Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Lumen] Future of Lumen vs Laravel? #1631

Closed
barryvdh opened this issue May 9, 2019 · 41 comments

Comments

@barryvdh
Copy link

@barryvdh barryvdh commented May 9, 2019

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 #1631 (comment)

@ludo237

This comment has been minimized.

Copy link

@ludo237 ludo237 commented May 9, 2019

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

@barryvdh

This comment has been minimized.

Copy link
Author

@barryvdh barryvdh commented May 9, 2019

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

This comment has been minimized.

Copy link

@martinbean martinbean commented May 15, 2019

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

This comment has been minimized.

Copy link

@CupOfTea696 CupOfTea696 commented May 15, 2019

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

This comment has been minimized.

Copy link

@martinbean martinbean commented May 15, 2019

@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

This comment has been minimized.

Copy link

@CupOfTea696 CupOfTea696 commented May 15, 2019

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

This comment has been minimized.

Copy link

@martinbean martinbean commented May 15, 2019

@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

This comment has been minimized.

Copy link
Author

@barryvdh barryvdh commented May 15, 2019

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

This comment has been minimized.

Copy link

@CupOfTea696 CupOfTea696 commented May 16, 2019

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

@barryvdh

This comment has been minimized.

Copy link
Author

@barryvdh barryvdh commented May 16, 2019

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

This comment has been minimized.

Copy link

@mattstauffer mattstauffer commented May 16, 2019

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

This comment has been minimized.

Copy link

@chay22 chay22 commented May 20, 2019

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

This comment has been minimized.

Copy link

@xtrasmal xtrasmal commented Jun 1, 2019

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

This comment has been minimized.

Copy link

@mfn mfn commented Jun 5, 2019

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

This comment has been minimized.

Copy link

@xtrasmal xtrasmal commented Jun 6, 2019

Y'all probably right.

@xtrasmal

This comment has been minimized.

Copy link

@xtrasmal xtrasmal commented Jun 11, 2019

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

@halaei

This comment has been minimized.

Copy link

@halaei halaei commented Jun 13, 2019

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

This comment has been minimized.

Copy link

@georgeboot georgeboot commented Jun 27, 2019

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

This comment has been minimized.

Copy link
Author

@barryvdh barryvdh commented Jun 27, 2019

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

This comment has been minimized.

Copy link

@kostaspt kostaspt commented Jun 27, 2019

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

This comment has been minimized.

Copy link
Author

@barryvdh barryvdh commented Jun 28, 2019

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

This comment has been minimized.

Copy link

@mfn mfn commented Jun 28, 2019

… 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

This comment has been minimized.

Copy link

@dugajean dugajean commented Jul 5, 2019

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.

@Chris1904

This comment has been minimized.

Copy link

@Chris1904 Chris1904 commented Jul 5, 2019

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

This comment has been minimized.

Copy link

@martinbean martinbean commented Jul 7, 2019

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

This comment has been minimized.

Copy link
Member

@taylorotwell taylorotwell commented Jul 31, 2019

Not really a concrete "idea".

@barryvdh

This comment has been minimized.

Copy link
Author

@barryvdh barryvdh commented Aug 1, 2019

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

This comment has been minimized.

Copy link

@crynobone crynobone commented Aug 1, 2019

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

This comment has been minimized.

Copy link

@mfn mfn commented Aug 1, 2019

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

This comment has been minimized.

Copy link

@crynobone crynobone commented Aug 1, 2019

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 comment has been minimized.

Copy link

@mfn mfn commented Aug 1, 2019

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

This comment has been minimized.

Copy link
Author

@barryvdh barryvdh commented Aug 1, 2019

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

This comment has been minimized.

Copy link

@crynobone crynobone commented Aug 1, 2019

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
@redLineColor

This comment has been minimized.

Copy link

@redLineColor redLineColor commented Sep 9, 2019

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

This comment has been minimized.

Copy link
Author

@barryvdh barryvdh commented Sep 9, 2019

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

@martinbean

This comment has been minimized.

Copy link

@martinbean martinbean commented Sep 9, 2019

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

This comment has been minimized.

Copy link
Author

@barryvdh barryvdh commented Sep 9, 2019

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.

@redLineColor

This comment has been minimized.

Copy link

@redLineColor redLineColor commented Sep 9, 2019

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.

@redLineColor

This comment has been minimized.

Copy link

@redLineColor redLineColor commented Sep 9, 2019

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

This comment has been minimized.

Copy link

@martinbean martinbean commented Sep 9, 2019

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

This comment has been minimized.

Copy link

@georgeboot georgeboot commented Sep 10, 2019

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.