Λίστα ελέγχου αρχιτεκτονικής Backend: Πώς να δημιουργήσετε ένα προϊόν από το μηδέν

Ξυπνάτε ένα πρωί για να πιείτε τον καφέ σας και το voilà, η στιγμή του Eureka είναι εδώ. Τελικά καταλάβατε το επιχειρηματικό σας μοντέλο και όλα ταιριάζουν. Ξέρετε ότι οι επενδυτές θα το λατρέψουν και απλώς δεν μπορείτε να περιμένετε να αρχίσουν να κατασκευάζουν το προϊόν. Το πρώτο πλεονέκτημα μετακίνησης είναι δικό σας.

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

ΣΗΜΕΙΩΣΗ - Τα παρακάτω σχετίζονται με την κατασκευή αρχιτεκτονικών λογισμικού από το μηδέν. Αν λοιπόν σας ενδιαφέρει να μάθετε την καλή τεχνολογία των σχετικών τεχνολογιών, συνεχίστε. Διαφορετικά, μοιραστείτε με αυτούς που σίγουρα θα το λατρέψουν: P

Από πού προήλθε αυτός ο οδηγός

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

Υπάρχουν τόσα πολλά πράγματα που εμπλέκονται στην κατασκευή μιας αρχιτεκτονικής από το μηδέν που θα ξεχάσετε εντελώς ορισμένα κομμάτια. Και θα επιστρέψουν για να σας δαγκώσουν σε μεταγενέστερα στάδια του κύκλου προϊόντων.

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

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

Επιλέξτε τη ΣΩΣΤΗ γλώσσα και πλαίσιο (για το έργο σας)

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

Τούτου λεχθέντος, είναι σπάνιο, επειδή υπάρχουν πολύ λίγοι άνθρωποι που είναι Javascript Ninjas, ή Python Panther, ή ό, τι funky ονόματα είναι εκεί έξω.

Επιλέξτε λοιπόν μια γλώσσα που έχει πραγματική καλή υποστήριξη στον κλάδο, όπως Javascript, Python, Java ή Go to name μερικά. Μπορείτε να επιλέξετε οποιαδήποτε γλώσσα, απλώς επιλέξτε ποια είναι η πιο άνετη για εσάς.

Και θυμηθείτε - δημιουργείτε ένα MVP (Ελάχιστο βιώσιμο προϊόν) και θα είστε στη διαδικασία δημιουργίας ενός POC (Απόδειξη της έννοιας). Λάβετε λοιπόν το προϊόν σας το συντομότερο δυνατό. Δεν χρειάζεται να κολλήσετε σε ζητήματα που μπορεί να προέρχονται από τη νέα γλώσσα στην πόλη. Για να αποφύγετε αυτά τα ζητήματα, επιλέξτε μια ευρύτερα χρησιμοποιούμενη, καλά τεκμηριωμένη γλώσσα.

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

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

Ένας καλός πόρος που θα σας βοηθήσει να αποφασίσετε -

//content.techgig.com/top-5-programming-languages-for-backend-web-development/articleshow/67337449.cms

Εφαρμογή μικροϋπηρεσιών ελέγχου ταυτότητας και εξουσιοδότησης

Υπάρχουν πολλοί τρόποι για τον έλεγχο ταυτότητας και την εξουσιοδότηση ενός χρήστη. Θα μπορούσατε να δοκιμάσετε τα Διακριτικά περιόδου σύνδεσης, το JWT (Διακριτικά Ιστού JSON) ή το OAuth, για να αναφέρετε μερικά. Κάθε επιλογή έχει τα δικά της πλεονεκτήματα και μειονεκτήματα. Ας δούμε λοιπόν μερικά από αυτά πιο προσεκτικά.

Διακριτικά Ιστού JSON

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

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

