it-swarm.com.de

Sollten Sie Ihr Backend als API schreiben?

Ich hatte heute eine hitzige Diskussion über unsere MVC-Anwendung. Wir haben eine Website in MVC geschrieben ( ASP.NET ), und sie folgt normalerweise dem Muster, etwas in der Ansicht zu tun -> den Controller zu treffen -> Controller erstellt ein Modell (ruft einen Manager auf, der das erhält Daten, erstellt das Modell in der Controller-Methode selbst) -> Modell wird angezeigt -> spülen und wiederholen.

Er sagte, unser Code sei zu eng gekoppelt. Wenn wir beispielsweise auch eine Desktop-Anwendung wünschen, können wir unseren vorhandenen Code nicht verwenden.

Die Lösung und bewährte Methode, die er sagte, besteht darin, eine API zu erstellen und dann Ihre Website über Ihrer API zu erstellen. Anschließend ist es sehr einfach, eine Desktop-Anwendung, eine mobile App usw. zu erstellen.

Dies scheint mir aus verschiedenen Gründen eine schlechte Idee zu sein.

Jedenfalls kann ich durch Googeln anscheinend nichts finden, was diese Praxis diskutieren könnte. Hat jemand Informationen über Vor- und Nachteile, warum Sie sollten, warum Sie nicht sollten oder weiterlesen?

Einige Gründe, die ich für eine schlechte Idee halte:

  • Es ist viel zu abstrakt, um Ihr Backend über eine API auszuführen. Sie versuchen, es zu flexibel zu machen, was es zu einem unüberschaubaren Durcheinander macht.

  • Alle in MVC integrierten Funktionen wie Rollen und Authentifizierung scheinen nutzlos zu sein. Zum Beispiel [Autorisieren] Attribute und Sicherheit; Sie müssen Ihre eigenen rollen.

  • Für alle Ihre API-Aufrufe sind Sicherheitsinformationen erforderlich, und Sie müssen ein Tokensystem entwickeln und so weiter.

  • Sie müssen vollständige API-Aufrufe für jede einzelne Funktion schreiben, die Ihr Programm jemals ausführen wird. Nahezu jede Methode, die Sie implementieren möchten, muss über eine API ausgeführt werden. Ein Abrufen/Aktualisieren/Löschen für jeden Benutzer sowie eine Variante für jeden anderen Vorgang, z. B. Aktualisieren des Benutzernamens, Hinzufügen eines Benutzers zu einer Gruppe usw. usw., und jeder wäre ein eigener API-Aufruf.

  • Sie verlieren alle Arten von Tools wie Schnittstellen und abstrakte Klassen, wenn es um APIs geht. Sachen wie WCF haben eine sehr schwache Unterstützung für Schnittstellen.

  • Sie haben eine Methode, die einen Benutzer erstellt oder eine Aufgabe ausführt. Wenn Sie 50 Benutzer erstellen möchten, können Sie es einfach 50 Mal aufrufen. Wenn Sie sich für diese Methode als API entscheiden, kann Ihr lokaler Webserver eine Named-Pipes-Verbindung herstellen, und dies ist kein Problem. Ihr Desktop-Client kann sie auch ausführen. Bei der Erstellung von Massenbenutzern wird die API jedoch plötzlich 50 Mal über das Internet gehämmert, was nicht der Fall ist ist nicht gut Sie müssen also eine Massenmethode erstellen, aber eigentlich erstellen Sie sie nur für Desktop-Clients. Auf diese Weise müssen Sie am Ende a) Ihre API basierend auf der Integration ändern, und Sie können nicht einfach direkt in sie integrieren, b) viel mehr Arbeit leisten, um eine zusätzliche Funktion zu erstellen.

  • YAGNI . Wenn Sie nicht speziell planen, zwei identisch funktionierende Anwendungen zu schreiben, beispielsweise eine Web- und eine Windows-Anwendung, ist dies eine enorme zusätzliche Entwicklungsarbeit.

  • Das Debuggen ist viel schwieriger, wenn Sie nicht durch Ende-zu-Ende gehen können.

  • Viele unabhängige Vorgänge, die viel Hin und Her erfordern, z. B. Code kann den aktuellen Benutzer abrufen, überprüfen, ob der Benutzer die Administratorrolle innehat, das Unternehmen ermitteln, zu dem der Benutzer gehört, eine Liste anderer Mitglieder abrufen und alle senden eine E-Mail. Dies würde viele API-Aufrufe erfordern oder das Schreiben einer maßgeschneiderten Methode für die gewünschte Aufgabe, wobei der einzige Vorteil dieser maßgeschneiderten Methode die Geschwindigkeit wäre, der Nachteil jedoch wäre, dass sie unflexibel wäre.

  • Wahrscheinlich noch ein paar weitere Gründe, warum mir das nicht so klar ist.

Es scheint mir nur so, als ob es sich wirklich nicht lohnt, wenn Sie nicht wirklich zwei identische Anwendungen benötigen. Ich habe noch nie eine ASP.NET-Anwendung gesehen, die so erstellt wurde. Sie müssten zwei separate Anwendungen (die API und Ihren Code) schreiben und beide Versionskontrollen durchführen (wenn Ihre Benutzerseite ein neues Feld erhält, müssen Sie) d müssen die API und Ihren konsumierenden Code gleichzeitig aktualisieren, um keine negativen Auswirkungen zu gewährleisten, oder viel zusätzliche Arbeit in die Robustheit investieren).


Bearbeiten: Einige großartige Antworten, die wirklich eine gute Vorstellung davon bekommen, was dies alles jetzt bedeutet. Um meine Frage zu erweitern, wie würden Sie eine MVC-App strukturieren, um dieser API-Struktur zu folgen?

Sie haben beispielsweise eine Website, auf der Informationen zu einem Benutzer angezeigt werden. Unter MVC haben Sie:

View - (CS) HTML-Seite, auf der ein UserViewModel-Controller angezeigt wird - Ruft GetUser () auf und erstellt ein UserViewModel, das an die View Manager-Klasse (Art Ihrer API) mit einer GetUser-Methode übergeben wird.

Der Controller führt GetUser () aus, aber Sie möchten auch eine Desktop-App. Dies bedeutet, dass Ihr GetUser über eine Art API verfügbar gemacht werden muss. Möglicherweise möchten Sie eine TCP -Verbindung, entweder WCF oder Remoting. Sie möchten auch eine mobile App, die REST-fähig ist, da dauerhafte Verbindungen unzuverlässig sind.

Würden Sie dann für jeden eine API schreiben, einen WCF-Webdienst mit einer Methode GetUser () und dem Code, der nur return new UserManager().GetUser() ausführt? Und eine MVC 4 Web-API-Methode, die das Gleiche tut? Rufen Sie GetUser weiterhin direkt in Ihrer MVC-Controller-Methode auf?

