Laramen — a Laravel app with Lumen powered API routes

My current project (Eyewitness.io) is a web front end powered by Laravel, with an API backend powered by Lumen.

To handle the thousands of connections per minute from hundreds of servers that are monitored, I knew I needed the API to be powered by Lumen from the beginning. The superior response times, lower server resource consumption and less overhead just made loads of sense.

But if you’ve ever used both Laravel and Lumen on one project, you’ll probably be familiar with the situation of having duplicate code between each project, or having to package the common code (such as Eloquent Models, console commands, business logic etc) to allow them to be shared between each project.

This makes development more complicated.

Recently I’ve been toying with the idea/wish that I could have the full power of Laravel and the speed of Lumen in one application. No packages to share code, not issues of duplication, just one project with the benefits of both, and the ability to have all code in the one place.

The biggest power of both Laravel and Lumen is how Taylor has “glued” them together. Realising this gave me the understanding that we can allow these to easily co-exist, and they actually dont need to be separate at all.

That’s how the idea of Laramen was born.

Laramen is a proof of concept, allowing you to combine Laravel and Lumen into one application. The idea is simple — any /api/* route should be powered by Lumen, otherwise use Laravel.

So what is the benefit? Simple — all your code in one place. They are the same application — so lets treat them as such.

Here is a visual demo:

You can try the interactive working demo here: https://laramen.xyz

A copy of the GitHub code is here: https://github.com/laurencei/laramen

What works well:

• Performance: there is literally no overhead with this solution. Your /api/* routes only use Lumen, and your other routes only use Laravel. So performance is not changed vs using either solution separately.
• Tests: you explicitly choose to use either Laravel or Lumen for each of your test classes. In the Github example you can see how both are handled.
• Logs: your “Laravel” logs go to “laravel.log”, and if any errors occur in the API they go to “lumen.log”. This could easily be changed so they all go to the one place, but I think it makes sense to keep them separated.
• Console: artisan continues to use Laravel, so you get all the “scaffolding” tools etc
• Exceptions: your Laravel web application uses the laravel.php exception handler, and your API uses the api.php exception handler. This allows you to report and handle exceptions different for your web vs your API.
• Code: all your code can be shared in one place. i.e. all your models, commands, etc — it all resides in one place.

To do:

• Config: I’ve not tried yet, but I think we can get Lumen to look for, and use, the config:cache option (which currently it is not available). I think that should improve co-existence, without any real performance hits?
• Packages: I’ve not tried how this will affect certain packages, especially if they specifically target Lumen or Laravel (but I think it should work).

Remember, this is just a proof of concept. I’ve not fully tested it, and there might be some issues that I’ve not yet considered. Some of the code can be easily refactored or done in a slightly different way.

But hopefully this is a good starting place for some discussions on how we can take this forward.

Run a Laravel application? Eyewitness.io is a monitoring and application analytics solution built specifically for Laravel. Know how your Laravel applications are actually performing. Monitor uptime, queues, cron schedules, email, logs, security, SSL, DNS and much more. Super simple installation — be up and running in just 90 seconds…