I'm curious, maybe @Rufhausen knows the answer. I get this is a trimmed down laravel. But isn't most of the bulk in laravel necessary for api's and similar?

@mhopkins321 I would say, no, the bulk of Laravel isn't necessary, but a lot of Laravel does appear to be available to Lumen, but in more of an a-la-carte fashion (eloquent, etc.). My concern for this first release is I'm used to using route groups in the fashion I posted earlier to build up the routes. Also, "php artisan route:list" appears to be missing from artisan. I rely on that for getting a good overview of all routes as the routes file is built up. Another thing I've relied on some when creating APIs with Laravel is the Basic Auth filter/middleware. That doesn't appear to be included either, but I suppose it could be ported over.

To see the differences between Laravel and Lumen I tried to compare their dependencies. Here's what I discovered:

 "illuminate/exception": "5.0.*", // replaced with a single class: Exceptions\Handler.php
 "illuminate/foundation": "5.0.*" // replaced with a single class:  Application.php
 "illuminate/log": "5.0.*" // replaced with plain Monolog
 "illuminate/mail": "5.0.*" // mailing component has been removed
 "illuminate/redis": "5.0.*" // redis support has been removed
 "illuminate/routing": "5.0.*" // replaced with nikic/fast-route

Many other things (like facades, Eloquent, middleware, etc.) are disabled by default, but they are still there. I wonder what would be the performance benefit if all those things are enabled.

@Rufhausen Agreed. I'm in the middle of building an API that will definitely require speed and would love to use Lumen. However, I'm concerned that although it is seemingly designed to be used for API creation, it lacks some of the features that one would need in order to easily create an API, such as resourceful routing, transformers, auth filter, etc. Not that these things can't be implemented on Lumen, but it seems that without them the API use case isn't really covered. Of course, this is v1 so maybe a Lumen-specific package of sorts will be built specifically to enhance API development.

Lumen looks awesome for building APIs.

Just a thought here: Wouldn't be also useful the mailing component?

Also useful for client side IoT products.

On a Raspberry Pi 1 model B or an Arduino Yun, a simple response with some SQLite/Eloquent :

• Laravel : ~3.50s
• Lumen : ~0.11s

I'm still wondering why Lumen is being compared to other frameworks?

umm, because it's a micro-framework, just like the other two... I don't understand the confusion with this. It's kind of like asking why would you compare the Chevrolet Silverado 1500 vs Dodge Ram 1500 vs Ford F-150.

I could understand your question if you were asking why is it being compared to CodeIgnitor or CakePHP, because those are completely different types of frameworks in completely different classes than Lumen.

Think of Lumen, Silex and Slim 3 as light duty trucks like an F-150 for example. it's a great truck, it'll do most all of your lifting. But for real jobs, you're going to need to step into a big boy truck like an F-350 Super Duty with the King Ranch Package, i.e. Laravel.

I compare Laravel to an F-350, because I put Symfony at the F-450 class.

@hfalucas, definitely, see you're thinking outside of the box. Lumen will be great for APIs, but it's also perfect for off-loading other types of services and even for that quick and dirty app where you don't need a full-blown framework.

@mhopkins321, no the bulk of laravel is not needed for APIs, My APIs for example, are generally done in Silex.

I don't understand the complaint of things like loss of such trivial things like route prefixing, Route::resource(), etc.. So you do it yourself. When you aren't building for speed (i.e. Laravel) you include things like that. When you are building for speed, you sacrifice things like that and count on the developer to understand what's going on. If you want the best of both worlds, then use Laravel, that's what it's for.

If you don't see the point in Lumen, you don't compare Lumen to Laravel, they have two completely different purposes. Also if you haven't used Silex or Slim 3 in the past, and/or don't know what a micro-framework is then it's probably not for you.

It really isn't yet clear exactly when we should and shouldn't use Lumen (aside from vague generalities like it being good for an API or maybe a "simple" website, but not good for a "full scale" website). Eventually I would want to see a complete list of exactly what is not possible with Lumen that would require an upgrade to Laravel. The docs mention some differences, such as not having optional parameters for routes, but I don't know what else is missing beyond the few things it happens to mention. Really, it seems to offer most of Laravel's functionality, so if we don't happen to need one of the few things that's missing, why wouldn't we use it instead of Laravel?

I also wonder why it was necessary to make Lumen a completely separate framework. Wouldn't it have been possible to just have a "fast boot" mode for Laravel that you can optionally choose that would just use a different bootstrap method and use the faster router? Is there more to it than that? Doesn't route caching get around the issue of a slow router anyway? So then what else would make Laravel with route caching still be slower than Lumen?

I wonder if laravel 5.1 will reflect back onto Lumen and be a mix between the 2 yet requiring a need to turn more things on when needed compared to having all that eager loading always on.

@orrd, when would you use Silex or Slim over laravel? Those are the same circumstances that you would choose Lumen.

