Βέλτιστες πρακτικές για την ανάπτυξη βάσεων δεδομένων σε πραγματικό χρόνο σε Firebase

Το News Rush χρησιμοποιεί το Firebase για 4 μήνες τώρα και παρόλο που υπάρχουν πράγματα που θέλουμε να δούμε βελτιωμένα (μπορείς να το ονομάσεις "τέλειο προϊόν;"), υπήρξε πολύτιμη προσθήκη στη στοίβα μας για τις απαιτήσεις συγχρονισμού δεδομένων για κινητά.

Στην πορεία, έχουμε μάθει μερικά μαθήματα σχετικά με τον καλύτερο τρόπο να χρησιμοποιήσουμε την πλατφόρμα για να καλύψουμε τις ανάγκες μας. Το Firebase είναι μια βάση δεδομένων με βάση τα έγγραφα / NoSQL και, ως εκ τούτου, μοιράζεται πολλά από τα χαρακτηριστικά αυτών των πλατφορμών, αλλά έχει και μερικά μοναδικά χαρακτηριστικά γνωρίσματα για να μάθει. Εδώ είναι ένας γρήγορος χώρος εγκεφάλου από αυτό που ανακαλύψαμε στο δρόμο.

RTFM!

Η τεκμηρίωση SDK είναι συνήθως τρομερή, έτσι πολλοί από εμάς τείνουν να απομακρύνουν τα υψηλά σημεία και να επιστρέψουν αργότερα (ή ποτέ).

Το αντίθετο ισχύει εδώ. Οι οδηγοί και τα δείγματα είναι εύκολο να ακολουθηθούν και τα έγγραφα αναφοράς είναι τόσο λεπτομερή όσο και παραπλανητικά σύντομα. Σχεδόν κάθε φορά που η ομάδα μας είχε μια ερώτηση ή ένα θέμα, βρήκαμε τη λύση σε κάτι που χάσαμε στα έγγραφα. Καθίσαμε τελικά και διάβαζαν κάθε λέξη κατευθείαν και ήταν 3 ώρες δαπανημένοι.

Υπάρχει επίσης ένα blog που είναι ένας θησαυρός για την εξεύρεση λύσεων σε πραγματικό κόσμο προβλήματα. Εδώ είναι μερικές από τις θέσεις που βρέθηκαν πιο κρίσιμες στο News Rush:

  • Ομαδική ασφάλεια στη βάση δεδομένων Firebase
  • Ερωτήματα, Μέρος 1: Κοινά ερωτήματα SQL που έχουν μετατραπεί για Firebase
  • Βέλτιστες πρακτικές: Πλακέτες σε Firebase

Συμπεράσματα: "Σχήματος χωρίς" δεν σημαίνει ότι δεν είναι εγκεφαλικά!

Είναι μια συνήθης εσφαλμένη αντίληψη ότι οι βάσεις δεδομένων με γνώμονα έγγραφα προσδίδουν αρχικό σχεδιασμό σχετικά με τον τρόπο με τον οποίο τα δεδομένα θα δομηθούν λιγότερο σημαντικά. Αυτός είναι ένας μύθος. Αν μη τι άλλο, βρήκαμε το αντίθετο: απαιτούν περισσότερα.

Δεν υπάρχει τίποτα ασυνήθιστο να λέμε ότι ο καλός προγραμματισμός μπορεί να βοηθήσει στη συμπίεση των περισσότερων επιδόσεων από οποιοδήποτε στοιχείο λογισμικού. Αλλά στις βάσεις δεδομένων SQL είναι συνήθως εύκολο να διορθώσετε τα λάθη σχεδιασμού, είτε με τη συμμετοχή σε περισσότερους πίνακες, την υπο-υποβολή ερωτημάτων ή την πραγματοποίηση μαζικών ενημερώσεων δεδομένων. Δεδομένου ότι η Firebase δεν έχει αυτές τις έννοιες, αφιερώστε χρόνο για να καθίσετε και να μοντελοποιήσετε τα δεδομένα σας και τα πρότυπα πρόσβασης μπροστά από το χρόνο. Θα χαρούμε να το κάνατε.

Και RTFM!

Η υποστήριξη είναι σύγχυση

