TypeSpec: Neue Sprache für API-zentrierte Entwicklung

 (typespec.io)
6 Punkte von GN⁺ 2024-05-02 | 1 Kommentare | Auf WhatsApp teilen
  • TypeSpec ist eine neue Sprache für API-zentrierte Entwicklung und wurde entwickelt, um die Anforderungen von API-Entwicklern, -Architekten und -Managern zu erfüllen.
    • Es wurde in einem Umfeld entwickelt, in dem es immer schwieriger und wichtiger wird, konsistent qualitativ hochwertige APIs und passende Erlebnisse bereitzustellen.
    • TypeSpec ist mehr als nur eine Sprache; es ist eine Plattform, die Abstraktion ermöglicht, die Wiederverwendung von Code fördert und moderne Tools für eine schnelle Entwicklung einsetzt.

Hauptmerkmale von TypeSpec

  • Interoperabilität
    • TypeSpec ist keine einfache API-Beschreibungssprache, sondern eine hochrangige Definitionssprache, mit der sich APIs definieren und gleichzeitig für verschiedene Protokolle, Clients, Server und Dokumentation ausgeben lassen.
    • Es ist mit branchenweiten API-Definitionssprachen interoperabel und überbrückt dadurch die Lücken zwischen verschiedenen Optionen.
  • Produktivität
    • TypeSpec bietet ein hervorragendes Entwicklererlebnis, das den Daten- und API-Definitionsprozess angenehmer und produktiver macht.
    • Die Sprache ist prägnant und erlaubt es, komplexe Daten- und API-Formen mit minimalem Aufwand zu definieren.
  • API-Muster
    • TypeSpec kapselt gängige Datentypen, API-Muster und Richtlinien in wiederverwendbare, hochrangige Bausteine, die team- oder Ökosystem-weit geteilt werden können, um die API-Qualität zu verbessern.
  • Vertrautheit
    • TypeSpec fühlt sich durch die Inspiration aus TypeScript und C# vielen Entwicklern vertraut an und ist leicht zu erlernen.
  • Erweiterbarkeit
    • TypeSpec kann über benutzerdefinierte Dekoratorvokabulare und Typvorlagen erweitert werden, sodass APIs in Geschäfts- oder Anwendungslogik-Domänen modelliert werden können.
  • Ökosystem
    • Mit TypeSpec lassen sich gemeinsame Typen, Sprach-Erweiterungen, Linter und Emitter als Pakete bündeln und intern in der Organisation oder im gesamten Ökosystem über npm bereitstellen.

Community und Zusammenarbeit

  • Einsatz bei Microsoft
    • Microsoft setzt TypeSpec ein, um den API-Entwicklungsprozess zu revolutionieren.
    • Viele Azure-Dienste haben TypeSpec übernommen, und deren Anzahl wächst täglich.
    • Das Microsoft-Graph-Team nutzt das Potenzial von TypeSpec, um die Produktivität zu steigern und die Anpassung zu vereinfachen.
  • Aufruf zur Teilnahme
    • TypeSpec ist mehr als eine Sprache – es ist eine Community.
    • Alle Entwickler mit unterschiedlichen Hintergründen sind eingeladen, an der offenen Beta teilzunehmen und die Stärke von TypeSpec selbst auszuprobieren.

