SQLBraid ist eine TypeScript-Library, die in dieser Meldung als GitHub-Projekt vorgestellt wird: Man schreibt SQL direkt in TypeScript und verzichtet auf die Übersetzungsschicht, die Query-Builder zwischen Code und Datenbank einschieben. Der Anlass ist konkret: Der Autor arbeitet laut der Quelle in einem Java-Unternehmen, in dem Queries in MyBatis-ähnlicher XML-Syntax laufen und die meiste Logik in SQL mit mehreren tausend Zeilen steckt, wie die Meldung erklärt.
Ich hab da erstmal an alte XML-Query-Dateien gedacht, in denen der Editor nicht mehr mitliest und jede Änderung zum Suchen durch Notation wird. Genau so arbeitet auch das Team des Autors: internes Java-Framework, MyBatis- oder iBATIS-ähnliche XML-Query-Syntax, dazu die übliche SI-Praxis, dass Logik nicht im Code, sondern in sehr langen Queries lebt. Sein Gegenentwurf ist ein privates Projekt, das er auf GitHub zeigt: SQLBraid.
Was SQLBraid verspricht, fasst die Quelle in drei Stichpunkten zusammen: SQL schreiben, TypeScript behalten, die Query-Builder-Übersetzung weglassen. Wie die Typprüfung im Detail funktioniert oder wie die Datenbank-Verbindung aufgebaut ist, steht in der Meldung nicht. Der Rest des Quelltexts ist ansonsten recht dünn, was bei einer Projektvorstellung auf GitHub normal ist; der aktuelle Stand liegt im Repository auf github.com.
Das Spannende ist, dass die Idee ein reales Problem trifft: Query-Builder sind oft eine eigene Mini-Domainsprache, und wer dort mehrere tausend Zeilen pflegt, hat das XML-Problem nur in eine andere Syntax verschoben. Mein Zweifel hat dagegen einen konkreten Grund: Die Meldung liefert keine Zahlen, keine Beispieldateien und keinen Projektstand, weshalb ich nicht sagen kann, ob direktes SQL im TypeScript-Code in so großen Projekten wirklich weniger Wartung bedeutet oder nur die Unbequemlichkeit verlagert.
Wenn in eurem Projekt also die nächste Logik-Query über mehrere tausend Zeilen wächst, dann? Eine TypeScript-Datei, die SQL trägt, oder doch die gewohnte XML-Welt, weil das Team dort seit Jahren zuhause ist?