Έτσι, μάθετε τα πλεονεκτήματα και τα μειονεκτήματα κάθε συστήματος ελέγχου ταυτότητας και επιλέξτε αυτό που ταιριάζει καλύτερα στις απαιτήσεις σας. Προσωπικά προτιμώ JWTs (αλλά αυτή είναι η δική μου επιλογή).

Εξουσιοδότηση

Μην ξεχάσετε ποτέ να εφαρμόσετε την εξουσιοδότηση των χρηστών. Δεν θέλετε να συνδεθείτε στο User1 για να αλλάξετε τις λεπτομέρειες του User2. Αυτό μπορεί να προκαλέσει καθαρό χάος στο σύστημά σας.

Προσδιορίστε τα τελικά σημεία που χρειάζονται εξουσιοδότηση και εφαρμόστε τα αμέσως. Δεν θέλετε να καταστραφεί η κατάσταση της βάσης δεδομένων σας έτσι. Θυμηθείτε τη διαφορά μεταξύ 401 και 403.

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

Πολλά πλαίσια τα παρέχουν έξω από το κουτί, αλλά τα σκεφτείτε πριν τα δημιουργήσετε μόνοι σας. Ελέγξτε το authentication_classes και δικαιώματα_classes στο Django Rest Framework για περαιτέρω αναφορά.

Ρίξτε μια ματιά σε αυτόν τον πόρο Django REST Framework -

//www.django-rest-framework.org/tutorial/4-authentication-and-permissions/

Δημιουργήστε ένα αφηρημένο βασικό μοντέλο που θα κληρονομηθεί από κάθε άλλο μοντέλο στη βάση δεδομένων σας

Θυμηθείτε την DRY Αρχή - Μην επαναλάβετε τον εαυτό σας; Πρέπει να ακολουθηθεί στον πυρήνα της Μηχανικής Λογισμικού.

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

Ας δούμε αυτόν τον κώδικα και τι σημαίνει:

  • id - Αν και δεν είναι γραμμένο εδώ, δημιουργείται αυτόματα από το πλαίσιο Django. Αλλά αν δεν υπάρχει εκεί, γράψτε το σε αυτήν την τάξη. Είναι απλώς ένα πεδίο αυτόματης αύξησης που μπορεί να χρησιμοποιηθεί ως κύριο κλειδί στη σχέση βάσης δεδομένων σας
  • create_at - Αυτό υπονοεί όταν το πεδίο / σειρά εισήχθη στον πίνακα σας και συμπληρώθηκε από το ίδιο το πλαίσιο. Δεν χρειάζεται να το ορίσετε ρητά.
  • Diperbarui_at - Αυτό υποδηλώνει πότε το πεδίο / σειρά τροποποιήθηκε / ενημερώθηκε τελευταία φορά στον πίνακα σας και πάλι συμπληρώθηκε από το ίδιο το πλαίσιο.
  • delete_at + is_deleted - Άρα αυτό είναι ένα αμφιλεγόμενο πεδίο. Δεν έχω ακριβή απάντηση ως προς το αν πρέπει να είναι εκεί ή όχι - γιατί για να είμαι ειλικρινής, τίποτα στο Διαδίκτυο δεν διαγράφεται ποτέ. Αυτό το πεδίο, εάν συμπληρωθεί, απεικονίζει ότι η γραμμή διαγράφεται από το σύστημα (αν και τα δεδομένα παραμένουν στο σύστημα για μελλοντικές αναφορές και μπορούν να αφαιρεθούν από τη βάση δεδομένων και να αποθηκευτούν σε αντίγραφα ασφαλείας)
  • uuid - Εξαρτάται από το αν θέλετε να το βάλετε στο τραπέζι σας ή όχι. Εάν πρέπει να εκθέσετε το πρωτεύον κλειδί του τραπεζιού σας σε ένα εξωτερικό σύστημα, είναι καλύτερο να το εκθέσετε αντί να το πεδίο αυτόματης αύξησης ακέραιου. Ίσως αναρωτιέστε γιατί ...; Λοιπόν, γιατί θα θέλατε να πείτε σε ένα εξωτερικό σύστημα ότι έχετε 10378 παραγγελίες στο τραπέζι σας; Αλλά και πάλι είναι μια προσωπική επιλογή.