Meinung von GN⁺

  • TypeSpec wirkt wie eine API-Definitionssprache mit hohem Abstraktionsniveau, die die Art und Weise der API-Entwicklung grundlegend verbessern könnte.
    • Der "API First"-Ansatz wird unterstützt und kann die Entwicklungseffizienz sowie die Produktqualität verbessern.
    • Durch die breite Protokollunterstützung, Erweiterbarkeit und ein starkes Ökosystem dürfte TypeSpec in vielen Entwicklungsszenarien einsetzbar sein.
  • Da die Einführung einer neuen Sprache jedoch immer mit Kosten für das Erlernen verbunden ist, sollte vor einer Team-Einführung eine ausreichende Schulung vorausgehen.
    • Es ist positiv, dass man versucht hat, die Lernkurve durch die Übernahme der Syntax von TypeScript und C# zu senken.
  • Es scheint notwendig, die Unterscheidungsmerkmale gegenüber bestehenden API-Definitionssprachen mit ähnlicher Funktion (wie Swagger, RAML, API Blueprint usw.) klarer herauszuarbeiten.
    • Beispielsweise, wie bestehende Grenzen überwunden werden und wie einfach Migrationen möglich sind.
  • Der Umstand, dass Microsoft TypeSpec intern zuerst nutzt und es durch Dogfooding weiter verbessert, wirkt vertrauenswürdig.
    • Da es erst seit kurzer Zeit als Open-Source-Projekt öffentlich verfügbar ist, werden kontinuierliche Weiterentwicklung und Community-Support in den kommenden Jahren entscheidend sein.
  • Die Richtung der Standardisierung und verbesserten Wiederverwendbarkeit in der API-Gestaltung ist richtig, zugleich entsteht der Eindruck, dass versucht wird, zu viele Probleme auf einmal zu lösen.
    • Es wäre sinnvoll, mit klaren Prioritäten schrittweise Funktionen zu verstärken.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-05-02
