Parse service retired

[Rollo62]

Hallo zusammen,

sehe gerade Parse ist gestorben, und
das wo ich mich doch schon ernsthaft damit beschäftigt hatte das einzusetzen, und nicht Kinvey (weil zu teuer).

Die Frage auf einer Roadshow warum man einen simplen, eigenen "Parse"-Server (REST) nicht mit PHP mal schnell
auf einen einfachen Hosting Server bringen könnte wurde seinerzeit abgetan:

Zitat:

"Weil Cloud viel schneller, super skalierbar und soviele Features hat dam man Mannjahre bäuchte um das selber zu machen, und bei Millionen Anfragen pro Sekunde ohne LoadBalancing alles crasht (so in etwa ...)".

Die Antwort siehe oben, weil man sich eben bei Cloud auf nichts verlassen kann, und jeder der dort eine grosse Anwendung hat ist jetzt in den Allerwertesten gebissen.

Aber was mir erstmal reichen würde wäre ein ganz einfacher PHP-Server, der die Daten mehr oder weniger
in mehreren flachen Tabellen ablegt.
Natürlich sollte eine kleine Nutzerverwaltung und genug Security schon dabei sein, wie z.B. bei Slim basierte Lösungen.
Das ist für den Start sehr kostengünstig, weil auch mehrere Projekte auf einem Server Laufen können.

Ich würde das gerne zusammen mit iOS und Android Mobile Clients einsetzen, um simple Daten auszutauschen,
da erwarte ich erstmal nicht tausende von Anfragen.
Vorstellen könnte ich mir PHP-Server mit ähnlichen API wie Parse/Kinvey, um schnell eine Anwendung zu bauen und zu testen, und dann kann man ja immer noch in die Cloud.

Hat vieleicht schonmal jemand Erfahrung mit PHP so einer "eigenen" Cloud-Lösung gemacht, gibt es Empfehlungen ?

Rollo

[Uwe Raabe]

Wenn ich das richtig interpretiere, steht der Parse Server doch jetzt offen zur Verfügung.

[Daniel]

Wir müssen das richtigstellen: JETZT ist niemand in den Allerwertesten gebissen. Parse hat angekündigt, seinen Service ENDE Januar 2017 einzustellen.
Am grundsätzlichen Prinzip der Cloud ändert sich dadurch nichts und ich sehe die zitierte Aussage aus der Roadshow auch nicht widerlegt. Dienstleister kommen und gehen, das ist wahr. Und wer seine Lösung mit den BaaS-Komponenten von Delphi realisiert hat, wird wenigstens Delphi-seitig nur die Zugangsdaten ändern müssen, um z.B. zu Kinvey zu wechseln. Genau dafür wurde die Schnittstelle ausgelegt.

[Rollo62]

Hallo Daniel,

danke für die Klarstellung.

Aber dir ist auch klar das wohl niemand ein NEUES Projekt auf Parse starten würde, das ist ja wohl klar.

Den Parse-Source habe ich noch nicht gesehen, der läuft aber wohl nicht, wie meine Frage war, auf PHP-Virtual Hosts ?
Ich möchte eigentlich keinen Parse2 Server aufbauen, sondern eben alles eine Nummer kleiner.

Dazu suche ich ein paar Ideen.

Rollo

[Uwe Raabe]

Es kann aber durchaus sein, daß es demnächst ein paar andere Anbieter geben wird, die auf Basis des Parse Servers einen alternativen Dienst anbieten. Nach dem, was ich bisher gelesen habe, braucht es dazu nur einen Node.JS server.

Leider haben Sie den Push-Dienst wohl nicht mit rein gepackt - das macht es für meine Anwendung leider unbrauchbar. Dann bleibt dafür zur Zeit wohl nur Kinvey als Alternative.

[Rollo62]

Hallo Uwe,

ja richtig, der PushDienst ist natürlich ein Argument.
Aber für mich spricht gegen Kinvey das Preismodell.

Hast du denn gecheckt was nötig ist im die ParseSourcen auf einem eigenen Server zum Laufen zu bringen ?
Ich nehme mal auch an das dies dann auch OHNE Push wäre, denn dafür braucht man doch sicher schwer zu bekommende
Sondervertrage mit den Mobil-Providern.

