Το κινητό χάνει το σήμα συνεχώς. Οι εφαρμογές SaaS για κινητά πρέπει να δουλεύουν και όταν πέφτει το δίκτυο. Οι χρήστες χρειάζονται πάντα τα δεδομένα τους. Χρειάζονται επίσης να τελειώσουν τη δουλειά που έχουν μπροστά τους.

Η εφαρμογή μπορεί να στείλει αυτές τις αλλαγές αργότερα, μόλις επιστρέψει το σήμα. Έτσι το προϊόν δείχνει αξιόπιστο και όχι εύθραυστο. Μειώνει επίσης την απογοήτευση που φέρνει ένα αδύναμο δίκτυο.

Για τις ομάδες που φτιάχνουν εργαλεία SaaS για κινητά, η λειτουργία offline δεν είναι έξτρα δυνατότητα. Ανήκει στον σχεδιασμό από την πρώτη μέρα.

Τι σημαίνει offline-first

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

Αυτό αντιστρέφει τη συνηθισμένη σχέση ανάμεσα στην εφαρμογή και το backend. Ο διακομιστής κρατά τον έλεγχο, όμως η συσκευή στέκεται μόνη της σε πολλές εργασίες.

Το μοντέλο ταιριάζει καλά στις εφαρμογές SaaS για κινητά, επειδή οι χρήστες ζουν με ασταθές σήμα. Ανοίγουν εφαρμογές στο τρένο, στο ασανσέρ, σε ένα υπόγειο ή σε μια γεμάτη αίθουσα.

Μια συνηθισμένη εφαρμογή δείχνει δείκτη φόρτωσης μόλις πέσει το σήμα. Μια εφαρμογή offline-first συνεχίζει να δείχνει τα τοπικά δεδομένα και δέχεται ακόμη εισαγωγή. Η διαφορά μετράει, γιατί ο κόσμος κρίνει το λογισμικό από τη δύσκολη μέρα.

Γιατί οι εφαρμογές SaaS για κινητά θέλουν λειτουργία offline

Τα εργαλεία SaaS για κινητά κουβαλούν δουλειά που δεν αναβάλλεται. Πωλητές, οδηγοί, τεχνικοί πεδίου και συνεργεία εξαρτώνται από τη συσκευή όλη μέρα. Ένα νεκρό σημείο κόβει τη ροή στη χειρότερη στιγμή. Οι χρήστες χάνουν όσα πληκτρολόγησαν ή επαναλαμβάνουν ένα βήμα, επειδή δεν βλέπουν το αποτέλεσμα.

Ο σχεδιασμός offline-first χωρίζει τη συμπεριφορά της εφαρμογής από την κατάσταση του δικτύου. Η εφαρμογή δέχεται την αλλαγή τώρα και τη στέλνει μετά. Βελτιώνεται και η ταχύτητα, αφού τα τοπικά δεδομένα εμφανίζονται αμέσως.

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

Η τοπική αποθήκευση είναι το θεμέλιο

Η τοπική αποθήκευση είναι το θεμέλιο κάθε εφαρμογής offline-first. Επιτρέπει στο κινητό να κρατά καθαρά, τυποποιημένα δεδομένα χωρίς κλήση στον διακομιστή. Για τα περισσότερα προϊόντα, μια μικρή βάση δεδομένων κερδίζει ένα απλό key-value store. Η βάση κάνει πολύ πιο εύκολα τα ερωτήματα, τα ευρετήρια, τις σχέσεις και τα μεγάλα σύνολα.

Το SQLite είναι η συνηθισμένη επιλογή στα κινητά. Είναι μια μικρή σχεσιακή μηχανή που κάθεται πάνω στη συσκευή, και η ομάδα της εξηγεί πού ταιριάζει η μηχανή και πού όχι.

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

Πώς διαλέγουμε τι μένει στη συσκευή

Το offline-first δεν σημαίνει αντιγραφή όλου του backend σε κάθε κινητό. Αυτή η προσέγγιση σπαταλά χώρο και ανεβάζει τον κίνδυνο για την ιδιωτικότητα.

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

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

Μια ουρά για τις ενέργειες offline

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

