Backend-as-a-Service - Eure Wahl

[Dextera]

Hallo Devs!

Mal völlig davon abgesehen, für welche Plattform oder in welcher Sprache schlussendlich entwickelt wird - sobald am Ende ne App dabei rausschaut, die an andere Leute gerichtet ist, wird es irgendeine Art von BaaS dafür brauchen.

Fürs erste rumspielen freunden sich wohl die meisten mit Googles Firebase an, weil sie relativ simpel aufbaut, ausreichend performt und am Anfang halt noch kostenlos ist - was später natürlich skaliert, sobald man da mal andere User ranlässt.

Ganz egal, in welcher Form man so etwas betreibt: Laufende Kosten wird man damit immer haben. Wenn mans aber vollständig einkauft, dann sind die Ausgaben an Extern natürlich entsprechend höher. Und wie jeder weiß, haben Leute offenbar so überhaupt keine Ambition, laufend für eine Software Geld zu bezahlen. Warum auch

Gesetz dem Fall man verwendet lediglich den internen Speicher der Geräte für Daten und dann eben nur ein Login-Verfahren von Google, dann bezahlt man halt laufend, nur damit sich User einloggen/registrieren können. Oder rein auf "Login with Apple/Google" bleiben?

Habt ihr brauchbare Alternativen? Oder wie handhabt ihr das?
Ich steh momentan vor dem Schritt dieser Implementierung und frag mich halt, was man da machen könnte damit man bei einer 1x-Bezahl-Software bleiben kann. Ohne dass ich jetzt selbst ne Serverlandschaft hinstellen und sichern muss.

Bisher bekannt sind mir noch Backendless, Back4App, AWS Aplify und Parse.

Ich bin eigentlich Entwickler für andere Dinge, App-Entwicklung mach ich aus reinem Spaß an der Freude.
Aber wenn man am Ende vielleicht mal ne App in den Store schmeißen möchte, sollte man sich halt vorab ein ordentliches Konzept hinlegen

 

[wegus]

Google, AWS und Co werden schnell teuer. Bisher bin ich da bei eigenen Servern. Aber ich lerne auch gern dazu und bin gespannt was kommt….

 

[Dextera]

Auch eigene Server kosten Geld Die laufen ja auch nicht mit Hamstern ...
Ich versteh daher diese abneigende Haltung gegenüber Abos auch nicht - aber vielleicht denken die Leute da einfach nicht nach. Man verwechselt das mit den Disketten und CDs von früher - wo du dir 1x ne Software mit Stand X kaufst und das isses dann.

Allein das Login-Thema beschäftigt mich. Natürlich könnt ich auf Login with Apple/Google ausweichen. Allerdings hab ich dann halt so garkeine weitere Möglichkeit mehr für Funktionalitäten. Sowas wie ne Sharing-Funktion innerhalb der App, wo du Dinge dann mit eingeladenen Freunden teilen kannst oder ähnliches. Wenn ich diese Datenhaltung vollständig zu Apple/Google lege, dann weiß ich genau nicht wer da grad angemeldet ist - und die finden dann auch keine anderen Leute

 

[wegus]

Wie ist das eigentlich mit DSGVO uns Sign in via Apple oder Google?

 

[Dextera]

Ich hab mich noch Null damit beschäftigt - aber wo siehst du hier was? Ist doch genau in die Richtung, wo DSGVO hinzielt. Ich als app-Entwickler habe keinerlei Daten, keine Infos wer das ist. Und bei Apple/Google liegt eh schon alles, deren Service liefert mir halt nen nutzlose, nicht identifizierbare ID retour.

 

[Dextera]

Die Resonanz is ja Wahnsinn
Es bleibt wohl dabei, dass man sich hier nur ausgiebig über die beste Farbe für Notebooks streiten kann (Silber)

Ich setze gerade einen Server auf und spiel mich mal mit Parse. Wenn ichs richtig verstanden habe, ist sowas wie Back4App nix anderes - nur dass da jemand anderes für dich nen Parse-Server hostet gegen Geld Was ich bisher gesehen habe schaut aber ganz gut aus.

So nett Firebase auch ist ... Ich glaub, man sollte lieber gleich von Anfang an was eigenes aufziehen (sofern man die Möglichkeit dazu hat).

 

[wegus]

Die Resonanz is ja Wahnsinn

zumindest mich interessiert das sehr, ja!
Meine Lösung bisher besteht aber eben aus eigenem (V-)-Server, MariaDB oder Postgres und dann eigenes Backend drauf laufen lassen. Der Parse Stack sieht interessant aus.

Es bleibt wohl dabei, dass man sich hier nur ausgiebig über die beste Farbe für Notebooks streiten kann

Das würde ich durchaus gern wieder ändern. Ich wäre sehr dafür hier wieder mehr Devs im Bereich Freelancer und auch Web-Programmierung zu sehen! Bin gerne dabei das mit Themen zu initiieren!

 

[KiLa-Apps]