Oder sehe ich das falsch und die Push-Dienste sind simpel zu lösen ?
Es gab doch ein Video von Sarina wo die einen CloudService vorgestellt hatte, finde es auf die Schnelle nicht mehr,
aber ging es da um Push oder um Ads ?

Rollo

[mjustin]

Zitat:

Zitat von Rollo62 (Beitrag 1328751)

Oder sehe ich das falsch und die Push-Dienste sind simpel zu lösen ?

Sehr einfach - wenn es nur für eine Plattform sein soll. Parse und Kinvey übernehmen, wenn ich es richtig verstehe, die Kommunikation mit den APIs von Apple und Google.

Einen minimalen Google Cloud Messaging (GCM) Backend Server kann man anhand des Tutorials und Demo-Codes (in Java oder einer der anderen unterstützten Sprachen, für die es Doku gibt) an einem Nachmittag bauen. Der muss nur auf eingehende Requests von Google warten, ist also z.B. ein einfacher HTTP Server. Und für Push-Nachrichten sendet man einen einfachen HTTP Request an Google, in dem die Geräte-ID enthalten ist.

(Ob man mit FireMonkey allerdings die geräteseitig notwendigen Funktionen hat, weiss ich nicht. Ich habe für den Client einfach das Java SDK verwendet.)

[Daniel]

Zitat:

Zitat von mjustin (Beitrag 1328753)

(Ob man mit FireMonkey allerdings die geräteseitig notwendigen Funktionen hat, weiss ich nicht. Ich habe für den Client einfach das Java SDK verwendet.)

Server und Client lassen sich bei Bedarf sowohl für iOS als auch für Android mit Delphi erstellen. Grundsätzlich ist alles vorhanden.

[mjustin]

Zitat:

Zitat von Daniel (Beitrag 1328756)

Server und Client lassen sich bei Bedarf sowohl für iOS als auch für Android mit Delphi erstellen. Grundsätzlich ist alles vorhanden.

Sorry, natürlich ist clientseitig alles da (denn die Geräte kommunizieren ja immer nur mit Apple APN oder Google GCM, nicht mit Parse oder Kinvey). Wer also mag, kann den Server komplett ohne SaaS (Parse / Kinvey) bauen.

Aber heisst "Grundsätzlich ist alles vorhanden" dass es (für alle die ohne Parse / Kinvey arbeiten wollen) einen "Wizard" oder ein Projekt-Template in Delphi gibt, das einen APN oder GCM Backend-Server erstellt?

[Daniel]

Ich muss den Code wieder herauskramen - aber aus dem Gedächtnis:
Für den Server hatte ich lediglich einen INDY-Client sowie die Zertifikate von Apple genutzt. Damit hatte ich dann die von Dir beschriebene Verbindung zu den Servern von Apple / Google aufgebaut.

Für den Client musste ich ein oder zwei Klassen ableiten, um die Notifikationen empfangen zu können. Ich konnte mich dabei aber eng am dem Code der Parse-/Kinvey-Komponenten orientieren. Denn der eigentliche Versand der Notifikationen erfolgt ja auch bei denen dann über die offiziellen Server. Client-Seitig spielt es also keine Rolle, wie der Push nun initiiert wurde.

[mjustin]

Zitat:

Zitat von Daniel (Beitrag 1328760)

Für den Server hatte ich lediglich einen INDY-Client sowie die Zertifikate von Apple genutzt. Damit hatte ich dann die von Dir beschriebene Verbindung zu den Servern von Apple / Google aufgebaut.

Mit Apple habe ich noch nicht gearbeitet, bei GCM braucht man neben dem HTTP Client auch einen eigenen HTTP oder XMPP Server, der die Geräte-Registrierungen mit der Device-ID von Google empfängt und (bei HTTP) auch Nachrichten vom Client.

[sh17]

Hier entsteht gerade eine Übersicht an Alternativen zu Parse

https://github.com/relatedcode/ParseAlternatives

[RWarnecke]

Ich habe aktuelle eine App in Xcode fertiggestellt. Ich benutzte nur die Zertifikate und lediglich ein entsprechendes PHP Skript, welches für mich die Push-Notifications entsprechend versendet. Meine App empfängt die Nachrichten und zeigt diese dann entsprechend an. Jede Nachricht ist im JSON-Format. Für Push-Notifications benötige ich keinen fremden Dienst, lediglich nur einen LAMPP oder XAMPP.

