Supabase - Backend as a Service

Hat man die Anforderung eine neue Webanwendung zu entwickeln, so muss man sich für einen Technologie Stack entscheiden. Das bedeutet nichts anderes, als aus der Vielzahl der möglichen Technologien diejenigen auszuwählen, die folgende Kriterien erfüllen:

• Für den Anwendungsfall geeignet sind.
• miteinander kompatibel sind und sich ideal ergänzen
• Heute und in absehbarer Zukunft gut unterstützt werden.

Alle drei Kriterien zu erfüllen, kann mitunter eine Herausforderung sein. Zudem wenn man bedenkt, dass jede der Technologien eine Lernkurve mit sich bringt - man sollte also möglichst Technologien wählen, bei denen eine effiziente Einarbeitungsphase möglich ist (gute Dokumentation, Nähe zu bestehendem Wissen etc.).

In diesem Blogpost konzentrieren wir uns nur auf die Wahl der Backend Technologien.

Die Wahl des Technologie Stacks

Grundsätzlich lässt sich das Backend in folgende Kategorien einteilen.

• Authentifizierung
• Rest API
• Datenbank
• Storage
• Backups
• Logging
• (KI) Traditionell kein integraler Bestandteil des Backends, wird aber zunehmend in den Begriff integriert.

Im Prinzip findet man allein durch diese Aufteilung 5-6 verschiedene Technologieanbieter mit denen man sich auseinandersetzen muss. Zudem muss man die Grundsatzentscheidung treffen, ob man alles selbst auf einem eigenen Server hosten möchte oder lieber den Serverless Weg wählt, bei dem jemand das Hosting übernimmt.

Ein weiterer Punkt der die Auswahl erschwert ist, dass jeder Anbieter seine eigenen Preise und Rahmenbedingungen hat.

Wäre es nicht toll, wenn man die Auswahl stark vereinfachen könnte und sich mit nur einem Anbieter begnügen könnte?

Backend as a Service

Backend as a Service ist, wenn ein Anbieter die gesamte Technologie aus einer Hand anbietet. So muss man sich weniger Gedanken über Kompatibilität, Rahmenbedingungen und Preise machen.

Auch hier gibt es zwei unterschiedliche Modelle.

• Closed Source
• Open Source

Normalerweise gibt es meiner Meinung nach keinen großen Unterschied zwischen Open und Close Source Anbietern. Hier aber schon. Backend as a Service bedeutet, dass wir eine sehr enge Bindung zwischen dem Anbieter und unserer Webanwendung eingehen. Es ist eine zwingende und dauerhafte Abhängigkeit.

Closed Source + Backend as a Service

Closed Source Anbieter haben im Prinzip die volle Kontrolle über ihr Angebot und damit auch über einen Großteil der von uns entwickelten Webapplikation. Wenn der Anbieter die Preise verdoppeln will, können wir nur nicken, es sei denn wir sind bereit die halbe Applikation neu zu schreiben. Gleiches gilt, wenn sich die Geschäftsbedingungen oder Teile der API ändern oder der Service komplett eingestellt wird.

Open Source + Backend as a Service

Open Source in Verbindung mit Backend as a Service hat den Vorteil, dass man auf das Hosting des Unternehmens setzen kann, solange man mit den Bedingungen einverstanden ist. Sollte der Anbieter die Bedingungen in eine Richtung ändern, mit der man nicht mehr einverstanden ist, kann man jederzeit das Hosting selbst übernehmen und ist somit viel mehr vom Einfluss des Anbieters isoliert. Natürlich ist es nie im Interesse des Anbieters, dass wir den Dienst selbst hosten, da sie dann kein Geld mehr verdienen. Das heißt, durch die Kombination von Open Source und Backend as a Service entsteht eine gegenseitige Abhängigkeit zwischen Kunde und Anbieter. Meiner Meinung nach ist diese Abhängigkeit ein Garant dafür, dass der Anbieter ständig daran erinnert wird, im Sinne des Kunden (uns) zu arbeiten und nicht nur für den eigenen Profit (z.B. Kunden in sein Ökosystem einzusperren und zu melken).

Supabase - Open Source Backend as a Service

Ein aus meiner Sicht sehr interessanter Anbieter einer Backend as a Service Lösung ist Supabase. Ich möchte an dieser Stelle nicht im Detail darauf eingehen, was Supabase alles bietet und wie man den Service in Anspruch nimmt, da ich dafür lieber auf die offizielle Website und die hervorragende Dokumentation verweise. Eine kurze Auflistung analog zum vorherigen Kapitel ist aber sicherlich angebracht:

