Dovresti scrivere il tuo back-end come API?

Ho avuto una discussione accesa oggi sulla nostra applicazione MVC. Abbiamo un sito Web scritto in MVC ( ASP.NET ) e di solito segue lo schema di fare qualcosa nella vista -> premi il controller -> il controller crea un modello (chiama un Manager che ottiene i dati, costruisce il modello nel metodo di controllo stesso) -> il modello visualizza -> risciacqua e ripeti.

Ha detto che il nostro codice era troppo stretto. Ad esempio, se volessimo anche un'applicazione desktop, non saremmo in grado di utilizzare il nostro codice esistente.

La soluzione e le migliori pratiche che ha detto è quella di creare un'API, quindi costruire il tuo sito Web in cima all'API e quindi creare un'applicazione desktop, un'app mobile, ecc. È molto semplice.

Questa mi sembra una cattiva idea per vari motivi.

Ad ogni modo, non riesco a trovare nulla su Google che possa discutere di questa pratica. Qualcuno ha qualche informazione su pro, contro, perché dovresti, perché non dovresti o leggere ulteriormente?

Alcuni motivi penso che sia una cattiva idea:

• È troppo astratto per eseguire il back-end da un'API. Stai cercando di renderlo troppo flessibile, il che lo renderà un casino ingestibile.

• Tutto il materiale integrato in MVC sembra inutile, come ruoli e autenticazione. Ad esempio, [Autorizza] attributi e sicurezza; dovrai tirare il tuo.

• Tutte le tue chiamate API richiederanno informazioni sulla sicurezza allegate e dovrai sviluppare un sistema token e quant'altro.

• Dovrai scrivere chiamate API complete per ogni singola funzione che il tuo programma potrà mai svolgere. Praticamente ogni metodo che si desidera implementare dovrà essere eseguito da un'API. Un Get / Update / Delete per ogni utente, oltre a una variante per ogni altra operazione, ad esempio aggiornare il nome utente, aggiungere l'utente a un gruppo, ecc. Ecc. E ognuno sarebbe una chiamata API distinta.

• Perdi tutti i tipi di strumenti come interfacce e classi astratte quando si tratta di API. Roba come WCF ha un supporto molto debole per le interfacce.

• Hai un metodo che crea un utente o esegue alcune attività. Se vuoi creare 50 utenti, puoi semplicemente chiamarlo 50 volte. Quando decidi di utilizzare questo metodo come API il tuo webserver locale può connettersi ad esso e senza problemi: anche il tuo client desktop può colpirlo, ma all'improvviso la creazione di utenti in blocco comporterà il martellamento dell'API su Internet 50 volte che non è va bene. Quindi devi creare un metodo di massa, ma in realtà lo stai solo creando per i client desktop. In questo modo, devi finire per a) modificare la tua API in base a ciò che si integra con essa e non puoi semplicemente integrarti direttamente con essa, b) fare molto più lavoro per creare una funzione extra.

• YAGNI . A meno che non si stia pianificando in particolare di scrivere due applicazioni funzionanti in modo identico, ad esempio un'applicazione Web e un'applicazione Windows, si tratta di un'enorme quantità di lavoro di sviluppo aggiuntivo.

• Il debug è molto più difficile quando non è possibile passare da un capo all'altro.

• Molte operazioni indipendenti che richiederanno molto avanti e indietro, ad esempio alcuni codici potrebbero ottenere l'utente corrente, verificare che l'utente abbia il ruolo di amministratore, ottenere la società di appartenenza dell'utente, ottenere un elenco di altri membri, inviarli tutti un'email. Ciò richiederebbe molte chiamate API o la scrittura di un metodo su misura dell'attività specifica desiderata, in cui l'unico vantaggio di tale metodo su misura sarebbe la velocità, ma il rovescio della medaglia sarebbe che sarebbe inflessibile.

• Probabilmente alcuni altri motivi per cui questi sono appena fuori dalla mia testa.