Ρυθμίστε μια υπηρεσία μικρο ειδοποίησης

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

Σίγουρα θα πρέπει να σκεφτείτε να δημιουργήσετε μια μικροσυσκευή που παρέχει υπηρεσίες ειδοποίησης (όπως Push Notification, Email και SMS) στους τελικούς χρήστες σας.

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

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

Θυμηθείτε να δημιουργήσετε και τις 3 λειτουργίες:

  • Ειδοποιήσεις προώθησης (APNS + FCM),
  • Email (απλώς ενσωματώστε έναν πελάτη SMTP για εκκίνηση)
  • και SMS

ΣΗΜΕΙΩΣΗ - Έχετε δύο κανάλια για αποστολή SMS, συναλλαγές και διαφημιστικά. Μην στέλνετε ποτέ διαφημιστικό SMS σε κανάλι συναλλαγών, καθώς υπάρχουν πιθανότητες να μηνύσετε έναν καλά ενημερωμένο και ενθαρρυντικό χρήστη.

Ένας εύκολος τρόπος για να ρυθμίσετε τις παραμέτρους του προγράμματος-πελάτη SMTP στην εφαρμογή σας το χρησιμοποιεί στις ρυθμίσεις σας:

Το έκανα στο Django, αλλά μπορείτε να κάνετε το ίδιο στην επιλεγμένη γλώσσα και πλαίσιο.

Ρύθμιση καταγραφής σφαλμάτων

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

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

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

Η επίσημη αρχική σελίδα της Airbrake - //airbrake.io/

Η επίσημη αρχική σελίδα του Sentry - //sentry.io/welcome/

Εφαρμογή αιτήματος - απόκριση και καταγραφή εφαρμογών

Σενάριο - Ένας χρήστης έρχεται στην υποστήριξή σας και λέει ότι δεν έχει λάβει την απόδειξη συναλλαγής για την αγορά που πραγματοποίησε στον ιστότοπό σας. Τι θα κάνεις?

Εάν έχετε τοποθετήσει το Application Logging στο σύστημά σας, τότε μην ανησυχείτε. Τώρα τι εννοώ με αυτό; Είναι πάντα καλύτερο να δείχνετε ένα παράδειγμα παρά να προσπαθείτε να το εξηγήσετε με λέξεις. Ορίστε λοιπόν:

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

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

Η στοίβα ELK είναι μια καλή επιλογή για αυτό: ElasticSearch - Logstash - Kibana.

Περισσότερα για τη στοίβα ELK - //www.elastic.co/what-is/elk-stack

ΣΗΜΕΙΩΣΗ - Κατά την καταγραφή αιτήματος και απαντήσεων, προσέξτε τα εξής:

  • Μην καταγράφετε κωδικούς πρόσβασης.
  • Μην καταγράφετε διακριτικά (τα διακριτικά πρόσβασης που χρησιμοποιούνται για έλεγχο ταυτότητας)
  • Μην καταγράφετε OTP

Εισαγάγετε το γκάζι στα API σας και περιορίστε τους ρυθμούς στους διακομιστές εφαρμογών σας

Σενάριο - Μόλις ξεκινήσατε την υπηρεσία σας και έχετε προωθήσει το προϊόν σε πλατφόρμες κοινωνικών μέσων. Ένας μαύρος χάκερ ανακάλυψε και ήθελε να παίξει με το σύστημά σας. Έτσι σχεδίασαν μια επίθεση DOS (άρνηση υπηρεσίας) στο σύστημά σας.

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