Ένας χρήστης αλλάζει μια εγγραφή πελάτη ενώ είναι εκτός δικτύου. Η εφαρμογή αποθηκεύει την αλλαγή και προσθέτει μια εγγραφή συγχρονισμού στην ουρά. Όταν επιστρέψει το σήμα, περνά τη λίστα με τη σειρά.

Κάθε εγγραφή πρέπει να κρατά αρκετές λεπτομέρειες για να παιχτεί ξανά η ενέργεια: τον τύπο, το αναγνωριστικό της εγγραφής, το payload, μια χρονοσήμανση και ένα μοναδικό id.

Η ουρά χρειάζεται επίσης επαναλήψεις, γιατί μια στιγμιαία διακοπή δεν πρέπει να πετά μια ενέργεια του χρήστη. Οι επαναλήψεις όμως φέρνουν νέο κίνδυνο. Η ίδια κλήση σταλμένη δύο φορές δημιουργεί διπλές εγγραφές.

Γιατί μετράνε τα idempotent API

Μια idempotent κλήση δίνει το ίδιο αποτέλεσμα όσες φορές και αν τρέξει. Αυτή η ιδιότητα γίνεται κρίσιμη μόλις η συσκευή αρχίσει τις επαναλήψεις.

Σκεφτείτε μια εφαρμογή που δημιουργεί μια παραγγελία εκτός δικτύου. Συνδέεται ξανά και στέλνει την κλήση, αλλά η σύνδεση πέφτει πριν φτάσει η απάντηση. Η εφαρμογή δεν ξέρει αν ο διακομιστής δέχτηκε την παραγγελία. Πρέπει λοιπόν να δοκιμάσει ξανά.

Χωρίς προστασία, η επανάληψη φτιάχνει δεύτερη παραγγελία. Με idempotent endpoint, ο διακομιστής εντοπίζει την πρώτη κλήση και επιστρέφει το ίδιο αποτέλεσμα. Η συνηθισμένη προστασία είναι ένα μοναδικό αναγνωριστικό ενέργειας από τον client. Ο διακομιστής κρατά αυτό το id δίπλα στην εγγραφή που έφτιαξε.

Το HTTP έχει όνομα για την ιδιότητα, και το RFC 9110 ορίζει ποιες μέθοδοι τη φέρουν. Το μοτίβο βοηθά πολύ πέρα από τη δουλειά εκτός δικτύου. Προστατεύει επίσης τις κανονικές κλήσεις σε ασταθή σύνδεση. Στις εφαρμογές SaaS για κινητά, η idempotency ανήκει στον σχεδιασμό του API από την αρχή, όχι σε ένα μπάλωμα αργότερα.

Σχεδιασμός του κύκλου συγχρονισμού

Ο συγχρονισμός ενώνει την τοπική αποθήκευση με την αλήθεια του διακομιστή. Θέλει ρητές πολιτικές για το τι γίνεται όταν η συσκευή επιστρέφει.

Ένας απλός κύκλος ξεκινά όταν η εφαρμογή βλέπει ζωντανή σύνδεση. Στέλνει τις εκκρεμείς τοπικές ενέργειες και μετά κατεβάζει φρέσκα δεδομένα. Η σειρά εξαρτάται από τους επιχειρηματικούς κανόνες. Άλλες ομάδες στέλνουν πρώτα, άλλες κατεβάζουν πρώτα.

Σημασία έχει ο κύκλος να τρέχει με τον ίδιο τρόπο κάθε φορά. Μια προβλέψιμη διαδικασία επιτρέπει στην ομάδα να δοκιμάσει πολλούς τρόπους αποτυχίας.

Ο συγχρονισμός δεν πρέπει ποτέ να υποθέτει σταθερή σύνδεση. Ένα κινητό κρατά σήμα για λίγα δευτερόλεπτα και το χάνει ξανά. Για αυτόν τον λόγο, ο συγχρονισμός τρέχει σε μικρές παρτίδες. Η εφαρμογή σημειώνει κάθε παρτίδα που περνά, και ό,τι αποτυγχάνει περιμένει την επόμενη προσπάθεια.

