Frage zu Back-End

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Frage zu Back-End

    Hey!
    Nachdem ich hier meistens nur die anderen Threads im Stillen verfolge, gehöre ich nun auch mal wieder zu den Fragestellern... ;)
    Und zwar spiele ich zur Zeit mit Ideen für eine kleine iOS-App, welche eine Back-End-Anbindung benötigen würde. Als Back-End habe ich Parse geplant. Jetzt habe ich mich ein wenig auf der Website von Parse umgesehen, auch wegen Pricing & Co..
    In der kostenlosen Variante stehen einem 30 requests/second, 20GB File Storage, 20GB Database Storage und 2TB File Transfer (-> parse.com/plans) zur Verfügung.
    Da ich mit Back-Ends bisher wenig bis gar nichts am Hut habe, wollte ich mal um eine Einschätzung von euch bitten. Was kann man mit solchen Werten anstellen? Für welche Benutzerzahlen ist das geeignet? Dazu sei noch gesagt, dass in meiner App keine großen Dateien oder ähnliches, sondern lediglich kurze Texte (circa Twitter-Länge... ) zwischen dem Server und der App übertragen werden sollen.
    Meine zweite Frage ist, was der Unterschied zwischen File Storage und Database Storage ist. In den FAQs schreibt Parse: "Database storage refers to data stored as Parse Objects, which are limited to 128 KB in size. File storage refers to static assets that are stored using the Parse File APIs, typically images, documents, and other types of binary data.", aber irgendwie will ich diese Passage gerade nicht verstehen... Könnte mich da jemand kurz aufklären?
    Vielen Dank im voraus...
  • Vorweg: Parse ist nicht so toll wie es scheint.
    Worth reading
    profi.co/all-the-limits-of-parse/
    parse.com/plans/faq

    -30 requests/second
    Zusammengezählte Zugriffe auf deine DB von allen Apps aus
    -20GB File Storage
    Files die als Bilder, Videos etc. abgelegt werden
    -20GB Database Storage
    Dokumente werden als Parse Objekte oder als Subklasse davon gespeichert (ParseUser, ParseRole...)
    Hier darf eines max 128kb groß sein. Üblicherweise wird unter diesem ein Dokument verstanden
    -2TB File Transfer
    Datenübertragung von ParseFiles

    Zur 100% Klarstellung zu den Plan-Details kannst du sonst noch mal im Parse Forum nachfragen. Da antworten Entwickler von Facebook relativ schnell.

    Das mit der Nutzung hängt von deiner App ab. Das kann man pauschal nicht sagen.
    Bsp:
    Wieviel Videos, Images werden gespeichert?
    Wie oft feuert der Client einen Request ab?
    Wieviele aktive User hast du?
    ....

    Für 140 Zeichen Text + ein paar andere Attribute sollte es locker reichen. ;)

    HTH
  • Hey und danke für die ausführliche Antwort!

    msch schrieb:

    Vorweg: Parse ist nicht so toll wie es scheint.
    Ja, das glaube ich dir. Bin eigentlich auch, alleine deswegen, weil es Facebook gehört, etwas abgeneigt von Parse. Aber die Umsetzung schien mir am Unkompliziertesten und auch preislich ist es wohl nicht das teuerste.

    msch schrieb:

    Worth reading
    profi.co/all-the-limits-of-parse/
    parse.com/plans/faq
    Die FAQs habe ich mir auch durchgelesen, der andere Artikel ist (auch) wirklich lesenswert. Einige der Zahlen kenne ich bereits, aber dadurch, dass der Autor beispielsweise die 30 req/s hervorhebt, bestätigt er mein Gefühl, dass man vorher abschätzen sollte, wie viel man benötigt. Die häufigen Downs sind mir neu.

    msch schrieb:

    -30 requests/second
    Zusammengezählte Zugriffe auf deine DB von allen Apps aus
    -20GB File Storage
    Files die als Bilder, Videos etc. abgelegt werden
    -20GB Database Storage
    Dokumente werden als Parse Objekte oder als Subklasse davon gespeichert (ParseUser, ParseRole...)
    Hier darf eines max 128kb groß sein. Üblicherweise wird unter diesem ein Dokument verstanden
    -2TB File Transfer
    Datenübertragung von ParseFiles
    Das heißt, wenn Strings gespeichert wird, so betrifft dies den Database Storage?

    msch schrieb:

    Das mit der Nutzung hängt von deiner App ab. Das kann man pauschal nicht sagen.
    Bsp:
    Wieviel Videos, Images werden gespeichert?
    Wie oft feuert der Client einen Request ab?
    Wieviele aktive User hast du?
    Bin leider etwas unerfahren, um das qualitativ abschätzen zu können.
    Videos und Bilder kann ich ausschließen.
    Wie viele Requests pro Client? Hm, das hängt natürlich von der Nutzung des Users ab, aber auch davon, wie ich es umsetze. Der User soll gewisse Daten erhalten, aber ich bin mir nicht sicher, ob er dafür mehrere Requests abfeuern muss, oder ob ich die Daten (vielleicht über Cloud Function...?) bereits auf dem Server bereitstellen kann, sodass ein Request zum Download reicht.
    Wie viele aktive User? Momentan noch keinen... ;) Kann ich auch schlecht abschätzen, man weiß ja nie wie es läuft... :)

    Hast du denn eine Alternative zu Parse, die funktional als auch preislich im ähnlichen Bereich liegt?
    Danke noch mal.
  • Osxer schrieb:

    Bin eigentlich auch, alleine deswegen, weil es Facebook gehört, etwas abgeneigt von Parse. Aber die Umsetzung schien mir am Unkompliziertesten und auch preislich ist es wohl nicht das teuerste.

    Das heißt, wenn Strings gespeichert wird, so betrifft dies den Database Storage?


    Der User soll gewisse Daten erhalten, aber ich bin mir nicht sicher, ob er dafür mehrere Requests abfeuern muss, oder ob ich die Daten (vielleicht über Cloud Function...?) bereits auf dem Server bereitstellen kann, sodass ein Request zum Download reicht.


    Wie viele aktive User? Momentan noch keinen... ;) Kann ich auch schlecht abschätzen, man weiß ja nie wie es läuft... :)

    Hast du denn eine Alternative zu Parse, die funktional als auch preislich im ähnlichen Bereich liegt?
    Danke noch mal.
    Die Daten gibst du halt Facebook for free und der User bekommt nichts davon mit.

    Bitte versteh mich nicht falsch, Parse macht einige Dinge gut.
    Bsp:
    Logins auch mit Facebook und Twitter ohne das man sich große Sorgen um Security machen muss.
    Sobald man aber nicht so triviale Dinge lösen muss, steht man schnell vor Problemen, da das Parse entweder nicht kann oder schwierig zu realisieren ist.

    Das Problem bei Cloud Code ist, dass es kein nodejs und auch kein 'normales' Javascript ist. Man muss sich halt damit zurechtfinden und man legt sich auf die Parse Plattform fest.

    Alternativen kann ich dir nennen. Erfahrungen habe ich damit keine, da ich finde, dass ich mit einem eigens geschriebenen Backend in ASP.NET auf der Azure Plattform zeitlich und funktional besser dran bin. Die Plattform für das eigene Backend ist hier aber Geschmacksache.

    firebase.com/

    Du kannst dir diesen Macoun Talk anschauen:
    youtube.com/watch?v=gENx_36O13c

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von 99s99m ()

  • msch schrieb:

    Die Daten gibst du halt Facebook for free und der User bekommt nichts davon mit.
    Ja, das stimmt. Darüber habe ich mir auch Gedanken gemacht, aber da bei dieser App keine persönlichen Daten gespeichert werden und alle vom Nutzer eingegebenen Daten (wie z.B. in einem Forum) eh öffentlich online angezeigt werden, würde ich es in diesem Fall akzeptieren. Ich denke das Problem hat man bei fertigen Backends von Drittanbietern immer... Ich meine, firebase gehört Google. Ob die so viel besser mit den Daten umgehen als Facebook... ;)

    msch schrieb:

    firebase.com/
    Danke erst mal für den Tipp. Ich habe mich mal auf der Website umgeschaut und durch die FAQs gelesen, verstehe allerdings nicht alles.
    Was ist so toll an dieser "Realtime Database", die so hervorgehoben wird? Ist nicht jedes Server-Backend in Echt-Zeit?
    Was ist der Unterschied zwischen Connection und Request? Wenn ich Connection mit Request gleichsetze, würde Parse (1800 Req/Min) mehr als Firebase (1000 Con/Min) bieten (Ich hoffe, es kommt nicht all zu knauserig rüber, wenn ich die ganze Zeit auf den Preis schaue. Ich weiß, es gibt nichts umsonst und ich bin i. d. R. durchaus bereit, für gute Sachen Geld zu zahlen. Aber da die App ein reines Hobby-Projekt ist, versuche ich natürlich, die Kosten (vorerst) niedrig zu halten). Gibt es sonst Unterschiede zu Parse (vom Konzept her gesehen)?
    Als positiver Punkt ist mir aufgefallen, das Firebase Autoscale anbietet, im Gegensatz zu Parse. Erwähnenswert ist aber auch die mit Parse verglichen niedrige Database Storage. In der Free-Variante nur 100MB, selbst in der kostenpflichtigen Variante für 50$/Monat nur 3GB, während bei Parse schon in der Free-Variante 20GB zur Verfügung stehen. Allerdings fehlt mir auch hier die Erfahrung, um einschätzen zu können, wie viel Speicherplatz meine App-Daten benötigen.

    msch schrieb:

    Du kannst dir diesen Macoun Talk anschauen:
    youtube.com/watch?v=gENx_36O13c
    Danke für den Link, aber den Talk kenne ich. Da war ich live! ;)
  • Nein. Mit Realtime ist gemeint, dass Firebase eine Art Observer Pattern implementiert. Eine Echtzeitdatenbank bietet sich bei Multiplayergames etc. an. Bei Änderungen in der DB wird automatisch ein Update an die registrierten Observer also Clients geschickt. Bei Parse gibts so ein Feature meines Wissens nicht.

    firebase betitelt 'Connection' so:
    A connection is a measure of the number of users that are using your app or site simultaneously. This isn't the same as the total number of visitors to your site or the total number of users of your app. It's any open network connection to our database servers, including streaming REST API requests. All other REST API requests don't count towards your connection limits.


    Ein weitere Unterschied den man evaluieren sollte, ist Offline-Support, wenn das für einen relevant ist. Parse hat hier ein Feature in der SDK nachgeliefert. Bei firebase müsste man die Docs durchschauen.
    Parse hat kein autoscale. Das muss man selbst erledigen. Wenn die Limits erreicht werden, bekommst du am Client einen Fehler mit Code xyz.
  • msch schrieb:

    Mit Realtime ist gemeint, dass Firebase eine Art Observer Pattern implementiert. Eine Echtzeitdatenbank bietet sich bei Multiplayergames etc. an. Bei Änderungen in der DB wird automatisch ein Update an die registrierten Observer also Clients geschickt. Bei Parse gibts so ein Feature meines Wissens nicht.
    Ah okay, danke!

    msch schrieb:

    Ein weitere Unterschied den man evaluieren sollte, ist Offline-Support, wenn das für einen relevant ist.
    Ja, ich habe schon gemerkt, dass Firebase einige nette Features bereitstellt, wovon ich (in diesem Projekt) aber nur wenige verwenden kann. Ich behalte Firebase aber mal im Hinterkopf, man weiß ja nie...
    Ich mache mir jetzt erst einmal detailliert Gedanken, wie sich mein Konzept umsetzen lässt. Ich werde Cloud Functions in Anspruch nehmen, weiß aber noch nicht ganz wie genau...

    Bis dahin noch mal Danke für deine Zeit...! :thumbup: