Voglio progettare un'API supportata da un database (non importa quale, ma per rendere la discussione più interessante, diciamo che è Mongo - spiegazione in basso) che invia i dati a un client.
Il database contiene diversi tipi di record. Alcuni di essi fanno riferimento ad altri tipi di record.
Non è raro che un record sia referenziato da diversi altri record di diverso tipo. Quindi i dati sul DB sono normalizzati.
Quali sono le considerazioni nella progettazione di un server API che invia i record al client?
Mi vengono in mente due opzioni (sei invitato a suggerire di più oa correggermi su quelle):
- L'API è granulare. Invia dati normalizzati. Lascia che il cliente chieda più record in base a ciò che riceve. Il client può avere una cache, esso può decidere che non ha bisogno di chiedere al server per tutto.
- L'API invia tutti i record che potrebbero essere necessari al client in base a dati richiesti In tal modo denormalizzando efficacemente i dati.
Con l'opzione 1, il client può effettuare più richieste HTTP in modo che possa avere i dati completi di cui ha bisogno. Significa più comunicazione di rete, che può rallentare il trasferimento totale dei dati. Il server è più semplice e il client può chiedere selettivamente solo i record che non ha già.
Con l'opzione 2, meno richieste HTTP. Ma potremmo inviare i dati del cliente che ha già (forse già ricevuto e memorizzato nella cache, alcuni dei record in una precedente richiesta). Il server è più complicato. Soprattutto se non è RDBMS. Non ci sono join in Mongo, quindi dobbiamo interrogare il DB più di una volta per ottenere tutti i dati.
Ulteriori ipotesi:
- I dati cambiano ogni pochi giorni (2-3 volte a settimana). Quindi il client può potenzialmente avere una cache persistente.
- Le query Mongo sono un po 'lente (milioni di documenti in ogni raccolta).
- In ciascuna di queste sessioni verranno inviati al cliente circa 2 MB di dati.