[vagtler]

Zitat:

Zitat von RWarnecke (Beitrag 1328914)

[...] lediglich ein entsprechendes PHP Skript, welches für mich die Push-Notifications entsprechend versendet. [...]

Wie sicher ist das Skript bei mehreren 100.000 Empfängern (evtl. Multi-Plattform)? Kann das Skript auch Segmentierung und A/B-Testing inkl. Analytics?

[RWarnecke]

Zitat:

Zitat von vagtler (Beitrag 1328915)

Wie sicher ist das Skript bei mehreren 100.000 Empfängern (evtl. Multi-Plattform)?

Wird sich über die Zeit zeigen, da die App erst seit Donnerstag letzte Woche draußen ist. Das PHP-Script kann Push-Notifications an Android und iOS Geräte schicken.

Zitat:

Zitat von vagtler (Beitrag 1328915)

Kann das Skript auch Segmentierung und A/B-Testing inkl. Analytics?

Was verstehst Du unter Segmentierung, A/B-Testing ? Wozu wird das gebraucht ?

[sh17]

Zitat:

Zitat von RWarnecke (Beitrag 1328914)

Ich habe aktuelle eine App in Xcode fertiggestellt. Ich benutzte nur die Zertifikate und lediglich ein entsprechendes PHP Skript, welches für mich die Push-Notifications entsprechend versendet. Meine App empfängt die Nachrichten und zeigt diese dann entsprechend an. Jede Nachricht ist im JSON-Format. Für Push-Notifications benötige ich keinen fremden Dienst, lediglich nur einen LAMPP oder XAMPP.

Push-Notify ohne Google gcm etc? An ein konkretes Gerät? Wie machst Du das ohne polling durch die App?

[vagtler]

Zitat:

Zitat von RWarnecke (Beitrag 1328942)

[...] Was verstehst Du unter Segmentierung, A/B-Testing ? Wozu wird das gebraucht ?

Segmentierung bedeutet die Unterteilung der potentiellen Empfänger in Segmente (z.B. schreibe nur die an, die meine App vor sieben Tage installiert haben, oder nur die, die meine App nur einmal benutzt haben und seit mehr als drei Tagen nicht mehr).

Und beim A/B-Testing kann ich z.B. unterschiedliche Messages an unterschiedliche Testgruppen senden, um zu sehen, welche Message die bessere Conversion Rate erzielt, um dann zu entscheiden, welche ich an die Gesamtheit versende.

https://de.wikipedia.org/wiki/A/B-Test

Und was halt gerne vergessen wird: auch ein PHP-Skript will betrieben sein. Und in Zeiten von Diensten wie z.B. https://onesignal.com/ ist bei mir das Ergebnis der Make or Buy Decision ziemlich klar...

[sh17]

Zitat:

Zitat von vagtler (Beitrag 1328950)

Und in Zeiten von Diensten wie z.B. https://onesignal.com/ ist bei mir das Ergebnis der Make or Buy Decision ziemlich klar...

hmm, wieder kostenlos, sind solche Dienste denn codeseitig leicht ersetzbar? Ich meine, siehe Parse, Zack, weg isses

[vagtler]

Zitat:

Zitat von sh17 (Beitrag 1328953)

[...] hmm, wieder kostenlos, sind solche Dienste denn codeseitig leicht ersetzbar? Ich meine, siehe Parse, Zack, weg isses

Codeseitig ist das wohl eher ein kleines Problem - die kommen ja nun wirklich mit einem Minimalset an Code aus. Das Problem ist im Falle des Falles die Datenmigration.

Davon abgesehen war das auch nur ein Anbieter von vielen - auch kostenpflichtigen. Eine Auswahl findet sich unter anderem hier: https://github.com/relatedcode/Parse...tion-providers

Und von wegen Parse und "Zack, weg isses": die haben ja immerhin eine Redemption Period von fast einem Jahr. Da kann man meiner Meinung nach zumindest nicht von "Zack" sprechen...

[Rollo62]

Dankesehr für die vielen Tips, die Liste der ParseAlternativen muss ich noch mal durchgehen.

Zitat:

Ich benutzte nur die Zertifikate und lediglich ein entsprechendes PHP Skript, welches für mich die Push-Notifications