Mi sembra solo se non hai davvero bisogno di due applicazioni identiche, quindi non ne vale davvero la pena. Non ho mai visto un'applicazione ASP.NET costruita in questo modo, dovresti scrivere due applicazioni separate (l'API e il tuo codice) e controllare anche la versione di entrambe (se la tua pagina utente ottiene un nuovo campo, " devo aggiornare contemporaneamente l'API e il tuo codice utente per garantire l'assenza di effetti negativi o dedicare molto lavoro extra per mantenerlo robusto).

Modifica: alcune ottime risposte, iniziando davvero ad avere una buona idea di cosa significhi tutto questo ora. Quindi, per espandere la mia domanda, come struttureresti un'app MVC per seguire questa struttura API?

Ad esempio, hai un sito Web che visualizza informazioni su un utente. Sotto MVC, hai:

Visualizza: pagina (CS) HTML che visualizza un controller UserViewModel: chiama GetUser () e crea un UserViewModel che passa alla classe view manager (ordinamento dell'API) con un metodo GetUser.

Il controller esegue GetUser () ma vuoi anche un'app desktop. Ciò significa che GetUser deve essere esposto tramite un qualche tipo di API. È possibile che si desideri una connessione TCP, WCF o Remoting. Vuoi anche un'app mobile che sia RESTful poiché le connessioni persistenti sono instabili.

Quindi scriveresti un'API per ognuno di essi, un servizio Web WCF che ha un metodo GetUser () e il codice lo fa return new UserManager().GetUser()? E un metodo api mvc 4 web che fa la stessa cosa? Continuando a chiamare GetUser direttamente nel metodo del controller MVC?

O sceglieresti la soluzione che funzionerebbe per tutti e tre (servizio REST di api Web) e basarti su tutto, quindi tutte e tre le app effettuano chiamate API (quelle mvc, al computer locale).

E questo è solo uno scenario teoricamente perfetto? Riesco a vedere grandi spese generali nello sviluppo in questo modo, soprattutto se devi svilupparti in un modo che ti permetta di eseguire le operazioni in modo RESTful. Penso che parte di questo sia stato trattato nelle risposte.

Modifica 2: Dopo aver letto più cose, ho inserito un commento sotto che penso possa spiegarlo. La domanda è un po 'una domanda trabocchetto, penso. Se dovessi scrivere il tuo back-end come un'API mi ha fatto confondere pensando che ci dovrebbe essere un unico servizio web che tutto (app mvc, app desktop, app mobile) chiama per fare cose.

La conclusione a cui sono giunto è che ciò che dovresti davvero fare è assicurarti che il tuo livello di logica aziendale sia correttamente disaccoppiato. Guardando il mio codice, lo faccio già: il controller chiamerà GetUser()un manager, quindi creerà un modello di visualizzazione da renderizzare con una vista. Quindi, davvero, il livello di logica aziendale è un'API. Se vuoi chiamarlo da un'app desktop, devi scrivere qualcosa come un servizio WCF per facilitare la chiamata. Anche solo avere un metodo WCF chiamato GetUser()che contiene il codice return MyBusinessLayer.GetUser()sarebbe sufficiente. Quindi l'API è la logica aziendale e WCF / API Web ecc. Sono solo titoli di codice per consentire alle applicazioni esterne di chiamarlo.

Quindi c'è un sovraccarico, nel senso che devi avvolgere il tuo livello di logica aziendale in diverse API a seconda di ciò che ti serve, e dovrai scrivere un metodo API per ogni operazione che vuoi che facciano le altre tue app, inoltre dovrai risolvere un modo per fare l'autenticazione, ma per la maggior parte è lo stesso. Incolla la tua logica di business in un progetto separato (libreria di classi) e probabilmente non avrai problemi!

Speriamo che questa interpretazione sia corretta. Grazie per tutte le discussioni / i commenti che ha generato.

Si, dovresti.

Non solo rende riutilizzabile il back-end, ma consente una maggiore sicurezza e un design migliore. Se scrivi il tuo backend come parte di un singolo sistema, stai realizzando un design monolitico che non è mai facile da estendere, sostituire o migliorare.

Un'area in cui questo è popolare al momento è in Microservizi . Laddove il back-end è suddiviso in molti servizi piccoli (o addirittura di grandi dimensioni), ciascuno dei quali fornisce un'API utilizzata dal sistema client. Se immagini di utilizzare molte fonti di dati di terze parti nella tua applicazione, ti rendi conto che potresti già farlo.

Un altro vantaggio è che la costruzione e la manutenzione di ciascun servizio può essere affidata a un team diverso, che può aggiungere funzionalità che non influiscono su nessun altro team che produce prodotti. Solo quando hanno finito e rilasciano il loro servizio, questi iniziano ad aggiungere funzionalità al prodotto per utilizzarli. Questo può rendere lo sviluppo molto più agevole (sebbene potenzialmente più lento nel complesso, si tende a ottenere una qualità migliore e comprensibile)

Modifica: OK Vedo il tuo problema. Pensi all'API come a una libreria remota. Non è. Pensa al servizio come a un servizio di fornitura di dati. Si chiama il servizio per ottenere dati e quindi eseguire operazioni su tali dati localmente. Per determinare se un utente ha effettuato l'accesso, è necessario chiamare " GetUser" e quindi esaminare il 'logged on'valore, ad esempio. ( YMMV con quell'esempio, ovviamente).

Il tuo esempio per la creazione di utenti in blocco è solo quello di scusare: qui non c'è alcuna differenza, qualunque cosa avresti potuto fare in un sistema monolitico può ancora essere fatta in un'architettura di servizio (ad esempio avresti passato un array di utenti per creare in blocco, o uno da creare. Puoi sempre fare esattamente lo stesso con i servizi).

MVC si basa già sul concetto di servizi isolati, solo i framework MVC li raggruppano in un unico progetto. Ciò non significa che perdi nulla tranne gli helper in bundle che il tuo framework ti offre. Usa un framework diverso e dovrai usare helper diversi. Oppure, in questo caso, arrotolando il proprio (o aggiungendolo direttamente utilizzando una libreria).

Anche il debug è semplice: puoi testare accuratamente l'API in modo da non dover eseguire il debug in esso (e puoi eseguire il debug end-to-end, Visual Studio può collegarsi a più processi contemporaneamente).

Cose come il lavoro extra che implementa la sicurezza è una buona cosa. Attualmente, se raggruppi tutto il codice nel tuo sito Web, se un hacker accede ad esso, ottengono anche l'accesso a tutto, DB incluso. Se lo dividi in un'API, l'hacker può fare ben poco con il tuo codice a meno che non abbia anche hackerato il livello API - il che sarà incredibilmente difficile per loro (ti sei mai chiesto come gli aggressori ottengano vasti elenchi di tutti gli utenti del sito Web o dettagli cc? È perché hanno violato il sistema operativo o il server Web e aveva una connessione diretta al DB dove potevano eseguire " select * from users" facilmente.

Dirò che ho visto molti siti Web (e applicazioni client-server) scritti in questo modo. Quando lavoravo nel settore dei servizi finanziari, nessuno scriveva mai un sito Web all-in-one, in parte perché troppo rischioso per la sicurezza, e in parte perché molto sviluppo è piuttosto una GUI piuttosto che un'elaborazione dei dati back-end stabile (ovvero legacy) sistemi. È facile esporre il sistema DP come sito Web usando un'architettura di stile di servizio.

2a modifica: alcuni collegamenti sull'argomento (per l'OP):

Si noti che quando si parla di questi nel contesto di un sito Web, il server Web deve essere considerato il livello di presentazione, perché è il client che chiama gli altri livelli e anche perché costruisce le viste dell'interfaccia utente che vengono inviate al browser per il rendering. È un argomento importante e ci sono molti modi per progettare la tua applicazione - incentrata sui dati o incentrata sul dominio (in genere considero il centric del dominio come "più puro", ma YMMV ), ma tutto si riduce a fissare un livello logico tra il tuo cliente e il tuo database. È un po 'come MVC se consideri il livello intermedio, API, livello equivalente al tuo modello, solo il modello non è un semplice wrapper per il DB, è più ricco e può fare molto di più (ad es. Dati aggregati da 2 origini dati, post -elaborare i dati per adattarli all'API, memorizzarli nella cache, ecc.):

• Architettura a più livelli
• Creazione di un'applicazione N-Tier in .NET
• Tutorial di Youtube: vedi anche i link correlati, incluso uno da implementare in C #
• Corso di formazione Pluralsight (prova gratuita o a pagamento)

Non è possibile evitare di creare un'API . Anche se costruisci "solo un sito Web", dovrà comunque ottenere i suoi dati dal tuo backend in qualche modo. Comunque decidi di farlo, questa è la tua API di fatto .

Sapendo questo, la vera domanda non è se costruire un'API, ma come costruirla . Puoi farlo al volo come una cosa ad hoc - e in effetti, molti siti Web sono costruiti esattamente in questo modo - oppure puoi progettarlo con cura per essere utilizzabile in altri contesti. Metti in questo contesto, diventa abbastanza chiaro che il tuo collega ha ragione: dovresti prima fare l'API e quindi costruire il tuo sito su di esso.

Tuttavia, questo porta con sé alcune preoccupazioni, come fai notare. Per affrontarli:

È troppo astratto per eseguire il back-end da un'API. Stai cercando di renderlo troppo flessibile, il che lo renderà un casino ingestibile.

Dipende da come lo fai. Come sottolinea George Pólya nel suo eccellente testo Come risolverlo , spesso "il problema più generale può essere più facile da risolvere". Questo si chiama Paradosso dell'Inventore . Nel caso della programmazione, spesso funziona per mezzo della separazione delle preoccupazioni: il tuo backend non deve più preoccuparsi del formato dei dati che inserisce e estrae, e quindi il suo codice può essere molto più semplice. I tuoi parser e renderer di dati non devono più preoccuparsi di ciò che accade ai dati che creano, quindi anche loro possono essere più semplici. Funziona tutto suddividendo il codice in blocchi più gestibili.

Tutto il materiale integrato in MVC sembra inutile, come ruoli e autenticazione. Ad esempio, [Autorizza] attributi e sicurezza; dovrai tirare il tuo.

Confesso che trovo estremamente difficile simpatizzare con le persone che si rifiutano di imparare i loro strumenti. Solo perché non capisci il loro uso non significa che siano inutili, e certamente non significa che dovresti farlo da solo . Al contrario; non dovresti andare avanti con i tuoi strumenti finché non capisci le alternative, in modo da poter essere sicuro di affrontare gli stessi problemi che fanno (anche se solo a modo tuo).

Considera Linus Torvalds , che è più famoso per aver scritto Linux , ma che ha anche scritto git : ora uno dei sistemi di controllo versione più famosi al mondo. Uno dei fattori trainanti nel suo design era una profonda opposizione a Subversion (un altro VCS estremamente popolare , e probabilmente il più popolare al momento della stesura di git); decise di prendere tutto ciò che Subversion poteva e, per quanto possibile, risolvere quei problemi in modo diverso. Per fare questo, ha dovuto diventare un esperto di Subversion per conto proprio , proprio per poter comprendere gli stessi settori problematici e adottare un approccio diverso.

Oppure, nel processo di apprendimento dei tuoi strumenti, potresti scoprire che sono utili così come sono e che non è necessario sostituirli.

Tutte le tue chiamate API richiederanno informazioni sulla sicurezza allegate e dovrai sviluppare un sistema token e quant'altro.

Sì. Ecco come dovrebbe essere.

Dovrai scrivere chiamate API complete per ogni singola funzione che il tuo programma potrà mai svolgere. Praticamente ogni metodo che si desidera implementare dovrà essere eseguito da un'API. Un Get / Update / Delete per ogni utente, oltre a una variante per ogni altra operazione, ad esempio aggiornare il nome utente, aggiungere l'utente a un gruppo, ecc. Ecc. E ognuno sarebbe una chiamata API distinta.

Non necessariamente. Qui entrano in gioco architetture come REST . Identifichi le risorse con cui lavora la tua applicazione e le operazioni che hanno senso applicare a tali risorse, quindi le implementi senza preoccuparti così tanto delle altre .

Perdi tutti i tipi di strumenti come interfacce e classi astratte quando si tratta di API. Roba come WCF ha un supporto molto debole per le interfacce.

Al contrario, le interfacce diventano molto più importanti quando si utilizza un'API, non di meno . Vengono fuori nelle rappresentazioni in cui li rendi. La maggior parte delle persone oggigiorno specifica un formato basato su JSON per questo, ma è possibile utilizzare qualsiasi formato desiderato, purché sia ​​specificato bene. Rendi l'output delle tue chiamate in questo formato sul back-end e analizzalo in qualsiasi cosa desideri (probabilmente lo stesso tipo di oggetto) sul front-end. Il sovraccarico è piccolo e i guadagni in termini di flessibilità sono enormi.

Hai un metodo che crea un utente o esegue alcune attività. Se vuoi creare 50 utenti, puoi semplicemente chiamarlo 50 volte. Quando decidi di utilizzare questo metodo come API il tuo webserver locale può connettersi ad esso e senza problemi: anche il tuo client desktop può colpirlo, ma all'improvviso la creazione di utenti in blocco comporterà il martellamento dell'API su Internet 50 volte che non è va bene. Quindi devi creare un metodo di massa, ma in realtà lo stai solo creando per i client desktop. In questo modo, devi finire per a) modificare la tua API in base a ciò che si integra con essa e non puoi semplicemente integrarti direttamente con essa, b) fare molto più lavoro per creare una funzione extra.

Creare una versione in blocco di un metodo esistente non è certo qualcosa che definirei "molto più lavoro". Se non sei preoccupato per cose come l'atomicità, il metodo bulk può finire per essere non molto più di un frontend molto sottile per l'originale.

YAGNI . A meno che non si stia pianificando in particolare di scrivere due applicazioni funzionanti in modo identico, ad esempio un'applicazione Web e un'applicazione Windows, si tratta di un'enorme quantità di lavoro di sviluppo aggiuntivo.

No, YANI (ne hai già bisogno). L'ho sottolineato come sopra. L'unica domanda è quanto lavoro di progettazione mettere in esso.

Il debug è molto più difficile quando non è possibile passare da un capo all'altro.

Perché non saresti in grado di passare da un capo all'altro?

Ma più precisamente, essere in grado di esaminare i dati andando avanti e indietro in un formato facilmente riconoscibile che taglia tutta la trama del display tende a rendere il debugging più facile , non più difficile.

Molte operazioni indipendenti che richiederanno molto avanti e indietro, ad esempio alcuni codici potrebbero ottenere l'utente corrente, verificare che l'utente abbia il ruolo di amministratore, ottenere la società di appartenenza dell'utente, ottenere un elenco di altri membri, inviarli tutti un'email. Ciò richiederebbe molte chiamate API o la scrittura di un metodo su misura dell'attività specifica desiderata, in cui l'unico vantaggio di tale metodo su misura sarebbe la velocità, ma il rovescio della medaglia sarebbe che sarebbe inflessibile.

REST risolve questo problema lavorando su oggetti completi ( risorse , per usare i termini della teoria REST), piuttosto che sulle singole proprietà degli oggetti . Per aggiornare il nome di un utente, OTTIENI l'oggetto utente, modificane il nome e rimetti l'utente indietro. È possibile apportare altre modifiche contemporaneamente alla modifica del nome utente. Il problema più generale diventa più facile da risolvere, poiché è possibile eliminare tutte quelle singole chiamate per l'aggiornamento delle singole proprietà di un oggetto: basta caricarlo e salvarlo.

In un certo senso, questo non è diverso dalle architetture RISC dal lato hardware. Una delle differenze chiave tra RISC e CISC (il suo predecessore) è che le architetture CISC tendono ad includere molte istruzioni che operano direttamente sulla memoria, mentre le architetture RISC tendono ad operare principalmente nei registri: in un'architettura puramente RISC, le uniche operazioni sulla memoria sono LOAD (copia qualcosa dalla memoria in un registro) e STORE (prendi un valore da un registro e mettilo in memoria).

Penseresti che questo significherebbe fare molti più viaggi dai registri alla memoria, il che rallenterebbe la macchina. Ma in pratica accade spesso il contrario: il processore (client) fa più lavoro tra i viaggi in memoria (server) , ed è qui che arriva la velocità.

Per farla breve: il tuo collega ha ragione. Questa è la strada da percorrere. In cambio di un po 'di lavoro iniziale, semplificherà notevolmente il codice per il tuo sito Web e consentirà una migliore integrazione con altri siti Web e app. Questo è un prezzo che vale la pena pagare.

Ulteriori letture:

1. Progettazione API REST - Modellazione delle risorse

So che i microservizi sono di gran moda in questo momento, ma non ne valgono sempre la pena. Sì, l'obiettivo è un codice liberamente accoppiato. Ma non dovrebbe venire a scapito di un ciclo di sviluppo più doloroso.

Una buona via di mezzo sarebbe quella di creare un progetto dati separato nella soluzione. Il progetto di dati sarebbe una libreria di classi .NET. Il progetto ASP.NET MVC aggiungerebbe quindi un riferimento alla libreria di dati e tutti i modelli verrebbero estratti dal progetto di dati. Quindi, quando è arrivato il momento di creare un'app desktop o mobile, è possibile fare riferimento allo stesso codice. Quindi potrebbe non essere un'API ufficiale, ma funzionerà come tale. Se si desidera renderlo accessibile come API, è possibile creare un semplice progetto Web che funga da wrapper per il progetto dati.

Microsoft ha promosso questo concetto, che chiamano Portable Class Libraries .

No, non dovresti . Se non hai piani immediati per creare frontend alternativi (come app mobili o desktop o applicazioni Web separate) che accedono allo stesso backend, non dovresti introdurre un livello di servizio web. YAGNI .

L'accoppiamento allentato è sempre desiderabile (insieme all'alta coesione), ma è un principio di progettazione e non significa che devi separare fisicamente oggetti su server diversi! E un'API di servizio mal progettata può creare un accoppiamento stretto oltre i confini del server, quindi avere un'API non garantisce un accoppiamento lento.

