- Ich nutze es seit etwa einem Jahr und habe möglichst viele Projekte auf EdgeDB umgestellt
- EdgeDB ist eine auf Postgres aufbauende Graph-/relationale Datenbank
→ Die bestehende Engine blieb zwar erhalten, aber aus Sicht der Nutzer hat sich alles verändert. Die größte Veränderung sind die Abfragesprache und die Tools
Abfragesprache
- EdgeDB hat kein SQL, sondern verwendet mit EdgeQL eine eigene Sprache – und das ist ein Gamechanger
- Nachdem ich es einmal benutzt hatte, wollte ich nie wieder zu SQL zurück
→ Starke Typisierung, objektorientiert, Deep Queries sind extrem einfach und es passt gut dazu, wie Menschen über Datenabfragen nachdenken (niemand denkt schließlich in JOINs)
- Ich war zwar schon früher kein Fan von SQL, aber es gab faktisch keine Alternative
- Nach ein paar Tagen Lernen und Ausprobieren mit dem fantastischen Tutorial im Buchstil wurde mir klar, dass DB-Schema-Modellierung Spaß machen und leicht sein kann
→ Die Komplexität von SQL ist verschwunden, und mir wurde bewusst, wie ineffizient und seltsam SQL als Abfragesprache eigentlich ist
- EdgeQL ist leicht zu lernen, und mit Quickstart und Überblick kann man etwa 80 % davon erfassen
- Ich mag EdgeQL so sehr, dass ich mir wünschen würde, es würde zu einem eigenständigen Standard werden. Es wäre großartig, wenn es zum Beispiel etwas wie EdgeDBLite gäbe, das EdgeQL für dateibasierte DBs nutzbar macht
Tooling
- Es folgt dem heutigen Muster, mit einem einzigen Binary alles ausführen zu können (wie bei Go oder Flutter)
→ Server installieren und aktualisieren, DB erstellen/löschen, REPL, Migrationen, Backups und Projektverwaltung usw.
→ Und in den meisten Fällen gilt einfach: "It Just Works"
- EdgeDB hat die Art, wie man mit einer DB interagiert, neu erfunden
→ Mit dem Konzept von "Projects" verbindet es sich automatisch mit der DB und funktioniert einfach, ganz ohne DSN oder Konfigurationsaufwand
→ Im Vergleich dazu ist es extrem erfrischend, nicht mehr den exakten SQL-Befehl suchen zu müssen, um localhost seit über 10 Jahren Root-Zugriff zu geben
Funktionen
- Sehr einfache Modellierung von Many-to-Many-Beziehungen
- Eingebettetes GraphQL (direkte Verbindung vom Frontend aus möglich)
- Computed-Eigenschaft
rating := math::mean(.ratings.score)
- Backlinks: Links in umgekehrter Richtung verfolgen
→ select User.<author; durchsucht Tabellen, die mit einem Feld namens author auf User verweisen
uuid, Collection-, Scalar-, Abstract- und viele weitere Typen (mein Favorit ist cal::local_datetime)- Solche furchteinflößenden Dinge wie Inheritance, Constraints und Introspection
Bisherige Erfahrungen
- Ich nutze es seit etwa einem Jahr. Zuerst habe ich ein kleines privates Projekt migriert, später dann eines der Projekte in meiner Firma
- Die meisten meiner Arbeiten sind kleine, praktische Services für Endnutzer. Daher hatte ich oft den Luxus, allein verantwortlich zu sein und das am besten passende Tool auswählen zu können
- Die meiste Zeit mit EdgeDB war eine "It Just Works"-Erfahrung
- Die meisten Dinge lassen sich leicht finden, und die Dokumentation ist hervorragend (wirklich eine der besten Dokumentationsseiten, die ich je gesehen habe)
Ob es für Produktion geeignet ist
- Seit letztem Herbst "im Produktionseinsatz"
- Manche legen in "im Produktionseinsatz" zwar etwas mehr hinein als nur "wird tatsächlich genutzt", aber trotzdem …
- Als das Kommandozeilen-Tool refaktoriert wurde, musste ich Automatisierungsskripte leicht anpassen, aber das war keine große Sache
- Innerlich war ich darauf vorbereitet, als Early Adopter den Preis für das Risiko zu zahlen, aber bisher gab es keine Probleme
Ausdrucksstärke von EdgeQL
- Ich bin endlich davon befreit, ständig nach SQL-Snippets zu googeln und Umgehungen für ORM-Beschränkungen zu suchen
- Mit EdgeQL kann ich genau das ausdrücken, was ich aus der DB herausbekommen möchte, und es ist tatsächlich lesbar und verständlich (auch für andere Entwickler)
- Wegen EdgeQL lassen sich Transaktionen manchmal sogar vermeiden. Mehrfach verschachtelte Updates sind innerhalb einer einzelnen Query möglich
→ "Simplicity is complicated"
Migrationen
- Eines der coolsten Dinge ist, dass Migrationsfunktionen eingebaut sind
- Man ändert das Schema und ruft
edgedb migration create auf, dann wird eine Migrationsdatei erzeugt,
und mit edgedb migration apply auf dem Server wird sie direkt angewendet
- Migrationen sind über Hashes miteinander verknüpft, daher kann man nicht versehentlich irgendeine zufällige einzelne anwenden und alles kaputtmachen
- Beim Erstellen einer neuen Migration ist der Standard interaktiv, sodass alle Änderungen in der Kommandozeile bestätigt werden
Performance
- Ich verarbeite keine großen Datenmengen, daher brauche ich keine besonders hochperformante DB
- Da darunter aber Postgres läuft, ist die Performance im Vergleich zu anderen DBs kein Problem
- EdgeDB selbst ist in Python geschrieben (Go wäre mir lieber gewesen, aber die Entwickler scheinen mit Python vertrauter zu sein)
Go-Client-Bibliothek
- Da ich Go verwende, war es gut, dass es eine native Go-Bibliothek für EdgeQL gibt
- Es gibt offizielle Bibliotheken für Typescript/Javascript, Python und Go, während .Net und Elixir von der Community unterstützt werden
Upgrades
- EdgeDB abstrahiert die Komplexität rund um Serverversionen und Updates
- Die EdgeDB-CLI erledigt das standardmäßig selbst. Wenn es ein neues Update gibt, zeigt sie es an und führt das Upgrade durch
→ Verdächtig reibungslos
- Derzeit ist 2.0 RC erschienen, aber ich mache mir überhaupt keine Sorgen. Meine bisherigen Erfahrungen lassen mich glauben, dass es sicher und einfach ablaufen wird
Kommunikation und Support
- Als Early Adopter bin ich sehr zufrieden damit, wie schnell ich über die offiziellen EdgeDB-Kanäle Antworten und Hilfe bekomme
EdgeDB 2.0
- Mit 2.0, das morgen veröffentlicht wird, kommen gute neue Funktionen hinzu
- EdgeDB UI: Web-App mit visuellem Schema-Editor, REPL usw.
- Gruppenabfragen, globale Schemavariablen, objektspezifische Sicherheit, Direct EdgeQL over HTTP usw.
Was ich nicht mag oder worüber ich mir Sorgen mache
- Zusagen zur Kompatibilität
- Bisher war alles gut. Minor-Updates ohne Kompatibilitätsbruch
- Es wäre schön, wenn es ein klares Commitment zur Kompatibilität gäbe
- Das wachsende Feature-Set
- Es gibt jetzt schon mehr Funktionen, als ich eigentlich brauche, und es werden immer mehr
- Je mächtiger EdgeQL wird, desto unschärfer wird die Grenze zwischen DB und Server, sodass man sich fragt: "Gehört das ins Backend oder in ein kluges DB-Schema?"
- Die Richtung, mit einem eingebetteten HTTP-Server in den meisten Projekten den Backend-Server vollständig zu ersetzen, wirkt vernünftig … aber ich möchte einfach eine stabile DB mit dieser großartigen Abfragesprache und Engine haben
- Jedenfalls hoffe ich, dass EdgeDB stabil und konsistent bleibt und die Zahl der Funktionen nicht zu stark anwächst. Schon das aktuelle Feature-Set ist hervorragend
Fazit
- Für künftige Projekte habe ich nicht vor, klassische RDBs überhaupt noch in Betracht zu ziehen
- Zu SQL zurückzukehren wäre für mich so, als würde man von Flutter zu Ncurses oder von Go zurück zu Assemblersprache wechseln
- Für mich ist EdgeDB der größte Fortschritt im DB-Bereich der letzten 20 Jahre
- Vielleicht ändert sich das mit noch mehr Erfahrung, aber in über einem Jahr Nutzung hat nichts diese Freude getrübt
- Je länger ich EdgeDB nutze, desto mehr vertraue ich ihm
- Alles, was das EdgeDB-Team bei EdgeDB selbst, der Sprache, der Website, den Tools und der Community geleistet hat, ist enorm beeindruckend
→ "Mad respect to the team"
- Und es wirkt, als hätten sie gerade erst mit dem Aufwärmen begonnen
10 Kommentare
Dadurch habe ich EdgeDB kennengelernt und nutze es sehr gut! Vielen Dank~
Es sieht so aus, als würden sie einen ähnlichen Weg wie Prisma einschlagen. Ich nutze Prisma zwar gern, aber bei der Performance gibt es viele Punkte, die ich schade finde — das Benchmark-Ergebnis macht mich schon etwas neugierig?
Die Syntax ist allerdings nicht so ganz mein Stil … (ich nutze auch Protobuf, aber auch die Conversion-Beispielcodes sind etwas …)
Bevorzugen andere solche GraphQL-ähnlichen Syntaxen? Am Ende ist das Backend für mich ohnehin RDS, also wird dazwischen ja eine Conversion stattfinden — wenn das nicht klar ersichtlich ist, bin ich eher zurückhaltend …
Nachdem ich diesen Beitrag gesehen habe, fand ich ihn interessant und lerne seitdem weiter dazu.
Allerdings gibt es wohl noch nicht viele Suchergebnisse, wenn man an einer Stelle hängen bleibt, wahrscheinlich weil alles noch in einem frühen Stadium ist.
Es gibt zwar einen Discord-Kanal, aber ich dachte, es wäre gut, wenn heimische Entwickler bequem Fragen stellen und beantworten könnten, deshalb habe ich einen Open-Chat-Raum erstellt.
https://open.kakao.com/o/gtGY0Gve
Ich habe es mir auch notiert, weil ich es ausprobieren möchte.
Nachdem ich diesen Beitrag gelesen und das Tutorial vollständig durchgearbeitet habe, überzeugt es mich noch mehr.
Interessant. Eine Welt ohne SQL scheint wirklich etwas zu sein, zu der man nicht mehr zurückkehren kann..
Klingt interessant.
Beeindruckend!
Bei den GraphDB-Varianten hatte ich ArangoDB mit großem Interesse im Blick, aber ich sollte mir EdgeDB auch einmal anschauen.
Ein enormes Lob. Es heißt, dass am 28.7. um 10 Uhr vormittags (PT) Version 2.0 angekündigt wird.
EdgeDB 1.0 Release
EdgeDB - das Open-Source-ORDB der nächsten Generation für Entwickler