Genau sowas meinte ich, wenn mit PHP ganze CRM Systeme gebaut werden dann sollte das für simples Push und ein paar einfache Daten doch auch ausreichen.
Und ich glaube auch das man damit 1000000 Anfragen handeln kann, die kommen ja womöglich nicht alle gleichzeitig.

Das Ganze ist aber wieder ein ziemliche grosses Thema, da muss ich mich anscheinend mal wieder richtig tief reinlesen.

Bei dem kostenlosen Dienst OneSignal bin ich auch etwas skeptisch, wie Mutti schon sagte was nix kost is auch nix.
Was ist denn deren Geschäftsmodell ?

Trotzdem sehr traurig das die Halbwertzeit von solchen Diesten ja mittlerweile auf gefühlte 2 Jahre runter ist,
egal ob Google oder Facebook dahinterstehen.

Rollo

[vagtler]

Zitat:

Zitat von Rollo62 (Beitrag 1329011)

[...] Genau sowas meinte ich, wenn mit PHP ganze CRM Systeme gebaut werden dann sollte das für simples Push und ein paar einfache Daten doch auch ausreichen.
Und ich glaube auch das man damit 1000000 Anfragen handeln kann, die kommen ja womöglich nicht alle gleichzeitig. [...]

Das Problem an "simplen Push" ist halt, dass die Ansprüche mit der Zeit wachsen. Dann will man plötzlich Segmentierung, A/B-Testing, zeitversetztes Senden, Multi-App-Verwaltung, Analytics, usw. usf. Wenn dann noch die Unterstützung neuer Plattformen wie z.B. Web-Push hinzukommt, dann wird daraus plötzlich ganz schnell ein eigenes Projekt...

Und vertu Dich mal nicht. Wenn es darum geht, Push-Messages im 6-stelligen Bereich oder noch mehr zu senden, dann musst Du ja auch sicherstellen, dass diese Messages alle an die entsprechenden Push-Dienste gehen. Wenn Du das nicht zumindest parallelisierst, dann kannst Du das Timeout Deines Skripts am Besten schon mal auf viele Minuten stellen (mal ganz abgesehen davon, dass ansonsten auch so lange keine weitere Message gesendet werden kann). Also garniert man so einen Service idealerweise mit einem geeigneten Message-Bus bzw. einer Queue mit verteilten Subscription-Workern und dann ist das nicht mal eben nebenbei entwickelt. Und ein sicherer Betrieb benötigt halt neben der Umgebung auch ein Management.

Da steckt also schon ein wenig Gehirnschmalz und Technik dahinter, wenn man wie z.B. OneSignal "100,000 API requests per minute" schaffen möchte. Aber ja, natürlich kann man das mit PHP machen. Oder mit node.js. Oder whatever. Gehen tut das.

Wir haben in den letzten Jahren mal für uns selbst so einen - mittlerweile einigermaßen ausgereiften - Push-Server entwickelt bzw. genau genommen wurde bis vor ca. einem halben Jahr kontinuierlich immer wieder daran entwickelt. Dann sind wir auf OneSignal umgestiegen. :P

Zitat:

[...] Bei dem kostenlosen Dienst OneSignal bin ich auch etwas skeptisch, wie Mutti schon sagte was nix kost is auch nix.
Was ist denn deren Geschäftsmodell ? [...]

Von https://onesignal.com/about:

Zitat:

It's free; how does OneSignal make money?

We make money by using the data we aggregate to improve web and mobile experiences. We also offer custom solutions to enterprise clients.

Zitat:

Trotzdem sehr traurig das die Halbwertzeit von solchen Diesten ja mittlerweile auf gefühlte 2 Jahre runter ist, egal ob Google oder Facebook dahinterstehen. [...]

Naja, ein klein wenig länger war es schon: https://en.wikipedia.org/wiki/Parse_(company)

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1329011)

Trotzdem sehr traurig das die Halbwertzeit von solchen Diesten ja mittlerweile auf gefühlte 2 Jahre runter ist,
egal ob Google oder Facebook dahinterstehen.

In diesem Fall könnte man sogar mutmaßen, daß es gerade wegen Facebook passiert. Aber solche Dinge kann man eben nie ganz ausschließen.

[Rollo62]

Dankesehr an alle,

das Feedback zeigt mir das ich vielleicht doch falsch liege:

Zitat:

