How to setup microservices in laravel?

Great, thanks. I am not sure how big it will grows. But, definitely will more than Admin, customer, product & services, order etc.

So in this case, better to stick with laravel relations, and migrate to microservices if needed in future?

And running microservices could be quite expensive right?

And also would like to know how would it looks like if implemented as microservices. As what i know so far, every services is a laravel application then with it own database and store related data and using ID to connect each other. Am i right?

Sorry, maybe I am wrong.

From what i know here, let's take an example like simple blog app

I separated into 3 backend microservices which are posts, users, comments.

These 3 backend microservices are small laravel application.

In Posts service will consist only posts and user_id and everything just related to post. In Users service just basically to store the user details. In Comments service will consist only comment details and post id.

When i want to get a response with data of post, user, comment, then i need to call these services from my controller and return to my frontend.

CMIIW, I am not sure if this is right. Do you have any resources to share / sample output with description where can help to understand the implementation better if my concept was wrong. Appreciated it, thanks.

@crazylife Right. So now, what benefit do you think having three applications to develop, maintain and deploy is versus just having one “blog” application to look after?

They’re also not going to completely isolated. You have a comments “service” that needs to know about posts (because a comment belongs to a post).

When i want to get a response with data of post, user, comment, then i need to call these services from my controller and return to my frontend.

Cool. So now you have to call three APIs from three separate services just to do one operation (view a comment on a post).

Micro-services isn’t just about, “Let’s split this app up into smaller, multiple apps”. That’s just exponentially growing the number of codebases, and the headaches around looking after a project, for absolutely no gain or benefit.

All you’re doing is moving your relations from Eloquent models, to HTTP calls, which is just many orders of magnitude slower.

Alright, so meaning that if we can do it in monolithic way then it's better just stick to it for this cases. Where micro-services take places only if services can be independent and not belong to each other. Thus, will need to call multiple API just to get a single resource which is expensive.

But then if apply on login services, mail services... still acceptable? Is it because if the services too dependent on each others then it's better not to separated them "into smaller, multiple apps". Are we still allowed to like passing an id and get data from a service (e.g. to check user profile, user is a service and is independent)?

I have developed a SaaS application that I broke down into smaller applications. Customer Portal, Admin Portal and Vendor Portal (Each is a Laravel app)

I could break it down in micro-services (clients, products, vendors, order, etc) but I think at the end of the day you also need to look into the TCO (total cost of ownership).

I personally see micro-services as a way to minimize some risks when it comes to deployment; but I also see that is more costly to maintain and support.

@crazylife We are using Microservices on a project rebuild as we will then be able to scale the busy bits of the app. This also makes it easier for larger teams as each dev or team can work on a distinct group of endpoints rather than having to run up the whole app to modify a part of it.

Cost to develop Microservices is more expensive than a monolith application, so its worth avoiding unless you really need to.