Σενάριο - Το τελικό σημείο / otp / επικύρωση API που παίρνει 4 ψηφία OTP για έλεγχο ταυτότητας του χρήστη και επιστρέφει διακριτικά που θα χρησιμοποιηθούν για έλεγχο ταυτότητας API. Ένας κακόβουλος χρήστης παίρνει τον αριθμό κινητού για έναν από τους πελάτες σας και αρχίζει να χτυπά το τελικό σημείο του API με βίαιη επίθεση αλλάζοντας τα IP, μια επίθεση DDOS (Κατανεμημένη άρνηση υπηρεσίας) Ο περιοριστής τιμών δεν μπορεί να σταματήσει τον χρήστη, επειδή η IP συνεχίζει να αλλάζει με κάθε αίτημα που υποβάλλεται.

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

Επιτάχυνση στο REST Framework του Django -

//www.django-rest-framework.org/api-guide/throttling/

Δημιουργήστε και διαμορφώστε ασύγχρονη επικοινωνία από την πρώτη ημέρα

Σενάριο - Πρέπει να στείλετε ένα email καλωσορίσματος στον χρήστη όταν εγγραφεί στην αίτησή σας. Ο πελάτης διεπαφής χτυπά το API εγγραφής, δημιουργείτε τον χρήστη στο backend μετά τις επικυρώσεις και αυτό ξεκινά τη διαδικασία αποστολής email καλωσορίσματος.

Η αποστολή αυτού του email καλωσορίσματος θα διαρκέσει λίγα δευτερόλεπτα. Αλλά γιατί θα θέλατε να κολλήσει ο πελάτης κινητής τηλεφωνίας για μια τέτοια διαδικασία; Αυτό μπορεί να συμβεί στο παρασκήνιο χωρίς να κολλήσει ο χρήστης χωρίς ιδιαίτερο λόγο στη σελίδα Εγγραφή. Κάθε δευτερόλεπτο είναι πολύτιμο και δεν θέλετε ο χρήστης να χάσει αυτά τα πολύτιμα δευτερόλεπτα.

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

Ένα καλό παράδειγμα αυτού από τον κόσμο της Python είναι ο εργάτης του Σέλινου. Απλώς θέστε την εργασία που πρέπει να εκτελεστεί σε έναν μεσίτη μηνυμάτων (Rabbit MQ / SQS, κ.λπ.). Το σέλινο θα το ακούσει και θα στείλει την εργασία στον καθορισμένο εργαζόμενο. Αυτός ο εργαζόμενος στη συνέχεια θα επεξεργαστεί το αίτημα και θα βάλει το αποτέλεσμα σε ένα backend αποτελεσμάτων που μπορεί να είναι ένα σύστημα Cache / σύστημα βάσης δεδομένων. (Για παράδειγμα, Redis / PostgreSQL).

Μπορείτε να παρακολουθείτε αυτές τις εργασίες και τις ουρές με πολλές βιβλιοθήκες τρίτων. Ένα καλό παράδειγμα αυτού είναι το σέλινο λουλούδι που παρακολουθεί όλα αυτά.

Μπορείτε να διαβάσετε περισσότερα για το RabbitMQ εδώ - //www.rabbitmq.com/

Και σέλινο - //docs.celeryproject.org/en/stable/django/first-steps-with-django.html

Και τέλος, Σέλινο λουλούδι - //flower.readthedocs.io/en/latest/

Ρύθμιση εργασιών cron

Σενάριο - Μόλις ξεκινήσατε το προϊόν σας και πρέπει να στείλετε προτάσεις στους χρήστες σας για νέα προϊόντα στην πλατφόρμα σας. Θα τα στέλνετε με βάση το ιστορικό αγορών τους κάθε Σαββατοκύριακο.

Η παραπάνω εργασία μπορεί να εκτελεστεί εύκολα χρησιμοποιώντας μια εργασία cron. Είναι εύκολα διαμορφώσιμο σε κάθε πλαίσιο. Το σημαντικό πράγμα που πρέπει να θυμάστε είναι ότι δεν πρέπει να τοποθετείτε τις εργασίες cron απευθείας στο αρχείο crontab του διακομιστή σας. Πρέπει να αφήσετε το πλαίσιο να το χειριστεί.

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

