API umbauen auf Python - yay or nay?

[opatut]

Ohje.

Wie im Thema Aktueller Stand und weiterer Plan beschrieben brauchen wir nun zum Verarbeiten als Vektorkacheln eine PostGIS-Datenbank für das Portal.

Bisher läuft schon eine MongoDB für die Account/Auth/Track/Kommentar-Daten, und eine Redis für die Work Queue. Mit Docker ist das zwar relativ einfach alles zu starten, aber nicht besonders gut „ordentlich“ zu maintainen. Und drei Datenbanken getrennt korrekt zu verwalten ist eher unrealistisch, das wird/will niemand machen.

Ich überlege also, die API umzubauen auf PostgreSQL und auch die Work Queue einfach erstmal darin zu implementieren. Im Moment nutze ich da so eine Library, und die macht das ganz einfach, aber eigentlich würde ein kleiner Polling Worker reichen der nach unverarbeiteten Tracks sucht und die dann abarbeitet. Da braucht es nichtmal eine richtige „Work Task“ Abstraktion…

Und als ich so weit war, dachte ich mir: warum nicht die API gleich auch in Python schreiben? Das sind im Moment wie gesagt nur die Verwaltung der Accounts, Auth, Tracks und Kommentare. Und damit würde das Anstoßen der Verarbeitung und die ganze Integration von obs-face auch noch wesentlich einfacher werden…

Jetzt wollte ich eigentlich mal aufhören technisch alles umzubauen, und endlich mal vorankommen. Aber irgendwie bin ich mit diesem Technologie-Mix immer noch nicht zufrieden. Außerdem scheint eh niemand Bock auf Node.JS oder Python zu haben, und dann haben wir wenigstens nur eins von beidem

Was sagt ihr? Bin ich mal wieder zu perfektionistisch unterwegs, oder sollten wir die Technologie hier vereinheitlichen? Konkrete Ideen:

• API: Node.JS (express, mongoose, …) → Python (z.B. sanic, sqlalchemy, …)
• Queue: Redis → PostgreSQL
• Database: MongoDB → PostgreSQL
• Worker: Node.JS (call python script) → Python (import python library code)
• Migrations: Selbstgebaut → z.B. Alembic
• Authentication: Selbstgebaut → Keycloak

• Super Idee, mach das!
• Mach das, ich helfe dir sogar dabei!
• Nah, das würde ich lieber erstmal so lassen.
• Ich mag Node.JS lieber als Python.
• Ich hab keine Ahnung und lasse soetwas lieber andere entscheiden.

[boldt]

Mein Vorschlag: So wenig wie nötig selbst implementieren, also nur das, was den OBS ausmacht selbst machen. Beim Rest auf Standards setzen.

Self-Made-Tools:

• API: Ich würde bei der API bei express mit mongoose bleiben, da die nun soweit funktioniert. Lieber verbessern statt neu programmieren
• Worker: Wenn der nur ein Python-Script aufruft, dann kann man das definitiv gleich in Python machen

Auf Standards setzen bei:

• Database: Mongoose für die API
• Queue: Schaue dir mal https://nats.io an. Bin ich auch erst vor wenigen Tagen drauf gestoßen und habe noch nicht mehr als ein Hello-World damit gemacht. Es gibt da quasi für jede Programmiersprache eine passende Bibliothek
• Migrations: Gerne automatisiert
• Authentication: Gerne Keycloak

P.S.: node / express / react kann ich, bei Python bin ich komplett raus.

[opatut]

Danke für deinen Kommentar. Bei folgendem bin ich voll und ganz bei dir:

So wenig wie nötig selbst implementieren, also nur das, was den OBS ausmacht selbst machen. Beim Rest auf Standards setzen

Das wäre die treibende Kraft hinter dem Umbau doch auf Keycloak, um da das ganze Account Management aus der API wieder rausnehmen zu können, und trotzdem viele Features zu haben (PW reset, mail confirmation, …).

da die nun soweit funktioniert […] Mongoose für die API

Mein Hauptproblem ist eben der dreifache Maintenance-Aufwand für die Datenbanken. Eigentlich willst du ja jede richtig backupen, und Datenbank sind notorisch dafür nicht im laufenden Betrieb gebackuped werden zu wollen, sondern mit den entsprechenden Tools richtige Dumps zu erzeugen. Das ist dreifacher Aufwand so (naja, vielleicht nur zweifach, redis ist ziemlich egal).

