I've already read lots of topics about it, but still haven't found the better approach.
I have a User
. One User
may have many Posts
. Users and Posts are different microservices. I'm using Spring Boot.
When the front-end call my Posts
microservice sending a POST
request to /posts/user/1
, I need to check if the given userId
(1) exists on my Users
database. If no, throw an exception telling the front-end that the user doesn't exist. If yes, then insert the given request body as a Post
.
The question is: how should I check this information at my backend? We don't want to let this responsibility with the front-end, since javascript is client-side and a malicious user could bypass this check.
Options:
I understand that communication between them will create coupling, but I'm not sure if giving Posts access to Users database is the best option.
Feel free to suggest any options.
You have an option to do interprocess communication between Post
and User
microservices through RESTful
approach.
In case if you just want to check the existence of the resource and don't want any body in response then you should perfer using HEAD
http method. Therefore your API endpoint hosted at User
microservice will look like -
HEAD user/{userId}
Call this API from Post
microservice.
Return 200 / OK if user exist
Return 404 / Not Found if user does not exist
Click here and here to get more details on HEAD
method usage and use cases.
For this very particular use case, if you have a security layer, you can(should) make use of user access token, to ensure, that request is processed for the right user, which can be done by validating the token and relying on the fact that if user has token he exist. (As its just not about if user exist)
For any logic other than that, say you want to check if he is allowed to post or other such restrictions it is required to make a call to the user service.
Talking about giving access to the database, it will be against one basic guideline of microservices. Doing so will form a tight coupling between you and user. Its ok to call user service in this case which can decide how to serve this request. User service on its part should provide ways to answer your queries within the SLA by caching or other mechanisms.
One more thing that you can explore is BFF (Backend for Frontend) You rightly said you should not expose backend services to frontend or add any logic there, but often frontend pages may not be comfortable in accepting that content on same page is answered via n different back end services and there might be some logic to stitch such queries and thats where you can make use of BFF. Backend server (in my case node) which take of things like these requiring frontend to make just one call(or less calls) for a given page and at the same time hiding your backend services within.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With