Disaccoppiamento dell'API REST e dell'applicazione web frontend

Question

Disaccoppiamento dell'API REST e dell'applicazione web frontend

#1 da (8 voti)
#2 da (1 voti)

1

Sto imparando Ruby on Rails proveniente da Node.js / express e ho alcune domande sul design. Ho usato React.js per il frontend nelle mie app di Node e ho intenzione di continuare a farlo nelle mie app Rails.

Cosa stavo facendo in Node.js

Tutte le richieste che iniziano con / vengono gestite da un "router di visualizzazione". Questo serve essenzialmente tutto l'HTML e qualsiasi JSON iniettato. Ad esempio:

mywebsite.com/profile servirà HTML del profilo dell'utente.

Le richieste che iniziano con /api vengono gestite da un "router API". Questo aveva le rotte dell'API REST per accedere alle risorse.

GET mywebsite.com/api/profile serve il JSON per il profilo.

L'app React caricata in profile.html , ad esempio, renderebbe una richiesta HTTP a GET mywebsite.com/api/profile e popolerebbe la vista. (Naturalmente, avrei potuto inserire il profilo tramite EJS, ma questo è un caso d'uso di esempio)

Si noti che entrambi questi router erano in esecuzione sullo stesso server / IP

Cosa sto pensando di fare con Rails

Ho intenzione di creare app più complesse che abbiano sia un client Web che client mobili nativi. Ciò significa che ho bisogno di un server REST stateless. Ho letto questa guida sulla generazione di un'app Rails "solo API" che mi ha fatto pensare di rendere l'API REST il proprio server, forse sotto api.mywebsite.com e avere tutte le visualizzazioni pubblicate da mywebsite.com . La prima sarebbe un'app Rails solo per API, e quest'ultima sarebbe una normale app per Rails che offre viste.

Inoltre, come domanda a parte, stavo leggendo la Documento di reazione delle rotaie e stava avendo problemi a trovare alcuni aspetti negativi. Se qualcuno con la conoscenza di esso può fornire l'altro lato della storia, sarebbe molto apprezzato!

Per un'app che potrebbe potenzialmente complicarsi e scalare, il disaccoppiamento dell'API REST e del View è una buona idea? Cosa fanno le aziende come Twitter e Github (che usano o usano Rails credo)?

design-patterns rest ruby-on-rails

posta Carpetfizz 23.12.2016 - 23:16

fonte

2 risposte

1

Non creare app separate, creerai più lavoro per te stesso quando non ne hai davvero bisogno.

Ad esempio, se lo hai fatto

rails new --api

per creare solo un'app api grezza da eseguire sul proprio server, cool, che può funzionare MA ...

ora dì che vuoi questa altra app per eseguire il rendering delle pagine, quindi

rails new myapp

Hai un problema fondamentale che entrambe le app devono condividere lo stesso set di modelli per parlare allo stesso database. Ciò significa codice duplicato in entrambe le app. In teoria, potresti creare un motore per condividere quel codice e aggiungere il motore come una gemma di dipendenza da entrambe le app. Ma ancora, si crea molto più lavoro. Fidati, sono già stato in questa strada.

Per un nuovo progetto che vuoi ottenere velocemente, basta creare una singola app Rails monolitica, dimenticarti di Rails new --api. Basta creare una "api" namespace all'interno di quella singola app. Più tardi, quando ne hai la necessità, puoi separare più facilmente le cose.

risposta data 23.02.2017 - 19:39

fonte

Leggi altre domande sui tag design-patterns rest ruby-on-rails

Comunicazione tra lingue Confusione della dichiarazione nei puntatori [chiuso]

score 8 · Accepted Answer

Non posso parlare per Twitter e Github, ma posso parlare per Stack Overflow.

Non mi preoccuperei della "scala" come idea astratta possibile. Mi preoccuperei dei tuoi bisogni attuali e dimostrabili nei prossimi 6-12 mesi. Il ridimensionamento richiede molto lavoro, misurazione e messa a punto che non possono realmente essere anticipati. Ad esempio, Stack Overflow richiede solo alcune parti da suddividere in servizi. La maggior parte dell'applicazione è felicemente monolitica.
Una cosa che Github sicuramente fa e Twitter non lo rende sul server, così come sul client. Lo facciamo anche noi. Il motivo sono le prestazioni: a nessuno piace aspettare che una pagina venga caricata e quindi attendere il caricamento del contenuto. È stato dimostrato che anche l'aggiunta di 0,1 secondi a un tempo di caricamento della pagina ha un impatto negativo sull'impegno in modo sostanziale.

Di conseguenza, non mi preoccuperei troppo della struttura dell'URL per l'API. Mi preoccuperei invece di creare un framework condiviso che possa essere utilizzato sia sul front-end che sul back-end per accedere ai dati e quindi esposto in modo indipendente come pagine o API.