Oder würden Sie die Lösung wählen, die für alle drei funktioniert (Web-API REST Service) und alles darauf aufbauen, damit alle drei Apps API-Aufrufe (die MVC-Apps) an den lokalen Computer senden? .

Und ist das nur ein theoretisch perfektes Szenario? Ich sehe große Gemeinkosten bei der Entwicklung auf diese Weise, insbesondere wenn Sie sich so entwickeln müssen, dass Sie Operationen auf eine REST-artige Weise ausführen können. Ich denke, einiges davon wurde in den Antworten behandelt.


Bearbeiten 2: Nachdem ich mehr gelesen habe, habe ich unten einen Kommentar eingefügt, der meiner Meinung nach dies erklären könnte. Die Frage ist meiner Meinung nach eine Trickfrage. Wenn Sie Ihr Back-End als API schreiben, war ich verwirrt darüber, dass es einen einzigen Webservice geben sollte, den alles (MVC-App, Desktop-App, mobile App) aufruft, um Dinge zu erledigen.

Ich bin zu dem Schluss gekommen, dass Sie wirklich sicherstellen sollten, dass Ihre Geschäftslogikschicht korrekt entkoppelt ist. Wenn ich meinen Code betrachte, mache ich das bereits - der Controller ruft GetUser() auf einem Manager auf und erstellt daraus ein Ansichtsmodell, um es mit einer Ansicht zu rendern. Die Geschäftslogikschicht ist also eine API. Wenn Sie es jedoch von einer Desktop-App aus aufrufen möchten, müssen Sie so etwas wie einen WCF-Dienst schreiben, um das Aufrufen zu erleichtern. Selbst eine WCF-Methode namens GetUser(), die den Code return MyBusinessLayer.GetUser() enthält, würde ausreichen. Die API ist also die Geschäftslogik, und WCF/Web-API usw. sind nur Leckerbissen von Code, damit externe Anwendungen sie aufrufen können.

Der Aufwand besteht also darin, dass Sie Ihre Geschäftslogikschicht je nach Bedarf in verschiedene APIs einbinden müssen und für jeden Vorgang, den Ihre anderen Apps ausführen sollen, eine API-Methode schreiben müssen Suchen Sie nach einer Möglichkeit zur Authentifizierung, die jedoch größtenteils gleich ist. Stecken Sie Ihre Geschäftslogik in ein separates Projekt (Klassenbibliothek), und Sie werden wahrscheinlich kein Problem haben!

Hoffentlich ist diese Interpretation richtig. Vielen Dank für alle Diskussionen/Kommentare, die es generiert hat.

330
NibblyPig

Ja du solltest.

Es macht Ihr Backend nicht nur wiederverwendbar, sondern ermöglicht auch mehr Sicherheit und besseres Design. Wenn Sie Ihr Backend als Teil eines einzelnen Systems schreiben, erstellen Sie ein monolithisches Design, das nie einfach zu erweitern, zu ersetzen oder zu verbessern ist.

Ein Bereich, in dem dies derzeit beliebt ist, ist Microservices . Wo das Backend in viele kleine (oder sogar große) Dienste aufgeteilt ist, die jeweils eine API bereitstellen, die das Client-System verwendet. Wenn Sie sich vorstellen, viele Datenquellen von Drittanbietern in Ihrer Anwendung zu verwenden, stellen Sie fest, dass Sie dies möglicherweise bereits tun.

Ein weiterer Vorteil besteht darin, dass der Aufbau und die Wartung jedes Dienstes an ein anderes Team übergeben werden können. Es können Funktionen hinzugefügt werden, die sich nicht auf ein anderes Team auswirken, das Produkte herstellt. Erst wenn sie fertig sind und ihren Service freigeben, fügen sie Ihrem Produkt Funktionen hinzu, um sie zu nutzen. Dies kann die Entwicklung viel reibungsloser gestalten (obwohl dies insgesamt möglicherweise langsamer ist, erhalten Sie tendenziell eine bessere Qualität und sind verständlich).


Bearbeiten: OK Ich sehe Ihr Problem. Sie stellen sich die API als Remote-Bibliothek vor. Es ist nicht. Stellen Sie sich den Dienst eher als einen Datenbereitstellungsdienst vor. Sie rufen den Dienst auf, um Daten abzurufen, und führen dann lokal Vorgänge für diese Daten aus. Um festzustellen, ob ein Benutzer angemeldet ist, rufen Sie "GetUser" auf und sehen sich dann 'logged on' Wert zum Beispiel. ( YMMV mit diesem Beispiel natürlich).

