Microservizio a livello di frontend

Question

Microservizio a livello di frontend

#1 da (3 voti)
#2 da (1 voti)
#3 da (0 voti)

3

Sono uno sviluppatore di software e il tipo di sviluppatore che chiamiamo "sviluppatore front-end". Sto lavorando su argomenti come Angular, React, Vuejs e molti altri.

Volevo sapere come possiamo organizzare il nostro front end in modo da poter adattare un'architettura di microservizi.

In realtà, scaliamo i servizi tra le unità, ogni servizio è "indipendente" o, per lo meno, è disgiunto dagli altri. Questo ha perfettamente senso. La mia domanda è:

Come possiamo organizzare il codice, in modo che il nostro codice di front end possa abbinare questi servizi?

Non voglio creare applicazioni monolitiche in un contesto di microservizi e su larga scala. Stavo pensando a un modo per dividere i miei componenti front-end. Ma i problemi arrivano quando proviamo ad esporre quei componenti in una pagina web che li aggregherebbe per creare un'applicazione reale ...

Sono un po 'perso in questa situazione e ho bisogno di aiuto per capire il flusso su un lato frontale.

Se puoi, collega tutti gli articoli o le pratiche che potrebbero aiutarmi.

microservices front-end

posta mfrachet 26.01.2017 - 08:56

fonte

3 risposte

Leggi altre domande sui tag microservices front-end

In che modo i metodi CLS compatibili hanno variabili locali non conformi? Progettazione REST per azioni "complicate" che riguardano più di una risorsa

score 3 · Answer 1

La scorsa settimana ho svolto ricerche esaustive sull'organizzazione dei microservizi sul FrontEnd.

Penso che l'approccio più semplice sarebbe quello di sfruttare la tua libreria / struttura di scelta per separare diversi pezzi del Front End in verticali corrispondenti ai rispettivi micro servizi di back-end. In Angular questo sarebbe qualcosa come i Moduli che sono pigri carichi dove ogni modulo corrisponde a un microservizio. Potresti spingersi fino al punto di utilizzare i tuoi strumenti di compilazione (ad esempio Webpack) per limitare l'output ai soli componenti per i micro service che vengono distribuiti.

Se hai già repository frontali discreti, è più difficile perché devi decidere come unire i componenti. Alcune opzioni per la composizione della pagina includono:

iframe HTML che sono in circolazione da molto tempo, ma hanno compromessi come prestazioni, comunicazione tra componenti, nidificazione di componenti, ecc. Tuttavia gli iframe offrono la massima libertà quando si tratta di consentire due componenti (micro service) per eseguire side-by-side nello stesso DOM.
Polymer, Vue e React offrono molto quando si tratta di composizione di elementi personalizzati, ma senza un diverso documento di root dovrai gestire attentamente le dipendenze dei componenti in modo che le librerie non si combattano / si rompere l'un l'altra.
i componenti web nativi stanno per arrivare ai browser moderni, ma starai meglio con Polymer, Vue o React perché credo che offrano polifibri e altri vantaggi.

Dato che posso pubblicare solo 2 link, qui sono forse i più rilevanti.

link
link

score 1 · Answer 2

Non sono un granché un sostenitore del microservice (un po 'indifferente al concetto), avendo detto che quando li usavo considererei ancora nasconderli il più possibile dal frontend usando un'API specifica' backend for frontend '(BFF) . I microservizi dovrebbero essere scambiabili, questa possibilità di sostituzione non migliora quando si prende dipendenza da questi dal front-end.

Supponiamo che tu abbia un "microservizio" che si occupa di inviare e-mail basate su modelli per te. Il tuo front-end chiama la tua API BFF, richiedendo l'invio di un'email. Il BFF sceglierà e invocherà appropriatamente il microservizio sul tuo comportamento. Mantieni agnostico il tuo front-end.

score 0 · Answer 3

Nell'azienda in cui lavoro, abbiamo molti microservizi. Non so molto sullo sviluppo web, ma le nostre app per Android e ios hanno una struttura che rispecchia i microservizi. Quindi esiste una classe CustomerApi che gestisce solo la rete al CustomerService (nel back-end) e quindi nelle app c'è anche una classe CustomerService che contiene i metodi pubblici che altri componenti nell'app possono utilizzare come getCustomer () o updateCustomerPaymentMethod () . Queste classi di servizio vengono quindi iniettate nelle altre classi dell'app per l'uso. In realtà avevamo questa architettura nelle app anche quando avevamo ancora un backend monolitico ed era un modo molto naturale per organizzare le responsabilità.