Search code examples
design-patternsmicroservices

How to handle authentication (with registration) with custom user fields, relations, images in microservice architecture?

I'm new to microservices. Always used monolith frameworks.

I don't quite understand how to implement in microservices architecture for this sample project:

Client Application (SPA)

Backend

  • Users with different access (user, admin)
  • Quizzes (with quiz-sessions for each user.)
  • Gifts (for successfully completing quiz or questionary)
  • Images for quizzes
  • Images for gifts

I am planning on using API Gateway pattern for all requests from client side to be checked for authentication.

I kind of understand that API Gateway can generate JWT Tokens or similar and give them back to client side. Also API Gateway will store routes which require authentication and pass requests through only on authentication being successful.

I don't understand how to connect users microservice here. If I understand correctly - microservices are designed not only for decoupling but also for being reusable components (at least my main wish to create reusable microservices).

So API Gateway can be aware of user microservice and create users for registration there.

But what about sending emails for confirmation? How can this be done here? I assume I can create email sender microservice, and API Gateway will be aware of it as well.

But when business logic dictates to add additional field to users, except fields like email, name, phone etc. For example age, occupation, height etc? Wouldn't it make users microservice contaminated with custom business logic?

And after all that, I wonder how can I make relations between users and quizzes and gifts?

I intend to use docker and each stateful microservice to have it's own separate database (each microservice - separate docker compose files). Again, for reusing microservices after in different projects.

And how to store images? In what microservice precisely?

Solution

  • Okay, let's go through this one by one. There's a bit to unpack there.

    Also, API Gateway will store routes which require authentication and pass requests through only on authentication being successful.

    That's not necessarily how it has to be - I find it's easier and more efficient to fetch User from AuthService in Gateway, then propagate its data to underlying services. This way you can have permission flags and anything else you need to authenticate on the target service.

    So the API Gateway can be aware of the user microservice and create users for registration there.

    API Gateway, or rather, as it's commonly called - Gateway API, shouldn't be aware of anything, unless you want to create coupling. What you want to do is have a separate AuthService that's called by the Gateway API to resolve the token from the HTTP header/cookie upon request, and to fetch data you can propagate further into the services (also via header, cookie, or what-have-you).

    But what about sending emails for confirmation? How can this be done here? I assume I can create an email sender microservice, and the API Gateway will be aware of it as well.

    No, you're creating coupling. Your EmailService should be plugged into a Message Queue and await the SendEmail event to be sent with the recipient, subject, and message. This can be even less coupled using pub/sub communication - but that's another topic.

    But when business logic dictates adding an additional field to users, except fields like email, name, phone, etc. For example, age, occupation, height, etc. Wouldn't it make the users microservice contaminated with custom business logic?

    Your User is not the same User in different services. Meaning, the context changes.

    You can have User in AuthService with:
    { id, name, email, password }.

    Then, you can have Author in QuizService with:
    { id, nickname, quizzesSolved, quizzesCreated }.

    They're different entities in different contexts, and they can be related by having the same id.

    And after all that, I wonder how I can make relations between users and quizzes and gifts?

    When it comes to users, I told you what you need - a separate entity in your QuizService called Quizor or however you call the one who takes/creates quizzes.

    Personally, I think your QuizService could also handle gifts. You don't have to go this granular. There's no point (yet) in having such precise scaling.

    And how to store images? In what microservice precisely?

    You store them the same way you would store any other image. Then, on the frontend, you can utilize full URLs: https://myepicquiz.com/api/assets/get/{guid}.

    Where you store it is up to you. You can have a dedicated AssetStore, or have it inside QuizService.

    I wrote a little bit about all of that here: https://obeycode.com/articles/7/microservices-in-simple-terms---introduction#concept

    Maybe this will help?