Ligonsker's avatar

Does it make sense to separate data fetching logic from a controller to somewhere else?

Hi,

I want to start a new project that is using Blade.

I was wondering if it makes sense to separate all the data fetching logic into some sort of API, so that in the future, if I ever need to fetch data with another frontend (React for example), i will have the same API.

For example, if right now I have a page that shows list of items:

public function itemsList(Request $request)
{ 
    $items = DB::select(...); // 
    return view('items_list', ['items' => $items]);
}

I will have something like:

    $items = // get it from another internal API
    return view('items_list', ['items' => $items]);

So when I will use this API from within Laravel, it won't be another HTTP request, but just a call for a method (however, it will be the same method that the API uses). Then, in the future if I ever want to return the same data it will probably be somewhere in web.php under an /api prefix

Does it make sense? If so, what would be a good practice to do it? Where would I place all those API methods?

Thanks

0 likes
6 replies
Glukinho's avatar

When you compose pages using Blade templates, there is no API at all except one public URL per page. Pages are rendered server-side and sent in whole in a single request/response.

If you ever want to change frontend you most likely will have to recreate the whole app, so I wouldn't worry about it at this point. Just return views with prepared data from controllers as usual.

Ben Taylor's avatar

These days you would probably just use Inertia rather than building a separate SPA frontend. If you did that, you would just change the response to an Inertia response rather than a view. Everything else in the controller would stay the same.

Tray2's avatar

There are many ways to go about this.

  1. Keep it in the controller
  2. Move the fetch to the model
  3. Create a service class that you and move the fetch there
  4. Use some fancy pattern to achieve the result

Which ever you choose, don't make it more complex than you need to. The logic is quite easy to refactor if and when you need to.

Be aware that your API (When you move there) probably should use a JSON Resource

https://laravel.com/docs/12.x/eloquent-resources

1 like
tykus's avatar

... so that in the future, if I ever need to ...

Solve the problems you have today with solutions appropriate to those problems. Pre-maturely optimising for some notional future requirement is wasted effort.

2 likes
Ligonsker's avatar

thank you @tykus I was thinking about that, but I was thinking that it could maybe make the code more organized today as well, i.e. the controller will use the fetch from a Service class as suggested above (and in the future if ever needed it will be called via the web.php as an API, and if it's internally called it will simply be more organized instead of filling up the controller with data fetching but you are correct so I will probably not do that

martinbean's avatar

…so that in the future

@ligonsker This is the literal definition of “premature optimisation”.

Extract things when you need to. Not before.

Please or to participate in this conversation.