|
|
|
|
Wie haltet ihr es denn mit API-Clients? Schreibt ihr die selbst oder generiert ihr die?
Hintergrund meiner Frage ist, dass wir verschiedenste APIs über eine Plattform intern anbieten. Bisher haben sich alle Leute immer ihre Requests selbst geschrieben, was ich den denkbar schlechtesten Fall finde, zumindest, solange man das häufig macht. Ich hatte das ganze mal als Python-Code abstrahiert (bzw. angefangen), aber so richtig glücklich bin ich nicht, das alles selbst zu machen und den ganzen Maintenance-Aufwand bei Änderungen zu bekommen. Ich weiß, dass es so Code-Generatoren gibt, die einem Clients für OpenAPI-spezifizierte Schnittstellen erzeugen, habe aber zu wenig Erfahrung damit. Ergibt es da überhaupt noch Sinn, selbstständig einen Client / Wrapper zu schreiben?
|
|
|
|
|
|
|
Du könntest einen GRPC-REST adapter vor die API setzen, dann kann jeder client seine stubs generieren.
Das ist eigentlich gar nicht so abwegig, grpc bringt alles nativ in der verwendeten Sprache mit was validation und exception-handling angeht und die Verwendung im client-code ist echt angenehm. Trotzdem hat man noch REST, um die API mal manuell aufzurufen.
Krakend kann sowas per Plugin: https://www.krakend.io/blog/krakend-grpc-gateway-plugin/
|
|
|
|
|
|
|
| Zitat von homer is alive
Wie haltet ihr es denn mit API-Clients? Schreibt ihr die selbst oder generiert ihr die?
Hintergrund meiner Frage ist, dass wir verschiedenste APIs über eine Plattform intern anbieten. Bisher haben sich alle Leute immer ihre Requests selbst geschrieben, was ich den denkbar schlechtesten Fall finde, zumindest, solange man das häufig macht. Ich hatte das ganze mal als Python-Code abstrahiert (bzw. angefangen), aber so richtig glücklich bin ich nicht, das alles selbst zu machen und den ganzen Maintenance-Aufwand bei Änderungen zu bekommen. Ich weiß, dass es so Code-Generatoren gibt, die einem Clients für OpenAPI-spezifizierte Schnittstellen erzeugen, habe aber zu wenig Erfahrung damit. Ergibt es da überhaupt noch Sinn, selbstständig einen Client / Wrapper zu schreiben?
| |
Selber API Clients schreiben ist echt rausgeschmissene Mühe. Genauso wie die Requests in Postman oder so zusammenzubauen. Wenn du nen Standard wie z.B. OpenAPI oder Swagger verwendest, gibt es für jede ordentliche Programmiersprache bzw. Framework einen fix-fertigen API Client, der sich automatisiert aus deinen Configs, Annotations oder whatever generiert.
|
|
|
|
|
|
|
| Zitat von derSenner OpenAPI oder Swagger
| |
+1
|
|
|
|
|
|
|
| Zitat von Swift
| Zitat von derSenner OpenAPI oder Swagger
| |
+1
| |
+1
|
|
|
|
|
|
|
| Zitat von SwissBushIndian
| Zitat von Swift
| Zitat von derSenner OpenAPI oder Swagger
| |
+1
| |
+1
| |
+1 (+ aktuell 7923 Zeilen für unsere aktuelle Spec.yaml )
|
|
|
|
|
|
|
+1
Wir generieren Server-Endpoints und Clients in Scala und Java (mit https://guardrail.dev/) sowie Clients in Typescript (mit irgendwas anderem was mir gerade entfallen ist).
Neues Backend-Feature kommt? Gleich mal mit dem Frontend-Team die Spec fertig machen und schon kann jeder die nächsten Wochen in Ruhe bauen.
|
|
|
|
|
|
|
Scroll hier so durch,.., coole Sachen machen die Leute hier, und ich so:
"Hmm, warum wird das div hier auf dem IE11 so komisch gestreched"...
|
|
|
|
|
|
|
IE wird nicht mehr supported, aus fertig. Spätestens seit Boostrap v5 auch den Support gedropped hat, sollte das jeder andere auch machen.
|
|
|
|
|
|
|
Nicht in dem kundenuniversum in dem ich herumfloate.. Hmm float :left könnte helfen... Danke pot
|
|
|
|
|
|
|
Ich hab heute ein VueJS2 + Webpack Projekt auf Vite umgestellt und dabei fast den Verstand verloren.
|
|
|
|
|
|
|
| Zitat von X-Tender
Nicht in dem kundenuniversum in dem ich herumfloate.. Hmm float :left könnte helfen... Danke pot
| |
Wir sagen den Kunden mittlerweile auch einfach: Update Browser or GTFO! Das müssten viel mehr machen, sonst ändert sich da nämlich nie was.
|
|
|
|
|
|
|
| Zitat von derSenner
IE wird nicht mehr supported, aus fertig. Spätestens seit Boostrap v5 auch den Support gedropped hat, sollte das jeder andere auch machen.
| |
Bootstrap
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Fabsn am 22.09.2021 11:34]
|
|
|
|
|
|
War halt ein Beispiel für ein Framework, dass großflächig verwendet wird und IE Support gedropped hat.
Dennoch finde ich Bootstrap auch nicht verkehrt. Generell sind, finde ich, sämtliche Frontend-Frameworks immer Pest oder Cholera, und ich bin froh, wenn ich mich da nicht groß damit beschäftigen muss. Bootstrap macht in der Riege aber meist sehr wenig Probleme, weil halt auch nicht übermäßig viel reingstopft wurde, dass man eh nie braucht.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von derSenner am 22.09.2021 11:42]
|
|
|
|
|
|
| Zitat von derSenner
Generell sind, finde ich, sämtliche Frontend-Frameworks immer Pest oder Cholera, und ich bin froh, wenn ich mich da nicht groß damit beschäftigen muss.
| |
Da hat aber noch jemand nicht Ember in den Fingern gehabt. :P
Denn Ember ist Liebe.
|
|
|
|
|
|
|
Na ja. Du findest halt auch PHP toll. Da mache ich lieber einen großen Bogen um Ember. :3
Edit: kurz reingeschaut. Ember mit Frameworks wie Bootstrap oder UiKit zu vergleichen, ist irgendwie... Nicht besonders sinnvoll.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SkunkyVillage am 22.09.2021 12:08]
|
|
|
|
|
|
Ich find PHP auch toll. Aber die Diskussion gab's ja schon vor einigen Seiten. Beschissenen Code kannste mit allem schreiben.
|
|
|
|
|
|
|
Ich hab ja auch bloß 1 Jokus in Anspielung an die Diskussion gemacht. :3
|
|
|
|
|
|
|
|
|
|
|
| Zitat von SkunkyVillage
Na ja. Du findest halt auch PHP toll. Da mache ich lieber einen großen Bogen um Ember. :3
Edit: kurz reingeschaut. Ember mit Frameworks wie Bootstrap oder UiKit zu vergleichen, ist irgendwie... Nicht besonders sinnvoll.
| |
In dem von mir zitierten Satz ist ja auch von "Frontend Frameworks" die Rede.
/ Und PHP ist mir eigentlich total egal. Ich benutze halt Laravel, weil es genau das macht, was es soll.
// Und wie es halt so ist, ne: Laravel benutze ich, weil es mir mal empfohlen wurde. Ich kenne sonst eigentlich keine Alternative, war von Laravel aber von Anfang an ziemlich beeindruckt darüber, wie viel Arbeit das einem einfach abnimmt. Ist ja afaik auch schon ein Elefant, scheint mir aber immer noch ziemlich nice zu sein.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Ameisenfutter am 22.09.2021 13:56]
|
|
|
|
|
|
|
Code: |
curl -s "https://laravel.build/example-app" | bash |
|
...
|
Code: |
Loading composer repositories with package information
Updating dependencies
Lock file operations: 110 installs, 0 updates, 0 removals |
|
Joa, Elefant. Demo-Project, 110 composer installs. Super.
|
|
|
|
|
|
|
|
|
|
|
Die werden doch nix böses tun...
|
|
|
|
|
|
|
Die vielleicht nicht, aber was, wenn da jemand dazwischen hockt
|
|
|
|
|
|
|
Hätte ich gewusst, was für ein elitäres Gehabe hier manche an den Tag legen, hätte ich den Thread besser nicht aufgemacht.
|
|
|
|
|
|
|
| Zitat von [KDO2412]Mr.Jones
|
Code: |
curl -s "https://laravel.build/example-app" | bash |
|
...
|
Code: |
Loading composer repositories with package information
Updating dependencies
Lock file operations: 110 installs, 0 updates, 0 removals |
|
Joa, Elefant. Demo-Project, 110 composer installs. Super.
| |
Wo ist da das Problem konkret?
|
|
|
|
|
|
|
| Zitat von Ameisenfutter
Hätte ich gewusst, was für ein elitäres Gehabe hier manche an den Tag legen, hätte ich den Thread besser nicht aufgemacht.
| | Es gibt Gründe, warum ich hier so wenig poste. Es ist nicht das elitäre Gehabe, sondern das ich noch viel, viel schlimmer bin
TDD or GTFO!
|
|
|
|
|
|
|
| Zitat von derSenner
| Zitat von [KDO2412]Mr.Jones
|
Code: |
curl -s "https://laravel.build/example-app" | bash |
|
...
|
Code: |
Loading composer repositories with package information
Updating dependencies
Lock file operations: 110 installs, 0 updates, 0 removals |
|
Joa, Elefant. Demo-Project, 110 composer installs. Super.
| |
Wo ist da das Problem konkret?
| |
Ich wollte nur mal kurz ein Demo-Projekt angucken und nicht Kaffee kochen gehen...
|
|
|
|
|
|
|
Macht hier eigentlich jemand so richtig serious-bussiness WebDev mit Microservices, API-Gateways, HighAvailability, Resilience, Skalierung, DDD, EventSourcing, CQRS, NoSQL, Read-/WriteModels, DevOps, Container, Kubernetes, CI/CD, OpenID/OAuth2.0? (Klingt wie ein schlechtes WebDev-Bullshit-Bingo, ist aber die Wahrheit! )
Habe die letzten 3 Jahre so ein Projekt mit 20 Microservices und 3 REST-APIs in C# mit .net Core entwickelt.
Seitdem wundere ich mich immer ein wenig, das es noch Leute gibt die tatsächlich ServerSideRendering mit PHP machen und quasi "alles" innerhalb der Request-Lifetime auf dem Server erledigen "müssen".
|
|
|
|
|
|
|
| Zitat von Ameisenfutter
Hätte ich gewusst, was für ein elitäres Gehabe hier manche an den Tag legen, hätte ich den Thread besser nicht aufgemacht.
| |
Was meinst du genau?
110 Composer Dependencies sind halt wirklich viel.
|
|
|
|
|
|
Thema: Software-Entwicklung 0 ( new SammelThread() ) |