Ihr Beispiel für die Erstellung von Massenbenutzern sind nur Ausreden - hier gibt es keinen Unterschied, was auch immer Sie in einem monolithischen System hätten tun können, kann immer noch in einer Dienstarchitektur getan werden (z. B. hätten Sie eine Reihe von Benutzern an Massenerstellung übergeben, oder Sie können immer noch genau das Gleiche mit Diensten tun.

MVC basiert bereits auf dem Konzept der isolierten Dienste, nur die MVC-Frameworks bündeln sie in einem einzigen Projekt. Das bedeutet nicht, dass Sie etwas verlieren, außer den gebündelten Helfern, die Ihnen Ihr Framework bietet. Verwenden Sie ein anderes Framework und Sie müssen verschiedene Helfer verwenden. Oder rollen Sie in diesem Fall Ihre eigenen (oder fügen Sie sie direkt über eine Bibliothek hinzu).

Das Debuggen ist ebenfalls einfach - Sie können die API gründlich isoliert testen, sodass Sie kein Debuggen durchführen müssen (und Sie können das End-to-End-Debuggen durchführen, Visual Studio kann mehrere Prozesse gleichzeitig verbinden).

Dinge wie zusätzliche Arbeit bei der Implementierung von Sicherheit sind eine gute Sache. Wenn Sie den gesamten Code in Ihre Website bündeln und ein Hacker Zugriff darauf erhält, erhält er derzeit auch Zugriff auf alles, einschließlich DB. Wenn Sie es in eine API aufteilen, kann der Hacker nur sehr wenig mit Ihrem Code tun, es sei denn, er hackt auch die API-Ebene - was für ihn unglaublich schwierig sein wird (haben Sie sich jemals gefragt, wie Angreifer umfangreiche Listen aller Benutzer oder CC-Details der Website erhalten? Sie haben das Betriebssystem oder den Webserver gehackt und es hatte eine direkte Verbindung zur Datenbank, auf der sie "select * from users" mit Leichtigkeit).

Ich werde sagen, dass ich viele Websites (und Client-Server-Anwendungen) gesehen habe, die so geschrieben wurden. Wenn ich in der Finanzdienstleistungsbranche gearbeitet habe, hat niemand jemals eine All-in-One-Website geschrieben, teils weil dies ein zu großes Sicherheitsrisiko darstellt, teils weil viel Entwicklung ziemlich GUIs über stabile (dh ältere) Back-End-Datenverarbeitung sind Systeme. Es ist einfach, das DP-System mithilfe einer Service-Architektur als Website verfügbar zu machen.

2. Bearbeitung: Einige Links zum Thema (für das OP):

Beachten Sie, dass der Webserver, wenn im Kontext einer Website über diese gesprochen wird, als Präsentationsschicht betrachtet werden sollte, da der Client die anderen Ebenen aufruft und auch die UI-Ansichten erstellt, die zum Rendern an den Browser gesendet werden. Es ist ein großes Thema, und es gibt viele Möglichkeiten, Ihre Anwendung zu entwerfen - datenzentriert oder domänenzentriert (ich halte domänenzentriert normalerweise für "reiner", aber YMMV ), aber es kommt darauf an, eine logische Ebene zwischen Ihrem Client und Ihrer Datenbank zu platzieren. Es ist ein bisschen wie MVC, wenn Sie die mittlere, API- und Tier-Ebene als gleichwertig mit Ihrem Modell betrachten. Nur das Modell ist kein einfacher Wrapper für die Datenbank, es ist umfangreicher und kann viel mehr (z. B. aggregierte Daten aus 2 Datenquellen, Post -Verarbeiten Sie die Daten so, dass sie in die API passen, zwischenspeichern Sie die Daten usw.):

286
gbjbaanb

Sie können das Erstellen einer API unmöglich vermeiden. Selbst wenn Sie "nur eine Website" erstellen, müssen die Daten irgendwie aus Ihrem Backend abgerufen werden. Wie auch immer Sie sich dafür entscheiden, das ist Ihre de facto API.

In diesem Wissen ist die eigentliche Frage nicht, ob eine API erstellt werden soll, sondern wie sie erstellt werden soll . Sie können dies im laufenden Betrieb als ad hoc Sache tun - und tatsächlich werden viele Websites genau auf diese Weise erstellt - oder Sie können es sorgfältig so gestalten, dass es in anderen Kontexten verwendet werden kann. In diesem Zusammenhang wird ziemlich deutlich, dass Ihr Kollege Recht hat: Sie sollten zuerst die API ausführen und dann Ihre Site darauf aufbauen.

Dies bringt jedoch einige Bedenken mit sich, wie Sie hervorheben. Um sie anzusprechen:

Es ist viel zu abstrakt, um Ihr Backend über eine API auszuführen. Sie versuchen, es zu flexibel zu machen, was es zu einem unüberschaubaren Durcheinander macht.

Das hängt davon ab, wie Sie es tun. Wie George Pólya in seinem ausgezeichneten Text hervorhebt Wie man es löst , oft "das allgemeinere Problem kann leichter zu lösen sein". Dies nennt man das Paradox des Erfinders. Bei der Programmierung funktioniert dies häufig durch Trennung von Bedenken: Ihr Backend muss sich nicht mehr mit dem Format der Daten befassen, die es ein- und ausgibt, und daher kann sein Code viel einfacher sein. Ihre Datenparser und Renderer müssen sich nicht mehr darum kümmern, was mit den von ihnen erstellten Daten geschieht, sodass auch sie einfacher sein können. Es funktioniert alles, indem der Code in besser verwaltbare Teile zerlegt wird.

Alle in MVC integrierten Funktionen wie Rollen und Authentifizierung scheinen nutzlos zu sein. Zum Beispiel [Autorisieren] Attribute und Sicherheit; Sie müssen Ihre eigenen rollen.

Ich gebe zu, dass es mir äußerst schwer fällt, mit Menschen zu sympathisieren, die sich weigern, ihre Werkzeuge zu lernen. Nur weil Sie ihre Verwendung nicht verstehen, bedeutet dies nicht, dass sie nutzlos sind, und es bedeutet sicherlich nicht, dass Sie Ihre eigenen rollen sollten . Ganz im Gegenteil; Sie sollten nicht Ihre eigenen Tools rollen bis Sie verstehen die Alternativen, damit Sie sicher sein können, die gleichen Probleme zu lösen, die sie haben (auch wenn nur auf Ihre eigene Weise).

Betrachten Sie Linus Torvalds , der am bekanntesten für das Schreiben von Linux ist, aber auch git : jetzt eines der beliebtesten Versionskontrollsysteme in die Welt. Einer der treibenden Faktoren in seinem Design war eine tiefe Opposition gegen Subversion (ein weiteres äußerst beliebtes VCS und wohl das beliebteste bei die Zeit git wurde geschrieben); er beschloss, alles zu nehmen, was Subversion konnte, und soweit es möglich war, diese Probleme anders zu lösen. Dazu musste er selbst Experte für Subversion werden , damit er die gleichen Problembereiche verstehen und einen anderen Ansatz verfolgen konnte.

Während Sie Ihre Tools erlernen, stellen Sie möglicherweise fest, dass sie unverändert nützlich sind und nicht ersetzt werden müssen.

Für alle Ihre API-Aufrufe sind Sicherheitsinformationen erforderlich, und Sie müssen ein Tokensystem entwickeln und so weiter.

Ja. So sollte es sein.

Sie müssen vollständige API-Aufrufe für jede einzelne Funktion schreiben, die Ihr Programm jemals ausführen wird. Nahezu jede Methode, die Sie implementieren möchten, muss über eine API ausgeführt werden. Ein Abrufen/Aktualisieren/Löschen für jeden Benutzer sowie eine Variante für jeden anderen Vorgang, z. B. Aktualisieren des Benutzernamens, Hinzufügen eines Benutzers zu einer Gruppe usw. usw., und jeder wäre ein eigener API-Aufruf.

Nicht unbedingt. Hier kommen Architekturen wie REST ins Spiel. Sie identifizieren die Ressourcen, mit denen Ihre Anwendung arbeitet, und die Vorgänge, die für diese Ressourcen sinnvoll sind, und implementieren diese dann, ohne sich um die anderen zu kümmern .

Sie verlieren alle Arten von Tools wie Schnittstellen und abstrakte Klassen, wenn es um APIs geht. Sachen wie WCF haben eine sehr schwache Unterstützung für Schnittstellen.

Im Gegenteil, Schnittstellen werden viel wichtiger, wenn Sie eine API verwenden, nicht weniger . Sie kommen in den Darstellungen heraus, in die Sie sie rendern. Die meisten Leute geben heutzutage ein JSON - basiertes Format dafür an, aber Sie können jedes gewünschte Format verwenden, solange Sie es gut spezifizieren. Sie rendern die Ausgabe Ihrer Aufrufe im Backend in dieses Format und analysieren sie im Frontend in das, was Sie möchten (wahrscheinlich dieselbe Art von Objekt). Der Overhead ist gering und der Gewinn an Flexibilität ist enorm.

Sie haben eine Methode, die einen Benutzer erstellt oder eine Aufgabe ausführt. Wenn Sie 50 Benutzer erstellen möchten, können Sie es einfach 50 Mal aufrufen. Wenn Sie sich für diese Methode als API entscheiden, kann Ihr lokaler Webserver eine Named-Pipes-Verbindung herstellen, und dies ist kein Problem. Ihr Desktop-Client kann sie auch ausführen. Bei der Erstellung von Massenbenutzern wird die API jedoch plötzlich 50 Mal über das Internet gehämmert, was nicht der Fall ist ist nicht gut Sie müssen also eine Massenmethode erstellen, aber eigentlich erstellen Sie sie nur für Desktop-Clients. Auf diese Weise müssen Sie am Ende a) Ihre API basierend auf der Integration ändern, und Sie können nicht einfach direkt in sie integrieren, b) viel mehr Arbeit leisten, um eine zusätzliche Funktion zu erstellen.

