API remota vs locale per lo sviluppo di app Web locali

Question

API remota vs locale per lo sviluppo di app Web locali

#1 da (5 voti)

3

Sto sviluppando sia un'API REST che un'app Web front-end. Qual è il modo migliore per collegare l'API all'app Web mentre sto sviluppando localmente sul mio computer?

Potrei creare una copia locale dell'API e indirizzare la mia app Web a localhost:api-port , ma sembra un lavoro amministrativo non necessario avere una copia locale dell'API e dell'app Web in esecuzione. Ogni volta che voglio svolgere qualsiasi lavoro di sviluppo dovrò far ruotare l'API, quindi avviare l'applicazione web.
Potrei configurare un ambiente di sviluppo remoto e indirizzare la mia app web a dev.api.mydomain.com per lo sviluppo locale, ma sembra controintuitivo dover impostare una sandbox API remota per sviluppare localmente l'app web.
Potrei simulare schemi e dati con file JSON per lo sviluppo locale. Anziché l'app Web che esegue un recupero su api.mydomain.com , leggerà solo ./mock-data/some-resource.json . Sembra un sovraccarico in più per mantenere schemi e dati corrispondenti alla produzione. Inoltre, non gestirà alcuna logica incorporata nell'API oltre a restituire le risorse non elaborate.

Il modo migliore per avanzare?

api development-environment

posta Nick Faughey 06.04.2017 - 17:09

fonte

1 risposta

Leggi altre domande sui tag api development-environment

Ereditarietà con singleton Il modo migliore per progettare i flussi in base alle operazioni

score 5 · Accepted Answer

L'opzione 1 è sicuramente la strada migliore nella mia esperienza. A volte uso l'Opzione 2, in genere in scenari come l'aggancio della mia applicazione locale a un database remoto (che di solito ha anche un'altra istanza dell'applicazione collegata ad esso, lo fa con estrema cautela).

I vantaggi di eseguire tutte le applicazioni localmente per lo sviluppo:

Puoi eseguire il debug delle integrazioni con la tua API senza il fastidio di un debugger remoto.
Puoi vedere i log per entrambe le applicazioni senza dover accedere a un server tramite ssh (o Desktop remoto per Windows)
Puoi fare tutto ciò che vuoi sui dati sottostanti dell'applicazione senza influire su nessun altro che lavori sull'app (supponendo che tu esegua il database dell'applicazione anche localmente).
È possibile prototipare le modifiche in entrambe le codebase senza la distribuzione.

L'esecuzione di tutto localmente comporta un costo di installazione (a seconda di quanto siano complesse le dipendenze del runtime, questo può variare da pochi minuti a diversi giorni di lavoro), ma anche così, il sovraccarico è uno sforzo una tantum. / p>

Every time I want to do any development work I'll have to spin up the API, then spin up the web app.

Per risolvere questo problema, puoi scrivere uno script di avvio che avvia entrambi i servizi insieme. In alternativa, puoi utilizzare docker e docker-compose per eseguire localmente le app. Se li collega esplicitamente nel file docker-compose.yml , l'API verrà avviata quando avvii il front -app app. Questo tipo di orchestrazione dell'applicazione è esattamente ciò per cui è creato docker-compose . Anche sul lato positivo, con Docker è sufficiente risolvere il problema di impostazione dell'ambiente una sola volta. Lo svantaggio di Docker è che può essere complicato (o impossibile) collegare un debugger IDE nel contenitore a seconda del tuo runtime. In questi casi potrebbe essere preferibile impostare il proprio ambiente di sviluppo locale in modo nativo sulla macchina e utilizzare l'approccio dello script di avvio per l'orchestrazione dei servizi.