Se in futuro dovesse sorgere la necessità di un'API di servizio, puoi sempre introdurla a quel punto. Finché manterrai il tuo codice ben stratificato (accesso ai dati e logica aziendale ben separati dalla logica dell'interfaccia utente), non sarà più difficile introdurlo più tardi di quanto non sia ora. E il design risultante sarà molto migliore quando progettato per soddisfare i requisiti effettivi.

Nota Suppongo che la domanda sia se è necessario creare un'API del servizio Web o meno. La domanda dice semplicemente API, ma API può anche significare solo l'interfaccia di una libreria, e quindi ovviamente ogni livello avrà un'API per definizione. In conclusione, i livelli di logica aziendale e di accesso ai dati devono essere separati in modo chiaro dalla logica dell'interfaccia utente a livello di progettazione, ma non è necessario introdurre un livello di servizio Web se non è necessario.

La mia azienda ha un'applicazione sviluppata in questo modo. Inizialmente ci è stato commissionato di creare un back-end con API per un front-end creato da un altro sviluppatore. Quando l'altro sviluppatore non è stato in grado di sviluppare quel front-end, ci è stato commissionato anche il front-end. Mentre ci sono sicuramente vantaggi in questo approccio, c'è un enorme svantaggio: il costo. La build iniziale sarà significativamente più costosa e la manutenzione in corso sarà più costosa, a causa della maggiore quantità di codice da mantenere e della distribuzione di due sistemi separati. A causa del costo aggiuntivo, questa dovrebbe essere sempre una decisione aziendale, non presa per capriccio dagli sviluppatori.