Ich habe selbst noch kein App-Backend benötigt, habe aber ein wenig Erfahrung mit AWS und die Free-Tier von denen gibt eigentlich schon was her: https://aws.amazon.com/de/free
Man muss dann natürlich die Services nutzen, die immer kostenlos sind (DynamoDB, Lambda, SNS, ...). Das genügt aber natürlich nicht für alles (vor allem der DynamoDB Speicher kann je nach Art der App schnell voll werden) und ist ab einer gewissen Last auch kostenpflichtig.

Aber evtl ist Firebase da sogar besser, da hab ich keine Erfahrung mit.

 

[Dextera]

Firebase ist hervorragend - aber eben monatlich zu zahlen.
Mittlerweile steht am Server ne VM mit Debian, auf die ich Parse installieren und mir selbst ein Backend bereitstelle.
Es bringt ja nicht viel jetzt erstmal mit FireBase zu starten - und es dann alles umzubauen sobald ich merke dass es zu teuer wird (auch wenn ich an den Punkt vielleicht niemals komme).

Dank der Geiz-ist-Geil-Mentalität darf man sich halt mit so nem Blödsinn auch noch beschäftigen ^^

 

[modev]

Parse habe ich auch schon einmal ausprobiert. hat mich letztendlich aber nicht überzeugt. Normalerweise schreibe ich meine Backends selber, wie im Web Bereich eben üblich. Aber da quasi jede App die ich bisher gebaut habe nur ein glorifizierter CRUD client ist, habe ich mich trotzdem noch einmal nach alternativen umgeschaut. Aktuell baue ich gerade einen kleinen Prototypen mit Postgraphile.

Als Hoster für geizige kann ich definitiv die Hetzner Cloud empfehlen. Sehr sehr guter Preis Leistungsverhältnis, aber eben nur Server in DE und Finnland (glaube ich jedenfalls, kann sich auch geändert haben). Letztendlich würde ich aber bei kleinen Projekten immer bei Firebase (oder vielleicht auch Supabase) landen, denn meine Lebenszeit ist mir mehr Wert als die paar Euro die ich spare.

 

[Dextera]

Bei Hetzner bin ich mit meinen Domains/Webspace ...
Den Parse Server hab ich auf einer eigenen Server-Landschaft hochgezogen, die bei einem Kumpel steht.

wie im Web Bereich eben üblich

Zählt für dich da App-Entwicklung dazu? Also iOS/Android Apps.

 

[modev]

Zählt für dich da App-Entwicklung dazu? Also iOS/Android Apps.

Ne nicht direkt. Aber Web ist eben das was ich kann, iOS ist das was ich lerne. Aber im Endeffekt ist es ja egal, ne RestAPI ist ne RestAPI, egal was dein Client ist.

Den Parse Server hab ich auf einer eigenen Server-Landschaft hochgezogen, die bei einem Kumpel steht.

Das hat ein Kumpel auch gemacht, wem es Spaß macht

 

[Dextera]

Ich finds etwas unsinnig hier auch noch Server-Blades laufen zu lassen, wenn bei ihm (in nem Land mit wesentlich billigerem Strom) eh alles vor sich hin idled

Ja, Rest ist Rest - macht halt nen Unterschied wie viele Leute da dagegentrommeln

 

[gishmo]

Ohne konkreter Angaben was Du vorhast wird das schwer. ;-)

Mein letztes Projekt läuft zum ersten Mal nicht mehr auf einem eigenen Server, sondern in der Cloud bei AWS. EC2, S2 und eine Aurora-DB. Verfügbarkeit, Ausfallsicherheit und Security sind ein Traum. Performance ist fantastisch.

Und, auf Grund der besseren Möglichkeit zu Skalieren, ist es sogar günstiger als der eigene Server. Genial finde ich, dass ich bei steigender Last weitere Pods einfach hochfahren kann, um gute Antwortzeiten zu garantieren. Und, sobald die Pods nicht mehr gebraucht werden, werden diese runter gefahren.

Da es in der europäischen Region läuft, ist es DSGVO konform und der Abschluss einer Auftragsdatenverarbeitungsvereinbarung ist recht simpel.

Und ja, Leute zahlen nicht gerne für Software. Aber dann sollten Sie auch nicht schreien, wenn so etwas wie gerade mit log4j passiert ...

 

[Dextera]

Sie auch nicht schreien

Naja, So funktioniert das nicht

Ohne konkreter Angaben was Du vorhast wird das schwer. ;-)

Die gibt es nicht. Wie ich sagte fange ich an, Apps zu schreiben.
Und obs jetzt nur für ne Authentifizierung ist - oder auch Daten ablegen welche halt auch in einem Account - und nicht nur dem Handyspeicher landen sollen ...

 

[Deine Mudda]

Die gibt es nicht. Wie ich sagte fange ich an, Apps zu schreiben.
Und obs jetzt nur für ne Authentifizierung ist - oder auch Daten ablegen welche halt auch in einem Account - und nicht nur dem Handyspeicher landen sollen ...

Über was für Last sprechen wir denn?

