Microservices - create post for logged in user

Question

I am working on a small project with microservices architecture in Spring Boot. As to not make unnecessary calls to users-microservice, I have duplicated some necessary User data (id, name, summary, photo) also into the posts-microservice, by having an Entity named UserExt ('external').

The posts-microservice contains these Entities:

@Table(name = "posts")
public class Post {

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

// the table that holds the id of the User that made the Post. Used the wording 'ext' for External, to differentiate the
// data that is not in this microservice (or database, but for simplicity I use 1 DB, even though each microservice,
// uses its own set of tables). However, since it would be inefficient to call users microservice to retrieve user data when
// building a post response, we also store some crucial user data in this ms as well.
@ManyToOne
@JoinColumn(name = "user_ext", referencedColumnName = "id", nullable = false)
private UserExt userExt;

// --- other post related fields
}

@Table(name = "user_ext")
public class UserExt {

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

@Column(nullable = false, name = "user_id_ext")
private Long userIdExt;

@Column(nullable = false, name = "user_email_ext")
private String userEmail;

@Column(name = "first_name", nullable = false)
private String firstName;

@Column(name = "last_name", nullable = false)
private String lastName;

@Column(name = "short_summary")
private String shortSummary;

@Column(name = "profile_photo")
private String profilePhoto;

}

The issue I am facing is this:

If I chose to use POST /posts to create a new post, the client will not need to give any ID and I can get the username/email of the currently authenticated user to identify the user that the created post belongs to. However, this way, unless I make a call to users-microservice, I will not be able to get the userId. One way would be to only store the email/username of the user in the UserExt entity. However, this would be an issue with the below scenario.

Another scenario: If GET /users/userId/posts is used to get all the posts of a certain user and I only store the username/email of user in the UserExt, how would I be able to satisfy this case.

What would be the best way to handle these cases?

Answer 1

I'm assuming you are using JWTs for authentication. You can store userId, username and email in the JWT. However, you will need to have user data from user service.

The one to one relationship is probably wrong though. One user can have many posts right? In this case you can try to save the post with that userId, if that fails because of foreign key constraint violation (user does not exist in the posts db), then you can fetch the user from user service and save it to the database and save the post again.

Now you are dealing with redundant data, which means that you will have to have a way of telling the posts service that user data was updated on user service. This is done with some message broker - kafka, rabbitmq, etc. - where you emit "UserUpdated" event from user service and listen for this event in posts service and update user information accordingly.

I think that this is how microservices are done properly, however, this means a lot of work is required and a lot of complexity is introduced.

If you want to reduce complexity, don't have redundant data, but just store userId. So Post entity will have userId, which you will then resolve into the user by calling the other service. This simplifies your design, although it is a bit more inefficient and adds a bit of complexity if you want to query your posts.

The main takeaway is to stay away from microservices if possible.

Answer 2

One of the core principles about microservices is that they are independently deploy-able. There are additional disciplines that are required to make that a reality, but let's restate the requirements that are necessary in this scenario:

1. Posts must be associated with a user
2. Assumption: it's a UI requirement to see poster email, etc.
3. Assumption: we want to see the current user information
4. We must minimize the number of synchronous calls

There's some inferred requirements we want to include here based on the fact we are using microservices.

1. We do not want to leak implementation details for user information (i.e. replicate that data in different services)
2. We want one authoritative source of user information (i.e. the user service)

With all of that in mind, there are already a couple technologies that help solve those problems. The first issue is associating posts with a user.

• JWT can contain more than the user ID. It should have everything necessary to validate the user has the correct permissions (i.e. attributes and roles)
• The JWT should only be valid for a short period to avoid easy spoofing
• The Posts service would be storing a reference to the User. I.e. the sub claim in the JWT.
• The Post service's POST handler would require the JWT to exist in the Authorization HTTP header (or application specific header), and that the JWT is validated and the user is authorized to perform the action before continuing

Also, providing a layer to view your data as a graph can avoid extra calls when necessary. Currently, the most prominent solution for that is GraphQL. Historically there was also Falcore, but it's maintainers abandoned it in favor of GraphQL.

• When properly configured, GraphQL solves the N+1 problem (i.e. 1 query to get a list of results, and 1 query for each row to look up associated information)
• The Schema allows the client to request the size and shape of data (i.e. limit the fields to what is needed in the front end)
• The GraphQL layer allows you to view the information in your Posts service and your User service as if they were one related group.
• You can easily introduce caching in this layer to speed up common queries

Obviously there are more than one way of solving this problem. This combination avoids the complexity of asynchronous updates to notify services when data changes.