Υπάρχει μια σειρά από επιλογές υποστήριξης, αλλά η προσπάθεια να χρησιμοποιηθεί το λάθος σε μια συγκεκριμένη κατάσταση μπορεί να είναι απογοητευτική. Οι εμπειρίες μας ήταν:

  • Χαλαρή: η αυτοβοήθεια και η καταιγίδα με προσανατολισμό προς την κοινότητα δεν είναι κατάλληλες για άλλους χώρους. Δεν είναι κατάλληλο για "κάτι έχει μειωθεί".
  • Φόρμα υποστήριξης: Ο "επίσημος" τόπος υποστήριξης. Αναφέρετε "κάτι είναι κάτω" εδώ. Τα αιτήματα των δυνατοτήτων θα μπορούσαν να πάρουν μια κονσέρβα "θα το εξετάσουμε, αλλά δεν υποσχέσεις" απάντηση.
  • Ομάδες Google: Ενεργός εμπλοκή της κεντρικής ομάδας με τις συνήθεις προειδοποιήσεις σχετικά με το χρόνο ανακατανομής σε συστήματα αλληλογραφίας που απευθύνονται σε ομάδες. Το καλύτερο μέρος για εξαιρετικά τεχνικές συζητήσεις σχετικά με τα εσωτερικά εφαρμογών και τα "παράξενα" θέματα.
  • StackOverflow: Λιγότεροι / απρόβλεπτοι χρόνοι απόκρισης αλλά το καλύτερο μέρος για υλικό αναφοράς. Εάν έχετε διαβάσει ένα ερώτημα & ερώτημα στο StackOverflow, γνωρίζετε τον τύπο της ερώτησης που είναι καλύτερο για να δημοσιεύσετε εκεί, επίσης.

Οι αναφορές και οι απλές ανακλήσεις είναι "φθηνές"

Στην Firebase, ένα "ref" είναι σαν ένας δείκτης στα δεδομένα. Είναι ενστικτώδες να θέλετε να αποθηκεύσετε προσωρινά δεδομένα ή να τα διαχειριστείτε διαφορετικά, αλλά στις τρέχουσες βιβλιοθήκες προγράμματος-πελάτη Firebase δεν πρέπει ποτέ να το κάνετε αυτό. Είναι πολύ απλά περιτυλίγματα γύρω από τις αναφορές διευθύνσεων URL σε αντικείμενα δεδομένων και οι επαναλήψεις συμβάντων που παρέχουν πρόσβαση μπορούν να έχουν μόνο έναν ακροατή κάθε φορά. Εάν πρέπει να αναφέρετε ένα αντικείμενο από δύο διαφορετικά μέρη, πάρτε δύο αναφορές σε αυτό. Δεν κοστίζει περισσότερο για να το κάνει αυτό.

Ένας παρόμοιος κανόνας ισχύει και για την ανάκτηση δεδομένων. Αυτά που προέρχονται από βάσεις δεδομένων SQL είναι συνηθισμένα να προσπαθούν να ανακτήσουν μεγαλύτερα αντικείμενα σε όσο το δυνατόν λιγότερα ερωτήματα για να εξαλείψουν το χρόνο ταξιδιού και το γενικό ερώτημα. Κατά την ισοπέδωση δομών δεδομένων, είναι δελεαστικό να αντιγράφετε δεδομένα "περίληψης" σε πολλαπλές τοποθεσίες για να επιτρέψετε σε μία μόνο ανάκτηση να λάβετε τα πάντα.

Στην Firebase, αυτή είναι σχεδόν εξ ολοκλήρου η λάθος απόφαση. Για ένα πράγμα, οι απλές ανάκτηση βασισμένες στο ref / ref βασίζονται σε μεγάλο βαθμό και το Firebase προσφέρει μαζική οριζόντια κλίμακα για αυτούς. Στην δοκιμή μας απόδοσης στο News Rush, διαπιστώσαμε επίσης ότι το Firebase κάνει πολύ καλύτερα με περισσότερα, μικρότερα αντικείμενα. Ακόμη και η αφαίρεση μερικών περιττών πεδίων μπορεί να προσφέρει μια μετρήσιμη αύξηση απόδοσης.

Όπως και με τα βελτιστοποιημένα μοτίβα Redis για δομές όπως τα hashes και τα σύνολα, η μαζική οριζόντια κλιμάκωση της Firebase είναι ένα από τα βασικά χαρακτηριστικά της. Δεν πρέπει να είναι μόνο ένα ωραίο να έχουμε. Θα πρέπει να χρησιμοποιηθεί μόνη της ως εργαλείο για τα σχέδια εφαρμογών σας.

Αποφύγετε τους πίνακες

Η τεκμηρίωση Firebase καλύπτει ήδη αυτό το θέμα. Όλα είναι σωστά. Αποφύγετε τους.

Δεν υπάρχουν ημερομηνίες

Η Firebase δεν έχει τύπο αντικειμένου ημερομηνίας και δεν επιτρέπει φθίνουσα ταξινόμηση. Απλά γράψαμε μια συνάρτηση βοήθειας "ενημέρωσης" που παίρνει τα εγγενή αντικείμενα με τα πεδία ημερομηνίας και τα μετατρέπει σε τιμές χιλιοστών του δευτερολέπτου από την εποχή και προσθέτει αντίστοιχες αρνητικές αριθμητικές παραλλαγές αυτών των τιμών. Η ταξινόμηση ανόδου σε τιμή αρνητικού αριθμού χρόνου παρέχει την επιθυμητή φθίνουσα σειρά.

Ένα μέγεθος δεν ταιριάζει σε όλα

Φαινόταν σαν μια τέτοια καλή ιδέα τότε ...

Αξιοποιήστε τις δυνάμεις της Firebase. Μην προσπαθήσετε να το κάνετε σε κάθε δουλειά που έχετε. Εδώ είναι μερικά πράγματα Firebase δεν είναι:

  • Μια μηχανή αναζήτησης. Έχει μερικές βασικές λειτουργίες όπως το πρόθεμα, αλλά αυτό είναι. Χρησιμοποιήστε ELK, Algolia, κ.λπ. αν χρειάζεστε πλήρη αναζήτηση αναζήτησης.
  • Μια στοίβα API. Οι λειτουργίες Cloud για το Firebase φαίνονται πολύ ελπιδοφόρες, αλλά εξακολουθούν να βρίσκονται στη Beta. Εάν η εφαρμογή σας είναι κάτι παραπάνω από μια λίστα υποχρεώσεων, σχεδιάστε τον τρόπο εκτέλεσης κώδικα από πλευράς διακομιστή / έμπιστου κώδικα.
  • Μια μηχανή αναφοράς. Ίσως να θέλετε να εκμεταλλευτείτε μια σχεσιακή βάση δεδομένων όταν χρειάζεται να κάνετε φέτες / ζάρια / φίλτρα / μεταλλάξετε / χρωματίσετε / κλπ τα δεδομένα σας.
  • Αυτο-φιλοξενείται ή μπορεί να χρησιμοποιηθεί πλήρως εκτός σύνδεσης. Η λειτουργικότητα εκτός σύνδεσης παρέχεται μέσω συγχρονισμού / επιμονής, αλλά στο πρώτο πρέπει να συμμετέχει το σύννεφο Firebase.

Ορισμός έναντι ενημέρωσης

Υπάρχει μεγάλη διαφορά μεταξύ των λειτουργιών SET και UPDATE. Επηρεάζει το τι συμβαίνει εάν δεν υπάρχει ακόμα ένα κλειδί, ιδιαίτερα κλειδιά μέσα σε σύνθετα αντικείμενα. Δώστε προσοχή σε αυτό!

Το FirebaseUI είναι εκπληκτικό!

Ας πρέπει να αναφέρω, υπάρχουν FirebaseUI συνοδευτικά έργα για πολλές πλατφόρμες. ΧΡΗΣΙΜΟΠΟΙΗΣΕ τους. Είναι εξαιρετικά χρήσιμες για πράγματα όπως η δημιουργία πίνακα προβολής για την εμφάνιση μιας λίστας αντικειμένων σε μια συλλογή Firebase.

Αυτή η βιβλιοθήκη παρέχει τις κλάσεις FUICollectionViewDataSource και FUITableViewDataSource (και τα αντίστοιχά τους σε Android) που κάνουν ξεκινώντας σε μια κινητή πλατφόρμα μερικές μόνο γραμμές κώδικα. Αυτή η εκκίνηση ήταν πολύ ωραία όταν αρχικά αξιολογούσαμε την Firebase. Ήμασταν σε θέση να συνθέσουμε μια απόδειξη της έννοιας μέσα σε λίγες ώρες με πολύ λίγη μάθηση εμπλέκονται σε σχέση με άλλες επιλογές στο τραπέζι.

Όταν είστε έτοιμοι για περισσότερη πολυπλοκότητα και έλεγχο, το FirebaseUI εξακολουθεί να είναι χρήσιμο επειδή παρέχει επίσης τις κλάσεις συλλογής δεδομένων FUIArray και FUIIndexArray χαμηλότερου επιπέδου που σας επιτρέπουν να οδηγείτε πράγματα όπως κεφαλίδες καρτελών και άλλες οθόνες.

Μου χάσατε τίποτα; Μοιραστείτε το δικό σας!