Das Erstellen einer Massenversion einer vorhandenen Methode würde ich kaum als "viel mehr Arbeit" bezeichnen. Wenn Sie sich nicht um Dinge wie Atomizität sorgen, kann die Bulk-Methode nicht viel mehr als ein sehr dünnes Frontend für das Original sein.

YAGNI . Wenn Sie nicht speziell planen, zwei identisch funktionierende Anwendungen zu schreiben, beispielsweise eine Web- und eine Windows-Anwendung, ist dies eine enorme zusätzliche Entwicklungsarbeit.

Nein, YANI (du brauchst es schon). Ich habe das wie oben beschrieben. Die Frage ist nur, wie viel Designarbeit darin steckt.

Das Debuggen ist viel schwieriger, wenn Sie nicht durch Ende-zu-Ende gehen können.

Warum könnten Sie nicht durch Ende-zu-Ende gehen?

Um es auf den Punkt zu bringen: Wenn Sie in der Lage sind, die Daten in einem leicht erkennbaren Format zu untersuchen, das die gesamte Anzeige-Cruft ausschneidet, wird das Debuggen einfacher, nicht schwieriger.

Viele unabhängige Vorgänge, die viel Hin und Her erfordern, z. B. Code kann den aktuellen Benutzer abrufen, überprüfen, ob der Benutzer die Administratorrolle innehat, das Unternehmen ermitteln, zu dem der Benutzer gehört, eine Liste anderer Mitglieder abrufen und alle senden eine E-Mail. Dies würde viele API-Aufrufe erfordern oder das Schreiben einer maßgeschneiderten Methode für die gewünschte Aufgabe, wobei der einzige Vorteil dieser maßgeschneiderten Methode die Geschwindigkeit wäre, der Nachteil jedoch wäre, dass sie unflexibel wäre.

REST löst dieses Problem, indem an vollständigen Objekten ( Ressourcen gearbeitet wird, um REST Theoriebegriffe) und nicht die einzelnen Eigenschaften von Objekten . Um den Namen eines Benutzers zu aktualisieren, rufen Sie das Benutzerobjekt ab, ändern seinen Namen und setzen den Benutzer zurück. Sie können andere Änderungen gleichzeitig mit der Änderung des Benutzernamens vornehmen. Das allgemeinere Problem lässt sich leichter lösen, da Sie alle diese einzelnen Aufrufe zum Aktualisieren einzelner Eigenschaften eines Objekts eliminieren können: Sie laden es einfach und speichern es.

In mancher Hinsicht ist dies nicht anders als RISC Architekturen auf der Hardwareseite. Einer der Hauptunterschiede zwischen RISC und CISC (seinem Vorgänger) besteht darin, dass CISC-Architekturen in der Regel viele Anweisungen enthalten, die direkt im Speicher ausgeführt werden, während RISC-Architekturen dazu neigen arbeiten hauptsächlich in Registern: In einer reinen RISC-Architektur sind die einzigen Operationen im Speicher LOAD (etwas aus dem Speicher in ein Register kopieren) und STORE (einen Wert aus einem Register nehmen und in den Speicher ablegen).

Sie würden denken, dass dies bedeuten würde, viel mehr Fahrten von den Registern in den Speicher zu unternehmen, was die Maschine verlangsamen würde. In der Praxis passiert jedoch häufig das Gegenteil: Der Prozessor (Client) erledigt mehr Arbeit zwischen Speicherauslösungen (Server) , und hier kommt die Beschleunigung von.

Lange Rede, kurzer Sinn: Ihr Kollege hat recht. Dies ist der richtige Weg. Im Gegenzug für ein wenig Vorarbeit wird der Code für Ihre Website erheblich vereinfacht und eine bessere Integration mit anderen Websites und Apps ermöglichen. Das ist einen Preis wert.

Weiterführende Literatur:

  1. REST API Design - Ressourcenmodellierung
91
The Spooniest

Ich weiß, dass Microservices momentan der letzte Schrei sind, aber sie sind es nicht immer wert. Ja, lose gekoppelter Code ist das Ziel. Dies sollte jedoch nicht auf Kosten eines schmerzhafteren Entwicklungszyklus gehen.

Ein guter Mittelweg wäre, ein separates Datenprojekt in Ihrer Lösung zu erstellen. Das Datenprojekt wäre eine .NET-Klassenbibliothek. Ihr ASP.NET MVC-Projekt würde dann einen Verweis auf die Datenbibliothek hinzufügen, und alle Modelle würden aus dem Datenprojekt abgerufen. Wenn dann die Zeit gekommen ist, eine Desktop- oder mobile App zu erstellen, können Sie auf denselben Code verweisen. Es ist also möglicherweise keine offizielle API, aber es wird als eine funktionieren. Wenn Sie es als API zugänglich machen möchten, können Sie ein einfaches Webprojekt erstellen, das als Wrapper für das Datenprojekt fungiert.

Microsoft hat dieses Konzept beworben, das sie Portable Class Libraries nennen.

63
fotijr

Nein, solltest du nicht. Wenn Sie nicht sofort planen, alternative Frontends (wie mobile oder Desktop-Apps oder separate Webanwendungen) zu erstellen, die auf dasselbe Backend zugreifen, sollten Sie keine Webdienstschicht einführen. YAGNI .

Eine lose Kopplung ist immer wünschenswert (zusammen mit einer hohen Kohäsion), aber sie ist ein Konstruktionsprinzip und bedeutet nicht, dass Sie Objekte auf verschiedenen Servern physisch trennen müssen! Und eine schlecht gestaltete Service-API kann eine enge Kopplung über Servergrenzen hinweg erzeugen, sodass eine API keine lose Kopplung garantiert.