Nats.io wäre in dem Zusammenhang nur noch eine weitere Technologie, die a) zu maintainen ist, und b) contributors erlernen müssten. Das wäre aus meiner Sicht eher kontraproduktiv.

Den Worker kann ich ebenfalls nur in Python umbauen wenn wir a) das Datenbankschema in Python abbilden, da die Tracks ja gelesen, gefunden, modifiziert, … werden, und b) wir uns von der Redis-backed queue library lösen, da es die nur für Node.js gibt. Das Problem a) habe ich jetzt schon, da das Processing ja in die PostgreSQL schreiben soll/muss (für die Vektorkacheln), und ich dann eigentlich die API auch daraus lesen lassen will (um die Infos nicht doppelt vorzuhalten, in PostgreSQL und MongoDB).

Das alles so zusammen führte eben zu der Idee, gleich die API umzuschreiben. Das sind nur ca. 2000 Zeilen Code, von denen bestimmt 20-30% Auth-Zeugs sind (das muss eh mit Keycloak dann neu gemacht werden) und ein weiterer Großteil Glue-Code und die Aufrufe zur Datenverarbeitung, die dann wieder in Python ist, und das wird wesentlich einfacher. Ich hab so wenig Lust noch mehr von diesem frickeligen Gluecode zu schreiben, nur weil die Technologien auf den beiden Seiten so wenig aufeinander abgestimmt sind.

Dein Einwand, kein Python zu können, ist natürlich höchst relevant Da warte ich mal auf weiteres Feedback der Community, wie da so das „Stimmungsbild“ zu ist. Den umgedrehten Fall, die Datenverarbeitung aus Python herauszuholen halte ich aber für unrealistisch. Das ist schon die richtige Technologie für den Job

LG Paul

[gluap]

Hallo zusammen,

Bei mir ist es genau umgekehrt, bei node.js kann ich wenig beitragen, python mache ich jeden Tag. Bei nodejs hatte ich z. B. mal überlegt einen „run face evaluation“ step in den Worker einzubauen, dann aber keinen guten Zugang gefunden wie ich das einhake. Dafür würde es aber eigentlich auch reichen, wenn der Worker python ist.

Für mich wäre die Hürde für eigene Beiträge mit python niedriger. Aber ich bin eher so der Backend Typ.

Backups für Datenbanken fände ich nicht so schlimm wenn sie gleich Teil eines Referenz Docker Setups sind. Z.B. Über einen write dumps API Call den man im Backupscript per curl triggern kann.

Viele Grüße,
Paul

[natureshadow]

Ich würde keine umfangreichen Arbeiten machen können (aus Zeitgründen), habe aber umfangreiche Erfahrungen mit Web- und Web-API-Anwendungen in Python (Django und Flask), inkl. Datenbank (Django ORM, SQLAlchemy und PostgreSQL) und Background-Worker-Kram (Celery). Ein bisschen nebenbei mit draufgucken könnte ich also.

[opatut]

Für mich war die tatsächlich wichtigere Frage glaube ich: PostgreSQL für alles, oder MongoDB behalten.

Ich habe ein bisshcen experimentiert, und für mich entschieden: Ja, umbauen. Grund dafür ist nicht die Sprache (obwohl ich es jetzt wesentlich einfacher finde, die Skripte zu integrieren, wo ich den „Neubau“ mit PostgreSQL natürlich in Python gemacht habe), sondern eben die Datenbanktechnologie. So etwas hier war vorher nicht so einfach:

SQL ist eben nach wie vor eine super Sprache, um Fragestellungen als auswertbare Ausdrücke zu formulieren. Noch dazu sind die geographischen Fähigkeiten der PostGIS sehr stark, sodass obiger ausdruck zum Beispiel nicht nach Datum, sondern nach Region, gebaut werden könnte – ohne dass ich irgend eine „High Level Programmiersprache“ bräuchte.

Aus meinem Prototyp ist inzwischen ein fast fertiger Umbau geworden, den ich demnächst im entsprechenden Originalthread weiter dokumentiere. Der Umstieg wird nicht schwer (einmaliges Migrationsskript + Docker), die meisten Features sind implementiert (es fehlen glaube ich eigentlich nur Kommentare, und die sind ja einfach). Und es nutzt Keycloak + Cookie Session statt eigener OAuth