Στον κόσμο του Django, μπορείτε να χρησιμοποιήσετε το σέλινο για να διαμορφώσετε τα crons σας χρησιμοποιώντας σέλινο.

Μάθετε περισσότερα για το Celery Beat εδώ - // docs.celeryproject.org/en/latest/userguide/periodic-tasks.html

Διαχειριστείτε σωστά τα μυστικά σας (αρχείο παραμέτρων)

Υπάρχουν πολλοί τρόποι διαχείρισης μυστικών παραμέτρων στους διακομιστές παραγωγής σας. Κάποιοι από αυτούς είναι:

  • Δημιουργία ενός αρχείου μυστικών και αποθήκευση του σε έναν ιδιωτικό κάδο s3 και λήψη του κατά τη διάρκεια της ανάπτυξης της εφαρμογής σας.
  • Ρύθμιση παραμέτρων σε μεταβλητές περιβάλλοντος κατά την ανάπτυξη της εφαρμογής σας (αποθήκευση τους ξανά στο s3)
  • Βάζοντας τα μυστικά σε κάποια υπηρεσία μυστικής διαχείρισης (π.χ. //aws.amazon.com/secrets-manager/) και χρησιμοποιήστε τα για να λάβετε τα μυστικά στην αίτησή σας.

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

Έκδοση των API σας από την πρώτη ημέρα

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

Μπορείτε να έχετε διαφορετικές εφαρμογές για διαφορετικές εκδόσεις και να αφήσετε το nginx να το χειριστεί για την εφαρμογή σας. Εναλλακτικά, μπορείτε να διαθέτετε εκδόσεις στην ίδια την εφαρμογή και να αφήσετε τις διαδρομές στο διακομιστή εφαρμογών σας να το χειριστούν. Μπορείτε να επιλέξετε οποιαδήποτε μέθοδο για να την εφαρμόσετε - το κύριο σημείο είναι να έχετε ενεργοποιημένη την έκδοση από την αρχή.

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

Λοιπόν, ποια είναι η διαφορά μεταξύ σκληρών και μαλακών ενημερώσεων;

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

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

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

Μπορείτε να το κάνετε αυτό εφαρμόζοντας ή διαμορφώνοντάς το στο Play Store ή στο App Store. Ένας άλλος τρόπος είναι να δημιουργήσετε ένα API στην εφαρμογή backend που θα χτυπιέται κάθε φορά που ξεκινά η εφαρμογή για κινητά. Αυτό θα στείλει δύο κλειδιά: hard_update -> true / false και soft_update -> true / false, ανάλογα με την έκδοση του χρήστη και τις σκληρές και μαλακές εκδόσεις ενημέρωσης που έχουν οριστεί στο σύστημα backend σας.

Ένα καλό μέρος για την αποθήκευση αυτών των εκδόσεων βρίσκεται στην προσωρινή μνήμη (Redis / Memcache), την οποία μπορείτε να αλλάξετε εν κινήσει χωρίς να χρειάζεται να αναπτύξετε την εφαρμογή σας.

Εισαγάγετε τη συνεχή ενσωμάτωση (CI) από την πρώτη ημέρα

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

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

Υπάρχουν πολλές διαθέσιμες επιλογές στην αγορά. Μπορείτε είτε να επιλέξετε να το εφαρμόσετε μόνοι σας (Jenkins CI / CD), είτε μπορείτε να χρησιμοποιήσετε το TravisCI, το CircleCI κ.λπ. για το ίδιο.

Διαβάστε το TravisCI εδώ - //travis-ci.org/

Και CircleCI - //circleci.com/

Ενεργοποίηση υποστήριξης Docker (προσωπική προτίμηση)

Δημιουργήστε ένα Dockerfile και το docker-compose.yml για την εφαρμογή σας, έτσι ώστε όλοι να εκτελούν την εφαρμογή χρησιμοποιώντας το Docker από την αρχή. Ένας από τους κύριους λόγους για να χρησιμοποιήσετε μια τέτοια προσέγγιση είναι να έχετε συνέπεια στο τοπικό σας περιβάλλον / σκηνικό / παραγωγή, έτσι ώστε κανένας προγραμματιστής να μην μπορεί να το πει ξανά:

Αλλά έτρεξε στο μηχάνημά μου.

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

Ακολουθούν περισσότερες πληροφορίες σχετικά με το Docker Hub - //hub.docker.com/

Χρησιμοποιήστε ένα εργαλείο APM

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

Σενάριο - ο σκληρός δίσκος του διακομιστή cron είναι σχεδόν πλήρης και δεν είναι σε θέση να εκτελέσει εργασίες cron. Επειδή δεν μπορεί να βρει χώρο στο δίσκο, τα crons σας δεν εκτελούνται. Πώς μπορείτε λοιπόν να λαμβάνετε ειδοποίηση όταν συμβαίνει αυτό;

Υπάρχουν πολλά εργαλεία APM που μπορείτε να χρησιμοποιήσετε για να το παρακολουθήσετε. Μπορείτε να τα διαμορφώσετε ανάλογα με το πότε πρέπει να ειδοποιηθείτε. Θα λαμβάνετε ειδοποιήσεις στο μέσο της επιλογής σας όταν συμβαίνει τέτοιο χάος στο σύστημά σας - και πιστέψτε με αυτό συμβαίνει συνεχώς. Έτσι καλύτερα να είστε προετοιμασμένοι για αυτό. Το νέο λείψανο είναι μια καλή επιλογή.

Διαβάστε περισσότερα για το New Relic εδώ - //newrelic.com/

Χρησιμοποιήστε το ElasticSearch για να ενισχύσετε τις αναζητήσεις σε εφαρμογές σε εφαρμογές πελατών σας

Σύμφωνα με τη wikipedia,

Το Elasticsearch είναι μια μηχανή αναζήτησης που βασίζεται στη βιβλιοθήκη Lucene. Παρέχει μια κατανεμημένη μηχανή αναζήτησης πλήρους κειμένου με δυνατότητα πολλαπλών συνομιλιών με διεπαφή ιστού HTTP και έγγραφα JSON χωρίς σχήμα. Το Elasticsearch αναπτύσσεται στην Java.

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

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

Ακολουθεί μια καλή επισκόπηση του Elasticsearch για να ξεκινήσετε.

Και τα Έγγραφα Ελαστικής Αναζήτησης - //www.elastic.co/guide/index.html

Τοποθετήστε ένα τείχος προστασίας στον διακομιστή παραγωγής σας

Πρέπει σίγουρα να το κάνετε αυτό - είναι απαραίτητο. Τοποθετήστε ένα τείχος προστασίας στον διακομιστή παραγωγής σας και κλείστε όλες τις θύρες εκτός από αυτές που θα χρησιμοποιηθούν για API (συνδέσεις https). Δρομολογήστε τα τελικά σημεία του API χρησιμοποιώντας έναν διακομιστή web αντίστροφης μεσολάβησης, όπως το NGiNX ή το Apache. Κανένα λιμάνι δεν πρέπει να είναι προσβάσιμο στον εξωτερικό κόσμο εκτός από αυτό που επιτρέπεται από το NGiNX.

Γιατί πρέπει να χρησιμοποιήσετε το NGiNX:

  • //www.nginx.com/resources/wiki/community/why_use_it/
  • //blog.serverdensity.com/why-we-use-nginx/
  • //www.freecodecamp.org/news/an-introduction-to-nginx-for-developers-62179b6a458f/

Τυλίγοντας

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

Και στο τέλος κάνουμε όλα αυτά για να δημιουργήσουμε ένα ομαλό σύστημα από το μηδέν που λειτουργεί στην παραγωγή το συντομότερο δυνατό μετά την ιδέα.

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