Per farne una figura, stimerei che il progetto che ho citato sopra sia costato il 20% in più a causa di questo approccio. Non descrivi per quale tipo di progetto stai lavorando per il tipo di azienda per cui lavori, ma se sei un start-up per costruire il loro prodotto quel costo extra potrebbe essere la differenza tra la spedizione di alcune funzionalità extra che rendono il tuo prodotto un successo.

Un altro motivo per non, almeno non universalmente, è che se o quando si decide di creare quella seconda interfaccia, raramente esiste un mapping uno a uno di funzionalità. Se crei un'app mobile, ad esempio, tendono ad avere meno funzionalità. Ciò significa che alcuni dei tuoi metodi API non verranno mai riutilizzati. Pertanto, un compromesso con il collega potrebbe essere quello di decidere tra di voi le chiamate più cruciali / critiche e aggiungerle a un'API e utilizzare metodi più tradizionali per tutto il resto.

Un altro punto da considerare è che il tuo collega sta dicendo che non sarai in grado di riutilizzare il tuo codice esistente, il che non è vero se hai una certa separazione della tua logica aziendale. Devi semplicemente creare un wrapper di servizi Web sottile attorno alle tue API interne, che non è un compito particolarmente grande. Sarebbe ingenuo pensare di poter riutilizzare un livello di servizio Web per un altro front-end senza alcuna modifica.

