API REST con 1000 modelli di query?

0

Come gestisco forse 1000 query SQL in un'API REST Golang?

La mia esperienza SQL è al livello di base superiore usando Postgresql. Oggi utilizzo uno strumento che consente di utilizzare SQL semplice e una sorta di ORM per accedere direttamente al database. L'obiettivo di utilizzare ORM è quello di semplificare, ma con query complesse rende davvero più difficile. Quindi preferisco usare SQL semplice e voglio evitare GORM o simili.

Quando si parla di Golang, la mia esperienza è ai primi livelli. Ho fatto una semplice API REST con circa 5 query. Ed è gestibile.

Tutti gli esempi di API REST di Golang sono al livello Hello World. Ma ho bisogno di un modo per gestire diverse centinaia di strutture e query. Facile da codificare e facile da capire e mantenere. E ho trovato finora 3 modi per farlo.

  1. Archivia le query utilizzando modelli o simili.
    link

  2. Usa 1000 pacchetti. Ma questo mi sembra ingestibile.

  3. Memorizza le query insieme alla struct in un database Postgresql di ricerca. Scarica la query desiderata e attiva la query. Questo sarà facile da mantenere, ma aggiunge un altro livello che potrebbe influire sulla velocità.

Oltre a questi pensieri, ho provato un approccio dinamico senza fortuna.

Mi chiedo se qualcuno che si imbatte in questo possa condividere alcuni pensieri e consigli?

TIA!

    
posta sibert 22.10.2018 - 11:21
fonte

1 risposta

2

Scrivi 1000 pacchetti.

Il vantaggio di farlo in questo modo è quello di sfruttare al meglio il controllo del codice sorgente esistente e la pipeline di distribuzione per gestire lo sql.

Memorizzare le query da qualche altra parte significa che è necessario implementare un controllo supplementare sulle modifiche su tale spazio di archiviazione.

La vera domanda qui è però perché hai 1000 query SQL? Forse hai semplicemente 1000 tavoli, o dici 250 con CRUD su ciascuno.

Ma forse ci sono altre pecche nella tua progettazione o nei tuoi requirments che ti inducono ad avere più logica nel tuo SQL del necessario.

Ad esempio, se avessi un getEmployees API in azienda, non aggiungerei getEmployeeByCompanyAndEmployeeName a meno che non ci fossero migliaia di dipendenti per azienda. Vorrei lasciare che il codice chiamante effettui quella ricerca.

Allo stesso modo, selezionerei e restituirò tutti i campi in una tabella, invece di avere sql per diversi sottoinsiemi di dati. È compito dei codici di chiamata decidere quali campi usa o meno.

Devi davvero avere qualcosa di diverso da uno standard 'nascondi il database' api per voler rendere il modificabile sql separatamente dal codice.

    
risposta data 22.10.2018 - 13:09
fonte

Leggi altre domande sui tag