Ich hab zwei "kleine" Projekte mit etwa 50.000 Nutzern - das selbstgeschriebene NodeJs Backend läuft auf einem VServer bei Strato - seit Jahren ohne Probleme.

 

[Dextera]

Ich versteh nicht ganz, was an "ich fang an" und "wie handhabt ihr das für Apps" so unverständlich ist
Weder hab ich schon eine bestimmte Last im Sinn, noch brennt hier irgendwo bereits ne Leitung.

Es ist ein Vorfühlen, wie App-Entwickler solche Dinge angehen ANSTATT solcher Dienste wie Firebase. Also: Alles, wofür man Firebase verwenden könnte - einfach als Alternative. Das hier ist ein allgemeiner Thread - es gibt derzeit noch KEIN explizit zu benennendes Szenario

Ich würde nur gern gleich von Anfang an mit etwas fahren, was dann auch bleiben kann. SOLLTE irgendwann mal so viel Last anfallen, dass Dienste wie Firebase & Co eben unsinnig teuer werden. Und das halt in so einem Ausmaß, dass man die laufenden Kosten dafür eigentlich nur noch mit einer Abo-App handhaben könnte. Sowas will ich halt von vorn herein vermeiden - also jetzt nicht unsinnig Firebase "lernen", einsetzen und mich dran gewöhnen, wenn ichs später eventuell eh ersetzen muss.

Man könnte sagen: Ich bin ein Freund von "Machs gleich korrekt - anstatt im Nachgang mit doppelter Arbeit alles wieder umzubauen".
Deswegen ein allgemeiner Laber-Thread.

 

[gishmo]

Kannte FireBase gar nicht. Wahrscheinlich, weil ich mit einem anderen Stack arbeite.

Ich stelle meine Services als SpringBoot-Anwendung zur Verfügung. Das lässt sich leicht in einen Docker-Container verpacken und auf AWS deployen. Meine Services sind stateless, was es recht einfach macht auf Last zu reagieren. Als DBMS entwickle ich auf postgres und lass es auf Aurora laufen. (deutlich günstiger als eine PostGres-Instanz) Definierte Service-Zeiten und Skalierbarkeit sparen Betriebskosten.
Für die Authentifizierung gibt es ne Menge Möglichkeiten. Google, Facebook & Co lassen sich leicht einbinden. SMS-& E-Mail-Services sind kostengünstig und leicht umzusetzen.

Von daher mein erster Satz: "Ohne konkreter Angaben was Du vorhast wird das schwer. ;-)". Wenn man die Anforderungen parat hat, kann man etwas passendes mit Cloud-Diensten bereit stellen. Das Toolset von AWS (Wie bei Azure, Google & Co) gibt einen alle Möglichkeiten eine Infrastruktur nach eigenen Wünschen und Bedürfnissen aufzusetzen.

Ich hatte in der Vergangenheit einen VServer für eine grosse Anwendung im Einsatz. Rückblickend sind meine Erfahrungen: Das war teuerer, aufwendiger & häufiger down als die aktuelle Infrastruktur.

 

[Dextera]

Wie ich schrieb, könnte man natürlich bei der Registrierung auf „Sign in with Apple/Google“ setzen und erledigt ist der Käse. Aber ich bekomm dann nur eine anonyme ID zurück wenn ich das richtig verstanden habe (nur 10 min. damit beschäftigt bisher). Also kann ich dann bspw. die Leute sich nicht gegenseitig finden lassen in der App, oder? Also wenn die bspw. Dinge miteinander teilen wollen. Muss ich mir mal genauer anschauen. Ne doch, irgendwie muss das ja gehen. Machen andere ja auch.

Aber nehmen wir an das geht nicht - dann muss ich schonmal den SignUp Prozess selbst verwalten. Also Userdaten persistieren und eben Login with Email bereitstellen.

Wäre also 1) das Authentifizierungs-Thema.

Und wenn ich dann App Daten halten will, die schlicht am User hängen (damit sie halt nicht am Device selbst liegen), dann muss ich auch das bieten.

Also 2) Datenhaltung zum User.

Das sind doch eigentlich 2 so grundlegende Dinge, die man für ne App brauchen und bieten kann, oder? Das hat nan mit Firebase in 5 Minuten realisiert. Und solange man nur ne handvoll User, Requests und Speichernutzung hat, geht das auch kostenlos. Bis es dann halt den Rahmen sprengt und beginnt, monatliche Kosten zu verursachen.

Es geht hier nicht darum dass ich annehme, mit der App hier ein neues Instagram zu booten Es würd wohl die kostenlose Firebase Variante reichen. Aber eben: wenn, dann vielleicht gleich richtig.

Danke schonmal für den bisherigen Input.

 

[gishmo]

Da konnte AWS etwas zu schwergewichtig sein. Das mag so sein.

Ich denke, dass einzige was Du brauchst, ist eine Auftragsdatenverarbeitungsvereinbarung mit Firebase. Und, je nach Daten, muss Du sicherstellen, dass diese den EU-Raum nicht verlassen (Speicherung, und so).