Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

joffreypersia's avatar

Is Laravel a good choice if the constraint is to use services to communicate with the database

Hi,

A client contacted me to create an application that will serve as an image search portal for users in the photography industry. The database is quite large (500,000 images, etc.) and complex (around a hundred tables).

Request

serieId=627  
photoId=572410  
curl -H "Accept: application/json" --cookie "XDEBUG_SESSION=PHPSTORM;" -i -X POST "${dashboardBaseUrl}/v2/?&module=site&action=removeFromSerie&set=author&serieId=${serieId}&photoId=${photoId}&" -H "Authorization: Bearer ${jwtToken}" | json

Response

If the operation is successful:

{
    "nbRecords": 1,
    "resultCode": 1,
    "resultDescription": "SUCCESS",
    "affectedRows": 1,
    "nbPhotos": "5"
}

If the photo doesn’t belong to the series (e.g., duplicate submission):

{
    "nbRecords": 0,
    "resultCode": 1,
    "resultDescription": "SUCCESS",
    "affectedRows": 0,
    "nbPhotos": "5"
}

The developer suggests not directly connecting the Laravel application to the overly complex database but rather using dedicated APIs/services instead.

Is Laravel compatible with this approach? Would this be the best choice? And will it be relevant with Livewire..?

Thanks!

0 likes
9 replies
LaryAI's avatar
Level 58

Yes, Laravel is a good choice for building an application that communicates with a database through services or APIs. Laravel is a versatile framework that can be used to create RESTful APIs and consume external services, making it well-suited for this architecture. Here are some reasons why Laravel is compatible with this approach:

  1. HTTP Client: Laravel provides a powerful HTTP client based on Guzzle, which makes it easy to send HTTP requests to external services. You can use this to interact with your APIs.

    use Illuminate\Support\Facades\Http;
    
    $response = Http::withToken($jwtToken)
        ->post("${dashboardBaseUrl}/v2/", [
            'module' => 'site',
            'action' => 'removeFromSerie',
            'set' => 'author',
            'serieId' => $serieId,
            'photoId' => $photoId,
        ]);
    
    if ($response->successful()) {
        $data = $response->json();
        // Handle the response data
    }
    
  2. Service-Oriented Architecture: Laravel's service container and service providers make it easy to implement a service-oriented architecture. You can define services that handle communication with your APIs, keeping your code organized and maintainable.

  3. Middleware: You can use middleware to handle authentication, logging, and other cross-cutting concerns when making API requests.

  4. Error Handling: Laravel provides robust error handling, which can be extended to handle errors from external services gracefully.

  5. Testing: Laravel's testing tools allow you to mock HTTP requests and responses, making it easier to test your application's interaction with external services.

  6. Scalability: By decoupling your application from the database and using services, you can scale different parts of your application independently.

In summary, Laravel is well-suited for an architecture where the application communicates with a database through services or APIs. It provides the necessary tools and flexibility to implement this approach effectively.

martinbean's avatar

The developer suggests not directly connecting the Laravel application to the overly complex database but rather using dedicated APIs/services instead.

@joffreypersia And how are those “decimated APIs/services” going to get the data…? Answer: by connecting to the “overly complex” database.

Something needs to connect to the database to get the data. I don’t see how putting an “API” or “service” between the user and the database is going to be any better, because now the end user has to wait for two HTTP requests to resolve instead of just one:

User issues request to Laravel app -> Laravel app request to API/service -> API/service returns response to Laravel -> Laravel returns response to user

How is this any better than:

User issues request to Laravel app -> Laravel app returns response to user

?

joffreypersia's avatar

@martinbean Hi,

Indeed, it is not better at all.

The dev told me that for complex applications like this one, it is better to use a "micro soft" that catch the request and interact with the database, and send the response to the sender.

That way, we can connect more applications, like a mobile app, a web app, a saas for the photographers...etc without using all of them to read/write the database.

He told me it is better to do so, but I agree, it is double requests...

I don't know personally, I just worked on traditionnal small saas app with the traditional TALL stack.

Snapey's avatar

@joffreypersia he would probably have said "Micro Service" which means they are from an enterprise background. Unless your users are in the thousands per hour then this is total over-engineering.

It does not matter that there are 100s of tables, you are likely to only query a few at a time, and 500,000 rows is small system in database terms.

martinbean's avatar

@joffreypersia I don’t know who you’re talking to, but it sounds like they just like to say fancy terms and suggest fancy architectures without actually understanding them or their implications.

“More applications” still ultimately need to get their data from the database. Creating microservices doesn’t magically reduce load on a database, it’ll in fact increase load on the database if more applications are competing for connections.

Besides:

we can connect more applications, like a mobile app, a web app, a saas for the photographers...etc without using all of them to read/write the database.

All of those functionalities can be handled in a single Laravel codebase. The mobile app would need an API, which could be served by your Laravel app.

jdc1898's avatar

I agree with what @snapey is saying. This is a classic case of over engineering. Unless it is a requirement to build out using micro-services, don't do it until it is. The amount of time required to develop will be less and the code you write to interface with the database won't be lost. If and when you need to transition to micro-services, you simple move the database interface code down the stack.

It also could be a situation where your client wants visibility into what the application is doing. If that is the case, give them visibility through logs or some other means rather than doubling the development effort.

1 like
kerelka's avatar

its better not put API service between Laravel and Database. Laravel is enough to serve as API.

Sometimes the problem and what you need to concern is the Database and Server Database you using. Unless you need to make request more than 10.000 req/sec then you need to consider using like 'GO' maybe.

people use GO because it can handle much request (i heard ..), and for that much request you need to optimized database too, to keep up with the service API.

but overall, Laravel is enough...

1 like
jayandholariya's avatar

@joffreypersia you can try doing this

  1. Use Laravel for backend processing and API integration.

  2. Integrate APIs for data retrieval and manipulation to avoid database complexity.

  3. Utilize Livewire for dynamic front-end components (e.g., search filters, image galleries).

  4. Optimize API calls with caching mechanisms (e.g., Laravel Cache, Redis) for frequently accessed data.

1 like
joffreypersia's avatar

thank you all for your help. :) I really appreciate it.

Please or to participate in this conversation.