microservices structure in Laravel with aws lambda

Question

I am new to microservices, I only know the theory, developed some local examples, and also deploy them to AWS, but just that, and I have a project that has to be done with microservices, but my question is about the structure.

For example, I am planning to do the following:

• Vuejs SPA for the frontend store in AWS S3- this will make the request to the Main Laravel app
• the Main Laravel app to manage the authorization(login, register, password recovery)
• When the user is logged in, is redirected to the "posts" page and that page loads all the posts, you can create new posts, delete them, add comments, etc. This would be another Laravel app, another microservice
• Then I have another Laravel app for the user profile, where the users can update their information and also monetize their posts with given options

So, this is my plan:

• a SPA stored in S3
• a microservice for the Main app that handles authorization, this will be stored in lambda
• a microservice for posts, this will be stored in lambda
• a microservice for monetization, this will be stored in lambda

I am planning to use serverless so I am a little bit confused.

• Where should be the AWS API gateway in the SPA or Main app? or how can I configure it
• Should I use only one database and each microservice connect to it?
• Should I use different databases? if so, can I how can I synchronize them
• If a user logs in to the Main app, it generates a token with sanctum or passport, then this token is sent in the header request to the posts or monetization microservice, is ok this approach?
• Should I install a Sanctum or passport?
• Should I install Sanctum or passport in all the microservices or only in the Main app?

What can I do? thank you.

Answer 1

If I understand correctly you have one UI communicating with multiple microservices in the backend.

Since you are using serverless, a microservice is probably a set of functions around one functionality that are deployed together. That is totally fine.

In general you will want to have a separate storage area for each microservice. If they are physically different databases or not does not make the big difference in cloud environments because you can always change it according to your needs. The important point is that the storage area is encapsulated by the services. This might mean each microservice has an area within a database that noone else has access to.

This also means you have to use interfaces to get data of other microserivces. There are basically two ways to do so:

• synchronously API use of other microservice to retrieve data.
• asynchronous data replication via a message bus (event-driven architecture).

For token-based auth: your Main app will create an encrypted JWT token using a private key including user information like email, etc. This token has to be stored in the client and sent to other microservices via a header with every request. They can use decryption mechanisms to ensure the validity of the token and need the public key of the Main app for this. You might consider enter link description hereAWS Cognito libraries because they to that job for you

In general, you should overthink using microservice since they are no silver bullet. You should ask yourself the following two questions:

• Do I need to scale development? (e.g. 50 developers +)
• Do I need independent deployment/service evolution?

If the answer is "no" to these questions you might consider using some best practices of microservices, but I'd advice against introducing the full overhead of microservices. You could also just have some serverless functions working on a common database.