ORM (Eloquent) in Laravel 5.x VS Microservices architecture. How to develop web services using Eloquent that consume end-points of an API?

Question

Consider the following architecture:

This is a very modern model where the API offers end-points for different services to transact with the database.

I am a begginer user in Laravel, so my question is beginner regarding the Framework.

Laravel, like other frameworks like Simfony for example, has a powerful ORM that saves a lot of development time. In Laravel the Eloquent seems to be tbm the basis of many other amenities like Migrations, Seeds, authentication layers, among others.

If the previous idea is true, it seems logical to me that if we decide not to use the Laravel ORM, or the Migrations we will lose much of the power of the Laravel.

On the other hand, thinking of the drawing scheme above, how would the implementation of a Web Site/APP that only consumes end-points of a API? At the moment I’m using Guzzle to make use of the end-points. But in this case, my Web Website/APP You won’t need the ORM, you won’t need the Eloquent, and I won’t need the Séeds or the Migrations. So it seems logical that in this scenario I’ll be losing the advantages of the Laravel.

And if that conclusion is true, I will inevitably be forced to question Laravel’s advantage for nonmonolithic architectural designs.

Even inside the API-Restful where I could use all the amenities of the ORM the use of Laravel is questionable because here I will not need the views, I will not use Lade and tbm the whole package of associated amenities.

Perhaps that is why there is a Ligth version of Laravel to treat the development of Apis, the Lumen, which, according to its website, brings us the advantage of having something around 1900 connections per second. But tbm there are other options for developing php Apis such as Phalcon, in addition to Lumen, which are considered high-performance php frameworks. In addition there is the possibility of using Javascript with Nodejs to develop the API completeness. The purpose here of this post (which is my question), is not to discuss the performance of each of these options or qualify who is worse or better.

The fact is that looks like that the Laravel 5.x framework (5.4 is what I’m using now) does not seem to be tbm the appropriate choice to create the API (if chosen to be done in PHP).

Well, if to create the Web Site/APP The Laravel, who will not use the ORM and its amenities, seems to have no meaning, and for the creation of the API Laravel seems tbm not to be the first choice, we would have to conclude that Laravel (and other similar frameworks) is not a good choice for microservice design and by conclusion, the modern web.

So not to leave that thought open, so that if you set it off-topic, you get my exact question:

How to implement Laravel’s ORM in a Web Site/APP project that will consume end-points from an API? Will you need to have the Models or can the data already come straight from the Controllers? Will you have to replicate the entire database in Migrations and Models in order to use the benefits of queries? I can’t see how to implement this ORM.

Answer 1

Today I am working on a project that we chose to work with services (Apis) for the ease of product growth and partnerships to be created thus increasing the added value of our product.

I confess that it is something very arduous and not as beautiful as it seems to be, we have many benefits in this approach, such as: better defined team, leaner deploys, freedom of technologies (care), in this address has an explanation of perks microservice.

We have used Laravel 5 in 95% of Apis so far, why ? As our team knows Laravel well and he fit well to solve the proposed domains of our business, we applied it and this facilitated the creation of packages to assist in the whole stack. Examples:

• Package that brings API information such as Laravel version, environment, endpoints and other information.
• Our SDK that has access to all the endpoits of the Apis used in our customers that are Laravel and in the communication of services between services.
• Resource server, this is to validate access scopes of token generated on the authentication server and thus validating endpoints.
• And several others to help the stack.

In other words we haven’t lost almost anything from the only eloquent Laravel that is an ORM used by him to access the database layer. And this makes perfect sense if it is a client application that consumes the Apis does not access the database layer directly, consumes our business layer which is a service that is linked to a specific domain of our application. So I can have clients in javascript, python, java, etc.

One of our Apis is in Nodejs to serve our Redis pub-sub features thus creating a broadcast server to supply application that require "real-time" functionality using websocket in this link explain the idea.

With the services approach, we experienced difficulties in the integration tests between the Apis, the Oauth2 authentication server, in the deployment processes used Ocker thus facilitating deploys in all environments Speed, stating, testig and Production. But we hope to reap good fruits in the long term.

Don’t worry about losing the eloquent in the client application because you can have partners creating applications on top of your Apis with any language or paradigm, This is the magic of Apis giving you the freedom to be born with sensational projects on top of your Apis being public or private. Focus all your strength on your Apis.

Answer 2

On the other hand, thinking of the diagram of the drawing above, how would the implementation of a Web Site/APP that only consumes end-points of a API?

You will consume through the HTTP layer, using Guzzle or any other HTTP client. As mentioned in the above answer we build Sdks so that our applications that use Windows can consume the services in a simpler way. It will also be possible to consume your Apis with any other language.

How to implement Laravel’s ORM in a Web Site/APP project that will consume end-points of an API? You will need to have the Models or the data can already come straight from the Controllers? You will have to replicate the entire Base of data in Migrations and models to be able to use the benefits of darlings?

You won’t be using any Orms at this point, because the data/business rules will be focused on the Apis, so you won’t need to manipulate databases in the client application.

Just to reinforce, don’t worry about losing the eloquent in the client or the views with Blade in the Apis, as you can enjoy other framework features.