Everand Logo

Welcome to Everand!

  • Discover millions of ebooks, audiobooks, and so much more with a free trial

    Only $11.99/month after trial. Cancel anytime.

    MQL: Eine hierarchische Abfragesprache mit TypeScript erstellen
    MQL: Eine hierarchische Abfragesprache mit TypeScript erstellen
    MQL: Eine hierarchische Abfragesprache mit TypeScript erstellen
    Ebook93 pages41 minutes

    MQL: Eine hierarchische Abfragesprache mit TypeScript erstellen

    By Thomas Mahringer

    ()

    Read preview

    About this ebook

    Eine der großen Fragen bei webbasierten Apps bleibt immer die nach dem Datenaustausch mit den Backends. Obwohl es inzwischen durchaus erprobte und zuverlässige Abfragemethoden wie OData und GraphQL gibt, sind diese für alle denkbaren Aufgabenstellungen ausgelegt und bringen deshalb auch immer einen gewissen Overhead in Entwicklung und Ausführung mit sich. Deshalb würde es sich doch anbieten, einfach eine eigene Abfragesprache zu entwicklen, die genau auf die Bedürfnisse der Applikation zugeschnitten ist und im Idealfall auch in der Sprache der Webanwendung, also TypeScript, verfasst ist. So kann man sich viel Overhead sparen und behält gleichzeitig alle Freiheiten.

    In seinem shortcut zeigt Thomas Mahringer, wie das gelingt. Er erklärt, wie Sie mit überschaubarem Aufwand in TypeScript ein Domänenmodell mit einem daraus erzeugten maschinenlesbaren Schema und einer hierarchischen, JSON-basierten Query Language mit typsicherer Grammatik erstellen. Im weiteren Verlauf zeigt er, wie mit dieser auf relationale Datenbanken zugegriffen werden kann und wie die Antworten auf dem Client weiter verarbeitet werden.
    LanguageDeutsch
    Publisherentwickler.press
    Release dateFeb 15, 2019
    ISBN9783868028454
    MQL: Eine hierarchische Abfragesprache mit TypeScript erstellen

    Read more from Thomas Mahringer

    Related to MQL

    Titles in the series (100)

    View More
    View More

    Related ebooks

    Databases For You

    View More
    View More

    Related podcast episodes

    Related articles

    • Article

      Auf Spurensuche

      Mar 3, 2022

      Auf Spurensuche
      10 min read

    • Article

      Briefautomat

      Apr 21, 2022

      Briefautomat
      10 min read

    • Article

      Vorschau auf 12/2021

      Oct 20, 2021

      Vorschau auf 12/2021
      1 min read

    • Article

      Vorschau auf 07/2021

      May 19, 2021

      Vorschau auf 07/2021
      1 min read

    • Article

      Gehäusedeckel Aufschrauben

      Apr 7, 2022

      Gehäusedeckel Aufschrauben
      10 min read

    • Article

      Rückschau

      Nov 3, 2021

      Rückschau
      7 min read

    • Article

      Teilen und Herrschen

      Sep 21, 2023

      Teilen und Herrschen
      4 min read

    • Article

      Silhouette

      Jul 21, 2022

      Silhouette
      3 min read

    • Article

      Teilen und Herrschen

      Sep 21, 2023

      Teilen und Herrschen
      4 min read

    • Article

      Im Zahlendschungel

      Jul 21, 2021

      Im Zahlendschungel
      7 min read

    • Article

      Tooltipps

      Apr 7, 2021

      Queues erstellen und Tasks steuern Quelle: https://github.com/leahneukirchen/nq Lizenz: Public Domain Alternativen: At, Task-Spooler Jobwarteschlangen kommen oft zum Einsatz, wenn es gilt, Aufgaben sequenziell abzuarbeiten. Neben kostenpflichtigen Lö

      4 min read

    • Article

      Vorschau auf 08/2021

      Jun 16, 2021

      Vorschau auf 08/2021
      1 min read

    • Article

      Getrennte Wege

      Aug 18, 2021

      Getrennte Wege
      3 min read

    • Article

      Tooltipps

      May 5, 2021

      Schlanker Texteditor Quelle: https://github.com/ilai-deutel/kibi Lizenz: MIT/Apache Alternativen: Kilo, Joe, Nano An Texteditoren besteht unter Linux kein Mangel. Neben komplexen Anwendungen wie Vi(m) oder Emacs bringen die großen Desktop-Umgebungen

      5 min read

    • Article

      Verletzungsrisiko

      Apr 7, 2021

      Verletzungsrisiko
      5 min read

    • Article

      Scharfer Wachhund

      Aug 4, 2021

      Scharfer Wachhund
      10 min read

    • Article

      Vermittlungszentrale

      Apr 7, 2021

      Vermittlungszentrale
      11 min read

    • Article

      Vorschau auf 11/2022

      Sep 22, 2022

      Vorschau auf 11/2022
      1 min read

    • Article

      Vogelperspektive

      Dec 1, 2021

      Vogelperspektive
      8 min read

    • Article

      Saubere Arbeit

      Aug 4, 2022

      Saubere Arbeit
      7 min read

    • Article

      Punkt, Komma, Strich

      Feb 3, 2022

      Punkt, Komma, Strich
      3 min read

    • Article

      Muster Finden

      Jul 21, 2021

      Muster Finden
      6 min read

    • Article

      Wolkenbruch

      Aug 18, 2021

      Wolkenbruch
      5 min read

    • Article

      Punkt, Komma, Strich

      Jan 20, 2022

      Punkt, Komma, Strich
      3 min read

    • Article

      Mustervergleich

      Apr 7, 2021

      Mustervergleich
      4 min read

    • Article

      Multitool

      Jul 7, 2021

      Multitool
      4 min read

    • Article

      Sprachvergleiche

      Jun 2, 2021

      Sprachvergleiche
      7 min read

    • Article

      Multitasking

      Nov 3, 2021

      Multitasking
      5 min read

    • Article

      Tux Liest

      Jan 5, 2022

      Bücher über Software-Patterns und Kafka Das allgegenwärtige Cloud-Computing verursacht diverse Seiteneffekte. Es begünstigt beispielsweise MicroserviceArchitekturen, deren lose gekoppelte Komponenten ständig Daten austauschen. Zudem weckt es mit sein

      2 min read

    • Article

      Bunte Blöcke

      Jun 22, 2023

      Bunte Blöcke
      5 min read

    Related categories

    Reviews for MQL

    0 ratings

    0 ratings0 reviews

    What did you think?

    Tap to rate

    Review must be at least 10 words

      Book preview

      MQL - Thomas Mahringer

      GmbH

      1 Mit TypeScript Metadata und Reflection ein Domänenmodell aufbauen

      TypeScript-Sprachkonstrukte ermöglichen es, mit überschaubarem Aufwand einen modellgetriebenen Ansatz aus folgenden Elementen zu etablieren: einem Domänenmodell, einem daraus erzeugten maschinenlesbaren Schema und einer pragmatischen, hierarchischen Query Language.

      Webbasierte Applikationen haben sich zu Rich Clients entwickelt. Einer der Schwerpunkte bei datengetriebenen Rich Clients ist zweifellos ein möglichst effizienter und wartungsfreundlicher Datenaustausch mit Backends. Im Laufe der Zeit haben sich generische Abfragemethoden entwickelt, so z. B. OData, Facebook GraphQL oder Netflix Falcor. Da sie für möglichst breite Aufgabenstellungen konzipiert sind, bringen sie auch einen gewissen Overhead in Entwicklung und Ausführung mit sich. Wir wollen den Versuch wagen, mit den Konstrukten von TypeScript eine einfache, aber für die eigenen Bedürfnisse gut anpassbare Abfragesprache zu definieren. Die Basis dafür bildet ein Domänenmodell, das normale TypeScript-Klassen um Metadaten anreichert und aus dem ein maschinenlesbares Schema erzeugt wird. Letztendlich werden wir die in dieser Abfragesprache definierten Queries am Backend generisch auf eine relationale Datenbank mappen und das Ergebnis am Client typsicher verarbeiten. Durch die durchgängige TypeScript-Verwendung ersparen wir uns viel Overhead und schaffen Freiheitsgrade bei Design und Umsetzung.

      Wissensmanagement oder Enterprise Relationship Management

      Lassen Sie uns mit einem Beispiel aus der Praxis starten: In einem System, in dem es grob gesagt um das effiziente Verwalten und Wiederauffinden von Wissen oder Enterprise Relationship Management im weitesten Sinne geht, wird eine Vielzahl von Objekten logisch in einer netzwerkartigen Struktur gespeichert (Abb. 1.1).

      Abbildung 1.1: Verwaltung eines Wissensnetzwerks, einer Ontologie

      Die physische Speicherung soll jetzt noch nicht relevant sein, sondern nur, dass die Objekte sehr stark miteinander vernetzt sind: Personen, Kunden, Lieferanten, Verträge, Angebote, Mails, Projekte, Teilprojekte, Telefonate, Ressourcen, Aufgaben, Termine, Mitarbeiter und viele mehr. Schaut man sich das Ganze aus einer Domain-driven-Design-Sicht an, fällt schnell auf, dass sich keine klare hierarchische Struktur oder Aggregate Root finden lässt. Je nachdem, wer in welcher Rolle und welchem Anwendungsfall darauf sieht, ergeben sich beliebig viele Einstiegspunkte in das Beziehungsnetzwerk. Ein Projektleiter wird z. B. vorrangig über das Projekt einsteigen und will von dort aus möglichst schnell die zugehörigen Informationen finden. Ein Vertriebsmitarbeiter ist dagegen fast ausschließlich an der Sicht auf seine Kunden interessiert.

      Das Grundproblem: Endpoint Mania, Data Overfetching und Underfetching

      Wie man sich leicht vorstellen kann, ist nicht nur die endanwenderfreundliche User Experience eine Herausforderung, sondern auch, wie man die Datenabfragen möglichst effizient gestaltet. Abbildung 1.2 zeigt einen naiven Ansatz: Von einem REST-Endpunkt wird zunächst „meine Kunden" (eine Liste mit den IDs und Grunddaten der Kunden) geladen, danach werden die für den jeweiligen Screen relevanten Daten jeweils wieder über einen REST-Endpunkt geladen: die Anzahl der Einkäufe des Kunden, seine Stars (Bewertungen) usw.

      Abbildung 1.2: Ein naiver Ansatz, der N+1 Roundtrips verursacht

      Dieser naive Ansatz ist zur Laufzeit natürlich nicht haltbar: Wir verursachen N+1 Roundtrips vom Client zum Server und potenziell auch zur Datenbank.

      Ein anderer, ebenfalls naiver Ansatz wäre es, alle benötigten Daten für den Screen auf einmal zu laden, z. B. in einem REST-Endpunkt: „Lade alle Kunden und ihre Zusatzdaten für den Screen ‚Meine Kunden‘. Wenn wir dann einen weiteren Use Case oder Screen, z. B. „Kunden mit offenen Bug-Anfragen umsetzen, benötigen wir wieder etwas andere Daten, beispielsweise die Anzahl der offenen Bugs des Kunden oder seine Kundenzufriedenheit. Für diesen Fall liefert unser zuvor verwendeter Endpoint zu wenige Daten: sogenanntes Underfetching liegt vor. Wenn wir immer genau die passenden Daten pro Screen laden wollen, laufen wir schnell in eine Endpoint Mania (viele Endpoints für viele Use Cases), die unsere App nach kurzer Zeit unwartbar macht.

      Last but not least versuchen wir es gleich mit dem Ansatz „alles in Bausch und Bogen": Wir laden sämtliche Daten, die wir zu einem Kunden benötigen: Grunddaten, Anzahl der Käufe, seine Stars, Anzahl der offenen Bugs, seine Zufriedenheit usw. Offensichtlich haben wir dann aber ein Overfetching, denn von all den geladenen Daten benötigen wir pro Screen nur einige wenige. Wir stecken in einem Dilemma: Viele kleine CRUD-ähnliche Services oder große/breite Services mit umfangreichen Rückgabemengen.

      Navigieren im Netzwerk, jetzt wird’s hierarchisch

      Zusätzlich zur

      Enjoying the preview?
      Page 1 of 1