• Authentifizierung Supabase Auth
• Datenbank Postgres SQL
• Rest API Data API, die automatisch aus den Tabellen der Postgres SQL Datenbank generiert wird. Für Create-Read-Update-Delete (CRUD) Operationen.
• Speicher Storage mit verschiedenen Schnittstellen (inkl. S3)
• Edge-Functions Diese ergänzen die Data API (nur für CRUD Operationen) um komplexere Logik im Backend zu implementieren ohne einen separaten API Server aufsetzen zu müssen.
• Realtime Benachrichtigung von Frontend Instanzen bei Änderungen in der Datenbank oder auch für Broadcast Notifications.
• KI & Vektoren Zum Beispiel für Chat oder RAG Anwendungen

Man sieht also, dass Supabase eine Fülle an Backend Funktionalität bietet.

Bewertung Supabase

Supabase ist ein Backend as a Service bei dem der Code Open Source ist und auf GitHub eingesehen und heruntergeladen werden kann. Zusätzlich stellen sie auch eine Anleitung zur Verfügung, wie man Supabase selbst hosten kann. Man ist also zu keinem Zeitpunkt an deren Ökosystem gebunden.

Der Vorteil von Lösungen wie Supabase ist, dass alles aus einer Hand kommt. Jede Teilkomponente des Backends ist nahtlos aufeinander abgestimmt (z.B. Auth und Database etc.). Die Dokumentation einer Teilkomponente (z.B. Auth) erklärt nicht nur die Komponente an sich, sondern auch gleich den Zusammenhang mit den anderen Komponenten des Systems. Gleiches gilt für die APIs und auch für die SDKs, die für verschiedene Sprachen (JavaScript, C#, etc.) mitgeliefert werden. Dies vereinfacht den Einstieg in die Technologie und schränkt den Raum für Fehler oder Fehlinterpretationen ein.

Vergleich von Supabase mit traditionellen Cloud Anbietern (Azure, AWS, etc.)

Traditionelle Cloud Anbieter wie Azure und AWS bieten ebenfalls Backend als Service an. Mit Azure Functions, Cosmos DB, API Gateway und vielem mehr kann man prinzipiell alle Funktionen von Supabase abbilden. Zusätzlich hat man noch weitere Möglichkeiten wie Azure App Containers, um Backend Jobs einfach zu Loadbalancieren und zu orchestrieren.

Doch mit großer Macht kommt auch große Verantwortung. Hier sehe ich nach wie vor den Vorteil von Lösungen wie Supabase. Wenn man schnell und einfach eine Webapplikation aufsetzen will, ist es oft einfacher mit einer vollintegrierten Lösung zu arbeiten wo 90% der Funktionalität aus einem Guss kommt. Die großen Cloud Anbieter wie Azure und AWS werden immer ihre Daseinsberechtigung haben - vor allem für große Teams - aber es gibt auch gute Gründe und Anwendungsfälle wo es Sinn macht vom Standard wie Azure und AWS abzuweichen und einen Anbieter wie Supabase zu wählen.

Preis

Einerseits ist die Preisstruktur bei einer Paketlösung wie Supabase übersichtlicher und einfacher. Andererseits haben all die Annehmlichkeiten, die wir mit Supabase bekommen, auch ihren Preis. Auch Supabase selbst muss seinen Service irgendwo hosten und das ist letztlich wieder einer der großen Cloud Anbieter. Damit schließt sich der Kreis.

Supabase bekommt mit seiner Größe sicher bessere Deals als ein einzelnes kleines Unternehmen, aber trotzdem ist klar, dass sich ab einer gewissen Team / Unternehmensgrösse eine Lösung wie Supabase nicht mehr rechnet. Dann lieber wieder direkt auf die großen Cloud Anbieter setzen.

Fazit

In diesem Blogpost haben wir uns das Konzept Backend as a Service im Allgemeinen angeschaut und verschiedene Modelle und Anbieter verglichen. Meiner Meinung nach kann man mit einer umfassenden Lösung wie Supabase viel Zeit und Aufwand sparen. Allerdings sind die großen Cloud Anbieter mit ihrem riesigen Technologiekatalog nach wie vor unverzichtbar.