Meinungen auf Hacker News

  • Es gibt bereits TypeScript-Typen für APIs, deshalb habe ich https://github.com/vega/ts-json-schema-generator gebaut, das direkt aus dem Source JSON-Schemas erzeugt.
    Die Funktionsumfänge der beiden Sprachen unterscheiden sich etwas, daher gibt es auch seltsame Stellen, aber wir nutzen es seit Jahren gut. Wenn man kein TypeScript hat oder die API-Oberfläche klein genug ist, dass es okay ist, die Typen erneut zu schreiben, lohnt sich auch ein Blick auf TypeSpec. Es ist auf jeden Fall besser, als JSON-Schemas von Hand zu schreiben.

  • Neben dem YAML von OpenAPI sieht alles gut aus, das wirkt also fast wie Schummeln. Trotzdem halte ich OpenAPI nach wie vor für eine der besten Entwicklungen.
    Andererseits habe ich schon ziemlich gehofft, dass sich TypeScript als Schema-Sprache etabliert. Genauer gesagt: der überraschend große nicht-imperative, nicht-funktionale Teil davon. Mein erster Eindruck ist ungefähr: „Was wäre, wenn man JavaScript aus TypeScript entfernt, nur die Typen für JSON übrig lässt und Metadaten zur Beschreibung von Endpoints hinzufügt, damit es zum faktischen Nachfolger von OpenAPI und WSDL wird?“

    • „Neben dem YAML von OpenAPI sieht alles gut aus“ – Herausforderung angenommen.
      https://github.com/bufbuild/protovalidate/blob/main/examples...
    • Das TypeScript-Typsystem ist sehr fortgeschritten, daher scheint es unmöglich, Bindings für alle wichtigen Sprachen zu erstellen und sie dabei trotzdem jeweils idiomatisch zu halten. Für eine API-Sprache ist etwas sehr Einfaches und Intuitives besser.

  • Ich nutze TypeSpec seit Kurzem für APIs und suchte ein Werkzeug, mit dem man APIs ähnlich wie bei GraphQL beschreiben kann, aber mit einem Design-first-Ansatz.
    Alle OpenAPI-Editoren waren viel zu träge, und die Datenbeziehungen innerhalb der API wurden nicht gut sichtbar. TypeSpec war genau das Werkzeug, nach dem ich gesucht hatte, und hat hier wirklich geholfen.

  • Microsoft sagt zwar, man glaube an den Wert von „Dogfooding“, also die eigenen Produkte selbst zu nutzen, aber wenn man sich das chaotische Ökosystem für native Windows-Desktopentwicklung oder die Verbreitung von Xamarin/MAUI bei Mobile-Apps ansieht, wirkt es nicht so.

    • Windows betreibt Dogfooding mit allen Optionen für native App-Entwicklung gleichzeitig.
    • Dogfooding bedeutet nicht, bei jeder neuen Technologie alles von Grund auf neu zu schreiben.
    • Es könnte auch eine neue Richtlinie sein oder ein Fall, der nur für dieses Produkt gilt und sich gut vermarkten lässt.
      Ich habe E-Mails über Microsoft Graph verwaltet, und wenn Outlook das nutzt, wäre ich ziemlich überrascht.

  • Da es von Microsoft kommt, wirkt es wie eine Antwort auf GraphQL. Wenn sie intern Dogfooding betreiben, könnte die Tool-Qualität einigermaßen besser sein als bei etwas, das ein Open-Source-Konsortium hastig zusammengezimmert hat.
    Ich bin noch nicht überzeugt, aber es scheint das Potenzial zu haben, mehr Aufmerksamkeit zu bekommen.

    • Ich arbeite im Team, und TypeSpec mit GraphQL gleichzusetzen ist schwierig; deshalb kann TypeSpec allein diese Rolle kaum einnehmen.
      GraphQL bringt viele starke Annahmen mit, etwa zu Protokoll, Fehlerbehandlung und Query-Semantik, die für den Bau konkreter Anwendungen nötig sind. Der Kern von TypeSpec ist dagegen eher eine annahmenfreie DSL zur Beschreibung von APIs. Bestimmte Protokoll-Bindings werden als Libraries hinzugefügt, und eine GraphQL-Library ist schon seit Langem etwas, das wir prüfen.
      Kurz gesagt: Wenn Microsoft ein Bündel von Annahmen baut, das ähnliche Szenarien wie GraphQL löst, kann TypeSpec in diesem Kontext als API-Beschreibungssprache dienen. Aber diese Annahmen mit TypeSpec selbst gleichzusetzen, wäre nicht richtig.

  • Ich konnte die Kernfrage nach den unterstützten Ausgabesprachen nicht finden. Bleibt einem nur, nach OpenAPI zu exportieren und dann einen der dortigen schrecklichen Generatoren zu verwenden?

    • Man kann eigene Emitter bauen, und in der Dokumentation steht, wie das geht. Unser Team hat einen Custom-Emitter für TypeSpec gebaut, der SDKs und Library-Pakete ausgibt.

  • Sieht aus wie WSDL in einer TypeScript-Version.
    https://en.wikipedia.org/wiki/Web_Services_Description_Langu...
    Wird es WSDL überleben?

    • Wir benutzen WSDL immer noch, genauer gesagt die Plattform, auf der ich arbeite. Für neue Technologien mag es nicht beliebt sein, aber es lebt noch. Man kann darüber schimpfen, aber generiertes XML ist besser als das Generieren von YAML.
    • Vielleicht ist dir das schon klar, aber die genauere Analogie ist eher WSDL+SOAP.
      WSDL und SOAP sind in XML definiert, und SOAP beschreibt XML. Die Popularität dieser Technologien folgte dem Aufstieg und Niedergang von XML insgesamt. TypeSpec beschreibt JSON und protobuf; wenn die Popularität dieser Formate nachlässt, wird TypeSpec wahrscheinlich ebenfalls an Beliebtheit verlieren.
    • Das Problem von WSDL war, dass es von mehreren Ausschüssen großer Unternehmen entworfen wurde. Deshalb war es inkonsistent und aufgebläht. Dasselbe galt für viele XML-bezogene Standards.
      Heute werfen große Unternehmen lieber ihre eigene Lösung in den Markt, um ihn zu besetzen, statt zusammenzuarbeiten. Dadurch entstehen manchmal bessere Ansätze, weil ein einzelnes Team auf ein einheitliches Ziel fokussiert ist. Das ist besser, als zehn Anbieter mit jeweils eigenen Agenden zufriedenstellen zu wollen.

  • Es wäre schön, wenn man TypeSpec-Dateien in TypeScript oder anderen Sprachen einfach importieren und automatisch TypeScript-Typen erhalten könnte.
    Codegenerierung ist umständlich und fehleranfällig.

    • Ich bevorzuge im Allgemeinen Codegenerierung. Mir ist nicht klar, warum sie fehleranfälliger sein sollte als andere Ansätze.
      Im Gegenteil kann sie das Debugging erleichtern, weil Fehler nicht hinter zwei Abstraktionsebenen versteckt sind. Bei generiertem Code kann man außerdem Build-Schritte hinzufügen, um Schwächen oder Bugs des Generators zu umgehen; bei anderen Ansätzen muss man sie oft einfach hinnehmen.
      Den Punkt „umständlich“ verstehe ich. Direktes Feedback ist natürlich besser, als den Build erneut laufen zu lassen, daher sind die Vorteile der anderen Seite in Bereichen mit vielen Iterationen ebenfalls groß.
    • Es sieht TypeScript auch sehr ähnlich. Warum sollte man überhaupt nicht TypeScript für die API-Beschreibung verwenden? Man bekäme TypeScript-Typen und könnte das OpenAPI-Schema, das unter /openapi bereitgestellt wird, auch direkt zur Laufzeit generieren.

  • Kann YAML für die gewünschte Toolchain transformiert werden?
    So wie es CORBA IDL vor 25 Jahren gemacht hat, wäre eine High-Level-IDL schön, die Schemas und Stubs für mehrere Sprachen generiert.

    • Vor ein paar Tagen habe ich meinem OpenAPI-3-basierten Codegenerator Unterstützung für TypeSpec als Eingabespezifikation hinzugefügt.
      Das war ziemlich einfach, weil eine API bereitgestellt wird, die in OpenAPI-Dokumente konvertiert (https://github.com/mnahkies/openapi-code-generator/pull/158).
      Ich konzentriere mich darauf, sowohl Client-SDKs als auch Server-Stubs zu generieren, unterstütze bisher aber nur TypeScript. Wenn ich mit der Qualität der TypeScript-Templates zufrieden bin, möchte ich irgendwann auch andere Sprachen hinzufügen.
    • Die OpenAPI- und JSON-Schema-Emitter können YAML erzeugen.

  • Spezielle Sprachen sind schwer zu vermitteln und bedeuten auch für das Team, das sie entwickelt, erheblichen Mehraufwand.
    Die Leute wollen keine spezielle Sprache lernen. Außerdem muss man das gesamte Sprachökosystem an Tools bauen, etwa Compiler, Dokumentation, Language Server, IDE-Integration und Dependency Management.
    Ähnliche Versuche sind WaspLang und DarkLang, aber ich habe noch nicht gesehen, dass sie in der Praxis oder auf HN in nennenswertem Umfang genutzt werden. Besser ist es, bestehende Sprachen zu verwenden und sich auf den Mehrwert zu konzentrieren.
    Ich habe persönlich auch an etwas mit ähnlichem Nutzen gearbeitet, nämlich „Source of Truth -> alles“, und einen Teil dieser Schmerzen selbst erlebt.
    https://github.com/hofstadter-io/hof
    Die Idee ist CUE + text/template = ein Generierungs-Tool, das nicht auf APIs beschränkt ist.

    • Entweder man nutzt das hier oder schreibt OpenAPI-YAML direkt. Selbst für Leute, die YAML kennen, ist es damit viel einfacher, eine grundlegende OpenAPI-Definition zu erstellen und zu verwenden, als OpenAPI-Dokumente von Hand zu schreiben. Das manuelle Schreiben ist wirklich schmerzhaft.
    • Mit dem Aufkommen generativer KI-Programmierung geraten neue Sprachen noch stärker ins Hintertreffen. Selbst ein objektiv besseres neues Framework kann in der tatsächlichen Produktivität schlechter abschneiden, wenn die KI nicht darauf trainiert wurde.
    • Danke für hof. Ich überlege, es in einem Projekt auszuprobieren. Wie ist der aktuelle Projektstatus? Die jüngsten Commits scheinen weniger geworden zu sein, daher frage ich mich, ob es derzeit stabil ist und man es einfach so verwenden kann.