Dipende dal tipo di applicazione e dal tipo di mercato in cui ti trovi.

Ci sono compromessi e vantaggi per andare in questo modo. Non è una risposta chiara che un modo sia migliore dell'altro.

Parlerò per esperienza personale. Sono stato quello che ha deciso di prendere la base di codice su cui lavoro in questa direzione nel 2007. Quella base di codice è da qualche parte nell'ordine di un milione di righe di codice ora, metà delle quali è il codice server nascosto dietro un'enorme quantità di servizio web API, l'altra metà è una flottiglia di client, desktop nativo, desktop web, mobile, integrazioni back-end, ecc ... Questa decisione non è stata priva di inconvenienti, ma con il senno di poi 20/20 posso dire che lo farei di nuovo . Consentitemi di indicare alcuni dei compromessi coinvolti.

Benefici

• Flessibilità. Che si tratti di una richiesta per creare un'app mobile per migliorare l'esperienza desktop o di una richiesta di integrazione con il back-end di SAP, tutto diventa più facile quando hai già un'API da chiamare. Quando avrai abbastanza di queste richieste, ti evolverai organicamente verso un'API e l'unica domanda è se ha un servizio web standard davanti o se è un'API interna in cui i servizi web sono fatti su misura.

• Scalabilità (del team). Nel nostro caso abbiamo molti diversi gruppi di sviluppatori che si basano tutti su questa API. Abbiamo persino team API dedicati, che parlano con i diversi gruppi, riassumono le esigenze e ne costruiscono un'API per tutti gli usi. È arrivato al punto in cui non ci viene più nemmeno detto che le persone stanno costruendo cose sull'API e non tutti quelli che lo fanno funzionano per la nostra azienda.

• Sicurezza. Avere una netta divisione tra le parti non sicure e sicure della tua base di codice è utile per ragionare sulla sicurezza. La confusione dell'interfaccia utente e del codice back-end tende a confondere le cose.

Trade-off

• Flessibilità. Devi fare il lavoro per "correttamente" costruire qualcosa nell'API. Non è possibile eseguire rapidamente una query DB dall'interno del codice dell'interfaccia utente per risolvere un problema specifico. Inoltre, le API che sono effettivamente riutilizzabili devono tenere conto di così tanti casi d'uso che la soluzione rapida è di solito la soluzione sbagliata. L'API diventa meno flessibile per evolversi, soprattutto perché esiste già così tanto codice client (per questo motivo stiamo passando a un'API con versione).