Wenn in Zukunft eine Service-API erforderlich sein sollte, können Sie diese jederzeit an dieser Stelle einführen. Solange Sie Ihren Code gut geschichtet halten (Datenzugriff und Geschäftslogik sauber von der UI-Logik getrennt), wird es nicht schwieriger sein, ihn später als jetzt einzuführen. Das resultierende Design ist viel besser, wenn es den tatsächlichen Anforderungen entspricht.


Hinweis Ich gehe davon aus, dass die Frage lautet, ob Sie eine Webdienst-API erstellen sollen oder nicht. Die Frage lautet nur API, aber API kann auch nur die Schnittstelle einer Bibliothek bedeuten, und dann hat natürlich jede Ebene per Definition eine API. Unter dem Strich sollten Ihre Geschäftslogik- und Datenzugriffsschichten auf Entwurfsebene sauber von der UI-Logik getrennt sein. Sie sollten jedoch keine Webdienstschicht einführen, wenn Sie diese nicht benötigen.

34
JacquesB

Mein Unternehmen hat eine solche Anwendung erstellt. Zunächst wurden wir beauftragt, ein Back-End mit API für ein Front-End zu erstellen, das von einem anderen Entwickler erstellt wurde. Als der andere Entwickler dieses Frontend nicht entwickeln konnte, wurden wir beauftragt, auch das Frontend zu erstellen. Obwohl dieser Ansatz definitiv Vorteile bietet, gibt es einen großen Nachteil: die Kosten. Der anfängliche Build wird erheblich teurer und die laufende Wartung wird teurer, da mehr Code gewartet werden muss und zwei separate Systeme ebenfalls bereitgestellt werden müssen. Aufgrund der zusätzlichen Kosten sollte dies immer eine Geschäftsentscheidung sein, die nicht von Entwicklern aus einer Laune heraus getroffen wird.

Um es auf den Punkt zu bringen, ich würde schätzen, dass das oben erwähnte Projekt aufgrund dieses Ansatzes 20% mehr kostet. Sie beschreiben nicht, für welche Art von Projekt Sie an welcher Art von Unternehmen arbeiten, aber wenn Sie ein Start-up-Unternehmen sind, können diese zusätzlichen Kosten den Unterschied zwischen dem Versand einiger zusätzlicher Funktionen ausmachen, die Ihr Produkt ausmachen ein Erfolg.

Ein weiterer Grund, zumindest nicht allgemein, ist, dass es selten eine Eins-zu-Eins-Zuordnung von Funktionen gibt, wenn Sie sich entscheiden, diese zweite Schnittstelle zu erstellen. Wenn Sie beispielsweise eine mobile App erstellen, haben diese tendenziell weniger Funktionen. Dies bedeutet, dass einige Ihrer API-Methoden niemals wiederverwendet werden. Ein Kompromiss mit Ihrem Kollegen könnte daher darin bestehen, zwischen Ihnen die wichtigsten/kritischsten Aufrufe zu entscheiden, diese einer API hinzuzufügen und für alles andere traditionellere Methoden zu verwenden.

Ein weiterer zu berücksichtigender Punkt ist, dass Ihr Kollege sagt, dass Sie Ihren vorhandenen Code nicht wiederverwenden können, was nicht der Fall ist, wenn Sie eine gewisse Trennung Ihrer Geschäftslogik haben. Sie müssen lediglich einen Thin Web Service Wrapper um Ihre internen APIs erstellen, was keine besonders große Aufgabe ist. Es wäre naiv zu glauben, Sie könnten eine Web-Service-Schicht ohnehin ohne Änderungen für ein anderes Front-End wiederverwenden.

29
Ian Newson

Dies hängt von der Art der Anwendung und der Art des Marktes ab, in dem Sie sich befinden.

Dieser Weg hat Kompromisse und Vorteile. Es ist keine eindeutige Antwort, dass ein Weg besser ist als der andere.

Ich werde aus persönlicher Erfahrung sprechen. Ich war derjenige, der sich 2007 entschlossen hat, die Codebasis, an der ich arbeite, in diese Richtung zu übernehmen. Diese Codebasis liegt jetzt in der Größenordnung von einer Million Codezeilen, von denen die Hälfte Servercode ist, der hinter einer riesigen Menge an Webdiensten verborgen ist APIs, die andere Hälfte ist eine Flottille von Clients, Desktop-Native, Desktop-Web, Mobile, Back-End-Integrationen usw. Diese Entscheidung war nicht ohne Nachteile, aber im Nachhinein kann ich sagen, dass ich es wieder tun würde . Lassen Sie mich einige der damit verbundenen Kompromisse aufzeigen.

Vorteile

  • Flexibilität. Unabhängig davon, ob es sich um eine Anforderung zum Erstellen einer mobilen App zur Verbesserung der Desktop-Erfahrung oder um eine Anforderung zur Integration in das SAP-Back-End handelt, wird alles einfacher, wenn Sie bereits eine API zum Aufrufen haben. Wenn Sie genug von diesen Anforderungen erhalten, entwickeln Sie sich organisch zu einer API. Die einzige Frage ist, ob ein Standard-Webdienst vor Ihnen steht oder ob es sich um eine interne API handelt, bei der die Webdienste maßgeschneidert sind.

  • Skalierbarkeit (des Teams). In unserem Fall haben wir viele verschiedene Entwicklergruppen, die alle auf dieser API aufbauen. Wir haben sogar dedizierte API-Teams, die mit den verschiedenen Gruppen sprechen, die Anforderungen zusammenfassen und daraus eine Allzweck-API erstellen. Es ist zu einem Punkt gekommen, an dem uns nicht einmal mehr gesagt wird, dass Leute Dinge auf der API aufbauen, und nicht jeder, der das tut, funktioniert für unser Unternehmen.

  • Sicherheit. Eine klare Trennung zwischen den unsicheren und sicheren Teilen Ihrer Codebasis ist hilfreich, um die Sicherheit zu begründen. Das Durcheinander von Benutzeroberfläche und Back-End-Code führt zu Verwirrung.

Kompromisse

  • Flexibilität. Sie müssen die Arbeit erledigen, um etwas "richtig" in die API zu integrieren. Es ist nicht möglich, eine DB-Abfrage schnell aus dem UI-Code heraus auszuführen, um ein bestimmtes Problem zu lösen. Außerdem müssen APIs, die tatsächlich wiederverwendbar sind, so viele Anwendungsfälle berücksichtigen, dass die schnelle Lösung normalerweise die falsche Lösung ist. Die API lässt sich weniger flexibel weiterentwickeln, zumal es bereits so viel Client-Code gibt (aus diesem Grund wechseln wir zu einer versionierten API).

  • Anfangsentwicklungsgeschwindigkeit. Es ist ohne Zweifel langsamer, API-first zu entwickeln. Sie gewinnen es nur zurück, wenn Sie genügend Clients auf der API aufgebaut haben. Dann stellen Sie jedoch fest, dass Sie drei verschiedene Client-Implementierungen benötigen, bevor sich Ihre API als generisch genug entwickelt hat. Wir haben festgestellt, dass die meisten unserer anfänglichen API-Designs falsch waren und unsere Richtlinien für die Erstellung von Webdiensten stark überarbeiten mussten.

Rote Heringe

Sie haben ein paar davon erwähnt. In der Praxis spielen sie eigentlich keine Rolle.

  • Abstraktion. Ihre API wird abstrakt genug, um alle Anwendungsfälle abzudecken, die Ihr Produkt bedienen muss, und nicht mehr. Auch ohne Webdienste verfügen Sie entweder über eine interne API, die dies ausführt, oder über viel doppelten Code. Ich bevorzuge die Abstraktion gegenüber der Vervielfältigung.

  • Abbruch des serverseitigen MVC-Stacks. Heutzutage wird fast jedes System nach einer Weile eine mobile App benötigen. Wenn Sie dann Webdienste für diese mobile App erstellen, müssen Sie ohnehin herausfinden, wie Authentifizierung und Autorisierung in einem API-Kontext durchgeführt werden. Es ist tatsächlich weniger Arbeit, wenn Sie nur eine Möglichkeit haben, dies zu tun, wie Sie es in Ihren Webdiensten tun.

  • Massenoperationen. Wird normalerweise durch Erstellen einer Massen-API gelöst, die einen Back-End-Job startet und eine Job-ID für die Statusabfrage zurückgibt. Es ist keine so große Sache.

  • Debuggen. Ich stellte fest, dass die Fehlerbehebung im System insgesamt etwas einfacher wurde. Sie können weiterhin Haltepunkte sowohl im Front-End- als auch im Back-End-Code festlegen. In der Praxis ist es also nicht so schwierig, diese zu durchlaufen, und Sie erhalten die Möglichkeit, automatisierte API-Tests zu erstellen und die API für die Überwachung von Produktionssystemen zu instrumentieren.

  • Viele unabhängige Operationen. Das ist eine Frage, wie Sie Dinge entwerfen. Wenn Sie auf einer reinen CRUD-API bestehen, leiden Sie unter diesem Problem. Es ist jedoch in der Regel eine gute Idee, einige CQRS-APIs zu erweitern. Wenn Sie sichergestellt haben, dass Sie über eine interne API verfügen, für die die Services ein Front-End sind, können Sie diese interne API problemlos wiederverwenden, um Services für diese spezifischen APIs zu erstellen Szenarien.

Zusammenfassend

In einem System, das in ausreichend unterschiedlichen Kontexten verwendet wird, entwickelt sich natürlich eine API, da dies der einfachste Weg ist, alle Anforderungen zu erfüllen. Aber es gibt definitiv einen Fall von YAGNI. Es gibt Kompromisse und es macht keinen Sinn, bis es Sinn macht. Der entscheidende Punkt ist, nicht dogmatisch zu sein und offen für verschiedene Ansätze in der Architektur zu sein, um den sich entwickelnden Anforderungen des Produkts gerecht zu werden.

22
Joeri Sebrechts

Was Ihr Kollege beschreibt, ist eine serviceorientierte Architektur. Dies kann eine enorm skalierbare, testbare und vernünftige Art des Codierens sein, aber es hängt wirklich davon ab, was Sie machen.

SOA bietet einige bedeutende Vorteile, die ich aufzählen möchte:

Skalierbarkeit

Da Ihr hinteres Ende entkoppelt ist, wird Ihr vorderes Ende nur zu einer Reihe von Vorlagen, sogar zu Flatfiles. Flatfiles sind enorm schnell und kostengünstig von jedem CDN aus zu bedienen. Sie können minimiert und in statisches HTML vorkompiliert und dann mit Daten clientseitig gefüllt werden.

Ihre API muss konsistent bleiben, kann jedoch gegen eine schnellere Technologie ausgetauscht werden, ohne dass Ihr Stack beschädigt wird, wenn Sie über Ihre vorhandene Technologie hinauswachsen. Sie könnten es zum Beispiel in Go neu erstellen. Sie können es stückweise neu erstellen und die Last auf die Server verteilen. Solange die Schnittstelle gleich bleibt, wird die Technologie abstrahiert.

Testbarkeit

MVC fängt normalerweise sauber an, aber in der Praxis konzentrieren sich Controller selten auf eine einzelne Ressource. Je mehr Dinge Ihre Controller-Methoden tun, desto weniger testbar werden sie.

Eine API umgeht dieses Problem. Jeder API-Aufruf ruft eine Ressource ab und stellt sie bereit. Sauber und prüfbar.

Garantierte Trennung von Bedenken

Ihr vorderes und hinteres Ende sind vollständig geschieden. Sie können das Frontend einem anderen Entwickler oder Designer geben. Dies ist MVC auf eine andere Ebene gebracht. Ich bin sicher, Sie würden MVC nicht aufgeben wollen. SOA ist MVC, aber mehr noch.

Nachteile

Es gibt natürlich einige Nachteile. Ein Monolith ist oft schneller in Betrieb zu nehmen. Es kann das sein, was Sie gewohnt sind. Es kann besser in Ihren Stapel passen. Ihre Werkzeuge können für die Erstellung von Monolithen optimiert werden.

Keiner dieser Gründe ist meiner Meinung nach besonders gut, und Sie sollten eine Umrüstung in Betracht ziehen, wenn sie auf Sie zutreffen.

10
superluminary

Hier gibt es viele gute Antworten, daher füge ich nur meine Implementierungserfahrung hinzu.

So mache ich Dinge:

  • Erstellen Sie eine Datenbankzugriffsschicht, die alle/nur DB-Interaktionen verarbeitet (normalerweise wird manuelles SQL für Geschwindigkeit und Kontrolle verwendet, kein ORM) . Einfügen, Aktualisieren, Löschen, Auswählen ...
  • Erstellen Sie ein interface (virtual class), das die von mir benötigten API-Funktionen verfügbar macht/erzwingt. Bei der Implementierung werden sie die hochspezialisierten DBAL-Funktionen verwenden, um die Ergebnisse zu erzielen. Es hilft mir auch, die API auf Compilerebene zu erzwingen, damit ich sicherstellen kann, dass in der Server + API-Implementierung alle Funktionen integriert sind.
  • Erstellen Sie eine zweite Ebene, die die Schnittstelle implementiert (dies ist die eigentliche API) und Sicherheitsbeschränkungen erzwingt. Sie interagieren hier auch mit externen APIs.
  • Die Website verwendet die zweite Ebene direkt (für die Leistung) , ohne eine remote zugängliche API (wie SOAP) zu verwenden , JSON) .
  • Es wird ein eigenständiger Server erstellt, der die Schnittstelle implementiert und die zweite Ebene als tatsächliche fernzugängliche API für externe Desktop-/Mobilclients (Nicht-Website-Zugriff) verfügbar macht . Es werden lediglich Anforderungen dekodiert und Antworten codiert sowie Clients verwaltet/getrennt. Es unterstützt auch Pushback-Funktionen, um Clients über Ereignisse zu informieren, die von anderen verbundenen Peers generiert wurden (Funktionen, die eine Website normalerweise nicht benötigt) .

Technisch gesehen ist die API also die zweite Schicht. Sie verwenden es direkt mit der Website und stellen es über einen Server Remoteclients zur Verfügung. Code wird wiederverwendet und kein wiederverwendbarer Codeabschnitt ist jemals inline. (lebe und sterbe nach dieser Regel und alles ist fantastisch) Hilft bei der Wartbarkeit, beim Testen ... bei allem.

Sie verbinden die Website niemals mit dem Desktop-/mobilen API-Server (es sei denn, Ihre Website ist AJAX und läuft unter JSON) Wenn die Site jedoch dynamischen Inhalt im Markup rendert, wird Ihre Leistung durch das Durchlaufen einer Zwischen-API beeinträchtigt. Die Website muss schnell sein! Der Remote-Clientzugriff kann etwas langsamer sein.

PS : Ja, die Wartung ist etwas komplexer, da mehr Räder zusammenarbeiten, aber auf lange Sicht einfacher. Wenn Ihr Projekt also eine Weile leben soll und etwas komplex ist, haben Sie immer eine API. Es ist auch viel einfacher, jede Ebene einzeln zu testen.

7
CodeAngry

Der Streitpunkt ist nicht, ob Sie eine API verwenden sollten, sondern was eine "API" tatsächlich ist. Die einzige Alternative zur Verwendung einer entworfenen API ist die Verwendung einer API, bei der es sich um ein zufälliges Durcheinander von Code handelt. Sie schreiben, dass eine API die Dinge "zu flexibel" macht, was wiederum die Dinge unüberschaubar macht. Dies deutet auf ein vollständiges und gründliches Missverständnis der API hin. Wenn dieses Missverständnis nicht zwischen Ihnen und Ihrem Kollegen geteilt wird, haben Sie viel Zeit damit verschwendet, über völlig andere Dinge zu streiten.

Wenn Sie keine genau definierte API verwenden, können Sie tun, was Sie wollen. Per Definition ist dies die flexibelste Option. Außerdem ist "mach was du willst" per Definition immer noch eine API. Die Aufgabe nur einer API besteht darin, die Flexibilität zu entfernen. Durch das Entfernen der Flexibilität ermutigt eine gute API einen Benutzer, ähnliche Dinge auf ähnliche Weise zu tun.

Natürlich kann eine schlechte API entweder zu viel oder zu wenig Flexibilität bieten oder sogar beides gleichzeitig. Eine wirklich schlecht gestaltete API kann ein Projekt noch schneller beenden als der "Alles geht" -Ansatz. Best Practice ist einfach, kompetente Programmierer zu haben, die die API zusammen mit Ihrer Anwendung entwickeln und weiterentwickeln.

Beispiel

• Viele unabhängige Vorgänge, die viel Hin und Her erfordern, z. B. Code kann den aktuellen Benutzer abrufen, überprüfen, ob der Benutzer die Administratorrolle innehat, das Unternehmen abrufen, zu dem der Benutzer gehört, eine Liste anderer Mitglieder abrufen und diese senden alles eine E-Mail. Dies würde viele API-Aufrufe erfordern oder das Schreiben einer maßgeschneiderten Methode für die gewünschte Aufgabe, wobei der einzige Vorteil dieser maßgeschneiderten Methode die Geschwindigkeit wäre, der Nachteil jedoch wäre, dass sie unflexibel wäre.

Die Anzahl der API-Aufrufe, die für eine anständige API erforderlich wären, wäre wahrscheinlich 1. Ja, es ist unflexibel, aber warum sollte es flexibel sein?

7
Peter

Kurzversion : Ihr Controller ist effektiv eine API, egal was passiert; obwohl ASP.NET dies möglicherweise verdeckt.

Längere Version :

Denken Sie an eine einfache MVC-Web-App, die Informationen über Bier bietet und Ihnen optional eine verkauft. Wie sehen die Routen aus?

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

In einer normalen Web-App gibt es wahrscheinlich einige Nebenrouten wie:

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

In einer Web-API sind diese nicht erforderlich, da sie aus der HTTP-Methode abgeleitet werden.

Angesichts der obigen Symmetrie denke ich, dass dies ein ziemlich überzeugender Fall ist, dass Ihre API und Ihr Controller so nahe beieinander liegen, dass sie genauso gut dasselbe sein können.

Nach einigem Graben habe ich festgestellt, dass dies könnte der Stand der Dinge für Sie ist, abhängig davon, welche Version von ASP.NET Sie verwenden. Dem älteren MVC 5 und früher fehlen die Konventionen und die Schnittstelle, um die beiden Implementierungen solide zu vereinheitlichen. In alten Versionen füllt Web App return eine Ansicht aus, während die API eine HttpResponse ausgibt. In beiden Fällen generieren sie jedoch semantisch genau dieselbe Antwort.

Wenn Sie MVC 6 verwenden, erhalten Sie beide in einer einheitlichen Controller-Klasse, die hinsichtlich der Rückgabe klug sein kann. Ich habe keinen guten ASP Beispielcode für dieses Modell gefunden, aber ich habe einen Rails Code mit demselben Muster gefunden. Betrachten Sie Dieser Controller für "Likes" aus dem Diaspora-Projekt . Jede Controller-Methode verfügt über Routen, die durch eine "einfallsreiche Konvention" definiert sind hier die dem LCRUD in einer API entsprechen.

Wenn Sie jedoch die Implementierungen lesen, kann jeder möglicherweise auf HTML, Mobile HTML oder JSON reagieren. In Kombination mit einer Konvention zum Suchen der Ansichten werden die Web-App und die Web-API vollständig vereinheitlicht. Sie werden auch feststellen, dass nicht alle Methoden tatsächlich jede Antwort liefern (was sinnvoll ist, da die Benutzeroberfläche möglicherweise Methoden erfordert, die die API nicht benötigt, und umgekehrt).