Όταν συγκρούονται client και διακομιστής

Το πιο δύσκολο κομμάτι του offline-first φαίνεται όταν δύο αντίγραφα μιας εγγραφής αλλάζουν χωριστά.

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

Αυτή είναι μια σύγκρουση, και οι κανόνες της ανήκουν στον σχεδιασμό πριν από την κυκλοφορία. Η πιο απλή πολιτική είναι το last-write-wins: η νεότερη αλλαγή κατά ρολόι ή έκδοση παίρνει την εγγραφή. Είναι εύκολη στην κατανόηση, όμως χάνονται πραγματικές αλλαγές.

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

Καμία πολιτική δεν ταιριάζει σε όλες τις εφαρμογές SaaS για κινητά. Η σωστή ακολουθεί την επιχειρηματική διαδικασία, οπότε χαρτογραφήστε πρώτα τη διαδικασία.

Εκδόσεις και παρακολούθηση αλλαγών

Οι αριθμοί έκδοσης κάνουν τον συγχρονισμό πολύ πιο κατανοητό. Κάθε εγγραφή στον διακομιστή κρατά μια έκδοση που ανεβαίνει σε κάθε αλλαγή. Ο client στέλνει την έκδοση που είδε τελευταία. Ο διακομιστής ελέγχει αν η έκδοση ισχύει ακόμη.

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

Μια άλλη χρήσιμη τεχνική είναι να καταγράφετε μεμονωμένες αλλαγές αντί για ολόκληρες εγγραφές. Ο client στέλνει την ενέργεια, όχι όλο το αντικείμενο. Έτσι μειώνει τις πιθανότητες να πατήσει πάνω σε αλλαγές που δεν είδε ποτέ. Αφήνει επίσης καθαρό ίχνος για το τι προσπάθησε κάθε συσκευή.

Σχεδιασμός για αδύναμο σήμα

Το offline-first δεν αφορά μόνο τη νεκρή σύνδεση. Οι περισσότεροι χρήστες συναντούν αδύναμο σήμα πολύ πιο συχνά από καθόλου σήμα.

Ένα κινητό πηδά ανάμεσα σε Wi-Fi και δεδομένα κινητής όλη μέρα. Η σύνδεση μπορεί επίσης να απαντά, αλλά πολύ αργά. Οι εφαρμογές δεν πρέπει λοιπόν να μπλοκάρουν την οθόνη σε κάθε κλήση. Τα timeout μετράνε εδώ, αφού καμία κλήση δεν πρέπει να παγώνει την οθόνη όσο περιμένει η εφαρμογή.

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

Οι ενδείξεις δικτύου είναι επίσης αδύναμη πηγή αλήθειας. Μια συσκευή δηλώνει ζωντανή σύνδεση ενώ ο διακομιστής μένει άπιαστος. Το MDN σημειώνει ακριβώς αυτή την επιφύλαξη στις σημειώσεις του για την ιδιότητα online. Για αυτόν τον λόγο, θεωρήστε πιο ισχυρό σήμα μια πραγματική απάντηση του API.

Όταν αποτυγχάνει ο συγχρονισμός

Ο συγχρονισμός αποτυγχάνει για πολλούς λόγους. Ο διακομιστής απορρίπτει μια ενέργεια. Η σύνδεση πέφτει. Τα δεδομένα δεν ταιριάζουν πια με τους τρέχοντες κανόνες.

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

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

SQLite, WatermelonDB και μηχανή συγχρονισμού

Το SQLite μένει στέρεη επιλογή για τυποποιημένα τοπικά δεδομένα. Το σχεσιακό μοντέλο του ταιριάζει σε εγγραφές, σχέσεις, ερωτήματα και ασφαλείς εγγραφές. Μια ομάδα χτίζει επίπεδο συγχρονισμού κατευθείαν πάνω του. Αυτό δίνει πλήρη έλεγχο, όμως φορτώνει και περισσότερη δουλειά στην ομάδα.

Το WatermelonDB είναι άλλη επιλογή για εφαρμογές React Native που θέλουν πιο πλούσιο τοπικό επίπεδο. Στοχεύει σε local-first συμπεριφορά και αντιδραστικά διαβάσματα, και το έργο ζει ανοιχτά στο GitHub.

