Suggerimento di progettazione API (o simili)

1

Nella nostra azienda, abbiamo una struttura di dati relativamente grande, con terabyte di informazioni storiche memorizzate e ci sono molte viste, editor e report per tutti i dati. Con gli anni, ci sono state diverse "mani" coinvolte nel codice sottostante per il recupero e l'archiviazione dei dati, che abbiamo scoperto che hanno preso diverse considerazioni tra diverse viste (ad esempio) che portano a report non coerenti, ma questo è anche successo per le GUI di configurazione.

Pensiamo che potremmo implementare la nostra API in cima ai servizi di base, quindi ogni parte del sistema ha un solo punto di interazione con determinati dati, anche se questo può sembrare abbastanza semplice, abbiamo discusso alcune questioni che potrebbero ci turbano in tale implementazione, come ad esempio l'esecuzione di enormi rapporti, in cui devono essere analizzati migliaia di record con un sacco di possibili aggregazioni di dati, filtri e simili.

Ovviamente, possiamo facilmente creare un'API per le operazioni CRUD di base, ma per quanto riguarda le enormi operazioni di visualizzazione dei dati sullo schermo o per la creazione di rapporti Excel? Cosa dovrebbe essere fatto in questi scenari? Qualche buona pratica da considerare? Modelli di design, forse?

    
posta Gonzalo Vasquez 07.02.2017 - 16:55
fonte

3 risposte

1

Quando un'API copre una parte specifica dei dati, non necessariamente deve essere limitata alle operazioni CRUD su questi dati. Fare ciò non porterebbe nulla di utile in termini di astrazione dei dati e avrà un impatto importante sulle prestazioni.

Tale API dovrebbe invece imitare i casi aziendali in relazione ai dati sottostanti. Ciò significa che può fornire funzionalità come aggregazione, impaginazione, trasformazione dei dati in una forma più rappresentativa di una logica aziendale, ecc.

Tuttavia, introdurre troppa computazione / elaborazione nell'API crea il rischio di spostare troppa logica dai livelli superiori - i servizi che chiamano l'API - all'API stessa. Una regola empirica è che ha senso inserire la logica nell'API se la stessa logica viene utilizzata da molti client; se solo un client utilizza una logica specifica, questo deve essere un segno che la logica potrebbe essere stata implementata direttamente nel client.

In generale, quando l'API è ben progettata, non avrai troppi dubbi su dove mettere un pezzo di logica specifico. Ad esempio, è possibile esaminare le API più diffuse e i modi in cui sono state progettate. Ad esempio, l'API di Amazon S3 è piuttosto astratta quando si tratta del formato dei dati sottostanti: osservando l'API dell'S3, non si hanno indizi sulle origini dati (usano MongoDB? O forse PostgreSQL? O forse un mix di venti diversi fonti di dati?) o anche l'architettura (c'è un server che conserva tutti i dati? O forse un centinaio? o migliaia e migliaia di server interagiscono insieme?) Allo stesso tempo, l'API di S3 contiene esclusivamente la logica necessaria per lavorare con memorizzazione e recupero di blocchi di dati: ACL, memorizzazione nella cache, rimozione automatica, ecc., ma non contengono nulla che appartenga da qualche altra parte: ad esempio, S3 non fa alcuna differenza tra la memorizzazione di file video per un sito di streaming video o memorizzazione delle descrizioni dei prodotti per un sistema di gestione del prodotto.

    
risposta data 07.02.2017 - 21:25
fonte
1

Succede quando il tuo sistema è in funzione da molto tempo e raccogli enormi informazioni, penso che i passaggi seguenti potrebbero aiutarti.

  1. È necessario disporre di un nuovo server su cui è necessario memorizzare il database.
  2. Una volta che hai finito con il nuovo server per il database ora usa cdn per recuperare i dati.
  3. Per avere un tempo di esecuzione migliore utilizzare un linguaggio con operazioni di I / O migliori come Node JS

Spero che i punti sopra siano in breve non in dettaglio ma ti daranno un'idea.

    
risposta data 08.02.2017 - 15:34
fonte
1

Nei grandi scenari di dati ci sono in realtà due database

  • un database scrivibile per attività giornaliere con meno di un milione di datarows e
  • un database di sola lettura analitico con i terabyte di informazioni storiche per la generazione di report

Periodicamente (vale a dire una volta al giorno) i dati vengono trasferiti dal database scrivibile al database dei report di sola lettura

  • svantaggio: il contenuto del database storico è di 24 ore
  • vantaggio che hai buone prestazioni sul database scrivibile perché non è occupato dai rapporti

suggerimento di design: crea 2 sperate api-s:

  • uno per i report di dati di grandi dimensioni e
  • uno per l'attività giornaliera
risposta data 08.02.2017 - 17:47
fonte

Leggi altre domande sui tag