How to implement "Foreign key" using Micro Services architecture? Django

Asked

Viewed 806 times

1

I’m trying to build a system using micro services architecture, I came across the problem about dependency, in case how to implement chave estrangeira using this architecture? I’m using Django

Example

The class pedido which will be a service is linked to a customer, which will also be service, how to implement this in microservices architecture since both are physically uncoupled?

normally I would declare so

class Pedido:
    cliente = models.ForeignKey(Cliente)   

and would access a customer from such an order :

p = Pedido.objects.filter().first()
p.cliente.nome

Using the architecture of miroservicos I could not declare this way since the class Cliente would not exist in the service Pedido

  • I have no experience with micro services, but if I understand correctly you want to decouple Pedido of Cliente, so that they can reside in separate systems (maybe in different Bds, or even in different servers), is that it? If yes, I don’t know anything ready in Django to do that, I believe you would have to store in the field cliente not a foreign key but a simple (integer? string?) value that uniquely identifies that same customer between different services. So to get the customer associated with that order, you would make a Cliente.objects.get(xxx=p.cliente).nome.

  • 1

    That, is, doesn’t really have much information yet on how to do this in practice, in theory we see tons of articles saying what it is, showing the advantages but showing an implementation example is difficult, in that case then I would lose a good part of the advantages of Django’s ORM, I would have to do a very manual job. I don’t have more time, I’ll do monolithic and there in front we change the architecture, vlw

1 answer

3

Do not take this question of uncoupling too literally because it risks doing so in the wrong place. Try to bring the idea of micro service to the real world and see what happens. Imagine the following situation:

  1. You enter a restaurant and sit at a TABLE;
  2. The waiter come and take the ORDER and take the TABLE number;
  3. The waiter, takes the ORDER up to kitchen who prepares the REQUEST and doorbell when you are ready;
  4. The waiter serves the dish on the TABLE;
  5. You consume the ORDER and ask the waiter THE ACCOUNT;
  6. The waiter go to Té the cashier, ask for the BILL and give it to you;
  7. You go up to the cashier, pays the bill and leaves.

Note that in this case micro services are represented by waiter, kitchen and cashier.

The waiter doesn’t know anything about making food, the kitchen doesn’t know anything about serving and the cashier only knows they have to charge, meaning they are UNCOUPLED and work independently.

But see that they all have the customer view (represented by MESA) and ORDER. Here it is clear that you should not separate these entities and what happens in this type of architecture is the data REDUNDANCY because each service has to have a copy of the REQUEST with the TABLE number.

Therefore, Microservices although independent and asynchronous have to store the same information and to ensure this have to have an efficient form of communication (sockets is a good example).

If you read the article from Martin Fowler will see that it recommends to start same monolithic and create micro services only when necessary. To do this at the beginning is waste of time.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.