I think the complication arises from not knowing the architectural differences and needs.

Don't compare laravel to Lumen, they serve two different purposes.

@dberry

"Don't compare laravel to Lumen, they serve two different purposes."

That's not exactly what I got from reading the site this morning. I came away with the impression that Lumen serves a lower bar (mini) framework needs yet can be built out into a full Laravel. Generally, in a very open way, I agree though.

If you are used to using Laravel wouldn't Lumen be an obvious choice?

from the slim site:

It’s a shiny new micro-framework from Taylor Otwell, and it joins the Laravel family today. It looks to be a pretty nice framework, and it shares many of the same features and goals as Slim 3.0. I’m sure this raises a few question about Slim’s future roadmap.

This the first time for me to check out that framework and ... am I wrong??? based on Laravel?

@JeffreyWay

I find purpose behind Lumen quite perplexing. I hope Jeffrey does a video or two on Lumen answering some of these question. I watched Taylor's video and he spent the whole time rebuilding Lumen back to Laravel.

I have been building apps with CodeIgniter for a long time. It is lighting fast, very easy to use, lightweight. Just great for building web apps without too much fuss ..... should I just give up on Laravel and build my apps with Lumen ? Just curious.

I think for people getting confused the point of micro-frameworks is when you just want something small & simple with basic routing to operate fast. People used to ask the same questions about Symfony vs Silex.

I needed a simple framework today for a simple API that is used internally for zipping assets from URLs. Originally built yesterday in Laravel which felt overkill and then saw the good news about Lumen. It took 2 minutes to port over and now runs incredibly fast!

There was no need for caching, database etc. and so a micro work framework is ideal.

Also this will be great for building out simple command line apps for me.

@jimhill I hear what you say, and I guess my lack of Laravel experience is showing ... but I need to understand how you combine the two tools together with a real or example or two from Jeffrey, cause, at the moment it is really confusing.

The issue here is not understanding the difference between a full-stack framework and a micro-framework. They serve two completely different purposes.

Forget the terms Laravel and Lumen and figure out the difference between the two types of frameworks. As far as terminology goes, you can interchange Lumen with Silex, Slim 3 or any of the other micro-frameworks.

So think in terms of where would I use Slim versus using Laravel to develop my project? Does my project require a full-blown framework, or do I just need it to serve a single purpose?

I can't stress enough that they are two different frameworks that serve two completely different purposes.

I really don't know how it can be explained any better than this... http://lumen.laravel.com/docs/introduction#when-should-i-use-lumen

@vincej just think about what you need it for really. Laravel is brilliant for building robust applications - think of Laracasts itself as an example. Lots and lots of different components tied into an application - needs complex authentication, an admin are for both users and admins, heavy database use, caching requirements, emailing, payment processing, forum posting etc, etc

But if you just need a simple system - maybe a static website, or a simple API, or a command line tool that does one or two actions then a full scale application framework is overkill and has overhead - think of using a juggernaut to pick up your groceries ;)

Thanks for that - I gave the link a read. It looks to me that I could easily build a no fuss business app with Lumen just as I could with CI. I'm using Laravel now and even so, I always try to write simple, apps which are quick to code. I keep them pretty skinny.

Really loved lumen. I do exactly same work in my REST api projects. It took some time to do, but now I just install lumen, and jump start.

@jimhill Ok that helps ... I get it now. Still, it would be great if Jeffrey ran a video or two. cheers !

Just started implementing APIs to my Laravel project. I will definitely move it to Lumen.

I don't fully understand how it can be used to interact with a queue. Can someone lumen me on this ? :)

I see most of you do not use your head. Just waiting when someone will explain you what is micro framework. Lumen basically does same things as others. Benefit besides speed compared to Silex (as far as I know to this moment nobody has tests that confirms it) is familiar syntax and modules. THAT IS IT. And you can migrate project to Laravel, except routes, because router implementation is different.

Why are people asking "should I use Lumen for this, that or something else?"? If you want and can use it, USE IT. Pull it in and have a look around - see what you can do!

Good to see some of the Symfony stuff come out, that speeds it up a lot.

Well, I'm trying to use Lumen but in all routes I get 404 errors (the Sorry page), besides, the .htaccess is not "installed" by default in my case (I had to create manually)

@luddinus I think that's how things should be, no .htaccess, as it is specific to apache server, it will serve you nothing if you were using nginx, also you could just run the build-in server, artisan serve -> get your app on localhost to test it and start working

.htaccess was just added to the Lumen public folder ;)

@RemiC I've used composer create project command and the .htaccess is not included, and I still getting the "Sorry, the page you are looking for could not be found."

It's because it create it from the last stable release, which doesn't include the latest commits on the dev-master branch.

Try :

composer create-project laravel/lumen:dev-master

RemiC well, it works with artisan serve but not in MAMP environment... (localhost/lumen does not work)