A Laravel app with a Lumen API, does that really make sense?

Why would you build your app in 2 different frameworks? I think your confusing using Lumen for building an API with the idea of using Lumen to build the backend. Most likely what you've ready is using Lumen to build an API and then that would probably serve the starting html/css/js files that end up being a single page app on the frontend that communicates with that API. Or you have lots of other developers using the api. But there isn't a separate laravel app there. It's either Lumen or Laravel, not both.

Really you should evaluate what framework you want to use based on what it offers - Lumen provides probably 80 - 90% of what you will constantly be using to build an app so if it has what you need then no need for Laravel. If Laravel has more stuff that you need that Lumen doesn't, then use Laravel. Always try to base your design decisions on the needs of the project. If your building an API, make sure your thinking about your database, models, and service layers beyond the general controller methods. I think people think o it's just a small API so I can use something small but don't realize the logic behind the API is actually quite significant. But if your just starting out I'd say Lumen would be a good choice and I think you can change it to Laravel if you need to later since it's using the same components. If that's not right please someone correct me.

Hey Itrain, thanks for getting back to me!

See the thing is, I'm building an app that has the following:

• A front-end that requires some Laravel-only stuff like subdomain routing, this front-end is an actual website.
• A JS backend (probably VueJS)
• A private API

I could build all this in one Laravel app, that would work. The only reason I'm considering Lumen is because of performance for the API.

Hence the solution I suggested where I would have a Lumen API. Both the JS app and Laravel front-end would talk to this API.

Not the correct way to go about it then? I guess I'm trying to overcomplicate things.

Hi, last time I also was thinking about that. I'm building full app with Laravel but I would like to write api for customers later, and as you mention Lumen has much better performance and what now ? I also thought, that I should split that into 2 instances Laravel and Lumen as a separated projects, but this same database. I don't know if I'm right, I will also listen for advice.

The question you're really asking is more along the lines of "What are the advantages of microservices?" Because by splitting your application into two pieces that talk to each other via HTTP, that's what you're really doing.

As for why that's may be a good idea, I defer to Martin Fowler:

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

@thepsion5

Thanks for that link, interesting stuff!

The advantages of using Lumen as a microservice to build an API are clear to me. It's the disadvantages I'm pondering about.

Am I correct in thinking this approach would actually slow down the performance of my front-end Laravel app? (As it has to do an extra HTTP request to the API and that API would also have to do it's thing...)

I'd say in your case, it probably won't speed anything up, especially if you're basically just writing the same code in Lumen, on the same server - you're just adding the time required to process another request plus Lumen's bootstrap time, without decreasing Laravel's bootstrap time.

I think Martin Fowler is talking about Service Oriented Architecture when he says

which may be written in different programming languages and use different data storage technologies.

and that's something that companies like Google and Facebook use.

@thepsion5 exactly!

However, what if I still want to offer an incredibly fast private API to my customers, without having that overhead? Is my only option to write a seperate API in lumen that is essentially a duplicate of what I already have in Laravel then?

Pffft, these architectural issues keep me from sleeping, I just wanna get coding! :-)

You can create your app in laravel, and later create an API with lumen that is actually more efficient even if on the same server.

Namespace is key here. You can use your laravel models via composer autoload. Simply add the full namespace (like app name/app) and you then have access to the models eloquent with much less overhead.

In Envoyer a lumen app pings servers constantly to ensure it's up. I use lumen apps to request data from a big data database, crunch numbers so to speak and create reports. A very time consuming and resource intensive feature via artisan commands. Also use a luman app to as a queue handler for a laravel app that runs on specifically set resource amounts (like a vm almost).

How old is this post?

Anyway, what i do with laravel is build a multitenat app. And since i want a backend service to process queues or jobs, what i did was use guzzle to make an asynchronous request to my lumen application which is the backend service i need which takes care of the rest like events and other things which will slow down the main laravel app. Therefore, my laravel application is not too jumbled up with lots of code.

Would that be overkill? Unorthodox?

To make one more thing clear is, since queues can't handle sessions, i use lumen to handle those stuff.

Came back to say I used the advice provided by @jekinney. It actually made a lot of sense once implemented, I have a Laravel app and a Lumen app, they both share some code (mostly models), but each has their own controllers/authentication logic etc...