Von Firebase kommend
Firebase ist Googles Backend-as-a-Service, läuft vollständig auf Googles Infrastruktur mit nutzungsbasierter Abrechnung. So ziehst du dein Backend auf einen Server um, der dir gehört.
Warum Teams Firebase verlassen
Firebase ist ein schneller Weg, das Backend einer Mobile- oder Web-App zu versenden, ohne einen Server zu verwalten. Die Reibung zeigt sich, wenn die Nutzung wächst: Firestore-Reads und -Writes, Cloud-Functions-Aufrufe und Bandbreite werden alle separat abgerechnet, und die Rechnung kann schwer vorhersehbar werden.
Railyard betreibt dein Backend als normalen Server-Prozess zu einem flachen Preis pro Team, mit Postgres, MySQL oder Redis als verwaltetem Addon.
Was mitkommt
- Deine Backend-Logik, umgeschrieben, um als normale App auf einem Dockerfile, Buildpacks, oder einem Procfile zu laufen, statt als Cloud Functions.
- Deine Umgebungsvariablen und Secrets.
- Firestore-Daten, exportiert und in ein relationales Schema auf einem verwalteten Postgres-Addon migriert.
- Firebase-Auth-Nutzer, exportierbar und importierbar in dein eigenes Auth-System oder eine Library.
Der Umzug
- Einen Server anbinden: einen bestehenden, oder einen neuen, den Railyard in deinem Cloud-Account provisioniert.
- Dein Repo hinzufügen und das Postgres-, MySQL- oder Redis-Addon anhängen, das deine App braucht.
- Deine Daten migrieren aus Firestore in dein neues Schema.
- Deployen auf eine temporäre URL. Deine Release-Task ausführen und prüfen.
- DNS umschalten. Es gibt keine Downtime; Firebase bedient weiter bis zum Cutover.
Was anders ist
Ein flacher Preis pro Team statt Abrechnung pro Read, pro Write und pro Aufruf, und ein Server, über den du Bescheid weißt, statt einer Sammlung verwalteter Services.