Καμία βάση δεδομένων δεν φτιάχνει μόνη της σχεδιασμό offline-first. Οι ομάδες χρειάζονται ακόμη κανόνες συγχρονισμού, ουρά, χειρισμό συγκρούσεων και σωστή συμπεριφορά API.

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

Δοκιμές και παρακολούθηση

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

Αυτές οι δοκιμές φανερώνουν σφάλματα που σπάνια δείχνει η δοκιμή σε ζωντανό δίκτυο. Χτίζουν επίσης σιγουριά ότι η εφαρμογή θα αντέξει στο πεδίο.

Μετά την κυκλοφορία, η ομάδα χρειάζεται ακόμη μάτια στον συγχρονισμό. Χρήσιμες μετρήσεις είναι το ποσοστό επιτυχίας, οι επαναλήψεις, το μέγεθος της ουράς, το ποσοστό συγκρούσεων και ο χρόνος συγχρονισμού. Μια ουρά που μεγαλώνει δείχνει αστοχία στο backend ή σφάλμα συγχρονισμού. Ένα άλμα στις συγκρούσεις φανερώνει αλλαγή στον τρόπο που δουλεύει ο κόσμος. Τα logs πρέπει να κρατούν αρκετές λεπτομέρειες για ένα ίχνος, χωρίς προσωπικά δεδομένα.

Συνηθισμένα λάθη

Ένα συνηθισμένο λάθος είναι να θεωρούμε το offline πρόβλημα προσωρινής μνήμης. Η προσωρινή μνήμη δείχνει παλιά δεδομένα, αλλά δεν δέχεται εγγραφές.

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

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

Πώς φτιάχνει η Square εφαρμογές SaaS για κινητά

Η Square Software φτιάχνει τα δικά της προϊόντα λογισμικού και αναλαμβάνει έργα outsourcing για ομάδες που θέλουν αξιόπιστες εφαρμογές SaaS για κινητά. Οι χρεώσεις μας κινούνται στα 35-55 EUR/ώρα. Οι ίδιοι κανόνες ισχύουν σε όλο το stack: τοπική αποθήκευση, σχεδιασμός API, ροή συγχρονισμού και χειρισμός συγκρούσεων.

Ένας συνεργάτης βοηθά να μπει το θεμέλιο πριν γίνει δύσκολη η προσθήκη του offline. Αυτό σημαίνει επιλογή τοπικής αποθήκευσης, ανθεκτικά API, σχέδιο για τον κύκλο συγχρονισμού και συμφωνία στις πολιτικές συγκρούσεων. Μπορείτε να κοστολογήσετε ένα έργο ή να επικοινωνήσετε μαζί μας.

Συμπέρασμα

Ο σχεδιασμός offline-first κρατά χρήσιμες τις εφαρμογές SaaS για κινητά όταν πέφτει το δίκτυο. Συνδυάζει τοπική αποθήκευση, ουρά, idempotent API, κύκλο συγχρονισμού και καθαρούς κανόνες για τις συγκρούσεις.

Το SQLite και το WatermelonDB δίνουν το τοπικό θεμέλιο. Οι ουρές κρατούν τις ενέργειες μέχρι να απαντήσει ο διακομιστής. Τα idempotent endpoint εμποδίζουν τις επαναλήψεις να διπλασιάσουν εγγραφές. Οι εκδόσεις και οι πολιτικές συγχώνευσης ευθυγραμμίζουν ξανά τις δύο πλευρές.

Το αποτέλεσμα είναι κάτι παραπάνω από μια λειτουργία offline. Είναι ένα προϊόν SaaS για κινητά φτιαγμένο για τον τρόπο που δουλεύουν πραγματικά τα δίκτυα κινητής. Για μια επιχείρηση, αυτή η αξιοπιστία γίνεται εμπιστοσύνη και δουλειά που δεν χάνεται ποτέ.

Αρχιτεκτονική offline-first σε εφαρμογές SaaS για κινητά: συγχρονισμός και συγκρούσεις