• Velocità di sviluppo iniziale. È più lento sviluppare prima l'API, senza dubbio. Lo riconquisti solo quando hai abbastanza client basati sull'API. Ma poi scopri che hai bisogno di 3 diverse implementazioni client prima che l'API si sia evoluta per essere abbastanza generica. Abbiamo scoperto che la maggior parte dei nostri progetti API iniziali erano errati e abbiamo dovuto rivedere fortemente le nostre linee guida su come costruire servizi web.

Aringhe rosse

Ne hai menzionato un sacco. In realtà non contano in pratica.

• Astrazione. L'API diventa abbastanza astratta da coprire tutti i casi d'uso che il tuo prodotto deve servire e non altro. Anche senza i servizi web avrai un'API interna che lo farà, o avrai un sacco di codice duplicato. Preferisco l'astrazione rispetto alla duplicazione.

• Abbandono dello stack MVC sul lato server. Al giorno d'oggi quasi tutti i sistemi avranno bisogno di un'app mobile dopo un po '. Quando quindi crei servizi Web per soddisfare quell'app mobile, dovrai comunque capire come eseguire l'autenticazione e l'autorizzazione in un contesto API. In realtà è meno lavoro quando hai un solo modo di farlo, il modo in cui lo fai nei tuoi servizi web.

• Operazioni in serie. In genere risolto creando un'API di massa che avvia un processo back-end e restituisce un ID processo per la query sullo stato. Non è un grosso problema.

• Debug. Ho scoperto che nel complesso è diventato leggermente più facile risolvere il sistema. Puoi comunque impostare punti di interruzione sia nel codice front-end che in quello back-end, quindi in pratica non è poi così difficile passare in rassegna, e ottieni la capacità di costruire test API automatici e di strumentare l'API per il monitoraggio dei sistemi di produzione.

• Molte operazioni indipendenti. È una questione di come progetti le cose. Se insisti per avere un'API CRUD pura, allora sì, soffrirai di questo problema. Ma avere alcune API CQRS da aumentare è generalmente una buona idea e se ti sei assicurato di avere un'API interna per cui i servizi sono un front-end, puoi facilmente riutilizzare quell'API interna per costruire servizi specifici scenario di.

In sintesi

In un sistema utilizzato in contesti abbastanza diversi, un'API si evolverà naturalmente in quanto è il modo più semplice per soddisfare tutte le esigenze. Ma c'è sicuramente un caso di YAGNI in corso. Ci sono compromessi e non ha senso fino a quando non ha senso. Il punto chiave è non essere dogmatici e mantenere una mentalità aperta verso approcci diversi in architettura per soddisfare le esigenze in evoluzione del prodotto.

Ciò che il tuo collega sta descrivendo è un'architettura orientata ai servizi. Questo può essere un modo incredibilmente scalabile, testabile e sano per codificare, ma dipende davvero da cosa stai facendo.

La SOA offre alcuni vantaggi significativi, che cercherò di enumerare:

scalabilità

Poiché il back-end è disaccoppiato, il front-end diventa solo una serie di modelli, anche flatfile. I file flat sono tremendamente veloci ed economici da servire da qualsiasi CDN. Possono essere minimizzati e precompilati in HTML statico, quindi popolati con client lato dati.

L'API deve rimanere coerente, ma può essere scambiata per una tecnologia più veloce senza rompere lo stack se si supera la tecnologia esistente. Potresti rifarlo in Go per esempio. È possibile ricostruirlo frammentariamente e distribuire il carico tra i server. Finché l'interfaccia rimane la stessa, la tecnologia viene sottratta.

testabilità

MVC di solito inizia pulito, ma in pratica i controller raramente rimangono concentrati su una singola risorsa. Più cose fanno i metodi del tuo controller, meno sono testabili.

Un'API elimina questo problema. Ogni chiamata API estrae una risorsa e la serve. Pulito e testabile.

Separazione garantita delle preoccupazioni

Il tuo front-end e il back-end sono completamente divorziati. Puoi dare il front-end a un altro sviluppatore o un designer. Questo è MVC portato ad un altro livello. Sono sicuro che non vorrai rinunciare a MVC. SOA è MVC ma anche di più.

Svantaggi

Ci sono ovviamente alcuni aspetti negativi. Un monolite è spesso più veloce per andare avanti. Potrebbe essere quello a cui sei abituato. Potrebbe adattarsi meglio al tuo stack. I tuoi strumenti possono essere ottimizzati per la creazione di monoliti.

Nessuna di queste sono ragioni particolarmente buone secondo me, e potresti voler prendere in considerazione il ritocco se si applicano a te.

Ci sono molte buone risposte qui quindi aggiungerò solo la mia esperienza di implementazione.

Questo come faccio le cose:

• Creare un livello di accesso al database che gestisca tutte le interazioni DB / solo (di solito viene utilizzato SQL manuale per velocità e controllo, nessun ORM) . Inserisci, Aggiorna, Elimina, Seleziona ...
• Crea un interface( virtual class) che esponga / imponga le funzioni API di cui ho bisogno. Quando implementati, useranno le funzioni DBAL altamente specializzate per ottenere i risultati. Mi aiuta anche a imporre l'API a livello di compilatore, quindi mi assicuro che l'implementazione Server + API abbia tutte le funzioni integrate.
• Crea un secondo livello che implementa l'interfaccia (questa è l'API effettiva) e applica restrizioni di sicurezza. Qui interagisci anche con API esterne.
• Il sito Web utilizzerà direttamente il secondo livello (per le prestazioni) senza utilizzare un'API accessibile in remoto (come SOAP, JSON) .
• Viene creato un server autonomo che implementa l'interfaccia ed espone il secondo livello come una vera API accessibile da remoto a client desktop / mobili esterni (accesso non al sito Web) . Tutto ciò che fa è decodificare le richieste, codificare le risposte e gestire / disconnettere i client. Supporta inoltre le funzionalità di pushback per notificare in massa ai clienti gli eventi generati da altri peer connessi (funzionalità che un sito Web non richiede in genere) .

