I am working on a new product and i want to hear from you the best techniques of developing enterprise products.
I have 11 microservices based on Laravel, linked to frontend through API UMBRELLA.
For microservices, i am using DB:Manager instead of Eloquent - but i don't tested from Laravel 8 if Eloquent can be compared to a direct sql query. Maybe someone knows that better than me.
Also, I have this structure: Controller->Service->Repository.
Developing an enterprise product involves various considerations and best practices. Here are some suggestions for developing an enterprise product:
Use a Microservices Architecture: You mentioned that you already have 11 microservices based on Laravel, which is a good approach for building scalable and maintainable enterprise applications. Microservices allow you to break down your application into smaller, independent services that can be developed, deployed, and scaled independently.
API Umbrella: It's great that you have a centralized API gateway (API Umbrella) to handle the communication between your frontend and microservices. This helps in managing authentication, rate limiting, and other cross-cutting concerns.
Eloquent vs. DB:Manager: Laravel's Eloquent ORM provides a convenient and expressive way to interact with your database. It is generally recommended to use Eloquent for most database operations as it abstracts away the underlying SQL queries and provides a more intuitive syntax. However, there may be cases where using DB:Manager for direct SQL queries is necessary, such as complex queries or performance optimizations. It's important to evaluate the specific requirements of your application and choose the approach that best suits your needs.
Controller-Service-Repository Structure: The structure you mentioned (Controller -> Service -> Repository) is a common pattern in Laravel applications. It helps in separating concerns and keeping your codebase organized. Controllers handle the HTTP requests, services contain the business logic, and repositories handle the data access layer. This structure promotes code reusability, testability, and maintainability.
Unit and Feature Testing: It's great that you have unit and feature testing in place for each component of your application. Testing is crucial for ensuring the correctness and reliability of your code. Make sure to write comprehensive tests that cover different scenarios and edge cases. Laravel provides a robust testing framework that makes it easy to write and execute tests.
Overall, developing an enterprise product requires careful planning, architectural decisions, and adherence to best practices. It's important to consider factors like scalability, maintainability, security, and performance while building your application.
// Example of a UserController using the Controller-Service-Repository structure
namespace App\Http\Controllers;
use App\Services\UserService;
use Illuminate\Http\Request;
class UserController extends Controller
{
protected $userService;
public function __construct(UserService $userService)
{
$this->userService = $userService;
}
public function index(Request $request)
{
$users = $this->userService->getAllUsers();
return response()->json($users);
}
// Other controller methods...
}
// Example of a UserService
namespace App\Services;
use App\Repositories\UserRepository;
class UserService
{
protected $userRepository;
public function __construct(UserRepository $userRepository)
{
$this->userRepository = $userRepository;
}
public function getAllUsers()
{
return $this->userRepository->getAll();
}
// Other service methods...
}
// Example of a UserRepository
namespace App\Repositories;
use App\Models\User;
class UserRepository
{
public function getAll()
{
return User::all();
}
// Other repository methods...
}
Remember to adjust the code to fit your specific application and requirements.
What are you calling a microservice? Give an example. I ask because most users here asking about microservices aren't really using what they think is a microservice.
Or think they need microservices, but don't. Microservices makes things far harder than necessary.
A Doctor is setup with a Lab and can login to the Lab to see a patients lab results is fine.
But having separate code bases for the same institution is not normally necessary.
Basically you are saying you now have 11 code bases to maintain instead of one, just curious, why?
But why? I think is a great idea to start organized with clean code, well-structured, where each member of team can work on a single thing, not on an entire monolith.
A monolithic app can be well-structured. A microservice architecture can be a mess. Adding https:// in front of components isn't a solution to the issue.
Developers can still work on individual pieces independently. No difference.
Take the Linux kernel for example. It's a monolithic project with tens of millions of lines of code and thousands of active developers. They seemed to scale up pretty well.
@JussiMannisto Can you provide me, please a well-structured monolithic laravel app?
Also, Maybe headless or decoupled arhitecture is better for now? What do you think?
@marian-andreiasi just look into domain driven design or Laravel modular design. Basically you create modules like Users, Billing, Sales under the same monolithic app.
guys, I'm just asking you what you take into account when you want to develop scalable products, on which more people can work, if you had an enterprise saas to do like example
IMO, the correct way of doing microservices is: Don't. Unless you absolutely have to.
Breaking your app into separate pieces with asynchronous communication between them has big downsides. You need a good reason to do so.
Don't underestimate the scaling of monolithic apps. Caching, CDNs, load balancing, replicate DBs, search engines. There's many things you can do if you start getting bottlenecked.
And you can always lob parts off into separate microservices later on if you absolutely have to, as long as you keep your codebase loosely coupled.
@marian-andreiasi it doesn't have to be like that. you should be able to locate specific resource intensive parts of your application and separate only those into their own instance. Say your application needs to generate reports for users to download. In time these reports keep growing in size and your server starts to struggle to both run the job and serve everything else. Now you can decide to build a new instance that takes a json payload, generates the report and uploads it somewhere accessible by the user. You can boot and kill these instances depending on the amount of reports running.
Your architecture with Controller→Service→Repository and unit/feature testing is solid for enterprise-grade design. For Laravel Eloquent is performant enough with proper indexing, caching and query optimization, though DB manager suits complex queries. Using API Gateway is a good choice; also consider CI/CD, observability and scalability patterns. CONTUS Tech and other enterprise app development companies stress domain driven design and microservice governance for long-term maintainability.