Php – Laravel Algorithm for taxi app

Conceptually, it would be ideal to have a centralized API for each "system" (But not the same for all systems).

I use the term system, and quoted, because you may have many apps in a single system, as well as an app that works with more than one system. A nice example would be a WebApp and a Mobile Application, being two diferent "applications" that work over the same data. On the other side you may have a dashboard that controls your company's CRM as well as shows statistics for your website, which is basically one application interacting with two different "systems".

Having, for instance, website and sales data on the same database could result in big problems if you wanna change your website, as it may lead to issues with the sales data, and would be frowned upon by any sysadmin, as well as most if not all seasoned developers. Having two databases on the same application bring a whole new set of problems to deal with. And that is without considering possible permission issues and/or risk of an exploit or hack affecting "more sensitive data" than it should.

I would thus suggest you build a separate API for each system to have Models, Relationships and behaviors well separated and well-documented and working to your advantage. This means whenever there's a question or change in business logic, you have to look at it in one single place.

Over that, for each "app" I would have a separate codebase, but that is more of a personal opinion.

The idea now is that you must pull your data from the API, and after consuming the API you should only do formatting for presentation reasons. i.e.: If you have an eCommerce and have a cart total that is the sum of all products' values, this value comes from the API as FLOAT or DECIMAL, already making sure you have only 2 decimal digits, and the consuming part formats (i.e. adds currency etc.) the value.

This is to simplify possible different versions of apps, as well as ensure consistency (The cart total may never be wrong in one app but not the other, because it comes from the same API).

The main reason for the API is the consistency. Bigger codebases are bad for maintenance and performance reasons. Smaller codebases on the other hand may cause code to be duplicated, which may lead to consistency issues as well as weird bugs when one of the system changes their behavior.

Also, this decision comes BEFORE deciding the framework. Choosing a specific framework or language before deciding what you're trying to build carries a big risk of you making a bad decision. Consuming an API and working with presentation will be easier from any JavaScript front-end framework than from Laravel. Serving an API is probably way easier from Rails (Way better Models) or Node (Simplicity and performance, less stuff you never use lying around) than Laravel. Also, if you decide to consider using a different Database for whatever reasons (Be it NoSQL or Postgres or whatever), picking a framework before looking at your options may be a deal breaker.

All those decisions have to take one another in account. You need the most advantageous option you can feel comfortable working with. And while for a weekend project it usually means "whatever you want", for projects that may last months or years picking a different language or framework may have a big impact on the speed and quality of what you build, which is the reason for this being such a difficult and important decision.

This is one of the reasons why view models were created. Define a class that holds the necessary data for the view and this question becomes moot. The source of the data could be an Eloquent object or array, but since the view is rendering its own model the original source and format of the data is irrelevant.