Quindi, tecnicamente, l'API è il secondo livello. Lo usi direttamente con il sito Web e lo esponi a client remoti attraverso un server. Il codice viene riutilizzato e nessuna parte di codice riutilizzabile è mai in linea. (Vivi e muori secondo questa regola e tutto è fantastico) Aiuta con manutenibilità, test ... tutto.

Non connetti mai il sito Web al server API desktop / mobile (a meno che il tuo sito non sia AJAX e funzioni su JSON) . Ma se il sito esegue il rendering di contenuti dinamici nel markup, passare attraverso un'API intermedia farà scattare le tue prestazioni. Il sito web deve essere veloce! L'accesso client remoto può essere leggermente più lento.

PS : Sì, la manutenzione è un po 'più complessa poiché più ruote lavorano insieme ma è più facile a lungo termine. Quindi, se il tuo progetto è destinato a vivere per un po 'ed è leggermente complesso, hai sempre un'API. È anche molto più semplice testare ogni livello da solo.

Il punto di contesa non è se si dovrebbe usare un'API, ma che cos'è effettivamente un'API. L'unica alternativa all'utilizzo di un'API progettata è utilizzare un'API che è un disordine casuale di codice. Scrivi che un'API rende le cose "troppo flessibili" che a loro volta le rendono ingestibili. Ciò indica un malinteso completo e completo su cosa sia un'API. Se quell'incomprensione non è condivisa tra te e il tuo collega, allora hai perso molto tempo discutendo su cose completamente diverse.

Non usando un'API ben definita puoi fare quello che vuoi. Per definizione questa è l'opzione più flessibile. Inoltre, per definizione "fare quello che vuoi" è ancora un'API. L' unico lavoro di un'API è rimuovere la flessibilità. Rimuovendo la flessibilità, una buona API incoraggia un utente a fare cose simili in modi simili.

Ovviamente un'API errata può fornire troppa o troppa poca flessibilità, o anche entrambe allo stesso tempo. Un'API davvero mal progettata può uccidere un progetto ancora più velocemente dell'approccio "tutto va bene". Tuttavia, la migliore pratica è semplicemente quella di avere programmatori competenti che sviluppano ed evolvono l'API insieme all'applicazione.

Esempio

• Molte operazioni indipendenti che richiederanno molto avanti e indietro, ad esempio alcuni codici potrebbero ottenere l'utente corrente, verificare che l'utente abbia il ruolo di amministratore, ottenere la società a cui appartiene l'utente, ottenere un elenco di altri membri, inviarli tutta una mail. Ciò richiederebbe molte chiamate API o la scrittura di un metodo su misura dell'attività specifica desiderata, in cui l'unico vantaggio di tale metodo su misura sarebbe la velocità, ma il rovescio della medaglia sarebbe che sarebbe inflessibile.

Il numero di chiamate API che ciò richiederebbe su un'API decente sarebbe probabilmente 1. Sì, non è flessibile, ma perché vorresti che fosse flessibile?

Ha detto che il nostro codice era troppo stretto. Ad esempio, se volessimo anche un'applicazione desktop, non saremmo in grado di utilizzare il nostro codice esistente.

Bene, vero? Altrimenti, questa è un'affermazione piuttosto irrilevante.

Direi che se avessi creato una nuova applicazione nel 2015, allora esamineresti seriamente qualcosa con un'interfaccia utente che coinvolge un'API e non pagine HTML generate dal server. Ci sono costi chiari ma anche chiari benefici.

Ma se hai un sito esistente senza piani concreti per avere diverse interfacce (per quanto posso dire), i suoi commenti sono semplicemente irrilevanti.

Versione abbreviata: il controller in effetti è un'API, indipendentemente da cosa; sebbene ASP.NET possa oscurarlo.

Versione più lunga:

Pensa a un'app Web MVC di base che fornisce informazioni sulla birra e facoltativamente te ne vende una. Che aspetto hanno i percorsi?

/sign_in
/sign_out
/beer
/beer/{beer_name}
/order
/order/{order_number}

In una normale app Web, ci sono probabilmente alcuni percorsi ausiliari come:

/beer/new
/beer/{beer_name}/edit
/beer/{beer_name}/delete
/order/new
/order/{order_number}/edit
/order/{order_number}/delete

In un'API Web questi non sono richiesti, in quanto dedotti dal metodo HTTP.

Data la simmetria di cui sopra, penso che questo rappresenti un caso abbastanza convincente che l'API e il controller siano così vicini che potrebbero anche essere la stessa cosa.

Dopo aver fatto qualche ricerca, ho deciso che questo potrebbe essere lo stato delle cose per te a seconda della versione di ASP.NET che stai utilizzando. Il vecchio MVC 5 e precedenti mancano delle convenzioni e dell'interfaccia per unificare in modo armonioso le due implementazioni. Nelle versioni precedenti, i ritorni delle app Web popolano una vista mentre l'API fornisce una risposta http. In entrambi i casi, però, stanno generando la stessa risposta semanticamente.

