Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hints on extending with one additional service #7

Open
CesMak opened this issue Jan 26, 2022 · 1 comment
Open

Hints on extending with one additional service #7

CesMak opened this issue Jan 26, 2022 · 1 comment
Labels

Comments

@CesMak
Copy link

CesMak commented Jan 26, 2022

Hey Miguel,

I would like to extend the mircoflack chat app on one additional service named game.
This service should have access to the users and messages db.

I guess I have two options:

  1. Make users and messages a wheel and install that with the requirements of the game service, such that I can do inside app.py of game service
from microflack_users.app import User
  1. Use the api to get all relevant information from users and messages db
  • in this case I think I have to worry about tokens etc. for a secure access?
  • How can I make an api endpoint that is only access-able with an internal token?
  • Can you give a short code example how to do that in a secure way?
       ip='http://'+os.environ["HOST_IP_ADDRESS"]
        r = requests.get(ip+'/api/users')

I guess regarding the microservice architecture the second option is preferable.
What would you advise?

@miguelgrinberg
Copy link
Owner

miguelgrinberg commented Jan 26, 2022

Sharing the database of a microservice with another microservice is really against the microservice principles. The correct way to do this when following the microservices model is to have your new service use the APIs of the users and messages services to work with those entities.

If you can, you should get a token from the client, which you can then use to authenticate internally to other microservices. If that is not possible, then you can allocate a token that is only valid for internal use between services, or maybe configure your services so that they only require authentication for external requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants