[Musica]
quindi in questo discorso parleremo
sul perché back end per l’amico ed è la chiave
questo è il tuo viaggio in microservizi
in particolare un caso d’uso di Morningstar
è una prospettiva di un team mobile su
come sfruttano questo architettonico
modello così prima della logistica per favore
fai e raid questa sessione nell’app
apprezziamo molto , quindi voglio
presenta questo Brian hey quindi sono il
la seconda metà del mio intervento è Brian
concessione ho iniziato a programmare
professionalmente nel 2005 e iscritto
Morningstar a fine 2012 ho un po ‘ di
contributi significativi al design
e l’attuazione del BFF che
parleremo oggi e
Sono attualmente un manager tecnologico
morningstar di
squadra mobile investitore individuale e io sono
Christian Ramanathan e direttore di
ingegneria alla Morningstar in cui sono stato
l’industria del software per oltre 18 anni
codifica leader nella gestione e nell’architettura
sistemi software mi appassiona
micro servizi DevOps AI e macchina
imparando così iniziamo chi siamo
Morningstar al centro è un investimento
società di ricerca e la nostra missione è quella di
creare ottimi prodotti per questo aiuto
gli investitori cercano obiettivi finanziari così
ora ho parlato degli investitori che abbiamo
segmenti di clienti che vanno dall’individuo
gli investitori come te e me i tuoi prodotti
per loro a clienti come finanziari
consulenti di prodotti nello spazio di pensionamento
e anche la gestione patrimoniale ci siamo diffusi
attraverso 27 paesi e siamo all’incirca
42 cento più impiegati e noi siamo
con sede a Chicago
quindi siamo locali come serviamo i nostri clienti
quindi la chiave per qualsiasi investimento è avere
accesso a dati di qualità e creazione di un
decisione informata usando così il bambino
i client di cella forniscono dati al
fondamento per noi e poi risalendo il
piramide forniamo l’aggiunta di valore in cima
quindi forniamo prodotti software e
visualizzazione Honda lytx e anche l’accesso
all’analista di tutti gli investimenti in a
livello più alto del valore proposizione noi
fornisci anche consigli così da essere gestiti
investimenti gestiamo il portafoglio entrambi
anche dal punto di vista degli investimenti
dai conti di pensionamento
andiamo al discorso per amici
fine così ho preso questa descrizione dallo scatto
Il post sul blog di Newman è l’autore di
costruendo micro servizi ha fatto un grande
Parliamo ieri del nostro interruttore su funzionalità e
e la funzione di ramificazione era carina
interessante quindi sai che è anche il
host di micro servizi traccia oggi così lui
è venuto con questa descrizione e lui
accredita anche questo modello architettonico
a Philly Kyle Cairo così l’idea alle spalle
questo modello è invece di avere un
l’API di back-end del core centrale usa il
ti concentri maggiormente sulla costruzione di un back-end
per una particolare esperienza utente così dentro
questo caso lo schema a sinistra noi
avere due back-end per front-end in modo che il
il client desktop che hai creato ha un
back-end per questo e allo stesso modo per il tuo
app mobile hai un back-end per questo
esperienza utente il diagramma sulla destra
è una leggera variazione di ciò che vorresti
vedi che non puoi avere un back-end
per il tuo Android
diverso da un’esperienza del vuoto o a
esperienza utente per un Android così
fondamentalmente hai due back-end separati
per amico è per il tuo Android e uno
per il tuo iOS il driver chiave per usarli
pad e in genere si vedrebbe il
spazio mobile hai te te
generalmente tendono ad avere meno dati
l’ esperienza dell’utente è leggermente diversa
e anche tu hai una vista specifica
back-end hai bisogno di una vista specifica
back-end per soddisfare il tuo utente
esperienza così ho intenzione di camminare attraverso
il nostro viaggio come abbiamo iniziato probabilmente dieci
anni fa avevamo questo prodotto desktop
che abbiamo costruito, direi che è un
chiave prodotto b2b non posso rivelare il
nome in questo momento, ma era principalmente a
BFF abbiamo iniziato con il BFF a questo
tempo puoi anche chiamarlo monolite il
tutta l’ idea dietro quello eravamo noi
fondamentalmente potremmo avere un livello API
caddis per tutta l’esperienza dell’utente a
l’app desktop e l’ annuncio sono tornati su ciò che noi
è stato necessario sviluppare
lancio di altri tre prodotti, quindi cosa noi
è stato allungato l’ API del prodotto e
ha permesso l’ avvio di altri tre prodotti
rapidamente ed e questo era il tipo di
modello di progettazione che abbiamo scelto in quel momento così
che tipo di riutilizzata API intendevamo
mercato più veloce ma indovina cosa succede
subito dopo il team che ha prodotto il prodotto
beep C e D si sono dispersi e poi tu
finisci nella situazione in cui nessuno
passare al codice prodotto di cui P ha ora bisogno
tipo di un tipo di esso diventa molto
difficile fare quei cambiamenti perché
ora il tuo impatto
altri tre prodotti in modo che fosse un po ‘
il caso probabilmente otto anni fa noi
anche se siamo riusciti a riutilizzare ma
subito dopo la manutenzione è diventata a
problema perché ogni piccolo cambiamento ha un impatto
in tutti e tre i quattro prodotti ora probabilmente
a circa quattro anni fa ciò che noi
abbiamo fatto i nostri atti insieme e noi
applicato questo concetto di BFF e la costruzione
tutti i prodotti quindi abbiamo ampliato in due
dimensioni uno è stato aggiunto più servizi
e mi piace se vedi qui da quando ci occupiamo
con i titoli quindi creiamo specifiche API
ai titoli che abbiamo AP è specifico
un dato in tempo reale e abbiamo API
specifico per i portafogli tipo di a
capacità guidata o in movimento verso a
più architettura di microservizi e a
allo stesso tempo chiediamo anche ai team di prodotto
avere il proprio back-end così di questo tipo
di una graduale evoluzione ci ha permesso di
tipo di passaggio verso più moderno
architettura così approssimativamente cosa succede
tipicamente in una specie di team è quello che hai
la maggior parte delle squadre che costruiscono questi
servizi dopo due o tre anni
rendersi conto che hey il mio back-end è obsoleto
la tecnologia è obsoleta che voglio
costruisci una nuova versione di quello che era
questo è quello che è successo anche a noi
molti team i team di servizi di back-end
hanno iniziato a costruire una nuova versione di
la loro api è e noi abbiamo espanso
le nostre sfide ne hanno altre
versione così ora ha tutti i team di prodotto
per ora gestire tutte le API e la nuova API
quindi cosa facciamo in modo che il back-end
all’avanguardia e architettura ci hanno aiutato
questo e vedrai di più quando
Brian entra nel dettaglio di come noi
implementato quindi parlerò di
il nostro viaggio in mobilità, quindi abbiamo otto
app su App Store sul lato iOS e
una app su Android, quindi siamo di più
tipo di iOS focalizzato ora per via di
la maggior parte basata sulla ricerca dell’utente che abbiamo
più utenti iOS che Android quindi nel
viaggio mobile probabilmente cinque anni fa
noi l’app chiave tutte le otto app
App di vendita al dettaglio di iPad uno dei era uno di
l’app chiave per noi nel segmento retail
quindi avevamo già un sito web di dub
dub dub morningstar.com che era una rete
a quel tempo era un monolite era
facendo molte cose e stava servendo il nostro
utenti desktop tramite browser, quindi cosa abbiamo fatto
era al via abbiamo iniziato
costruendo la nostra app mobile con questo
Era il servizio mobile come strato BFF
abbastanza naturale per noi in quel momento noi
non sapevo di questo schema in questo
tempo ma noi ci siamo semplicemente cascati
quella volta perché non potevamo riutilizzare
qualsiasi applicazione web legacy lì
c’erano alcuni servizi disponibili in quel momento
ma nulla era riutilizzabile perché lo era
molto legato all’interfaccia utente era un MVC dotnet
app in quel momento quindi questo è come noi
ha iniziato il nostro viaggio in app per dispositivi mobili così sì
quindi avevamo già BFF per iniziare
con così e quattro anni probabilmente un anno
più tardi presto qui volevamo tipo
creare un’esperienza utente per smartphone in modo tale da
raggiungere l’ esperienza utente dello smartphone noi
sfruttiamo l’attuale BFF
quindi ricorda quando ho descritto il BFF
architettura ci sono due variazioni di
uno è si potrebbe avere lo stesso BFF per
sia il tuo Android e iOS o il tuo
smartphone o il tuo iPad o potresti
avere un’esperienza utente separata eccetto
tasso di back-end per amico e per un diff
per il tuo Android che è separato da
il tuo iOS, quindi abbiamo scelto questa rotta perché
dei benefici che abbiamo ottenuto è un marchio
andando ad approfondire ciò che sta parlando
questo quindi ora sì, passerò a
Brian per andare all’attuazione
va bene grazie per Sean, quindi lo farò
Trascorro la prima parte del mio tempo qui
parlando di alcuni dei del
dettagli di attuazione di questo BFF e
arriva una specie di alcune delle cose che noi
cercato di affrontare nel nostro nel nostro servizio
quindi questo servizio non è solo un
pass-through per i dati non è solo il
app che chiama il servizio e poi ottiene
dati fuori dai fornitori di dati così
questa è una delle cose da considerare come
Sto parlando da qui c’è molto
di tipo di normalizzazione in corso in
questo servizio e una sorta di dati massaggianti
e andando a prendere sai fare le cose in a
modo particolare in modo da mostrare le mani per
le persone che hanno scritto leggono dominio guidato
design di Eric Evans, probabilmente
non mi basta per saltare solo questi
diapositive così vado avanti e li faccio così a
design guidato dal dominio Eric Evans
introduce un concetto di limite
contesto e leggerò la citazione in rosso
lì in alto un contesto limitato
delimita l’ applicabilità di a
particolare modello in modo che la squadra
i membri hanno un chiaro e condiviso
comprensione di ciò che deve essere
coerente e in che modo si relaziona con gli altri
contesti così il beneficio del legame
contesto in questo caso è questo
crea uno spazio per far funzionare la squadra
all’interno di così tutte le nostre app hanno un avere
alcuni concetti di modellazione di dominio simili
nominare e quel genere di cose e il
BFF aiuta a mantenere quelli
relazioni e ci sono certamente a
sai che ci sono casi in cui c’è un
uno-a-uno tra il
contesto vincolante che stiamo operando
all’interno e i dati che stiamo consumando
dai nostri fornitori di dati ma dove ci
sono disallineamenti il BFF aiuta a tipo di
massaggio che i dati e trasformare quel
dati in uno spazio dove siamo in grado di
usare il tipo di
non modellare il dominio coerente all’interno
sia il servizio che le app sono così
un contesto limitato ti dà il
flessibilità per produrre il modello che è
giusto per la tua applicazione, quindi abbiamo a
un paio di casi diversi in cui lo farò
chiamare un modello di dati ibrido in cui abbiamo
modelli di dati rappresentati nel
applicazione che in realtà unisce
dati da più sistemi così in questo in
questo screenshot qui dal nostro smartphone
applicazione abbiamo questa lista di contenuti
riassunti a sinistra e che esce
di un sistema e quelli l’URL o mi dispiace
gli URL per quelle miniature escono
di un sistema diverso , quindi il tipo di BFF
tira quelle informazioni insieme e
ritorna in uniforme uniforme
risposta per le applicazioni da utilizzare e
notizie notizie sono notizie confuse
quindi consumiamo i dati da un servizio e
servizio interno chiamato nuovo servizio e
come farebbe chiunque chiameremo la roba
uscendo dalle notizie di servizio notizie e come
stiamo lavorando con le notizie che abbiamo iniziato
facendo un po ‘di lavoro con un po’ di più profondo
categorizzazione e consentire
utenti per ordinare i filtri in modo diverso
categorie di notizie e abbiamo iniziato
lavorando con analisi notizie e video
notizie e commenti notizie e notizie notizie
che era un po ‘disordinato ma il fatto
che avevamo tutto questo nome e roba del genere
controllato all’interno di questo contesto limitato
siamo stati in grado di fare un corso
correzione, ammettiamolo, era il nostro problema
in primo luogo, ma tu sai se noi
lo sapevi che dipendeva dai dati
fornitore di sorta di correggere alcuni di quello
roba sarebbe stato molto più disordinato
di noi semplicemente cambiamo i nomi
e aggiustando le API e cose del genere
e il nome è difficile ed i loro nomi sono
sbagliando sai che tutti conosciamo quel nome
è duro e, anche quando lo diamo
meglio provare sapete abbiamo un po ‘di quel
roba di tanto in tanto e di tanto in tanto
accade con i nostri fornitori di dati, nonché
e quindi è bello avere questo spazio
quale tu
dì che sei come questi dannati nomi, no
ha senso per noi questi modelli no
ha senso per noi, quindi faremo un po ‘
rimodellare quella roba in nomi e modelli
che noi abbiamo più senso per noi e
e intendo onestamente come chi non lo fa
ama come un buon venerdì pomeriggio
una conversazione di due ore su di te
denominazione modelli e perché vorresti
lasciare quel tipo di divertimento al tavolo quando
potresti dire ok, quindi il prossimo tipo di
preoccupazione generale che gestiamo nel
BFF è qualcosa di relativo alle prestazioni , quindi
in termini di memorizzazione nella cache utilizziamo una versione distribuita
nella memoria cache per un numero di
cose diverse uno di quelli del
le cose principali sono molti dei nostri dati di sicurezza
è riusabile attraverso una richiesta quindi se tu
richiesta se vuoi dare un’occhiata a
stelle stellari di stelle per Apple e
Google e poi vengo e voglio
per visualizzare quegli stessi dati non è nessuno
diverso per noi due così così noi
tipicamente pigro carica questi dati in
la nostra cache così sai che la richiesta arriva
in noi controlliamo la cache se non è lì
andiamo a prendere i dati dai dati
il fornitore lo rispedisce nella cache e
poi quando questo e quelle successive richieste
vieni, possiamo riutilizzarlo dal
cache facciamo anche qualche tipo di batch
processi batch per attaccare cose dentro
la cache è la stessa schermata
che stiamo guardando prima del processo
per aver attraversato questo è per
assemblando questa lista è molto più di
tu vorresti fare nel lato client
in pratica chiamiamo una API a
ottenere un elenco di ID documento che vogliamo
per visualizzare qui e poi dobbiamo andare
al nostro fornitore di dati e assicuriamoci
abbiamo accesso a tutti loro perché
ci sono alcuni casi in cui c’è
o Windows in cui non lo sono
disponibile per noi o o non lo siamo
disponibili o non saranno mai più
disponibile per noi, quindi vogliamo essere sicuri
che non stiamo lanciando roba nel
app che un utente non sarà effettivamente
in grado di toccare e leggere e poi noi
cucire un paio di altre cose insieme
attaccare quella roba nella cache e poi
quando le app richiedono questo dato chiamato
l’API per questi dati è appena arrivata
destra, fuori dalla cache in modo che stiamo facendo
alcuni dei pesi più pesanti più pesanti
quello non sarebbe pragmatico da fare dentro
specialmente in più applicazioni
usiamo le intestazioni di cache HTTP di nuovo bel po ‘
tipo di cose riutilizzabili le stesse cose
che stavamo immagazzinando nel
cache in-memory sul lato server che inseriremmo
Intestazioni di cache HTTP su per voi sa per
riusabilità lì e poi cache privata
controlla le intestazioni quindi se voglio dare un’occhiata
il mio portafoglio di titoli che è
dati privati per me, ma l’app può
memorizzarlo nella sua cache locale e se lo sono
sai muoversi nell’app e io
torna a quella vista e alla vista
vuole aggiornarlo è memorizzato nel
localmente la cache HTTP locale e così via
non ha bisogno di recuperare tutti quei dati
di nuovo così farò una breve deviazione
dalla discussione della performance a
Parliamo di riposo , prendiamoci un minuto
potresti rivolgerti a qualcuno che è vicino a te
tu o tu potresti rompere in più piccolo
gruppi e basta discutere vedi se puoi
venire con la definizione di ciò che a
il servizio di riposo sembra appena me lo darò
ti piace parlare tra 45 secondi
voi stessi
forse circa altri dieci secondi
va bene sono felice di vedere il no
scazzottate scoppiarono su quello oltre
discussione qualcuno forse qualcuno
voglio condividere la definizione che sono venuti
con tutto bene, sì, va bene tutto
giusto sì uso di verbi HTTP HTTP e
nomi di folla e quel genere di cose
va bene quindi questo è un po ‘un trucco
domanda perché c’è il the
discussione su cosa sia il riposo e come
lo si fa e se si sta facendo
è vero che è così contorto a volte
guardare due minuti sarebbero mai abbastanza I
significa che potremmo probabilmente passare mezza giornata
ne parliamo dalle discussioni
che sei tu che ho fatto parte di
almeno così se hai un’opinione forte
A riposo, questo è un avvertimento che sto per fare
parla di riposo un po ‘che non puoi
sono d’accordo con le parole che uso o il
modo descrivo il riposo che probabilmente
non mi rende una cattiva persona
e tu sai anche se non siamo d’accordo
Sono altrimenti abbastanza facile andare d’accordo
con e sai che penso di sapere
non lasciamo che questo tipo di a
il disaccordo ci impedisce di diventare
amici per tutta la vita va bene così come eravamo
costruito mentre stavamo costruendo il nostro migliore amico
servizio abbiamo cercato di adottare un numero di
diverso tipo di architettura riposante
principi e questo questo Richardson
il modello di maturità era una specie di nostra guida
luce guida rispetto al nostro
implementazione Martin Fowler ha un
post sul blog davvero buono su come discuterne
modello e tipo di picking a parte il
diverse fasi e parlando di alcuni
di alcuni dei pro e contro ma il
l’ idea di base è che tu sai adottare
queste diverse fasi e ottieni
Non sono la gloria del riposo, quindi non lo siamo
non siamo lì sì , non so cosa
succede quando arrivi lì forse tu
sapere cessare di esistere da questo piano di
esistenza o non so che ti lascerò
sapere quando arriviamo
quindi solo un paio di commenti su
in che modo sfruttiamo queste idee
il nostro nel nostro BFF così di livello uno nel
Il modello di maturità di Richardson è l’uso di
risorse quindi se vuoi indirizzare un
risorsa c’è una sorta di contestuale
percorso per arrivarci compreso te lo sai
nomi di gruppi di risorse più il
ID delle risorse quindi se vuoi un
informazioni su una sicurezza puoi vedere
il puntatore va bene o virgolette o articoli
per sicurezza puoi usare un percorso simile
questo con l’ID di sicurezza e allo stesso modo
se sei un cliente e vuoi l’accesso
alle tue partecipazioni per un particolare
portfolio useresti un URI come questo
questi due verbi HTTP di livello due , quindi questi sono
tipo di quelli che facciamo di più
uso di qualsiasi uso qualsiasi opzione utenti nel
Opzioni di casa va bene va bene, sì tutti
giusto sì, non posso dimenticare le opzioni
perché nessuno sa che esiste e
quindi è una specie di grande livello
tre è l’uso di controlli hyper media
i controlli hyper media sono generalmente link
incorporato nel raccontare risposta del server
il cliente forse quali azioni possono fare
eseguire su una data una determinata risorsa così
se prendo una risorsa ci sarebbe
link in là dicendo che lo so sono io
permesso di cancellarlo sono autorizzato a
apportare modifiche ad esso quel tipo di cosa
e anche i collegamenti per i dati associati, quindi se
Sto tirando giù un pezzo di
informazioni e ci sono forse tre o
quattro altri pezzi di dati associati
ci sarebbero dei link a quelli che mi dicono
sai come sono in grado di accedere
quelle risorse particolari quindi il nome
per questo è hyper media come motore
il motore di stato dell’applicazione o hatty
Oz o Hetty O o comunque tu voglia
pronuncia che non prenderò un
litigare sulla pronuncia che usiamo
questo molto molto poco quindi non abbiamo
asceso alla gloria del riposo e lo farò
torna indietro e parla per parlare un po ‘
circa il tipo di dove questo si inserisce in un’ora
Viaggio BFF e poi ne usiamo alcuni
prova a usare generalmente le intestazioni HTTP e
codici di risposta e usiamo a
un po ‘ di intestazioni personalizzate qui e
lì e usiamo alcuni generali come
endpoint e parlerò di questo in
le diapositive in arrivo
quindi ora ti facciamo tornare regolarmente
programma previsto quindi uno dei
preoccupazioni di prestazione che proviamo quello
abbiamo lavorato per risolvere la nostra API
la nostra API BFF è ridurre il file
chattiness dell’applicazione client così
fondamentalmente dove c’è un’opportunità
per noi per tipo di nave fuori un intero gruppo
di dati che ha senso in un particolare
vedremo che lo faremo così li chiamerei
genere come API specifica vista quindi se se
si guarda in un Rhett severo in un altro
approccio restful rigoroso si potrebbe se
stai cercando informazioni sul tuo
possedimenti si potrebbe ottenere una matrice di
tenere oggetti con collegamenti associati
per ulteriori dati di sicurezza aggiuntivi
cita i dati quindi è il cliente
lavoro di applicazioni client per dire che lo sai
se hai 50 titoli in questo o in
50 partecipazioni qui per fare i prossimi 100
richiede di recuperare quei dati ma perché
sappiamo come appaiono le visualizzazioni
queste applicazioni che dobbiamo avere
tendeva a costruire in alcuni casi questi di più
il tipo di vista specifica per le API è così
di includere tutti quei collegamenti che vorremmo
incorporare i dati di sicurezza e la citazione
dati e qualunque sia l’altro tipo di
Dati associati proprio nella risposta così
il cliente non deve essere fare tutto
quei viaggi di andata e ritorno aggiuntivi per il
informazioni che sappiamo di aver bisogno
per quello per quei punti di vista comunque loro
alcune delle nostre API più generalizzate ci siamo noi
non erano società finanziaria facciamo un sacco di
roba con dati di mercato e e
titoli azionari quel tipo di cose
abbiamo aggiornato o abbiamo scritto il nostro
sicurezza correlata e API è a
Supporta più ID di sicurezza, quindi è così
abbastanza comune per una vista per voi sapere
mostra informazioni su più
titoli in un momento, se si desidera
confronta sai due o tre diversi
titoli e loro prestazioni e come
Morningstar ha valutato loro che tipo di
cosa potrebbe l’applicazione client potrebbe
semplicemente fare una richiesta per se voglio il
cita un elenco separato da virgola di Apple
e Google e Facebook e poi il
ultimo tipo di cosa correlata alla performance
di nuovo perché stiamo cercando di usare il
Servizio BFF per fare il più pesante
sollevando per le applicazioni il più possibile
facciamo un sacco di provare a fare uso di
parallelismo e operazioni asincrone
dovunque possiamo, così usiamo il
diplay framework any framework di gioco
gli utenti della casa sono bravi
quindi giocare ha un’API davvero molto bella per
facendo un sincrono asincrono
operazioni e questa è una specie di pseudo
codice II esempio di uno che facciamo
oggi abbiamo fondamentalmente una API dove
vuoi inviare il cliente vuole
invia una richiesta per un numero diverso
titoli e tornare indietro di un pezzo di
Analisi Morningstar
Morningstar commenta le notizie di terze parti
e il video di Morningstar è il problema
che i nostri fornitori di dati e supporto
interrogando in questo modo noi così così che cosa finiamo
il dover fare è per ogni sicurezza noi
licenziare quattro di queste richieste
in modo asincrono e poi il
framework API ci aiuta a farti sapere
tipo di farci sapere quando tutti quei dati
è disponibile e e quindi agire su di esso
quando è pronto , quindi raccogliamo
tutta la roba in questi promessi
oggetti e ci consente di dire che lo sai
se sto chiedendo questa informazione per
conosci una dozzina di titoli diversi noi
può licenziare queste richieste in lotti
di quattro per voi sapete per ciascuno di questi
titoli in modo che tu sappia fare molto
quel sollevamento pesante che sarebbe equo
oneroso da gestire dal lato del cliente
soprattutto attraverso soprattutto attraverso
più applicazioni è stato un grande
beneficio per noi così l’ultimo
argomento di implementazione che ho intenzione di parlare
a proposito di gestione degli errori e sto andando
usare un termine piuttosto interessante, penso sia bello
da Eric Evans questo è l’ anti
strato di corruzione quindi leggerà il
citazione qui, ma quando l’altro lato di
il confine inizia a filtrare attraverso il
traduzione il livello può assumere un altro
tono difensivo così design di dominio
riguarda il dominio della modellazione aziendale
consistenza di denominazione di modellazione che tipo di
roba ma quando lavori particolarmente
quando lavori con molte cose diverse
fornitori di dati che conosci molto
diversi stili di risposte e quello
tipo di cosa hai davvero bisogno di pensare
tipo di a livello centrale sul tuo errore
gestire la strategia e come stai andando
per essere che conosci te e probabilmente vuoi
per costruire quel tipo di cose nella tua
modellando così Sun Microsystems ci ha detto il
la rete è il computer e lo sto dicendo
tu che la rete è un sacchetto di rabbia
i gatti sono quelli che penso tu sappia
lavorare in una disabilità in un ambiente distribuito
ambiente vedi tutti questi strani
cose che conosci problemi di rete quando
stai parlando con un fornitore di dati
e tu sai chi sa cosa sono
fare dietro le quinte per ottenere i dati
che stai chiedendo così tanto spazio
per fallimento quindi abbiamo finito col costruire questo
tipo di integrazione del servizio web personalizzato
livello che si potrebbe tipo di pensare ad esso come
come un dao per le chiamate al servizio web se
sei in OS da dove siamo fondamentalmente
mi scusi maneggiare un sacco di piastre
la gestione degli errori va in timeout cose del genere
in modo che dov’eri catturato
questi potenziali problemi che noi che noi
avresti capito con chi interagire
diversi fornitori di servizi di dati così e
ovviamente perché i diversi dati
i fornitori di servizi hanno stili diversi
di errore gestendo noi stessi siamo gentili
di aver normalizzato quella roba così tu ci conosci
avere un bel po ‘di quelli che fanno
risposte standard del codice HTTP che possiamo
guarda molto facilmente tutti amano questo
un tutto quello che ti dice l’intestazione HTTP
che tutto va bene, ma poi guardi
al corpo di risposta e come
si scopre che tutto non va bene e poi
altri casi angusti strani dove tu
ha chiamato un’API JSON e vieni reindirizzato
a una pagina HTML succede
non molto spesso fortunatamente e poi così
per quanto riguarda la nostra API è la risposta a
le nostre applicazioni client abbiamo tipo
standardizzato su pochi diversi sai
pochi tipi di risposta di risposta HTTP parziali
il contenuto è interessante se possiamo soddisfare ogni vostra
sai diciamo l’applicazione client
chiede da una cosa e sotto le coperte
stavano forse chiamando due dati diversi
fornitori e cucendo quelle informazioni
insieme ma sai se parte di quello
l’informazione non ritorna per qualsiasi cosa
motivo per cui useremmo due di sesso a
dì che hai chiesto questo non l’ho capito
tutto ciò ma ti sto dando quello che ero
in grado di ottenere e l’altro gli altri due
che sono interessanti per evidenziare il nostro
503 fondamentalmente se facciamo una chiamata a
fornitore di dati di dati e qualcosa va
sono sbagliati, hanno sbagliato
ci ha dato HTML quando vogliamo JSON
tipo di cose quindi restituiamo un 503 a
le nostre applicazioni client e poi questo è
solo una specie di costruito nel contratto di
come facciamo a sapere come il cliente
le applicazioni stanno consumando questo è
una sorta di segnale è come se qualcosa fosse andato
sbagliato non è colpa nostra riprovare più tardi gentile
di una cosa e vale la pena di disegnare
attenzione al fatto che non lo faremo mai
produrre 500 errori o 500 risultati
intenzionalmente quelli sono riservati per il nostro
errori di programmazione e puntatore nullo
eccezioni e cose del genere quindi se
la nostra API non restituisce i 500 che conosciamo
abbiamo avuto qualche problema serio per
indirizzo perché noi siamo fondamentalmente
cadere così ho intenzione di parlare a
un po ‘di lezioni apprese queste
sai che la benedizione di Blessin
costruire questo BFF dal supporto
più applicazioni client dalla
anni così sai che ti costruisci un sistema
costruisci un servizio e ogni volta in a
mentre trovi che conosci soprattutto come
stiamo tutti parlando
su micro servizi come Oh micro
i servizi sono fantastici
sono un monolite dovrei essere un monolite
come sono preoccupato per questo tipo di
cose
cosa posso separarmi ed essere di più
micro servizio II quindi abbiamo sicuramente eseguito
in alcune situazioni dove siamo noi
comprendiamo che abbiamo costruito alcune cose nel nostro
servizio che in realtà non ci appartiene
come al massimo penso sia il più ovvio
esempio è che quando qualcuno compra un
abbonamento ai dati Morningstar tramite
la nostra app per iPad che va alla Apple
Store inviano le loro informazioni a uno
dei nostri sistemi internamente e poi quello
il sistema in realtà parla attraverso di noi
il nostro BFF torna ad Apple non appartiene
eccolo lì , non è davvero adatto
quel servizio è ancora lì oggi
noi probabilmente si sa rompere questo fuori
come servizio separato in futuro ma
è una di quelle cose che conosci
quando guardiamo a quel servizio , tipo
grattarci la testa e andare, sì, perché no
lo facciamo
e sai che ne abbiamo costruiti molti
diverse applicazioni su questo BFF
tre di loro sono molto simili
esperienze e così mi piace non io
pensa l’idea generale del BFF
il modello vale per quelli diversi
esperienze ma quando ne abbiamo costruiti altri
applicazioni o quando stiamo pensando
sulla costruzione di altre applicazioni è a
domanda di come dovremmo fare questo
dovremmo farcela con qualcosa
altrimenti dovremmo sapere infrangere questo
un servizio separato e avere quelli
i servizi si chiamano ma tu
so che sono solo conversazioni
abbiamo avuto nel tempo quando stiamo costruendo
nuove cose e poi c’è il
domanda inevitabile come Krishna e
menzionato su questa domanda di riutilizzo
da altre squadre siamo stati avvicinati da
un paio di squadre diverse sul
anni su di te sai hey che vogliamo usare
il tuo servizio perché hai questo bello
integrazione con questi dati sicuri
provider per i dati di sicurezza è
coerente hai fatto il lavoro già possibile
lo usiamo solo e noi tipo
ha deciso di tracciare una linea nella sabbia e
dì che sai che non vogliamo sostenere
che noi non vogliamo che vogliamo essere in grado
per apportare modifiche a ciò che è giusto
per la nostra applicazione e non essere tu lo sai
gravato dal sostenere un gruppo di altri
prodotti ma le applicazioni nella fonte
che controlli
libero di sborsarlo e sai prendere un take
un problema a costruire qualcosa con esso se
vuoi un BFF è stato davvero un
ottimo posto per tamponare il cambiamento così perché
abbiamo un numero diverso
applicazioni applicazioni mobili voi
sapere se abbiamo bisogno se vogliamo o abbiamo bisogno
per tagliare verso un nuovo fornitore di servizi se
stiamo aggiungendo dati o sottraendo dati o
spostare i dati in giro e la nostra modellazione e
quel genere di cose il the the BFF
il servizio è una specie di sportello unico per
sai gestire piuttosto quel cambiamento
di dover sapere apportare modifiche in
quattro diverse app e cerca di ottenerle
fuori per app store e, in in modo tempestivo
moda e perché controlliamo il
programma di rilascio su quel BFF possiamo gentile
di noi possiamo tipo di fare quelli introdurre
quei cambiamenti ogni volta che vogliamo fare
così se c’è un sai se
qualcuno sta deprecando un’API la prossima settimana
possiamo o sai che possiamo costruire build
tipo di funzionalità di un ponte oggi e
distribuire quello e poi quando quando le cose
sapere quando le cose lo rendono formale
la transizione la gestiamo semplicemente sul retro
fine e aiuto agli sviluppatori lato client
muoviti più velocemente bene è una specie di un
interessante
quindi quando stiamo costruendo una nuova API è di
corso vecchio in molti casi, se lo siamo
integrazione con un nuovo fornitore di dati o
qualcosa del genere o il lavoro ha
da fare nel servizio BFF o il
il lavoro può essere fatto nei dati
servizio di provider pure
quindi sai che c’è tempo di ritardo fino a quando
tutto quel lavoro viene fatto prima del
Gli sviluppatori di client possono costruire sai
le loro caratteristiche e quel tipo di cose così
quello che abbiamo finito per fare
numerosi casi è solo l’aggiunta di dati stub
al nostro servizio BFF in modo da sapere concordare
su un contratto API tra il server
e gli sviluppatori lato client di cosa si tratta
i dati devono apparire come sai
stub alcuni dati che il lato client
gli sviluppatori possono iniziare a lavorare con
immediatamente e poi nel migliore dei casi
scenari che è certamente non tutti
gli scenari in cui il lavoro su
integrazione al fuorigioco con i dati
il fornitore ha fatto solo i dati reali
inizia a fluire e tu sai
qualcuno raccoglie l’app in QA un giorno
e vede i dati reali invece dello stub
uno dei dati di cui ho parlato di questo
bilanciamento di api e scopi generali
visualizzare API specifiche mi sento come se avessimo
fatto un buon lavoro ragionevolmente
pensa quando quando iniziamo a costruire a
nuova API, in generale, stiamo pensando
su di esso come vogliamo che questo sia come
generale come possiamo perché siamo
sostenendo un numero di diverso
le applicazioni è un po ‘come anche bene
se è anche se questa applicazione ha bisogno
usare così in questo modo oggi sarebbe
buono per costruire questo in un relativamente
modo generale per sapere se questo
altra applicazione vuole usarlo domani
può semplicemente chiamare questi stessi endpoint e
e ottenere gli stessi dati e sì io
menzionato l’ API specifica della vista così
proviamo a provare a fare un po ‘
un po ‘meno di quello e si yeah abbiamo a
numero di esperienze diverse usando
queste api sono così ho detto che sarei tornato
ad Haiti ohi fanno cerniera come Cheerios
grazie grazie per aver spiegato la barzelletta
rende sempre la battuta migliore così come me
ha detto che non abbiamo raggiunto la gloria
di riposo che non stiamo usando non stiamo usando
ipermedia molto estensivamente dove
l’abbiamo usato penso che siamo davvero
lieto che lo abbiamo fatto e lo vediamo sicuramente
che penso che ne abbiamo fatti alcuni
errori dove se l’avessimo usato di più
non ci sarebbe molto
logica applicativa lato client dove tu
so oh ho preso questi dati che so come
scegli uno di questi punti dati e costruisci
un URL fuori di esso e ottenere un po ‘di più
dati in modo che le applicazioni client siano tutte
in qualche modo hanno tutti questa logica
cosparso ovunque così se usiamo
questo approccio un po ‘più di me
pensa di sapere che avremmo un po ‘
un po ‘meno di quella roba e se noi
vuoi spostare la data se vogliamo spostarci o
migrare i dati all’interno di queste API allora
allora quelli sarebbero solo lato server
cambia perché il cliente non lo farebbe
davvero sapere o cura di dove specifico
i dati verrebbero da ciò che deve sapere
chiamare un’API e quindi tornare indietro
potrebbe quasi chiudere quel riposante
conversazione che alcune persone direbbero
se non stai usando le radio non lo sei
riposante e va bene non ce l’ho
non conosci super-impegnato a
anche se non siamo riposanti, penso
tale approccio e richiedendo che
l’approccio forse ha un po ‘più senso
per generalizzato sai di più
Api di scopo generale ma in questo BFF
servizio prendendo più sorta di pragmatico
avvicinati saprai che non mi fa male se
se sai che ci riuniamo in seguito
e dì che sai che questo servizio non lo è
è riposante , ha funzionato bene per noi e
e sai che è vero, siamo su misura
specificamente al nostro cliente
le applicazioni che ritengo pesanti
uso di questo o per insistere sul fatto che lo usiamo
in tutti i nostri occhi API, quindi voglio aprire
il piano fino ad un certo QA giusto così
la domanda è che noi siamo dove abbiamo disegnato
la linea di riutilizzo era ma solo con
il BFF o l’API Gateway così così
sì, il BFF è davvero il nostro
gateway API quindi il nostro nostro cellulare
le applicazioni stanno chiamando il servizio BFF
e tu sai che sai
API gateway pure così questo è il
gateway di applicazioni a tutti questi dati
che è diverso dal gateway API
abbiamo parlato in Amazon oh sì quale
è o abbiamo il nostro gateway API
chiamato apogee che usiamo all’interno dei nostri dati
centro quindi è una specie di a
cross-cutting è un gateway per tutti
i nostri servizi di back-end
ma questo BFF è diverso da quello
collega direttamente è strettamente legato
all’esperienza utente che è il
app per client, quindi la domanda è
ci troviamo fondamentalmente in duplicazione
duplicare cose nel BFF che
fondamentalmente c’è una sorta di a
relazione uno-a-uno tra
l’API di BFF e l’API del fornitore di dati
è che non penso ci sia stato troppo
molti di quelli là ci sono stati
ce ne sono stati alcuni e questo è e
è un po ‘anche nei casi in cui
dove l’abbiamo fatto io ce n’è abbastanza
di questo tipo di errore consistente
gestendo una risposta coerente sai
standardizzazione in cui penso che otteniamo
abbiamo lo sviluppo di applicazioni client
è stato un beneficio da quel tipo di
cose grazie ragazzi
[Applausi]
quindi in questo discorso parleremo
sul perché back end per l’amico ed è la chiave
questo è il tuo viaggio in microservizi
in particolare un caso d’uso di Morningstar
è una prospettiva di un team mobile su
come sfruttano questo architettonico
modello così prima della logistica per favore
fai e raid questa sessione nell’app
apprezziamo molto , quindi voglio
presenta questo Brian hey quindi sono il
la seconda metà del mio intervento è Brian
concessione ho iniziato a programmare
professionalmente nel 2005 e iscritto
Morningstar a fine 2012 ho un po ‘ di
contributi significativi al design
e l’attuazione del BFF che
parleremo oggi e
Sono attualmente un manager tecnologico
morningstar di
squadra mobile investitore individuale e io sono
Christian Ramanathan e direttore di
ingegneria alla Morningstar in cui sono stato
l’industria del software per oltre 18 anni
codifica leader nella gestione e nell’architettura
sistemi software mi appassiona
micro servizi DevOps AI e macchina
imparando così iniziamo chi siamo
Morningstar al centro è un investimento
società di ricerca e la nostra missione è quella di
creare ottimi prodotti per questo aiuto
gli investitori cercano obiettivi finanziari così
ora ho parlato degli investitori che abbiamo
segmenti di clienti che vanno dall’individuo
gli investitori come te e me i tuoi prodotti
per loro a clienti come finanziari
consulenti di prodotti nello spazio di pensionamento
e anche la gestione patrimoniale ci siamo diffusi
attraverso 27 paesi e siamo all’incirca
42 cento più impiegati e noi siamo
con sede a Chicago
quindi siamo locali come serviamo i nostri clienti
quindi la chiave per qualsiasi investimento è avere
accesso a dati di qualità e creazione di un
decisione informata usando così il bambino
i client di cella forniscono dati al
fondamento per noi e poi risalendo il
piramide forniamo l’aggiunta di valore in cima
quindi forniamo prodotti software e
visualizzazione Honda lytx e anche l’accesso
all’analista di tutti gli investimenti in a
livello più alto del valore proposizione noi
fornisci anche consigli così da essere gestiti
investimenti gestiamo il portafoglio entrambi
anche dal punto di vista degli investimenti
dai conti di pensionamento
andiamo al discorso per amici
fine così ho preso questa descrizione dallo scatto
Il post sul blog di Newman è l’autore di
costruendo micro servizi ha fatto un grande
Parliamo ieri del nostro interruttore su funzionalità e
e la funzione di ramificazione era carina
interessante quindi sai che è anche il
host di micro servizi traccia oggi così lui
è venuto con questa descrizione e lui
accredita anche questo modello architettonico
a Philly Kyle Cairo così l’idea alle spalle
questo modello è invece di avere un
l’API di back-end del core centrale usa il
ti concentri maggiormente sulla costruzione di un back-end
per una particolare esperienza utente così dentro
questo caso lo schema a sinistra noi
avere due back-end per front-end in modo che il
il client desktop che hai creato ha un
back-end per questo e allo stesso modo per il tuo
app mobile hai un back-end per questo
esperienza utente il diagramma sulla destra
è una leggera variazione di ciò che vorresti
vedi che non puoi avere un back-end
per il tuo Android
diverso da un’esperienza del vuoto o a
esperienza utente per un Android così
fondamentalmente hai due back-end separati
per amico è per il tuo Android e uno
per il tuo iOS il driver chiave per usarli
pad e in genere si vedrebbe il
spazio mobile hai te te
generalmente tendono ad avere meno dati
l’ esperienza dell’utente è leggermente diversa
e anche tu hai una vista specifica
back-end hai bisogno di una vista specifica
back-end per soddisfare il tuo utente
esperienza così ho intenzione di camminare attraverso
il nostro viaggio come abbiamo iniziato probabilmente dieci
anni fa avevamo questo prodotto desktop
che abbiamo costruito, direi che è un
chiave prodotto b2b non posso rivelare il
nome in questo momento, ma era principalmente a
BFF abbiamo iniziato con il BFF a questo
tempo puoi anche chiamarlo monolite il
tutta l’ idea dietro quello eravamo noi
fondamentalmente potremmo avere un livello API
caddis per tutta l’esperienza dell’utente a
l’app desktop e l’ annuncio sono tornati su ciò che noi
è stato necessario sviluppare
lancio di altri tre prodotti, quindi cosa noi
è stato allungato l’ API del prodotto e
ha permesso l’ avvio di altri tre prodotti
rapidamente ed e questo era il tipo di
modello di progettazione che abbiamo scelto in quel momento così
che tipo di riutilizzata API intendevamo
mercato più veloce ma indovina cosa succede
subito dopo il team che ha prodotto il prodotto
beep C e D si sono dispersi e poi tu
finisci nella situazione in cui nessuno
passare al codice prodotto di cui P ha ora bisogno
tipo di un tipo di esso diventa molto
difficile fare quei cambiamenti perché
ora il tuo impatto
altri tre prodotti in modo che fosse un po ‘
il caso probabilmente otto anni fa noi
anche se siamo riusciti a riutilizzare ma
subito dopo la manutenzione è diventata a
problema perché ogni piccolo cambiamento ha un impatto
in tutti e tre i quattro prodotti ora probabilmente
a circa quattro anni fa ciò che noi
abbiamo fatto i nostri atti insieme e noi
applicato questo concetto di BFF e la costruzione
tutti i prodotti quindi abbiamo ampliato in due
dimensioni uno è stato aggiunto più servizi
e mi piace se vedi qui da quando ci occupiamo
con i titoli quindi creiamo specifiche API
ai titoli che abbiamo AP è specifico
un dato in tempo reale e abbiamo API
specifico per i portafogli tipo di a
capacità guidata o in movimento verso a
più architettura di microservizi e a
allo stesso tempo chiediamo anche ai team di prodotto
avere il proprio back-end così di questo tipo
di una graduale evoluzione ci ha permesso di
tipo di passaggio verso più moderno
architettura così approssimativamente cosa succede
tipicamente in una specie di team è quello che hai
la maggior parte delle squadre che costruiscono questi
servizi dopo due o tre anni
rendersi conto che hey il mio back-end è obsoleto
la tecnologia è obsoleta che voglio
costruisci una nuova versione di quello che era
questo è quello che è successo anche a noi
molti team i team di servizi di back-end
hanno iniziato a costruire una nuova versione di
la loro api è e noi abbiamo espanso
le nostre sfide ne hanno altre
versione così ora ha tutti i team di prodotto
per ora gestire tutte le API e la nuova API
quindi cosa facciamo in modo che il back-end
all’avanguardia e architettura ci hanno aiutato
questo e vedrai di più quando
Brian entra nel dettaglio di come noi
implementato quindi parlerò di
il nostro viaggio in mobilità, quindi abbiamo otto
app su App Store sul lato iOS e
una app su Android, quindi siamo di più
tipo di iOS focalizzato ora per via di
la maggior parte basata sulla ricerca dell’utente che abbiamo
più utenti iOS che Android quindi nel
viaggio mobile probabilmente cinque anni fa
noi l’app chiave tutte le otto app
App di vendita al dettaglio di iPad uno dei era uno di
l’app chiave per noi nel segmento retail
quindi avevamo già un sito web di dub
dub dub morningstar.com che era una rete
a quel tempo era un monolite era
facendo molte cose e stava servendo il nostro
utenti desktop tramite browser, quindi cosa abbiamo fatto
era al via abbiamo iniziato
costruendo la nostra app mobile con questo
Era il servizio mobile come strato BFF
abbastanza naturale per noi in quel momento noi
non sapevo di questo schema in questo
tempo ma noi ci siamo semplicemente cascati
quella volta perché non potevamo riutilizzare
qualsiasi applicazione web legacy lì
c’erano alcuni servizi disponibili in quel momento
ma nulla era riutilizzabile perché lo era
molto legato all’interfaccia utente era un MVC dotnet
app in quel momento quindi questo è come noi
ha iniziato il nostro viaggio in app per dispositivi mobili così sì
quindi avevamo già BFF per iniziare
con così e quattro anni probabilmente un anno
più tardi presto qui volevamo tipo
creare un’esperienza utente per smartphone in modo tale da
raggiungere l’ esperienza utente dello smartphone noi
sfruttiamo l’attuale BFF
quindi ricorda quando ho descritto il BFF
architettura ci sono due variazioni di
uno è si potrebbe avere lo stesso BFF per
sia il tuo Android e iOS o il tuo
smartphone o il tuo iPad o potresti
avere un’esperienza utente separata eccetto
tasso di back-end per amico e per un diff
per il tuo Android che è separato da
il tuo iOS, quindi abbiamo scelto questa rotta perché
dei benefici che abbiamo ottenuto è un marchio
andando ad approfondire ciò che sta parlando
questo quindi ora sì, passerò a
Brian per andare all’attuazione
va bene grazie per Sean, quindi lo farò
Trascorro la prima parte del mio tempo qui
parlando di alcuni dei del
dettagli di attuazione di questo BFF e
arriva una specie di alcune delle cose che noi
cercato di affrontare nel nostro nel nostro servizio
quindi questo servizio non è solo un
pass-through per i dati non è solo il
app che chiama il servizio e poi ottiene
dati fuori dai fornitori di dati così
questa è una delle cose da considerare come
Sto parlando da qui c’è molto
di tipo di normalizzazione in corso in
questo servizio e una sorta di dati massaggianti
e andando a prendere sai fare le cose in a
modo particolare in modo da mostrare le mani per
le persone che hanno scritto leggono dominio guidato
design di Eric Evans, probabilmente
non mi basta per saltare solo questi
diapositive così vado avanti e li faccio così a
design guidato dal dominio Eric Evans
introduce un concetto di limite
contesto e leggerò la citazione in rosso
lì in alto un contesto limitato
delimita l’ applicabilità di a
particolare modello in modo che la squadra
i membri hanno un chiaro e condiviso
comprensione di ciò che deve essere
coerente e in che modo si relaziona con gli altri
contesti così il beneficio del legame
contesto in questo caso è questo
crea uno spazio per far funzionare la squadra
all’interno di così tutte le nostre app hanno un avere
alcuni concetti di modellazione di dominio simili
nominare e quel genere di cose e il
BFF aiuta a mantenere quelli
relazioni e ci sono certamente a
sai che ci sono casi in cui c’è un
uno-a-uno tra il
contesto vincolante che stiamo operando
all’interno e i dati che stiamo consumando
dai nostri fornitori di dati ma dove ci
sono disallineamenti il BFF aiuta a tipo di
massaggio che i dati e trasformare quel
dati in uno spazio dove siamo in grado di
usare il tipo di
non modellare il dominio coerente all’interno
sia il servizio che le app sono così
un contesto limitato ti dà il
flessibilità per produrre il modello che è
giusto per la tua applicazione, quindi abbiamo a
un paio di casi diversi in cui lo farò
chiamare un modello di dati ibrido in cui abbiamo
modelli di dati rappresentati nel
applicazione che in realtà unisce
dati da più sistemi così in questo in
questo screenshot qui dal nostro smartphone
applicazione abbiamo questa lista di contenuti
riassunti a sinistra e che esce
di un sistema e quelli l’URL o mi dispiace
gli URL per quelle miniature escono
di un sistema diverso , quindi il tipo di BFF
tira quelle informazioni insieme e
ritorna in uniforme uniforme
risposta per le applicazioni da utilizzare e
notizie notizie sono notizie confuse
quindi consumiamo i dati da un servizio e
servizio interno chiamato nuovo servizio e
come farebbe chiunque chiameremo la roba
uscendo dalle notizie di servizio notizie e come
stiamo lavorando con le notizie che abbiamo iniziato
facendo un po ‘di lavoro con un po’ di più profondo
categorizzazione e consentire
utenti per ordinare i filtri in modo diverso
categorie di notizie e abbiamo iniziato
lavorando con analisi notizie e video
notizie e commenti notizie e notizie notizie
che era un po ‘disordinato ma il fatto
che avevamo tutto questo nome e roba del genere
controllato all’interno di questo contesto limitato
siamo stati in grado di fare un corso
correzione, ammettiamolo, era il nostro problema
in primo luogo, ma tu sai se noi
lo sapevi che dipendeva dai dati
fornitore di sorta di correggere alcuni di quello
roba sarebbe stato molto più disordinato
di noi semplicemente cambiamo i nomi
e aggiustando le API e cose del genere
e il nome è difficile ed i loro nomi sono
sbagliando sai che tutti conosciamo quel nome
è duro e, anche quando lo diamo
meglio provare sapete abbiamo un po ‘di quel
roba di tanto in tanto e di tanto in tanto
accade con i nostri fornitori di dati, nonché
e quindi è bello avere questo spazio
quale tu
dì che sei come questi dannati nomi, no
ha senso per noi questi modelli no
ha senso per noi, quindi faremo un po ‘
rimodellare quella roba in nomi e modelli
che noi abbiamo più senso per noi e
e intendo onestamente come chi non lo fa
ama come un buon venerdì pomeriggio
una conversazione di due ore su di te
denominazione modelli e perché vorresti
lasciare quel tipo di divertimento al tavolo quando
potresti dire ok, quindi il prossimo tipo di
preoccupazione generale che gestiamo nel
BFF è qualcosa di relativo alle prestazioni , quindi
in termini di memorizzazione nella cache utilizziamo una versione distribuita
nella memoria cache per un numero di
cose diverse uno di quelli del
le cose principali sono molti dei nostri dati di sicurezza
è riusabile attraverso una richiesta quindi se tu
richiesta se vuoi dare un’occhiata a
stelle stellari di stelle per Apple e
Google e poi vengo e voglio
per visualizzare quegli stessi dati non è nessuno
diverso per noi due così così noi
tipicamente pigro carica questi dati in
la nostra cache così sai che la richiesta arriva
in noi controlliamo la cache se non è lì
andiamo a prendere i dati dai dati
il fornitore lo rispedisce nella cache e
poi quando questo e quelle successive richieste
vieni, possiamo riutilizzarlo dal
cache facciamo anche qualche tipo di batch
processi batch per attaccare cose dentro
la cache è la stessa schermata
che stiamo guardando prima del processo
per aver attraversato questo è per
assemblando questa lista è molto più di
tu vorresti fare nel lato client
in pratica chiamiamo una API a
ottenere un elenco di ID documento che vogliamo
per visualizzare qui e poi dobbiamo andare
al nostro fornitore di dati e assicuriamoci
abbiamo accesso a tutti loro perché
ci sono alcuni casi in cui c’è
o Windows in cui non lo sono
disponibile per noi o o non lo siamo
disponibili o non saranno mai più
disponibile per noi, quindi vogliamo essere sicuri
che non stiamo lanciando roba nel
app che un utente non sarà effettivamente
in grado di toccare e leggere e poi noi
cucire un paio di altre cose insieme
attaccare quella roba nella cache e poi
quando le app richiedono questo dato chiamato
l’API per questi dati è appena arrivata
destra, fuori dalla cache in modo che stiamo facendo
alcuni dei pesi più pesanti più pesanti
quello non sarebbe pragmatico da fare dentro
specialmente in più applicazioni
usiamo le intestazioni di cache HTTP di nuovo bel po ‘
tipo di cose riutilizzabili le stesse cose
che stavamo immagazzinando nel
cache in-memory sul lato server che inseriremmo
Intestazioni di cache HTTP su per voi sa per
riusabilità lì e poi cache privata
controlla le intestazioni quindi se voglio dare un’occhiata
il mio portafoglio di titoli che è
dati privati per me, ma l’app può
memorizzarlo nella sua cache locale e se lo sono
sai muoversi nell’app e io
torna a quella vista e alla vista
vuole aggiornarlo è memorizzato nel
localmente la cache HTTP locale e così via
non ha bisogno di recuperare tutti quei dati
di nuovo così farò una breve deviazione
dalla discussione della performance a
Parliamo di riposo , prendiamoci un minuto
potresti rivolgerti a qualcuno che è vicino a te
tu o tu potresti rompere in più piccolo
gruppi e basta discutere vedi se puoi
venire con la definizione di ciò che a
il servizio di riposo sembra appena me lo darò
ti piace parlare tra 45 secondi
voi stessi
forse circa altri dieci secondi
va bene sono felice di vedere il no
scazzottate scoppiarono su quello oltre
discussione qualcuno forse qualcuno
voglio condividere la definizione che sono venuti
con tutto bene, sì, va bene tutto
giusto sì uso di verbi HTTP HTTP e
nomi di folla e quel genere di cose
va bene quindi questo è un po ‘un trucco
domanda perché c’è il the
discussione su cosa sia il riposo e come
lo si fa e se si sta facendo
è vero che è così contorto a volte
guardare due minuti sarebbero mai abbastanza I
significa che potremmo probabilmente passare mezza giornata
ne parliamo dalle discussioni
che sei tu che ho fatto parte di
almeno così se hai un’opinione forte
A riposo, questo è un avvertimento che sto per fare
parla di riposo un po ‘che non puoi
sono d’accordo con le parole che uso o il
modo descrivo il riposo che probabilmente
non mi rende una cattiva persona
e tu sai anche se non siamo d’accordo
Sono altrimenti abbastanza facile andare d’accordo
con e sai che penso di sapere
non lasciamo che questo tipo di a
il disaccordo ci impedisce di diventare
amici per tutta la vita va bene così come eravamo
costruito mentre stavamo costruendo il nostro migliore amico
servizio abbiamo cercato di adottare un numero di
diverso tipo di architettura riposante
principi e questo questo Richardson
il modello di maturità era una specie di nostra guida
luce guida rispetto al nostro
implementazione Martin Fowler ha un
post sul blog davvero buono su come discuterne
modello e tipo di picking a parte il
diverse fasi e parlando di alcuni
di alcuni dei pro e contro ma il
l’ idea di base è che tu sai adottare
queste diverse fasi e ottieni
Non sono la gloria del riposo, quindi non lo siamo
non siamo lì sì , non so cosa
succede quando arrivi lì forse tu
sapere cessare di esistere da questo piano di
esistenza o non so che ti lascerò
sapere quando arriviamo
quindi solo un paio di commenti su
in che modo sfruttiamo queste idee
il nostro nel nostro BFF così di livello uno nel
Il modello di maturità di Richardson è l’uso di
risorse quindi se vuoi indirizzare un
risorsa c’è una sorta di contestuale
percorso per arrivarci compreso te lo sai
nomi di gruppi di risorse più il
ID delle risorse quindi se vuoi un
informazioni su una sicurezza puoi vedere
il puntatore va bene o virgolette o articoli
per sicurezza puoi usare un percorso simile
questo con l’ID di sicurezza e allo stesso modo
se sei un cliente e vuoi l’accesso
alle tue partecipazioni per un particolare
portfolio useresti un URI come questo
questi due verbi HTTP di livello due , quindi questi sono
tipo di quelli che facciamo di più
uso di qualsiasi uso qualsiasi opzione utenti nel
Opzioni di casa va bene va bene, sì tutti
giusto sì, non posso dimenticare le opzioni
perché nessuno sa che esiste e
quindi è una specie di grande livello
tre è l’uso di controlli hyper media
i controlli hyper media sono generalmente link
incorporato nel raccontare risposta del server
il cliente forse quali azioni possono fare
eseguire su una data una determinata risorsa così
se prendo una risorsa ci sarebbe
link in là dicendo che lo so sono io
permesso di cancellarlo sono autorizzato a
apportare modifiche ad esso quel tipo di cosa
e anche i collegamenti per i dati associati, quindi se
Sto tirando giù un pezzo di
informazioni e ci sono forse tre o
quattro altri pezzi di dati associati
ci sarebbero dei link a quelli che mi dicono
sai come sono in grado di accedere
quelle risorse particolari quindi il nome
per questo è hyper media come motore
il motore di stato dell’applicazione o hatty
Oz o Hetty O o comunque tu voglia
pronuncia che non prenderò un
litigare sulla pronuncia che usiamo
questo molto molto poco quindi non abbiamo
asceso alla gloria del riposo e lo farò
torna indietro e parla per parlare un po ‘
circa il tipo di dove questo si inserisce in un’ora
Viaggio BFF e poi ne usiamo alcuni
prova a usare generalmente le intestazioni HTTP e
codici di risposta e usiamo a
un po ‘ di intestazioni personalizzate qui e
lì e usiamo alcuni generali come
endpoint e parlerò di questo in
le diapositive in arrivo
quindi ora ti facciamo tornare regolarmente
programma previsto quindi uno dei
preoccupazioni di prestazione che proviamo quello
abbiamo lavorato per risolvere la nostra API
la nostra API BFF è ridurre il file
chattiness dell’applicazione client così
fondamentalmente dove c’è un’opportunità
per noi per tipo di nave fuori un intero gruppo
di dati che ha senso in un particolare
vedremo che lo faremo così li chiamerei
genere come API specifica vista quindi se se
si guarda in un Rhett severo in un altro
approccio restful rigoroso si potrebbe se
stai cercando informazioni sul tuo
possedimenti si potrebbe ottenere una matrice di
tenere oggetti con collegamenti associati
per ulteriori dati di sicurezza aggiuntivi
cita i dati quindi è il cliente
lavoro di applicazioni client per dire che lo sai
se hai 50 titoli in questo o in
50 partecipazioni qui per fare i prossimi 100
richiede di recuperare quei dati ma perché
sappiamo come appaiono le visualizzazioni
queste applicazioni che dobbiamo avere
tendeva a costruire in alcuni casi questi di più
il tipo di vista specifica per le API è così
di includere tutti quei collegamenti che vorremmo
incorporare i dati di sicurezza e la citazione
dati e qualunque sia l’altro tipo di
Dati associati proprio nella risposta così
il cliente non deve essere fare tutto
quei viaggi di andata e ritorno aggiuntivi per il
informazioni che sappiamo di aver bisogno
per quello per quei punti di vista comunque loro
alcune delle nostre API più generalizzate ci siamo noi
non erano società finanziaria facciamo un sacco di
roba con dati di mercato e e
titoli azionari quel tipo di cose
abbiamo aggiornato o abbiamo scritto il nostro
sicurezza correlata e API è a
Supporta più ID di sicurezza, quindi è così
abbastanza comune per una vista per voi sapere
mostra informazioni su più
titoli in un momento, se si desidera
confronta sai due o tre diversi
titoli e loro prestazioni e come
Morningstar ha valutato loro che tipo di
cosa potrebbe l’applicazione client potrebbe
semplicemente fare una richiesta per se voglio il
cita un elenco separato da virgola di Apple
e Google e Facebook e poi il
ultimo tipo di cosa correlata alla performance
di nuovo perché stiamo cercando di usare il
Servizio BFF per fare il più pesante
sollevando per le applicazioni il più possibile
facciamo un sacco di provare a fare uso di
parallelismo e operazioni asincrone
dovunque possiamo, così usiamo il
diplay framework any framework di gioco
gli utenti della casa sono bravi
quindi giocare ha un’API davvero molto bella per
facendo un sincrono asincrono
operazioni e questa è una specie di pseudo
codice II esempio di uno che facciamo
oggi abbiamo fondamentalmente una API dove
vuoi inviare il cliente vuole
invia una richiesta per un numero diverso
titoli e tornare indietro di un pezzo di
Analisi Morningstar
Morningstar commenta le notizie di terze parti
e il video di Morningstar è il problema
che i nostri fornitori di dati e supporto
interrogando in questo modo noi così così che cosa finiamo
il dover fare è per ogni sicurezza noi
licenziare quattro di queste richieste
in modo asincrono e poi il
framework API ci aiuta a farti sapere
tipo di farci sapere quando tutti quei dati
è disponibile e e quindi agire su di esso
quando è pronto , quindi raccogliamo
tutta la roba in questi promessi
oggetti e ci consente di dire che lo sai
se sto chiedendo questa informazione per
conosci una dozzina di titoli diversi noi
può licenziare queste richieste in lotti
di quattro per voi sapete per ciascuno di questi
titoli in modo che tu sappia fare molto
quel sollevamento pesante che sarebbe equo
oneroso da gestire dal lato del cliente
soprattutto attraverso soprattutto attraverso
più applicazioni è stato un grande
beneficio per noi così l’ultimo
argomento di implementazione che ho intenzione di parlare
a proposito di gestione degli errori e sto andando
usare un termine piuttosto interessante, penso sia bello
da Eric Evans questo è l’ anti
strato di corruzione quindi leggerà il
citazione qui, ma quando l’altro lato di
il confine inizia a filtrare attraverso il
traduzione il livello può assumere un altro
tono difensivo così design di dominio
riguarda il dominio della modellazione aziendale
consistenza di denominazione di modellazione che tipo di
roba ma quando lavori particolarmente
quando lavori con molte cose diverse
fornitori di dati che conosci molto
diversi stili di risposte e quello
tipo di cosa hai davvero bisogno di pensare
tipo di a livello centrale sul tuo errore
gestire la strategia e come stai andando
per essere che conosci te e probabilmente vuoi
per costruire quel tipo di cose nella tua
modellando così Sun Microsystems ci ha detto il
la rete è il computer e lo sto dicendo
tu che la rete è un sacchetto di rabbia
i gatti sono quelli che penso tu sappia
lavorare in una disabilità in un ambiente distribuito
ambiente vedi tutti questi strani
cose che conosci problemi di rete quando
stai parlando con un fornitore di dati
e tu sai chi sa cosa sono
fare dietro le quinte per ottenere i dati
che stai chiedendo così tanto spazio
per fallimento quindi abbiamo finito col costruire questo
tipo di integrazione del servizio web personalizzato
livello che si potrebbe tipo di pensare ad esso come
come un dao per le chiamate al servizio web se
sei in OS da dove siamo fondamentalmente
mi scusi maneggiare un sacco di piastre
la gestione degli errori va in timeout cose del genere
in modo che dov’eri catturato
questi potenziali problemi che noi che noi
avresti capito con chi interagire
diversi fornitori di servizi di dati così e
ovviamente perché i diversi dati
i fornitori di servizi hanno stili diversi
di errore gestendo noi stessi siamo gentili
di aver normalizzato quella roba così tu ci conosci
avere un bel po ‘di quelli che fanno
risposte standard del codice HTTP che possiamo
guarda molto facilmente tutti amano questo
un tutto quello che ti dice l’intestazione HTTP
che tutto va bene, ma poi guardi
al corpo di risposta e come
si scopre che tutto non va bene e poi
altri casi angusti strani dove tu
ha chiamato un’API JSON e vieni reindirizzato
a una pagina HTML succede
non molto spesso fortunatamente e poi così
per quanto riguarda la nostra API è la risposta a
le nostre applicazioni client abbiamo tipo
standardizzato su pochi diversi sai
pochi tipi di risposta di risposta HTTP parziali
il contenuto è interessante se possiamo soddisfare ogni vostra
sai diciamo l’applicazione client
chiede da una cosa e sotto le coperte
stavano forse chiamando due dati diversi
fornitori e cucendo quelle informazioni
insieme ma sai se parte di quello
l’informazione non ritorna per qualsiasi cosa
motivo per cui useremmo due di sesso a
dì che hai chiesto questo non l’ho capito
tutto ciò ma ti sto dando quello che ero
in grado di ottenere e l’altro gli altri due
che sono interessanti per evidenziare il nostro
503 fondamentalmente se facciamo una chiamata a
fornitore di dati di dati e qualcosa va
sono sbagliati, hanno sbagliato
ci ha dato HTML quando vogliamo JSON
tipo di cose quindi restituiamo un 503 a
le nostre applicazioni client e poi questo è
solo una specie di costruito nel contratto di
come facciamo a sapere come il cliente
le applicazioni stanno consumando questo è
una sorta di segnale è come se qualcosa fosse andato
sbagliato non è colpa nostra riprovare più tardi gentile
di una cosa e vale la pena di disegnare
attenzione al fatto che non lo faremo mai
produrre 500 errori o 500 risultati
intenzionalmente quelli sono riservati per il nostro
errori di programmazione e puntatore nullo
eccezioni e cose del genere quindi se
la nostra API non restituisce i 500 che conosciamo
abbiamo avuto qualche problema serio per
indirizzo perché noi siamo fondamentalmente
cadere così ho intenzione di parlare a
un po ‘di lezioni apprese queste
sai che la benedizione di Blessin
costruire questo BFF dal supporto
più applicazioni client dalla
anni così sai che ti costruisci un sistema
costruisci un servizio e ogni volta in a
mentre trovi che conosci soprattutto come
stiamo tutti parlando
su micro servizi come Oh micro
i servizi sono fantastici
sono un monolite dovrei essere un monolite
come sono preoccupato per questo tipo di
cose
cosa posso separarmi ed essere di più
micro servizio II quindi abbiamo sicuramente eseguito
in alcune situazioni dove siamo noi
comprendiamo che abbiamo costruito alcune cose nel nostro
servizio che in realtà non ci appartiene
come al massimo penso sia il più ovvio
esempio è che quando qualcuno compra un
abbonamento ai dati Morningstar tramite
la nostra app per iPad che va alla Apple
Store inviano le loro informazioni a uno
dei nostri sistemi internamente e poi quello
il sistema in realtà parla attraverso di noi
il nostro BFF torna ad Apple non appartiene
eccolo lì , non è davvero adatto
quel servizio è ancora lì oggi
noi probabilmente si sa rompere questo fuori
come servizio separato in futuro ma
è una di quelle cose che conosci
quando guardiamo a quel servizio , tipo
grattarci la testa e andare, sì, perché no
lo facciamo
e sai che ne abbiamo costruiti molti
diverse applicazioni su questo BFF
tre di loro sono molto simili
esperienze e così mi piace non io
pensa l’idea generale del BFF
il modello vale per quelli diversi
esperienze ma quando ne abbiamo costruiti altri
applicazioni o quando stiamo pensando
sulla costruzione di altre applicazioni è a
domanda di come dovremmo fare questo
dovremmo farcela con qualcosa
altrimenti dovremmo sapere infrangere questo
un servizio separato e avere quelli
i servizi si chiamano ma tu
so che sono solo conversazioni
abbiamo avuto nel tempo quando stiamo costruendo
nuove cose e poi c’è il
domanda inevitabile come Krishna e
menzionato su questa domanda di riutilizzo
da altre squadre siamo stati avvicinati da
un paio di squadre diverse sul
anni su di te sai hey che vogliamo usare
il tuo servizio perché hai questo bello
integrazione con questi dati sicuri
provider per i dati di sicurezza è
coerente hai fatto il lavoro già possibile
lo usiamo solo e noi tipo
ha deciso di tracciare una linea nella sabbia e
dì che sai che non vogliamo sostenere
che noi non vogliamo che vogliamo essere in grado
per apportare modifiche a ciò che è giusto
per la nostra applicazione e non essere tu lo sai
gravato dal sostenere un gruppo di altri
prodotti ma le applicazioni nella fonte
che controlli
libero di sborsarlo e sai prendere un take
un problema a costruire qualcosa con esso se
vuoi un BFF è stato davvero un
ottimo posto per tamponare il cambiamento così perché
abbiamo un numero diverso
applicazioni applicazioni mobili voi
sapere se abbiamo bisogno se vogliamo o abbiamo bisogno
per tagliare verso un nuovo fornitore di servizi se
stiamo aggiungendo dati o sottraendo dati o
spostare i dati in giro e la nostra modellazione e
quel genere di cose il the the BFF
il servizio è una specie di sportello unico per
sai gestire piuttosto quel cambiamento
di dover sapere apportare modifiche in
quattro diverse app e cerca di ottenerle
fuori per app store e, in in modo tempestivo
moda e perché controlliamo il
programma di rilascio su quel BFF possiamo gentile
di noi possiamo tipo di fare quelli introdurre
quei cambiamenti ogni volta che vogliamo fare
così se c’è un sai se
qualcuno sta deprecando un’API la prossima settimana
possiamo o sai che possiamo costruire build
tipo di funzionalità di un ponte oggi e
distribuire quello e poi quando quando le cose
sapere quando le cose lo rendono formale
la transizione la gestiamo semplicemente sul retro
fine e aiuto agli sviluppatori lato client
muoviti più velocemente bene è una specie di un
interessante
quindi quando stiamo costruendo una nuova API è di
corso vecchio in molti casi, se lo siamo
integrazione con un nuovo fornitore di dati o
qualcosa del genere o il lavoro ha
da fare nel servizio BFF o il
il lavoro può essere fatto nei dati
servizio di provider pure
quindi sai che c’è tempo di ritardo fino a quando
tutto quel lavoro viene fatto prima del
Gli sviluppatori di client possono costruire sai
le loro caratteristiche e quel tipo di cose così
quello che abbiamo finito per fare
numerosi casi è solo l’aggiunta di dati stub
al nostro servizio BFF in modo da sapere concordare
su un contratto API tra il server
e gli sviluppatori lato client di cosa si tratta
i dati devono apparire come sai
stub alcuni dati che il lato client
gli sviluppatori possono iniziare a lavorare con
immediatamente e poi nel migliore dei casi
scenari che è certamente non tutti
gli scenari in cui il lavoro su
integrazione al fuorigioco con i dati
il fornitore ha fatto solo i dati reali
inizia a fluire e tu sai
qualcuno raccoglie l’app in QA un giorno
e vede i dati reali invece dello stub
uno dei dati di cui ho parlato di questo
bilanciamento di api e scopi generali
visualizzare API specifiche mi sento come se avessimo
fatto un buon lavoro ragionevolmente
pensa quando quando iniziamo a costruire a
nuova API, in generale, stiamo pensando
su di esso come vogliamo che questo sia come
generale come possiamo perché siamo
sostenendo un numero di diverso
le applicazioni è un po ‘come anche bene
se è anche se questa applicazione ha bisogno
usare così in questo modo oggi sarebbe
buono per costruire questo in un relativamente
modo generale per sapere se questo
altra applicazione vuole usarlo domani
può semplicemente chiamare questi stessi endpoint e
e ottenere gli stessi dati e sì io
menzionato l’ API specifica della vista così
proviamo a provare a fare un po ‘
un po ‘meno di quello e si yeah abbiamo a
numero di esperienze diverse usando
queste api sono così ho detto che sarei tornato
ad Haiti ohi fanno cerniera come Cheerios
grazie grazie per aver spiegato la barzelletta
rende sempre la battuta migliore così come me
ha detto che non abbiamo raggiunto la gloria
di riposo che non stiamo usando non stiamo usando
ipermedia molto estensivamente dove
l’abbiamo usato penso che siamo davvero
lieto che lo abbiamo fatto e lo vediamo sicuramente
che penso che ne abbiamo fatti alcuni
errori dove se l’avessimo usato di più
non ci sarebbe molto
logica applicativa lato client dove tu
so oh ho preso questi dati che so come
scegli uno di questi punti dati e costruisci
un URL fuori di esso e ottenere un po ‘di più
dati in modo che le applicazioni client siano tutte
in qualche modo hanno tutti questa logica
cosparso ovunque così se usiamo
questo approccio un po ‘più di me
pensa di sapere che avremmo un po ‘
un po ‘meno di quella roba e se noi
vuoi spostare la data se vogliamo spostarci o
migrare i dati all’interno di queste API allora
allora quelli sarebbero solo lato server
cambia perché il cliente non lo farebbe
davvero sapere o cura di dove specifico
i dati verrebbero da ciò che deve sapere
chiamare un’API e quindi tornare indietro
potrebbe quasi chiudere quel riposante
conversazione che alcune persone direbbero
se non stai usando le radio non lo sei
riposante e va bene non ce l’ho
non conosci super-impegnato a
anche se non siamo riposanti, penso
tale approccio e richiedendo che
l’approccio forse ha un po ‘più senso
per generalizzato sai di più
Api di scopo generale ma in questo BFF
servizio prendendo più sorta di pragmatico
avvicinati saprai che non mi fa male se
se sai che ci riuniamo in seguito
e dì che sai che questo servizio non lo è
è riposante , ha funzionato bene per noi e
e sai che è vero, siamo su misura
specificamente al nostro cliente
le applicazioni che ritengo pesanti
uso di questo o per insistere sul fatto che lo usiamo
in tutti i nostri occhi API, quindi voglio aprire
il piano fino ad un certo QA giusto così
la domanda è che noi siamo dove abbiamo disegnato
la linea di riutilizzo era ma solo con
il BFF o l’API Gateway così così
sì, il BFF è davvero il nostro
gateway API quindi il nostro nostro cellulare
le applicazioni stanno chiamando il servizio BFF
e tu sai che sai
API gateway pure così questo è il
gateway di applicazioni a tutti questi dati
che è diverso dal gateway API
abbiamo parlato in Amazon oh sì quale
è o abbiamo il nostro gateway API
chiamato apogee che usiamo all’interno dei nostri dati
centro quindi è una specie di a
cross-cutting è un gateway per tutti
i nostri servizi di back-end
ma questo BFF è diverso da quello
collega direttamente è strettamente legato
all’esperienza utente che è il
app per client, quindi la domanda è
ci troviamo fondamentalmente in duplicazione
duplicare cose nel BFF che
fondamentalmente c’è una sorta di a
relazione uno-a-uno tra
l’API di BFF e l’API del fornitore di dati
è che non penso ci sia stato troppo
molti di quelli là ci sono stati
ce ne sono stati alcuni e questo è e
è un po ‘anche nei casi in cui
dove l’abbiamo fatto io ce n’è abbastanza
di questo tipo di errore consistente
gestendo una risposta coerente sai
standardizzazione in cui penso che otteniamo
abbiamo lo sviluppo di applicazioni client
è stato un beneficio da quel tipo di
cose grazie ragazzi
[Applausi]
Please follow and like us: