Moin Golo, danke für das Video! Wie immer affengeil!😊 Es wäre cool so ein Commands-Beispiel in einem GO - Microservice zu sehen! Zum Beispiel für User (registration, athentication etc.)! Vielleicht wäre das eine idee für Live Session. Ich würde mich frohen!
Hi Golo, einfach danke. Wir waren am überlegen uns mit den genannten Technologien zu beschäftigen, jedoch haben deine Erläuterungen gezeigt, das wir mit unserem momentanen Weg ganz gut auf der Spur sind. Ein Livestream über das Thema wäre Super.
Guten Morgen Golo, dieses Video kommt genau zur richtigen Zeit. Ich habe mich die letzten Wochen genau mit diesem Thema beschäftigt (müssen). Ich wollte eine einfache, performante Lösung zum Sammeln von Maschinendaten. Auch ich war der Meinung das REST diesem CRUD Gedanken folgt. Also danke dafür das Du mich da eines besseren belehrt hast. Mit gRPC habe ich mich intensiver beschäftigt und bin da genau Deiner Meinung - Binärformat igitt-igitt. Und ansonsten ist das ganze Handling viel zu kompliziert. Ich habe mich dann, und Deine Meinung bestätigt mich, für diesen POST/GET Mechanismus entschieden, habe einen ReverseProxy davor gesetzt (selbst in GO geschrieben) und ich bin (bis jetzt) super glücklich. Mal sehen was passiert, wenn 10000 Maschinen ihre Daten im Minutentakt senden . Also vielen Dank für das Video.
Danke für die gute Zusammenfassung. Ich würde mich auch über eine vertiefende Session freuen, speziell das Strukturieren der Controller und Services, fachliche Aspekte und dann über noch Query und Commands. Danke an dieser Stelle für die vielen anderen Videos.
Vielen Dank für dieses großartige Video! Eine super Zusammenfassung zum Thema APIs. Was mich besonders fasziniert, ist euer sehr fachlicher Ansatz bei der Erstellung einer API. Es entspricht zeimlich genau der Vorgehensweise, die ich selbst bei der Entwicklung meiner APIs verfolge. Zugegebenermaßen war mein Weg dahin nicht ganz so überlegt und strukturiert wie bei euch. Anfangs habe ich meine APIs auf diese Art und Weise aufgebaut, weil es für mich als Programmier-Neuling einfach logisch erschien und ich REST vielleicht nicht zu 100% verstanden hatte 🫣😂. Doch schon damals fand ich es merkwürdig, einfach SQL "nach draußen weiterzuleiten". Das war für mich nicht der eigentliche Zweck einer API - wohl instiktiv einiges Richtig gemacht 😉. Auf lange Sicht hat sich diese Vorgehensweise als äußerst praktisch erwiesen. APIs mit URLs, die so für sich selbst sprechen, sind aus meiner Sicht einfach viel besser lesbar als die "echten" REST-APIs und damit auch für andere Entwickler gut zu verstehen. Ich freue mich auch immer wieder, wenn ich solchen APIs in der freien Wildbahn begegne und es freut mich, dass ihr da anscheinend ähnlich tickt. 👍😊
[gr] Das hört sich echt gut an, und ich denke, Du kannst da echt froh sein, dass Du (mehr oder weniger durch Zufall) um REST und diese Denkweise herumgekommen bist. Natürlich ist es manchmal hilfreich, aber es macht auch vieles kaputt, und der Schaden durch REST ist IMHO viel höher als der Nutzen.
wäre an einem Lifestream zur Architektur einer fachbezogenen API sehr interessiert. graphql klingt in der Forschung richtig gut, insbesondere, wenn man zwischen verschiedenen Datenbanken Beziehungen herstellen könnte, will ich mir mal anschauen. Danke für das tolle Video :) ich finde die Qualität eurer Auseinandersetzung mit Themen immer wieder erschreckend gut und motivierend. danke.
Vielen Dank für den direkten Vergleich und die Einblicke in deine/euren Erfahrungen mit diesen API-Technologien. CQRS ist auch eine sehr feine Sache. Ich finde jedoch, dass die Umsetzung über HTTP/JSON genau dem REST-Ansatz entspricht: die Ressourcen sind die beschriebenen Commands und Queries und via HATEOAS ergeben sich die fachlich nächsten Commands und Queries. Aber wir uns einig: REST funktioniert am besten mit einem fachlich getriebenem Prozess als mit Daten getriebenem CRUD 🙂
Schön erklärt und dank der englischen version, kann das auch direkt weiter an die Kollegen, danke dir. Ich baue JSON-over-HTTP APIs auch schon seit längerem mit POST für mutations und GET für reading operations. Das funktioniert sehr gut, muss ich sagen - auch wenn es bei den technisch verliebten Entwicklern immer wieder auf Verwunderung stößt, dass man nicht einfach einen PATCH anbieten soll - aber da kann ich ja nun das video verlinken :) Ich glaube, das JSON-over-HTTP mit POST for mutations und GET for read braucht allerdings einen besseren Namen. Sonst befindet man sich im Meeting über API Tech Diskussionen und spricht über REST (aka. CORS), GraphQL, GRPC und "JSON-over-HTTP mit POST und GET" - das passt nicht so ins Muster ;) und macht es schwieriger darüber zu sprechen, denn sonst bleibt einem nur "REST" als Terminology, was so ziemlich vieles Bedeuten kann (u.a. auch JSON:API) und am Ende keiner mehr weiß, was der Gesprächspartner mit REST meint.
Danke für die ganze Aufschlüsselung. Ich baue gerade für mich eine API auf dem Slim-Framework Angefangen hatte ich, wie ich es mal in meiner alten Firma mit Laravel gelernt hatte mit REST und damit CRUD. Eure Videos und Livestreams bringen mich aber zum umdenken und ich versuche diese API mal bewusst fachlich aufzuziehen. Also wie beschrieben Routen nur get für Queries und post für Commands. Wenn Gruppierungen eingezogen werden, dann nur nach fachlichen Bereichen und nicht nach Tabellennamen. Mal schauen wie gut ich damit zurecht komme. Macht weiter so, eure Video sind echt goldwert
Genau mit diesem Thema, habe ich mich vor 2 Wochen beschäftigt. Ich bin beim gleichen Ergebnis gelandet. Du hast jedoch nichts über OpenAPI / Swagger erwähnt. Ich finde die Dokumentation einer REST, macht eine gute API aus.
Super erklärt, volle Zustimmung . Das beste an „deiner Methode“ (wir machen es fast genauso): Sie kommt mit nur einem generischen Controller bzw. Endpunkt aus! Dieser kümmert sich um Serialisierung und schiebt den Command/die Query in einen Bus. Als EntwicklerIn muss ich also wirklich nur einen Command oder eine Query in einem fachlichen Modul/Projekt etc. schreiben, um der API etwas neues beizubringen. 😊
Vielen Dank für das tolle und lehrreiche Video! Das Video kommt genau zur rechten Zeit! 😃 Ich denke aktuell über die Umsetzung einer API nach und hatte mir überlegt, ob ich dem REST Ansatz folgen soll, weil mir schien es so, als wenn dass der gängige Weg wäre. Wobei ich ursprünglich eigentlich viel mehr etwas in der Richtung der Empfehlung umgesetzt hätte. Nach dem Video, finde ich euren Ansatz eigentlich erheblich besser 🙂
Sehr interessante Sichtweise! Ich kann dazu inhaltlich wenig beitragen, aber mein Eindruck ist, dass die API Endpunkte in SvelteKit-Projekten genau dieser fachlicher Ausrichtung entsprechen, die du im Video beschrieben hast. Aber das betrifft auch nur innerhalb einer Anwendung genutzte APIs. Und ja ein längeres Video zum Aufbau von APIs wäre sehr interessant!
Vielen Dank für die prägnanten Definitionen und Einordnungen der Technologien. Ich bin neu in der Webentwicklung und versuche mich gerade in die Thematik einzuarbeiten, aber nach dem Lesen diverser Blog Einträge, Diskussionen und dem überfliegen von Dokumentation war ich häufig genau so schlau wie vorher ohne die grundlegenden Funktionsweisen durchblickt zu haben, aber bei deiner Erklärung wurden on Point viele meiner Fragen beantwortet :)
Voll cool, so wie ihr eure APIs schreibt, so hab ich mir das auch bei meinem Minwork gedacht :D Schön, dass wir da einer Meinung sind. Sehe das bei REST so, dass es schön einfach ist, aber man kann es auch schön einfach verhunzen, weil REST an sich ja erst mal gar nicht so viel vorgibt. Außerdem ist das mit der Doku auch immer so eine sache, weil man REST ganz schnell sehr dynamisch aufbaut. Etwas dynamisches lässt sich nur schwer dokumentieren. GraphQL finde ich an sich gar nicht so verkehrt. Vor allem, wenn man sowas wie type-graphql verwendet, was einen Die Sache deutlich vereinfacht. Zu gRPC kann ich leider nix sagen, klingt aber erst mal auch ganz gut, nur halte ich von code generieren nix. Wenn dann kann aus dem Code etwas generiert werden, wie z.B. Typinformationen. So mache ich das. Ich hole die Typen von TypeScript in die Laufzeit hinein, sodass ich dann die API zumindest was die Typen angeht absichern kann. Zugriffsrechte sind dann wieder ein anderes Thema.
Interessant, eure Art Apis zu bauen, habe ich mal als Student "frei nach Kopf" genauso implementiert und wurde dann von meinem Prof kritisiert, da es ja REST gibt und das kein Industriestandard sein :P Damals kannte ich REST noch gar nicht. Welch Zufall, sehr interessant
Ich finde die Idee mit dem "fachlichen HTTP" sehr gut und verständlich. Die Ressourcen werden aber weiterhin wie in REST in der Url adressiert? Es gäbe also schon noch mehr Routen als eine Get und eine einzelne Post Route mit allen Infos? Um etwas zu löschen würdet ihr einen Post verwenden?
[gr] Ja, es gibt schon noch mehr Routen als nur zwei, aber eben nur noch zwei Typen: POST zum Schreiben, GET zum Lesen. Und ja, um etwas zu löschen, würden wir ein POST verwenden. Nur hieße diese Route dann nicht "Delete XYZ", weil es ja nicht um's Löschen geht - das ist ja nur der technische Effekt. Die Frage ist: WARUM willst Du löschen? Was ist die fachliche Intention? Um es mal am Beispiel einer Todo-Liste zu machen, auf der Du Aufgaben notieren, editieren und abhaken kannst. Dann hättest Du zum Beispiel: POST /note-todo POST /edit-todo POST /tick-off-todo Und als Queries: GET /remaining-todos GET /ticked-off-todos GET /all-todos
@@thenativeweb Nunja, löschen ist ja durchaus öfter mal auch etwas fachliches. Zb ein Item aus dem Warenkorb löschen..hier könnte die Route durchaus delete heißen. Danke für die Erklärung, das ist sehr hilfreich.
@@davidelsner9391 [gr] Du löschst ein Item nicht aus dem Warenkorb. Du legst es zurück. Oder Du entnimmst es. Aber Du löschst es nicht. Überleg mal, wenn Du im Supermarkt stehst und etwas im Einkaufswagen hast, was Du dann doch nicht nehmen möchtest: „Löschst“ Du das dann? 😉
Guten Morgen Golo, in zwei Monaten starte ich meine Diplomarbeit, in der ich eine iOS-App entwickeln möchte. Die App soll eine von mir selbst programmierte GO-API verwenden, die auf eine MSSQL-Datenbank zugreift. Da ich bisher noch keine API programmiert habe, wäre ein Live-Stream von dir dazu für mich unglaublich hilfreich. Danke im Voraus für deine Unterstützung! :)
Hey Golo, erst mal vielen Dank für das Video, definitiv mal wieder was gelernt. Ein bisschen konstruktives Feedback: Eure Darstellung von GraphQL ist meiner Meinung nach etwas eindimensional. "Dass man auf der Server-Seite nie so sehr vorhersehen kann, was man für Abfragen bekommt" stimmt einfach nicht, weil ich ja (egal ob design-first oder code-first) definitiv die Inputs und ihre Typen vorgeben muss, das funktioniert also quasi wie bei REST. "Es ist leichter in performance-kritische Abfragen zu laufen" ist zwar richtig, das gilt aber für jede Implementierung, ist mir also etwas zu generisch und in dem Video zu sehr Fingerpointing auf GraphQL. Und für solche Probleme gibt's ja auch vorgefertigte Konzepte, "data loaders" bei GraphQL zum Beispiel. Again: Sehr gutes Video, nur bei GraphQL evlt. etwas mehr Recherche investieren. Stichwort "Hasura" ist zum Beispiel auch stark im Kommen.
Moin Golo, schöne Zusammenfassung des Themas. Den Wunsch nach einem Livestream kann ich nur unterstützen. Aber ein anderes Thema. Nervt dich nicht das globale Menü am Mac bei deinem großen Monitor? Ich habe ein ähnliches Set-up und das ist so ein Punkt, mit dem ich nicht zufrieden bin. Wie ist denn dein Workflow?
[gr] Danke für Deinen Kommentar und das Feedback 😊 Was Deine Frage angeht: Nö, das stört mich nicht. Ich brauche die Menüleiste aber auch so gut wie nie (höchstens rechts oben die Icons und die Uhrueit). Das meiste läuft bei mir über Tastenkombinationen, weshalb ich das Menü so gut wie nie öffnen muss.
Kleine Anmerkung zu GraphQL: Queries sind HTTP GET's und Mutations sind HTTP POST's. Keine Technologie schützt einen vor schlechtem API design und sorgt dafür, dass die Fachlichkeit die Entwicklung treibt. Darauf muss man als Team immer selbst achten. Ich glaube mit allen 3 Technologien kann man super fachliche APIs entwickeln, aber viele nutzen die Möglichkeiten der Technologie falsch. Dann wird auf einmal fachliche Logik in den Client verschoben, die API führt nur noch Datenbankoperationen aus und man hat gar keinen Überblick mehr, wer was wo macht. Oder es wird ein "Schema First" Ansatz gefahren und auf einmal sind die Daten im Fokus anstatt der Fachlichkeit. Ich persönlich entwickle viel nativ mobile und deswegen reizt mich persönlich das feste Protokoll im Bezug auf Pagination, Error Handling, Status Codes, Discoveribility, Federated Requests und Code Generation von GraphQL am meisten. Man muss aber aufpassen, dass man den fachlichen Fokus nicht verliert.
GraphQL mit Hasura ist ein No-Brainer. gRPC ist denkbar auch für WebRTC (P2P) Lösungen. Golo, nimm doch bitte in Zukunft auch etwas differenziertere Überlegungen in deine Urteile auf. Danke LG
Die Behauptung, wenn man CRUD macht, kann man statt REST dem User auch direkt SQL geben, halte ich für zu kurz gedacht. Die REST API setzt nämlich die Zugriffskontrolle um, die man in den meisten SQL-Datenbanken nicht so feingranular in SQL abbilden kann und auch die Fehlermeldungen nicht so passend sind.
ich schreibe gerade mein eigenes ui framework, das in dei cloud deployed, im webbrowser läuft und als native app gebuildet werden kann und jede sprache im browser direkt übers backend supported. also für mich ist das kein ausnahmefall sondern die basis für meine arbeit. wieso sollte ich denn json benutzen, wenn ich auch direkt binärfiles nehmen kann
Ich habe solche Überlegungen schon länger. Das Video fast es wirklich sehr gut zusammen. Die Frage ist jedoch wie man seine Kollegen davon überzeugt bekommt? Die meisten lieben ihre Crud APIs. Da kann man so schön Endpunkte sparen. 🙄
[gr] Das ist leider wirklich eine sehr, sehr gute Frage … es ist generell nicht einfach, Leute von den Nachteilen von CRUD zu überzeugen. Das betrifft nicht nur Entwicklung, auch das Management … sagen wir es mal so: Es ist mühsam 😉
Ich mache das schon seit fast 10 Jahren so, bin aber immer mehr in einen Mischmasch übergegangen, zB wo ein query auch als POST abgebildet wird, wenn ich zB mehrere query Parameter haben und lieber den Body anstatt URL params nutzen möchte. Wir nennen es intern oft RESTless API oder RPC style HTTP API ☺️
Ist graphql im Endeffekt nicht auch nur eine Bibliothek, wo man die Struktur vorher definiert? trpc ist ja von der Struktur ähnlich wie grpc, bloß über http und du bist auf js/ts limitiert
@@Beolthorn Tatsächlich ist graphql eine Abfragesprache, genau wie SQL. Es gibt natürlich diverse Bibliotheken in vielen Programmiersprachen, die graphql implementieren. Ja ich denke genau die unterschiede sind es, die es schwierig macht tRPC und gRPC zu vergleichen. Gerade weil tRPC Typescript only ist. Meiner Erfahrung nach macht tRPC da sind wo ich ein Monorepo habe und mein Backend und Frontend typisiert kommunizieren lassen will. Gerade REST, Graphql und gRPC richtet sich ja an verteilte Systeme. Meine Erfahrung in tRPC ist allerdings auch relativ begrenzt, als kleiner Disclaimer.
@@geeksy2278 tRPC spezifiziert auch ein schema, das es ja selbst zur kommunikation benutzt. du kannst zwar deine router und procedures so zusammenstellen, wie du willst, aber es folgt trotzdem einem pattern. dazu kommt, dass procedures entweder querys, mutations, oder subscriptions/observer sind. wieder ein pattern. wenn tRPC "nur eine library" wäre, dürfte es sich von anderen HTTP clients wie axios oder GOT nicht unterscheiden.
@@FunctionGermany Ich glaube das Zitat von der tRPC Website fasst ganz gut zusammen was ich meine: "Since GraphQL is designed as a language-agnostic specification for implementing APIs, it doesn't take full advantage of the power of a language like TypeScript. If your project is built with full-stack TypeScript, you can share types directly between your client and server, without relying on code generation." Dahinter steckt eben keine offenes Protokoll. Die Bibliothek ist speziell für Typescript-Apps entwickelt worden.
Ok gut.. als du sagtest kein rest war ich skeptisch. Aber sicherlich weil ich den Begriff anders interpretiere.. die fachliche Definition mit Post/get die bilde ich auch so ab, allerdings sagte ich dazu auch REST and CRUD - sicherlich fälschlicherweise, dennoch läuft ja im backend dennoch CRUD ab, auch wenn ich es implementiere allerdings nicht explizit vom Client sondern in der business(Server) Logik. Weiterhin arbeite ich idR mit store procedures also have im backend nur die Logik die den Fall abbildet
Ich finde GraphQL in Verbindung mit Nest.JS und Prisma eine sehr gute Lösung. GraphQL definiert allerdings die maximale Ausbaustufe einer Query und ist performancetechnisch sehr gut. Sicherlich braucht es etwas Zeit für die Vorbereitung, aber der große Vorteil, nicht für jede kleine Abwandlung einer Abfrage, einen neuen Einstiegspunkt definieren zu müssen, ist einfach unschlagbar.
aber digger du vergisst hier ja auch das grpc auch gleichzeitg als service mesh benutzt werden kann. macht braucht halt einfach nur geile tools für grpc, aber es ist halt viel geiler als diese verdammten cors headers zu setzen, json zu senden und in jeder sprache einen server aufzumachen den du wieder neu programmieren musst, aio,flask etc. außerdem ist grpc streaming auch viel fortschirittlicher als websocket, siehe improbable
bin grad mit dem REST teil des videos durch. ich stimme dir bei den punkten zu REST zu, wenn wir über eine extern konsumierte API reden. wenn ich aber eine API in erster linie für das eigene frontend baue, halte ich eine dünne CRUD/REST schicht für sehr gut, da ich damit das system nicht mit mehr informationen anreicher als nötig. das geht natürlich nicht immer, aber manchmal hab ich halt ne einfache ressource, die ich zB per spring RestResource annotation auf das repository publishen und benutzen kann ohne einen controller zu schreiben.
Ich wäre an einem Video interessiert wie man APIs richtig baut.
Moin Golo,
danke für das Video! Wie immer affengeil!😊
Es wäre cool so ein Commands-Beispiel in einem GO - Microservice zu sehen! Zum Beispiel für User (registration, athentication etc.)! Vielleicht wäre das eine idee für Live Session. Ich würde mich frohen!
Hi Golo,
einfach danke. Wir waren am überlegen uns mit den genannten Technologien zu beschäftigen, jedoch haben deine Erläuterungen gezeigt, das wir mit unserem momentanen Weg ganz gut auf der Spur sind.
Ein Livestream über das Thema wäre Super.
[gr] Danke, das freut mich 😊
Danke und ja gern mal an einem praktischen Beispiel in der Praxis zeigen.
Schöne Woche!
[gr] Danke für Dein Feedback - und Dir ebenfalls eine schöne Woche 😊
Guten Morgen Golo,
dieses Video kommt genau zur richtigen Zeit. Ich habe mich die letzten Wochen genau mit diesem Thema beschäftigt (müssen). Ich wollte eine einfache, performante Lösung zum Sammeln von Maschinendaten. Auch ich war der Meinung das REST diesem CRUD Gedanken folgt. Also danke dafür das Du mich da eines besseren belehrt hast. Mit gRPC habe ich mich intensiver beschäftigt und bin da genau Deiner Meinung - Binärformat igitt-igitt. Und ansonsten ist das ganze Handling viel zu kompliziert. Ich habe mich dann, und Deine Meinung bestätigt mich, für diesen POST/GET Mechanismus entschieden, habe einen ReverseProxy davor gesetzt (selbst in GO geschrieben) und ich bin (bis jetzt) super glücklich. Mal sehen was passiert, wenn 10000 Maschinen ihre Daten im Minutentakt senden . Also vielen Dank für das Video.
Danke für die gute Zusammenfassung. Ich würde mich auch über eine vertiefende Session freuen, speziell das Strukturieren der Controller und Services, fachliche Aspekte und dann über noch Query und Commands.
Danke an dieser Stelle für die vielen anderen Videos.
[gr] Vielen Dank für Dein Feedback, und natürlich auch für das Lob 😊
Vielen Dank für dieses großartige Video! Eine super Zusammenfassung zum Thema APIs.
Was mich besonders fasziniert, ist euer sehr fachlicher Ansatz bei der Erstellung einer API. Es entspricht zeimlich genau der Vorgehensweise, die ich selbst bei der Entwicklung meiner APIs verfolge. Zugegebenermaßen war mein Weg dahin nicht ganz so überlegt und strukturiert wie bei euch. Anfangs habe ich meine APIs auf diese Art und Weise aufgebaut, weil es für mich als Programmier-Neuling einfach logisch erschien und ich REST vielleicht nicht zu 100% verstanden hatte 🫣😂. Doch schon damals fand ich es merkwürdig, einfach SQL "nach draußen weiterzuleiten". Das war für mich nicht der eigentliche Zweck einer API - wohl instiktiv einiges Richtig gemacht 😉.
Auf lange Sicht hat sich diese Vorgehensweise als äußerst praktisch erwiesen. APIs mit URLs, die so für sich selbst sprechen, sind aus meiner Sicht einfach viel besser lesbar als die "echten" REST-APIs und damit auch für andere Entwickler gut zu verstehen. Ich freue mich auch immer wieder, wenn ich solchen APIs in der freien Wildbahn begegne und es freut mich, dass ihr da anscheinend ähnlich tickt. 👍😊
[gr] Das hört sich echt gut an, und ich denke, Du kannst da echt froh sein, dass Du (mehr oder weniger durch Zufall) um REST und diese Denkweise herumgekommen bist. Natürlich ist es manchmal hilfreich, aber es macht auch vieles kaputt, und der Schaden durch REST ist IMHO viel höher als der Nutzen.
wäre an einem Lifestream zur Architektur einer fachbezogenen API sehr interessiert. graphql klingt in der Forschung richtig gut, insbesondere, wenn man zwischen verschiedenen Datenbanken Beziehungen herstellen könnte, will ich mir mal anschauen. Danke für das tolle Video :) ich finde die Qualität eurer Auseinandersetzung mit Themen immer wieder erschreckend gut und motivierend. danke.
Vielen Dank für den direkten Vergleich und die Einblicke in deine/euren Erfahrungen mit diesen API-Technologien. CQRS ist auch eine sehr feine Sache. Ich finde jedoch, dass die Umsetzung über HTTP/JSON genau dem REST-Ansatz entspricht: die Ressourcen sind die beschriebenen Commands und Queries und via HATEOAS ergeben sich die fachlich nächsten Commands und Queries. Aber wir uns einig: REST funktioniert am besten mit einem fachlich getriebenem Prozess als mit Daten getriebenem CRUD 🙂
Schön erklärt und dank der englischen version, kann das auch direkt weiter an die Kollegen, danke dir.
Ich baue JSON-over-HTTP APIs auch schon seit längerem mit POST für mutations und GET für reading operations. Das funktioniert sehr gut, muss ich sagen - auch wenn es bei den technisch verliebten Entwicklern immer wieder auf Verwunderung stößt, dass man nicht einfach einen PATCH anbieten soll - aber da kann ich ja nun das video verlinken :)
Ich glaube, das JSON-over-HTTP mit POST for mutations und GET for read braucht allerdings einen besseren Namen. Sonst befindet man sich im Meeting über API Tech Diskussionen und spricht über REST (aka. CORS), GraphQL, GRPC und "JSON-over-HTTP mit POST und GET" - das passt nicht so ins Muster ;) und macht es schwieriger darüber zu sprechen, denn sonst bleibt einem nur "REST" als Terminology, was so ziemlich vieles Bedeuten kann (u.a. auch JSON:API) und am Ende keiner mehr weiß, was der Gesprächspartner mit REST meint.
Danke für die ganze Aufschlüsselung. Ich baue gerade für mich eine API auf dem Slim-Framework
Angefangen hatte ich, wie ich es mal in meiner alten Firma mit Laravel gelernt hatte mit REST und damit CRUD.
Eure Videos und Livestreams bringen mich aber zum umdenken und ich versuche diese API mal bewusst fachlich aufzuziehen.
Also wie beschrieben Routen nur get für Queries und post für Commands. Wenn Gruppierungen eingezogen werden, dann nur nach fachlichen Bereichen und nicht nach Tabellennamen.
Mal schauen wie gut ich damit zurecht komme.
Macht weiter so, eure Video sind echt goldwert
Genau mit diesem Thema, habe ich mich vor 2 Wochen beschäftigt. Ich bin beim gleichen Ergebnis gelandet. Du hast jedoch nichts über OpenAPI / Swagger erwähnt. Ich finde die Dokumentation einer REST, macht eine gute API aus.
Super erklärt, volle Zustimmung . Das beste an „deiner Methode“ (wir machen es fast genauso): Sie kommt mit nur einem generischen Controller bzw. Endpunkt aus!
Dieser kümmert sich um Serialisierung und schiebt den Command/die Query in einen Bus.
Als EntwicklerIn muss ich also wirklich nur einen Command oder eine Query in einem fachlichen Modul/Projekt etc. schreiben, um der API etwas neues beizubringen. 😊
Ein Livestream über einen fachbezogenen API wäre wirklich super
[gr] Das werden wir machen - der erste Livestream nach der (Livestream-)Sommerpause wird sich um dieses Thema drehen 😊
Vielen Dank für das tolle und lehrreiche Video!
Das Video kommt genau zur rechten Zeit! 😃
Ich denke aktuell über die Umsetzung einer API nach und hatte mir überlegt, ob ich dem REST Ansatz folgen soll, weil mir schien es so, als wenn dass der gängige Weg wäre. Wobei ich ursprünglich eigentlich viel mehr etwas in der Richtung der Empfehlung umgesetzt hätte.
Nach dem Video, finde ich euren Ansatz eigentlich erheblich besser 🙂
[gr] Das freut mich sehr, dass das Video zum richtigen Zeitpunkt kam 😊
Und viel Erfolg bei der Umsetzung!
@@thenativeweb Danke! 😊
Sehr interessante Sichtweise!
Ich kann dazu inhaltlich wenig beitragen, aber mein Eindruck ist, dass die API Endpunkte in SvelteKit-Projekten genau dieser fachlicher Ausrichtung entsprechen, die du im Video beschrieben hast. Aber das betrifft auch nur innerhalb einer Anwendung genutzte APIs.
Und ja ein längeres Video zum Aufbau von APIs wäre sehr interessant!
Vielen Dank für die prägnanten Definitionen und Einordnungen der Technologien.
Ich bin neu in der Webentwicklung und versuche mich gerade in die Thematik einzuarbeiten, aber nach dem Lesen diverser Blog Einträge, Diskussionen und dem überfliegen von Dokumentation war ich häufig genau so schlau wie vorher ohne die grundlegenden Funktionsweisen durchblickt zu haben, aber bei deiner Erklärung wurden on Point viele meiner Fragen beantwortet :)
Ich gebe Dir mal wieder bei allem Recht. Super erklärt und argumentiert.
[gr] Vielen lieben Dank 😊
Super Video. Erst neulich habe ich mich umfangreich über alle Vorteile und Nachteile informiert xD
[gr] Vielen lieben Dank 😊
Voll cool, so wie ihr eure APIs schreibt, so hab ich mir das auch bei meinem Minwork gedacht :D Schön, dass wir da einer Meinung sind. Sehe das bei REST so, dass es schön einfach ist, aber man kann es auch schön einfach verhunzen, weil REST an sich ja erst mal gar nicht so viel vorgibt. Außerdem ist das mit der Doku auch immer so eine sache, weil man REST ganz schnell sehr dynamisch aufbaut. Etwas dynamisches lässt sich nur schwer dokumentieren. GraphQL finde ich an sich gar nicht so verkehrt. Vor allem, wenn man sowas wie type-graphql verwendet, was einen Die Sache deutlich vereinfacht. Zu gRPC kann ich leider nix sagen, klingt aber erst mal auch ganz gut, nur halte ich von code generieren nix. Wenn dann kann aus dem Code etwas generiert werden, wie z.B. Typinformationen. So mache ich das. Ich hole die Typen von TypeScript in die Laufzeit hinein, sodass ich dann die API zumindest was die Typen angeht absichern kann. Zugriffsrechte sind dann wieder ein anderes Thema.
Moin Golo,
noch mehr gehypt scheint ja in letzer Zeit tRPC zu sein. Gilt das gleiche wie für gRPC?
Interessant, eure Art Apis zu bauen, habe ich mal als Student "frei nach Kopf" genauso implementiert und wurde dann von meinem Prof kritisiert, da es ja REST gibt und das kein Industriestandard sein :P Damals kannte ich REST noch gar nicht. Welch Zufall, sehr interessant
Ich finde die Idee mit dem "fachlichen HTTP" sehr gut und verständlich.
Die Ressourcen werden aber weiterhin wie in REST in der Url adressiert? Es gäbe also schon noch mehr Routen als eine Get und eine einzelne Post Route mit allen Infos?
Um etwas zu löschen würdet ihr einen Post verwenden?
[gr] Ja, es gibt schon noch mehr Routen als nur zwei, aber eben nur noch zwei Typen: POST zum Schreiben, GET zum Lesen.
Und ja, um etwas zu löschen, würden wir ein POST verwenden. Nur hieße diese Route dann nicht "Delete XYZ", weil es ja nicht um's Löschen geht - das ist ja nur der technische Effekt. Die Frage ist: WARUM willst Du löschen? Was ist die fachliche Intention?
Um es mal am Beispiel einer Todo-Liste zu machen, auf der Du Aufgaben notieren, editieren und abhaken kannst. Dann hättest Du zum Beispiel:
POST /note-todo
POST /edit-todo
POST /tick-off-todo
Und als Queries:
GET /remaining-todos
GET /ticked-off-todos
GET /all-todos
@@thenativeweb Nunja, löschen ist ja durchaus öfter mal auch etwas fachliches. Zb ein Item aus dem Warenkorb löschen..hier könnte die Route durchaus delete heißen.
Danke für die Erklärung, das ist sehr hilfreich.
@@davidelsner9391 [gr] Du löschst ein Item nicht aus dem Warenkorb. Du legst es zurück. Oder Du entnimmst es. Aber Du löschst es nicht.
Überleg mal, wenn Du im Supermarkt stehst und etwas im Einkaufswagen hast, was Du dann doch nicht nehmen möchtest: „Löschst“ Du das dann? 😉
@@thenativeweb
Das ist natürlich ein Punkt :)
Guten Morgen Golo,
in zwei Monaten starte ich meine Diplomarbeit, in der ich eine iOS-App entwickeln möchte. Die App soll eine von mir selbst programmierte GO-API verwenden, die auf eine MSSQL-Datenbank zugreift. Da ich bisher noch keine API programmiert habe, wäre ein Live-Stream von dir dazu für mich unglaublich hilfreich.
Danke im Voraus für deine Unterstützung! :)
Ja, euer Konzept nochmals genauer. Fehlermeldungen packt ihr je nach dem in den JSON-Respond?
Hey Golo,
erst mal vielen Dank für das Video, definitiv mal wieder was gelernt.
Ein bisschen konstruktives Feedback:
Eure Darstellung von GraphQL ist meiner Meinung nach etwas eindimensional. "Dass man auf der Server-Seite nie so sehr vorhersehen kann, was man für Abfragen bekommt" stimmt einfach nicht, weil ich ja (egal ob design-first oder code-first) definitiv die Inputs und ihre Typen vorgeben muss, das funktioniert also quasi wie bei REST. "Es ist leichter in performance-kritische Abfragen zu laufen" ist zwar richtig, das gilt aber für jede Implementierung, ist mir also etwas zu generisch und in dem Video zu sehr Fingerpointing auf GraphQL. Und für solche Probleme gibt's ja auch vorgefertigte Konzepte, "data loaders" bei GraphQL zum Beispiel.
Again: Sehr gutes Video, nur bei GraphQL evlt. etwas mehr Recherche investieren. Stichwort "Hasura" ist zum Beispiel auch stark im Kommen.
Moin Golo, schöne Zusammenfassung des Themas. Den Wunsch nach einem Livestream kann ich nur unterstützen.
Aber ein anderes Thema. Nervt dich nicht das globale Menü am Mac bei deinem großen Monitor? Ich habe ein ähnliches Set-up und das ist so ein Punkt, mit dem ich nicht zufrieden bin. Wie ist denn dein Workflow?
[gr] Danke für Deinen Kommentar und das Feedback 😊
Was Deine Frage angeht: Nö, das stört mich nicht. Ich brauche die Menüleiste aber auch so gut wie nie (höchstens rechts oben die Icons und die Uhrueit).
Das meiste läuft bei mir über Tastenkombinationen, weshalb ich das Menü so gut wie nie öffnen muss.
@@thenativeweb am liebsten wäre mir Alfred könnte sich da einklinken … aber er geht ja. Ist nur Jammern auf hohem Niveau ;)
Danke für das Video, sehr informativ!!!
[gr] Danke schön 😊
Kleine Anmerkung zu GraphQL: Queries sind HTTP GET's und Mutations sind HTTP POST's.
Keine Technologie schützt einen vor schlechtem API design und sorgt dafür, dass die Fachlichkeit die Entwicklung treibt. Darauf muss man als Team immer selbst achten. Ich glaube mit allen 3 Technologien kann man super fachliche APIs entwickeln, aber viele nutzen die Möglichkeiten der Technologie falsch. Dann wird auf einmal fachliche Logik in den Client verschoben, die API führt nur noch Datenbankoperationen aus und man hat gar keinen Überblick mehr, wer was wo macht. Oder es wird ein "Schema First" Ansatz gefahren und auf einmal sind die Daten im Fokus anstatt der Fachlichkeit.
Ich persönlich entwickle viel nativ mobile und deswegen reizt mich persönlich das feste Protokoll im Bezug auf Pagination, Error Handling, Status Codes, Discoveribility, Federated Requests und Code Generation von GraphQL am meisten. Man muss aber aufpassen, dass man den fachlichen Fokus nicht verliert.
Bei GraphQL sind alles http POST requests
@@daheck81 Nicht mehr. Der Standard lässt auch HTTP GET für Queries zu
GraphQL mit Hasura ist ein No-Brainer. gRPC ist denkbar auch für WebRTC (P2P) Lösungen. Golo, nimm doch bitte in Zukunft auch etwas differenziertere Überlegungen in deine Urteile auf. Danke LG
Die Behauptung, wenn man CRUD macht, kann man statt REST dem User auch direkt SQL geben, halte ich für zu kurz gedacht. Die REST API setzt nämlich die Zugriffskontrolle um, die man in den meisten SQL-Datenbanken nicht so feingranular in SQL abbilden kann und auch die Fehlermeldungen nicht so passend sind.
ich schreibe gerade mein eigenes ui framework, das in dei cloud deployed, im webbrowser läuft und als native app gebuildet werden kann und jede sprache im browser direkt übers backend supported. also für mich ist das kein ausnahmefall sondern die basis für meine arbeit. wieso sollte ich denn json benutzen, wenn ich auch direkt binärfiles nehmen kann
Ich habe solche Überlegungen schon länger. Das Video fast es wirklich sehr gut zusammen.
Die Frage ist jedoch wie man seine Kollegen davon überzeugt bekommt? Die meisten lieben ihre Crud APIs. Da kann man so schön Endpunkte sparen. 🙄
[gr] Das ist leider wirklich eine sehr, sehr gute Frage … es ist generell nicht einfach, Leute von den Nachteilen von CRUD zu überzeugen. Das betrifft nicht nur Entwicklung, auch das Management … sagen wir es mal so: Es ist mühsam 😉
Super Video, ich sehe das sehr ähnlich.
[gr] Danke für Dein Feedback 😊
Ich mache das schon seit fast 10 Jahren so, bin aber immer mehr in einen Mischmasch übergegangen, zB wo ein query auch als POST abgebildet wird, wenn ich zB mehrere query Parameter haben und lieber den Body anstatt URL params nutzen möchte.
Wir nennen es intern oft RESTless API oder RPC style HTTP API ☺️
Wie findet ihr trpc, wenn man komplett im js/ts Universum unterwegs ist?
trpc ist ganz nützlich, aber in erster Linie eine Bibliothek. Denke damit fällt das nicht in die Kategorie Rest, Graphql, grpc.
Ist graphql im Endeffekt nicht auch nur eine Bibliothek, wo man die Struktur vorher definiert?
trpc ist ja von der Struktur ähnlich wie grpc, bloß über http und du bist auf js/ts limitiert
@@Beolthorn Tatsächlich ist graphql eine Abfragesprache, genau wie SQL. Es gibt natürlich diverse Bibliotheken in vielen Programmiersprachen, die graphql implementieren.
Ja ich denke genau die unterschiede sind es, die es schwierig macht tRPC und gRPC zu vergleichen. Gerade weil tRPC Typescript only ist. Meiner Erfahrung nach macht tRPC da sind wo ich ein Monorepo habe und mein Backend und Frontend typisiert kommunizieren lassen will. Gerade REST, Graphql und gRPC richtet sich ja an verteilte Systeme. Meine Erfahrung in tRPC ist allerdings auch relativ begrenzt, als kleiner Disclaimer.
@@geeksy2278 tRPC spezifiziert auch ein schema, das es ja selbst zur kommunikation benutzt. du kannst zwar deine router und procedures so zusammenstellen, wie du willst, aber es folgt trotzdem einem pattern. dazu kommt, dass procedures entweder querys, mutations, oder subscriptions/observer sind. wieder ein pattern.
wenn tRPC "nur eine library" wäre, dürfte es sich von anderen HTTP clients wie axios oder GOT nicht unterscheiden.
@@FunctionGermany Ich glaube das Zitat von der tRPC Website fasst ganz gut zusammen was ich meine:
"Since GraphQL is designed as a language-agnostic specification for implementing APIs, it doesn't take full advantage of the power of a language like TypeScript.
If your project is built with full-stack TypeScript, you can share types directly between your client and server, without relying on code generation."
Dahinter steckt eben keine offenes Protokoll. Die Bibliothek ist speziell für Typescript-Apps entwickelt worden.
Für alle die Typescript im Frontend und im Backend zusammen nutzen ist tRpc einen Blick wert.
[gr] Das stimmt 😊
Ok gut.. als du sagtest kein rest war ich skeptisch. Aber sicherlich weil ich den Begriff anders interpretiere.. die fachliche Definition mit Post/get die bilde ich auch so ab, allerdings sagte ich dazu auch REST and CRUD - sicherlich fälschlicherweise, dennoch läuft ja im backend dennoch CRUD ab, auch wenn ich es implementiere allerdings nicht explizit vom Client sondern in der business(Server) Logik. Weiterhin arbeite ich idR mit store procedures also have im backend nur die Logik die den Fall abbildet
Ich finde GraphQL in Verbindung mit Nest.JS und Prisma eine sehr gute Lösung. GraphQL definiert allerdings die maximale Ausbaustufe einer Query und ist performancetechnisch sehr gut. Sicherlich braucht es etwas Zeit für die Vorbereitung, aber der große Vorteil, nicht für jede kleine Abwandlung einer Abfrage, einen neuen Einstiegspunkt definieren zu müssen, ist einfach unschlagbar.
Interessant wäre noch, wie man am besten mit versionierten APIs umgeht, ohne total wahnsinnig zu werden...
Bei Typescript gibt es noch tRPC
Mir fehlt SOAP in der Liste.... ;D
Haha 🤣
aber digger du vergisst hier ja auch das grpc auch gleichzeitg als service mesh benutzt werden kann. macht braucht halt einfach nur geile tools für grpc, aber es ist halt viel geiler als diese verdammten cors headers zu setzen, json zu senden und in jeder sprache einen server aufzumachen den du wieder neu programmieren musst, aio,flask etc. außerdem ist grpc streaming auch viel fortschirittlicher als websocket, siehe improbable
ts frontend + ts backend = trpc ^ ddd ✅
[gr] 😊
bin grad mit dem REST teil des videos durch. ich stimme dir bei den punkten zu REST zu, wenn wir über eine extern konsumierte API reden. wenn ich aber eine API in erster linie für das eigene frontend baue, halte ich eine dünne CRUD/REST schicht für sehr gut, da ich damit das system nicht mit mehr informationen anreicher als nötig. das geht natürlich nicht immer, aber manchmal hab ich halt ne einfache ressource, die ich zB per spring RestResource annotation auf das repository publishen und benutzen kann ohne einen controller zu schreiben.
Er sagte Soap ist tot 😂😂😂