Und vertu Dich mal nicht. Wenn es darum geht, Push-Messages im 6-stelligen Bereich oder noch mehr zu senden,

Hier scheinen ja einige mit Ihrer App total erfolgreich zu sein, mit meinem Sonderkunden-Projekt im Bereich 100-1000 Usern liege ich da womöglich ziemlich weit drunter.
Aber was Ihr schreibt macht mir ja wieder Mut, wenn es wirklich so abgeht dann bin ich bestimmt der Letzte der sich dem aktuellen Trend in den Weg stellen will.

Trotzdem bin ich zu lange im Geschäftsleben um nicht gleich Alles überzubewerten, wenn man nicht gerade Spiele macht oder Facebook-Addons oder sonstwas extrem Cooles läuft es doch unter Umständen erstmal sehr gemächlich ab.
Ich glaube nicht das jeder auf die nächste Taschenrechner App wartet, und auch iOS will solche MeeToo Apps einschränken.

Also muss jetzt eine neue Killer-App her ........... aah ICH HABS ...... nee doch nicht .... oder so ... nö .... .. .

Ich geh jetzt erstmal schlafen :?

Rollo

[vagtler]

Du hast doch sogar von Push-Messages im 7-stelligen Bereich gesprochen... 8-)

[RWarnecke]

Zitat:

Zitat von sh17 (Beitrag 1328944)

Push-Notify ohne Google gcm etc? An ein konkretes Gerät? Wie machst Du das ohne polling durch die App?

Doch ich nutze schon Google GCM, sowas wie in dieser Richtung aus dem Stackoverflow-Beitrag nutze ich für meine App. Damit habe ich über PHP das Apple Push und Google Push kombiniert und kann somit Push Nachrichten von iOS nach Android und umgekehrt senden.

Zitat:

Zitat von vagtler (Beitrag 1328950)

Segmentierung bedeutet die Unterteilung der potentiellen Empfänger in Segmente (z.B. schreibe nur die an, die meine App vor sieben Tage installiert haben, oder nur die, die meine App nur einmal benutzt haben und seit mehr als drei Tagen nicht mehr).

Und beim A/B-Testing kann ich z.B. unterschiedliche Messages an unterschiedliche Testgruppen senden, um zu sehen, welche Message die bessere Conversion Rate erzielt, um dann zu entscheiden, welche ich an die Gesamtheit versende.

https://de.wikipedia.org/wiki/A/B-Test

Und was halt gerne vergessen wird: auch ein PHP-Skript will betrieben sein. Und in Zeiten von Diensten wie z.B. https://onesignal.com/ ist bei mir das Ergebnis der Make or Buy Decision ziemlich klar...

Vielen Dank für Deine Erklärung. Das war bei der gerade entwickelten App von mir unter iOS noch kein Thema.

Edit:
Der andere Punkt war auch noch, dass es Zusatzfunktionen im Backend gibt, welche mit den Push Nachrichten zusammenarbeiten müssen, deshalb habe ich mich für das PHP Skript entschieden.

[vagtler]

Zitat:

Zitat von RWarnecke (Beitrag 1329341)

[...] Der andere Punkt war auch noch, dass es Zusatzfunktionen im Backend gibt, welche mit den Push Nachrichten zusammenarbeiten müssen, deshalb habe ich mich für das PHP Skript entschieden.

Das ist oft der Fall. Daher ist auch die Güte der zur Verfügung stehenden API des Push-Service-Anbieters selbstverständlich bei einer Evaluierung mit in Betracht zu ziehen. ;)

[cipher]

Falls es hier noch jemanden interessiert, da ich ziemlich lange auf der Suche nach einem Ersatz für Parse war, die Push Notifications betreffend.

Letztendlich habe ich es mit Firebase (FCM - das neue GCM) geschafft, sowohl für iOS als auch für Android.

Hier sind die relevanten Schritte, die zum Ziel geführt haben:
http://community.embarcadero.com/ans...rse#reply-4669

[Rollo62]

Hallo cipher,

dankesehr, das ist sehr interessant.
Hast du auch ein gutes Tutorial für die generelle Einrichtung von Firebase gefunden ?

Ich hatte mal reingeschaut, aber das war für mich eine Mischung aus Firebase und dem alten Google GCM und
anderen Diesten, wo man nicht sicher war was jetzt neu und was depreceated ist.

Rollo