Gateway API: filtraggio dei dati tra microservizi

Question

Gateway API: filtraggio dei dati tra microservizi

#1 da (2 voti)

0

Ho un Location Service con un endpoint che restituisce le persone vicine a un determinato utente:

GET /users/near?user=7455 

[
    {
      "userId": 1214,
      "location" : [2134983, 89384]
    },
    //more users
]

D'altra parte, ho un Visits Service che gestisce le visite tra utenti:

[
    {
      "userVisitor" : 7155,
      "userVisited" : 8778,
      "date" : "1991/02/10"       
    }
]

Ora, dal gateway API, ho bisogno di recuperare utenti vicini a un determinato utente e che non sono ancora stati visitati da lui. Qualcosa come questo (pseudocodice):

user = 7758
users = LocationService.getNearUsers(user)
output = []
for (userTarget in users) {
    if VisitsService.userHasNotVisited(user, userTarget) {
        output.add(userTarget)
    }
}
return output

È un buon approccio? O dovrei implementare un endpoint in Visits Service che filtra gli utenti non ancora visitati da un determinato elenco di utenti? Qualcosa del genere:

GET /visits/filter/nonvisited?visitor=7758&targets=1277,3681,3586

e fai qualcosa come:

user = 7758
users = LocationService.getNearUsers(user)
output = VisitsService.filterNonVisited(user, users)
return output

Qual è la soluzione migliore?

api-design microservices

posta Héctor 24.07.2017 - 11:02

fonte

1 risposta

Leggi altre domande sui tag api-design microservices

Gli esempi di utilizzo nella documentazione XML dovrebbero essere testati esplicitamente? Come identificare con sicurezza i rami obsoleti di Git

score 2 · Accepted Answer

Questa è davvero una questione su come organizzi i tuoi dati.

La tua query complessiva "Ottieni utenti che non hanno visitato l'utente x all'interno di quest'area" è molto relazionale.

Puoi immaginare la configurazione della tabella, con gli utenti, la posizione e una tabella di visite da molte a molte, che puoi interrogare tutto in una volta.

Select * from users 
left join (select visits where userId= Y) 
where 
user.location is near X, 
visits.id = null

o qualcosa. Quindi ti staresti chiedendo se valeva la pena di preoccuparti o se una combinazione di ottenere utenti e ottenere visite potrebbe ottenere lo stesso effetto in un tempo ragionevole e più generico.

Tuttavia, se hai una configurazione NoSQL come hai indicato sei un po 'bloccato con le tue visite perché non puoi davvero fare la clausola relazionale where.

La soluzione NoSql richiede di raggruppare i dati con una singola chiave. Mettere tutte le visite in un singolo documento, possibilmente lo stesso documento utente che stai usando per tutto il resto.

Questo significa che puoi ottenere i tuoi risultati in due query veloci, ma devi fare il filtraggio del codice.

Lo svantaggio è che se ogni utente ha molte visite devi recuperare molti dati che non ti servono. Inoltre, l'inclusione di un campo data suggerisce che potresti voler effettuare un ulteriore filtraggio.

Un modo per ovviare a questo problema è introdurre un nuovo oggetto che raccoglie i dati desiderati.

Diciamo che il caso d'uso è un venditore che visita una città e vuole visitare tutti i clienti della città una volta, a meno che non li abbia visitati entro un mese.

È possibile generare quell'elenco di controllo una volta come un'operazione lenta, salvarlo in un singolo documento come un CityVisit e quindi chiedere all'utente di rimuovere gli elementi da esso ogni volta che effettuano una visita. Quindi è una rapida chiamata per recuperare l'elenco e può essere buttato via una volta terminato.