Se stai utilizzando MVC 6, ottieni entrambi in una classe di controller unificata che può essere intelligente su ciò che restituisce. Non ho trovato alcun buon codice di esempio ASP per questo modello, ma ho trovato del codice Rails con lo stesso modello. Considera questo controller per "Mi piace" dal progetto Diaspora . Ogni metodo controllore ha percorsi definiti da una "convenzione di risorse" qui tale importo la LCRUD in un'API.

Se leggi le implementazioni, tuttavia, ognuna può eventualmente rispondere a HTML, Mobile HTML o JSON. Questo, combinato con una convenzione per trovare le viste, unifica completamente l'app Web e l'API Web. Noterai anche che non tutti i metodi in realtà forniscono ogni risposta (il che ha senso, poiché l'interfaccia utente potrebbe richiedere metodi che l'API non intende e viceversa).

Si tratta di una discrepanza di impedenza perché ASP.NET ha capito tutto in ritardo, mentre Rails ha abbracciato la simmetria per un po 'di tempo e lo rende molto chiaro.

Speculazione:

Il tuo collega probabilmente ha ragione e torto, a seconda della versione di ASP che stai utilizzando. Nella versione precedente di MVC, la differenza tra API e App probabilmente rendeva una "best practice" la creazione anticipata dell'API perché il modello ASP.NET non permetteva davvero un buon riutilizzo del codice lì.

Con quello più recente, ha più senso utilizzare il codice unificato perché è stato semplificato il riutilizzo del codice con la classe base del controller unificato.

In entrambi i casi, tuttavia, il controller è effettivamente l'API.

Quando ho iniziato la mia carriera nel 2006, questo tipo di architettura era di gran moda nel mondo .NET. Ho lavorato su 3 progetti separati concepiti a metà degli anni 2000 con un servizio web tra il livello di logica aziendale e il frontend web. Ovviamente in questi giorni i servizi web erano SOAP ma ha sempre la stessa architettura. I presunti benefici erano la possibilità di passare da front-end a back-end e persino di sviluppare un programma desktop. Alla fine YAGNI si è rivelato vero. Non ho mai visto accadere nulla di tutto ciò. Per tutto questo tempo ho visto solo il costo della divisione del progetto in questo modo. Ho anche finito per strappare il servizio web da uno dei progetti (ci sono voluti sei mesi per rimuoverlo passo dopo passo mentre facevo altre cose) e tutto il team è stato felice. Da allora non ho mai provato questo approccio e non lo farò se non per una ragione ben precisa. 5 anni di esperienza nel provare questa architettura mi hanno insegnato che non ne avrò bisogno e nessun numero di esperti che mi dicono il contrario mi convincerà che lo farò. Solo un progetto in cui ne ho bisogno può farlo.

Detto questo, mi impegno a sviluppare un livello tra la logica aziendale e i controller / presentatori. Ad esempio, ho un livello di servizio, non espongo mai query, utilizzo interfacce per tutti i miei servizi e le inserisco nei controller con IoC. Se avrò mai bisogno di un servizio web nella mia architettura, sarò in grado di introdurlo a un costo ragionevole. Non voglio solo pagare questo costo in anticipo.

Inoltre mi piace l'idea dei microservizi, ma la mia comprensione è che microservizi significa moduli verticali anziché livelli orizzontali. Ad esempio, se stai costruendo Facebook, la funzione di chat sarà un servizio separato distribuito separatamente sui propri server, ecc. Questo è il tipo di servizi indipendenti che incoraggerei.

Terze parti lo useranno? Sì, dovresti .

Hai intenzione di riutilizzarlo in un futuro non così lontano? Si, dovresti.
Sarai la tua terza parte , con un'API documentata - o documentabile - o utilizzabile da terze parti che ti fornirà una solida riusabilità e modularità.

Sei di fretta? No non dovresti.
Il refactoring in seguito è più facile e veloce di quanto la maggior parte delle metodologie e gli insegnanti prevedono e raccontino. È più importante avere qualcosa che funzioni (anche con un cattivo design interno, come può e sarà riformulato) piuttosto che non avere nulla. (ma con un design interno incredibile , wohoo)

Il front-end potrebbe non vedere mai la luce del giorno a causa di motivi? Sì, dovresti .
Ho aggiunto questo motivo perché, beh, mi è successo molto.
E almeno mi rimangono i miei componenti per riutilizzarli, ridistribuirli ecc.

Ci sono buone risposte qui. Lo inserisco come una risposta parziale; forse sarebbe meglio come commento. Tuttavia, non è buono applicare lo stesso commento su numerosi post.

Non si può affermare che YAGNI sia un motivo per non creare un'API.

L'API è un endpoint di test naturale e logico. Quindi, sin dal giorno 0, ci sono due applicazioni che usano l'API: l'interfaccia utente e la suite di test. Uno è pensato per l'uomo, l'altro è pensato per le macchine. Sono necessariamente diversi. Il test del comportamento front-end è un'attività molto diversa rispetto al test del comportamento back-end. Quindi le tecniche, e probabilmente gli strumenti, sono completamente diverse. L'API consente di utilizzare lo strumento migliore per il lavoro. Inoltre, con la separazione offerta dall'API, i tester front-end non devono testare la funzionalità back-end.

L'API aiuta anche a mantenere i programmatori front-end fuori dalle preoccupazioni del programmatore back-end e viceversa. Queste sono competenze molto diverse nella nostra azienda; l'API ci consente di concentrarci dove siamo più forti.