Dies ist eine Impedanzfehlanpassung, da ASP.NET dies alles spät herausgefunden hat, während Rails die Symmetrie seit einiger Zeit angenommen hat und dies sehr deutlich macht.

Spekulation :

Ihr Mitarbeiter ist wahrscheinlich sowohl richtig als auch falsch, je nachdem, welche ASP - Version, die Sie verwenden. Unter der alten MVC-Version hat der Unterschied zwischen API und App es wahrscheinlich zu einer "Best Practice" gemacht. um die API im Voraus zu erstellen, da das ASP.NET-Modell dort keine gute Wiederverwendung von Code ermöglichte.

Bei der neueren Version ist es sinnvoller, einheitlichen Code zu verwenden, da die Wiederverwendung von Code mit der Basisklasse des einheitlichen Controllers vereinfacht wurde.

In beiden Fällen ist der Controller jedoch effektiv die API.

4
Jayson

Er sagte, unser Code sei zu eng gekoppelt. Wenn wir beispielsweise auch eine Desktop-Anwendung wünschen, können wir unseren vorhandenen Code nicht verwenden.

Na ja, oder? Wenn nicht, dann ist das eine ziemlich irrelevante Aussage.

Ich würde sagen, wenn Sie 2015 eine neue Anwendung erstellen möchten, sollten Sie sich ernsthaft mit einer Benutzeroberfläche befassen, die eine API und keine vom Server generierten HTML-Seiten umfasst. Es gibt klare Kosten, aber auch klare Vorteile.

Aber wenn Sie eine vorhandene Site haben, die keine konkreten Pläne für mehrere verschiedene Schnittstellen hat (soweit ich das beurteilen kann), sind seine Kommentare einfach irrelevant.

4
RemcoGerlich

Als ich 2006 meine Karriere begann, war diese Art von Architektur der letzte Schrei in der .NET-Welt. Ich habe an drei separaten Projekten gearbeitet, die Mitte der 2000er Jahre mit einem Webdienst zwischen der Geschäftslogikschicht und dem Web-Frontend konzipiert wurden. Natürlich waren die Webdienste heutzutage SOAP, aber es ist immer noch dieselbe Architektur. Die vermeintlichen Vorteile waren die Möglichkeit, entweder das Front- oder Backend zu wechseln und sogar Desktop-Programme zu entwickeln. Letztendlich erwies sich YAGNI als wahr Ich habe nie gesehen, dass dies passiert ist. Während dieser ganzen Zeit habe ich nur die Kosten für die Aufteilung des Projekts auf diese Weise gesehen. Am Ende habe ich sogar den Webdienst aus einem der Projekte herausgerissen (es dauerte ein halbes Jahr, um es Schritt für Schritt zu entfernen andere Dinge zu tun) und das ganze Team war glücklich. Ich habe diesen Ansatz seitdem nie mehr ausprobiert und werde es auch nicht tun, es sei denn, es wurde ein ganz bestimmter Grund angegeben. 5 Jahre Erfahrung mit dieser Architektur haben mich gelehrt, dass ich sie nicht brauchen werde und keine Anzahl von Experten Wenn ich das Gegenteil sage, werde ich davon überzeugt sein. Nur ein Projekt, bei dem ich es brauche, kann das tun.

Nachdem dies gesagt wurde, bemühe ich mich sehr, eine Schicht zwischen der Geschäftslogik und den Controllern/Präsentatoren zu entwickeln. Zum Beispiel habe ich eine Service-Schicht, ich stelle niemals Abfragen zur Verfügung, verwende Schnittstellen für alle meine Services und füge sie in Controller mit IoC ein. Wenn ich jemals einen Webdienst in meiner Architektur benötige, kann ich ihn zu angemessenen Kosten einführen. Ich möchte diese Kosten einfach nicht im Voraus bezahlen.

Ich mag auch die Idee von Microservices sehr, aber ich verstehe, dass Microservices eher vertikale Module als horizontale Schichten bedeuten. Wenn Sie beispielsweise Facebook erstellen, ist die Chat-Funktion ein separater Dienst, der separat auf seinen eigenen Servern usw. bereitgestellt wird. Dies ist die Art von unabhängigen Diensten, die ich empfehlen würde.

2
Stilgar

Dritte werden es verwenden? Ja, sollten Sie.

Sie planen, es in nicht allzu ferner Zukunft wiederzuverwenden? Ja, sollten Sie.
Sie sind Ihr Dritter und haben eine dokumentierte - oder dokumentierbare - oder verwendbare Die API für Drittanbieter bietet Ihnen eine solide Wiederverwendbarkeit und Modularität.

Sie sind in Eile? Nein, sollten Sie nicht.
Refactoring danach ist einfacher und schneller als die meisten Methoden und Lehrer vorhersagen und erzählen. Es ist wichtiger, etwas zu haben, das funktioniert (auch bei einem schlechten internen Design, da es überarbeitet werden kann und wird), als überhaupt nichts zu haben. (aber mit einem unglaublichen internen Design, wohoo)

Das Front-End wird aus Gründen möglicherweise nie das Licht der Welt erblicken? Ja, das sollten Sie.
Ich habe diesen Grund hinzugefügt, weil mir das sehr oft passiert ist.
Und zumindest bleiben mir meine Komponenten zur Wiederverwendung und Weiterverteilung usw. übrig.

2
ZJR

Hier gibt es gute Antworten. Ich poste dies als Teilantwort; es wäre vielleicht besser als Kommentar. Es ist jedoch nicht gut, denselben Kommentar auf zahlreiche Beiträge zu setzen.

Man kann nicht behaupten, dass YAGNI ein Grund dafür ist, keine API zu erstellen.

Die API ist ein natürlicher und logischer Testendpunkt. Ab Tag 0 gibt es also zwei Anwendungen, die die API verwenden: die Benutzeroberfläche und die Testsuite. Einer ist für Menschen gedacht, der andere für Maschinen. Sie sind notwendigerweise unterschiedlich. Das Testen des Front-End-Verhaltens ist eine ganz andere Aufgabe als das Testen des Back-End-Verhaltens. Daher sind die Techniken und wahrscheinlich die Werkzeuge völlig unterschiedlich. Mit der API kann das beste Tool für den Job verwendet werden. Dank der durch die API bereitgestellten Trennung müssen die Front-End-Tester die Back-End-Funktionalität nicht testen.

Die API hilft auch dabei, die Front-End-Codierer von den Bedenken des Back-End-Codierers fernzuhalten und umgekehrt. Dies sind sehr unterschiedliche Fähigkeiten in unserem Unternehmen. Mit der API können wir uns darauf konzentrieren, wo wir am stärksten sind.

1
Tony Ennis