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

Question

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

Navigation

#1 by (2 votes)
#2 by (1 votes)

6

Consider the following architecture:

ThisisaverymoderntemplatewheretheAPIprovidesend-pointsfordifferentservicestodotransactionswiththedatabase.

I'mabeggineruserinLaravel,somyquestionisabeginner'squestionregardingtheFramework.

Laravel,aswellasotherframeworkslikeSimfonyforexample,haveapowerfulORMthatsavesalotofdevelopmenttime.InLaraveltheEloquentseemstobealsothebasisofmanyotherfacilitieslikemigrations,seeds,layersofauthentications,amongothers.

Ifthepreviousideaistrue,itseemslogicaltomethatifwedecidenottousetheLaravelORM,orthemigrationswewilllosemuchofLaravel'spower.

Ontheotherhand,thinkingabouttheabovedrawingscheme,whatwouldaWebSite/APPimplementationthatonlyconsumesendpointsofanAPIbe?AtthemomentI'musing Guzzle to make use of the endpoints. But in that case, my Web Site / APP will not need ORM, nor Eloquent, nor will I need seeds or migrations. So it seems logical that in this scenario I will be losing the advantages of Laravel.

And if this conclusion is true, I will inevitably be forced to question Laravel's advantage for non-monolithic architecture designs.

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

Perhaps this is why there is a ligth version of laravel to handle the development of APIs, the Lumen , which, according to your website , gives us the advantage of having something around 1900 connections per second. But 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 completeness of the API. The purpose here of this post (which is my doubt) is not to discuss the performance of each of these options or to qualify who is worse or better.

The fact is it seems that the Laravel 5.x framework (5.4 is what I'm using now) does not seem to be the right choice to build the API as well if it is chosen to be done in PHP).

Well, if to create the Web Site / APP Laravel, which will not use the ORM and its amenities, it seems to make no sense, and to create the API > Laravel seems to be not the first choice, we would have to conclude that Laravel (and other similar frameworks) may not be a good choice for microservices design and, by the way, the modern web.

So do not leave this thought open, so that you set yourself off-topic, my exact question remains:

How to implement the Laravel ORM in a Web Site / APP project that will consume end-points of an API? Will you need to have the Models or the data already come directly from the Controls? Will you have to replicate the entire Database in migrations and Models to be able to use the benefits of queries? I can not see how to implement this ORM.

api laravel

asked by anonymous 11.04.2017 / 16:25

2 answers

1

On the other hand, thinking about the scheme of the drawing above, how would 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 answer above we build SDKs so that our applications using laravel can consume services in a simpler way. You will also be able to consume your APIs with any other language.

How to implement the Laravel ORM in a Web Site / APP project that will consume end-points from an API? You will need to have the Models or the data Can they come straight from the Controls? You will have to replicate the entire Base migrations and Models to use the benefits of queries?

You will not use any ORM at this point as the business data / rules will be concentrated on the APIs, so you will not need to manipulate the database in the client application.

Just reinforcing, do not worry about losing the eloquent on the client or the blade views in the APIs, as you can take advantage of other framework features.

11.04.2017 / 19:49

Mount structure with hexadecimal data Write to a CSV file

score 2 · Accepted Answer

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

I confess that it is something very hard 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), at this address has an explanation of advantages of microservices.

We have so far used Laravel 5 in 95% of the APIs, why? As our team knows Laravel well and he fit in well to solve the proposed domains of our business, we applied it and this made it easier to create packages to help the entire stack. Examples:

Package that brings API information like Laravel version, environment, endpoints among other information.
Our SDK that has access to all API endpoints used in our Laravel clients and in service communication between services.
Resource server, this is to validate access scopes of the token generated on the authentication server and thus validating endpoints.
And several more to help stack.

In other words we have lost almost nothing from the laravel only the eloquent which is an ORM used by it to access the database layer. And this makes sense if it is a client application that consumes APIs does not access the database layer directly, it 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 and etc.

One of our APIs is in NodeJS to serve our Redis pub-sub features thus creating a broadcast server to supply applications that require "real-time" functionality using websocket in that link I explain the idea.

With the services approach, we experience difficulties in integration tests between the APIs on the OAuth2 authentication server in the deploy processes used in the docker, thus making it easier to deploy in all development, stating, testig and production environments. But we hope to reap good results in the long run.

Do not worry about losing eloquent in the client application because you can have partners building applications on top of their APIs with any language or paradigm, this is the magic of the APIs you are free to be born sensational projects over your APIs being public or private. Focus all your strengths on your APIs.