Backend-softwarearkitekturcheckliste: Sådan oprettes et produkt fra bunden

Du vågner en morgen for at få din kop kaffe og voilà, Eureka-øjeblikket er her. Du fandt endelig ud af din forretningsmodel, og det hele falder på plads. Du ved, at investorer vil elske det, og du kan bare ikke vente med at begynde at bygge produktet. Den første bevægelsesfordel er din at tage.

Disse øjeblikke er sjældne, men når de sker, skal du starte på det rigtige tidspunkt. Alt hvad du behøver, er den rigtige guide, der hjælper dig med at finde ud af, hvad du skal og ikke bør gøre. Dette er ikke tid til at eksperimentere, det er tid til at udføre. Det er DIN tid nu!

BEMÆRK - Det følgende er relateret til bygning af softwarearkitekturer fra bunden. Så hvis du er interesseret i at kende nitty-gritty af de involverede teknologier, så fortsæt. Ellers skal du dele med dem, der helt sikkert vil elske dette: P

Hvor denne vejledning kom fra

Jeg har selv arbejdet på en håndfuld tidlige produkter, og for at være ærlig lavede jeg fejl. Jeg har altid ønsket, at der var en tjekliste, der skulle følges, mens jeg byggede et produkt fra bunden.

Der er så mange ting involveret i at opbygge en arkitektur fra bunden, at du helt vil glemme visse stykker. Og de vil vende tilbage for at bide dig i senere stadier af produktcyklussen.

Jeg besluttede endelig at oprette denne tjekliste over ting, som du bør overveje, før du trykker på implementeringsknappen for første gang.

Så uden yderligere opbygning, her er den tjekliste, du skal gennemgå, mens du bygger en Backend-arkitektur til et produkt fra bunden.

Vælg det KORREKTE sprog og ramme (til dit projekt)

At vælge det rigtige sprog og den rette ramme til dit produkt er vanskelig, og der er ingen særlig sølvkugle til dette. Mit råd er at vælge et sprog, du er mest fortrolig med og kende indviklingen ved ind og ud.

Når det er sagt, er det sjældent, for der er meget få mennesker, der er Javascript Ninjas eller Python Panthers eller hvad som helst funky navne derude.

Så vælg et sprog, der har virkelig god support i branchen, som Javascript, Python, Java eller Gå for at nævne nogle få. Du kan vælge ethvert sprog, bare vælg, hvilket sprog der er mest behageligt for dig.

Og husk - du bygger en MVP (Minimum Viable Product) og vil være i færd med at oprette en POC (Proof of Concept). Så få dit produkt ud så hurtigt som muligt. Du behøver ikke sidde fast i spørgsmål, der kan komme fra det nye sprog i byen. For at undgå disse problemer skal du vælge et mere udbredt, veldokumenteret sprog.

Endelig kan du skalere på et senere tidspunkt. Hvis du er i fasen med at udføre POC'er, skal du bare opbygge og få det gjort. Men hvis du bygger noget virkelig specifikt, og der er et sprog og en rammebygning specielt til det, så skal du helt sikkert vælge den teknologi.

Men det meste af tiden kan de problemer, vi prøver at løse, let håndteres med et af de ovennævnte sprog og deres respektive rammer. Så bare vælg en og kickstart dit produkt.

En god ressource til at hjælpe dig med at beslutte -

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

Implementere mikrotjenester til godkendelse og godkendelse

Der er mange måder at godkende og godkende en bruger på. Du kan prøve Session Tokens, JWT (JSON Web Tokens) eller OAuth, for at nævne nogle få. Hver mulighed har sine egne fordele og ulemper. Så lad os se nærmere på nogle af dem.

JSON Web Tokens

JWT'er er hurtige og nemme at implementere. Dette skyldes, at tokens aldrig er gemt hvor som helst på dit system. De er bare kodet, krypteret og sendt til brugeren. Så validering af en JWT er hurtigere end nogen anden metode.

Men da de ikke er gemt på systemet, kan du faktisk ikke få et token til at udløbe før dets faktiske udløbstid, og dette kan i visse tilfælde være et problem.

Så find ud af fordele og ulemper ved hvert godkendelsessystem, og vælg det, der bedst passer til dine behov. Jeg foretrækker personligt JWT'er (men det er mit eget valg).

Bemyndigelse

Glem aldrig at implementere godkendelse af brugere. Du vil ikke have logget ind User1 for at ændre detaljerne for User2. Dette kan forårsage rent kaos i dit system.

Identificer de slutpunkter, der har brug for godkendelse, og implementer dem med det samme. Du ønsker ikke, at tilstanden i din database skal blive ødelagt på denne måde. Husk forskellen mellem 401 og 403.

Følgende er visse slutpunkter, du absolut bør overveje, når du opretter dit godkendelsessystem (jeg oprettede et i Django ved hjælp af JWT). Der kan være visse tilføjelser / sletninger til din brugssag, men det er dem, du bør overveje at opbygge.

Mange rammer giver dem ud af kassen, men overvej dem, før du bygger dem alene. Tjek authentication_classes og permission_classes i Django Rest Framework for yderligere reference.

Se på denne Django REST Framework-ressource -

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

Opret en abstrakt basismodel, der skal arves af enhver anden model i din database

Husk det TØRRE princip - Gentag ikke dig selv? Det skal følges helt til kernen inden for Software Engineering.

På baggrund af ovenstående tankeproces vil der være visse kolonner i din database, som vil være til stede i hver tabel. Derfor er det bedre at oprette en abstrakt klasse for dem, så andre modelklasser kan arve fra dem.

Lad os gennemgå denne kode, og hvad den betyder:

  • id - Selvom det ikke er skrevet her, oprettes det automatisk af Django-rammen. Men hvis den ikke er der i din, skal du skrive den ned i denne klasse. Det er bare et automatisk inkrementeret felt, der kan bruges som en primær nøgle i dit databaseforhold.
  • created_at - Dette indebærer, når feltet / rækken blev indsat i din tabel, og det er udfyldt af selve rammen. Du behøver ikke at indstille det eksplicit.
  • updated_at - Dette indebærer, når feltet / rækken sidst blev ændret / opdateret i din tabel, og igen er det udfyldt af selve rammen.
  • delete_at + is_deleted - Dette er et kontroversielt felt. Jeg har ikke et nøjagtigt svar på, om det skal være der eller ej - for at være ærlig slettes intet på internettet nogensinde. Dette felt, hvis det er udfyldt, viser, at rækken slettes fra systemet (selvom dataene forbliver i systemet til fremtidige referencer og kan tages ud af databasen og gemmes i sikkerhedskopier)
  • uuid - Det afhænger af, om du vil lægge dette i din tabel eller ej. Hvis du har brug for at eksponere den primære nøgle på din tabel for et eksternt system, er det bedre at udsætte denne i stedet for det automatisk inkrementerede heltal-felt. Du undrer dig måske over hvorfor ...? Hvorfor vil du fortælle et eksternt system, at du har 10378 ordrer i din tabel? Men igen er det et personligt valg.

Opret en underretning mikroservice

Hvert produkt skal sende påmindelser og meddelelser til brugeren til engagement og transaktionsformål. Så hvert produkt har brug for dette.

Du bør bestemt overveje at opbygge en mikroservice, der leverer meddelelsestjenester (som Push Notification, Emails og SMS) til dine slutbrugere.

Dette skal være en separat Microservice helt. Byg ikke dette inde i din godkendelsesmikroservice eller din applikationstjeneste (den faktiske forretningslogik).

Der er mange tredjepartsbiblioteker / -tjenester, der kan bruges til at opbygge det til din applikation. Udnyt dem og bygg det oven på det.

Husk at opbygge alle de 3 funktioner:

  • Push-underretninger (APNS + FCM),
  • E-mails (integrer bare en SMTP-klient til start)
  • og SMS

BEMÆRK - Har to kanaler til afsendelse af SMS, transaktions- og salgsfremmende. Send aldrig en salgsfremmende SMS på en transaktionskanal, da der er chancer for, at du vil blive sagsøgt af en velinformeret og motiveret bruger.

En nem måde at konfigurere din SMTP-klient i din applikation på er at bruge dette i dine indstillinger:

Jeg gjorde dette i Django, men du kan gøre det samme på dit valgte sprog og din ramme.

Konfigurer fejllogning

Brug en middleware til at logge fejl, der opstår i dit produktionssystem. Dit produktionssystem overvåges ikke af mennesker, der sidder der for at se applikationslogfilerne 24/7. Så du har brug for et system, der logger disse interne serverfejl et centralt sted. Derefter kan du gå og tjekke dem dagligt eller oprette en webhook, så du kan blive advaret på det rigtige tidspunkt og tage sig af dem.

Der er mange tredjepartsværktøjslogningsværktøjer på markedet. Vælg bare en, der passer til dine behov. Jeg bruger mest Sentry / Airbrake.

Overvej at konfigurere webhooks, som jeg nævnte ovenfor. De vil informere dine brugere om fejl, og du kan for eksempel sende disse fejl, når og når de opstår på bestemte slanke kanaler. Derefter kan du kontrollere disse kanaler regelmæssigt og rette dem på baggrund af deres sværhedsgrad.

Airbrakes officielle hjemmeside - //airbrake.io/

Sentrys officielle hjemmeside - //sentry.io/welcome/

Implementeringsanmodning - svar og applikationslogning

Scenarie - En bruger kommer på din support og siger, at de ikke har modtaget transaktionskvitteringen for det køb, de foretog på dit websted. Hvad vil du gøre?

Hvis du har lagt Application Logging i dit system, skal du ikke bekymre dig. Hvad mener jeg nu med det? Det er altid bedre at vise et eksempel end at prøve at forklare med ord. Så her er det:

Jeg har logget på, at jeg er ved at sende e-mailen til den nævnte email_id. Jeg kan tjekke i applikationslogfilerne for at se, om e-mailen faktisk blev sendt til klienten ved at kontrollere, om en sådan log findes i systemet. Sørg for at anbringe omfattende logfiler i dit system, så du kan spore anmodningens rejse.

Derudover er det en god ide at sætte et async-system på plads, der udvælger sådanne anmodning-svar og applikationslogfiler fra dit system og dump dem på et centralt sted. Der kan de behandles for at være lettere at fortolke.

ELK-stakken er en god mulighed for dette: ElasticSearch - Logstash - Kibana.

Mere om ELK-stakken - //www.elastic.co/what-is/elk-stack

BEMÆRK - Når du logger på anmodning og svar, skal du passe på følgende:

  • Log ikke adgangskoder.
  • Log ikke tokens (adgangstokenerne, der bruges til godkendelse)
  • Log ikke OTP'er

Indfør begrænsning i dine API'er og hastighedsbegrænsning på dine applikationsservere

Scenarie - Du har lige lanceret din service og har markedsført produktet på sociale medieplatforme. En sort hathacker fandt ud af det og ville bare lege med dit system. Så de planlagde et DOS (Denial of Service) angreb på dit system.

For at bekæmpe dette kan du indstille hastighedsbegrænsning baseret på forskellige faktorer oven på dine belastningsbalancere til dine applikationsservere. Dette tager sig af DOS-angreb og forhindrer den ondsindede bruger i at angribe dine servere.

Scenarie - API-slutpunktet / otp / validering, der tager 4-cifrede OTP'er til godkendelse af brugeren og giver tilbage tokens, der skal bruges til godkendte API'er. En ondsindet bruger får mobilnummeret til en af ​​dine klienter og begynder at ramme API-slutpunktet med brute force-angreb, der ændrer IP'erne, et DDOS-angreb (Distribueret Denial of Service). Takstbegrænseren er ikke i stand til at stoppe brugeren, fordi IP'en ændrer sig ved hver anmodning, der fremsættes.

For at stoppe dette kan du også sætte skub i API'erne baseret på brugeren. Du kan konfigurere, hvor mange anmodninger der kan fremsættes af en bestemt bruger til et API-slutpunkt. For OTP-validering er et godt antal 5 anmodninger pr. 10 minutter. Dette forhindrer den ondsindede bruger i at udføre et brutalt DDOS-angreb på ovenstående API.

Begrænsning i Djangos REST Framework -

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

Opret og konfigurer asynkron kommunikation fra første dag

Scenarie - Du skal sende en velkomst-e-mail til brugeren, når de registrerer sig i din ansøgning. Frontendklienten rammer Register API, du opretter brugeren i backend efter valideringer, og dette starter processen med at sende en velkomst-e-mail.

At sende denne velkomst-e-mail vil tage tid, måske få sekunder. Men hvorfor vil du have, at mobilklienten sidder fast i en sådan proces? Dette kan ske i baggrunden uden at brugeren sidder fast uden særlig grund på siden Register. Hvert sekund er dyrebart, og du vil ikke have, at brugeren mister de dyrebare sekunder.

Så send bare e-mailen via en asynkron opgave. Brug medarbejdere, opgaver, meddelelsesmæglere og resultatet bag enderne til at udføre dette.

Et godt eksempel på dette fra Python-verdenen er selleri-arbejder. Bare læg den opgave, der skal udføres, i en meddelelsesmægler (Rabbit MQ / SQS osv.). Selleri vil lytte til dette og vil sende opgaven til den udpegede arbejdstager. Denne medarbejder behandler derefter anmodningen og placerer resultatet i en resultatbackend, der kan være et cache-system / databasesystem. (Redis / PostgreSQL for eksempel).

Du kan overvåge disse opgaver og køer med mange tredjepartsbiblioteker. Et godt eksempel på dette er selleri blomst, der overvåger alt dette.

Du kan læse mere om RabbitMQ her - //www.rabbitmq.com/

Og selleri - //docs.celeryproject.org/en/stable/django/first-steps-with-django.html

Og til sidst selleri blomst - //flower.readthedocs.io/da/latest/

Opret cron-job

Scenarie - Du har lige lanceret dit produkt, og du skal sende anbefalinger til dine brugere om nye produkter på din platform. Du sender disse på baggrund af deres købshistorik hver weekend.

Ovenstående opgave kan let udføres ved hjælp af et cron-job. Det kan let konfigureres i alle rammer. Det vigtige at huske på er, at du ikke skal placere cron-job direkte i crontab-filen på din server. Du skal lade rammen håndtere det.

Dette skyldes, at implementeringsingeniøren / Devops-ingeniøren skal være den eneste person, der har adgang til systemet som dette af sikkerhedsmæssige årsager. Selvom du ikke behøver at implementere det på denne måde, er det godt at have ting fra starten.

I Django-verdenen kan du bruge celerybeat til at konfigurere dine crons ved hjælp af selleriarbejdere.

Lær mere om selleri Beat her - // docs.celeryproject.org/en/latest/userguide/periodic-tasks.html

Administrer dine hemmeligheder korrekt (parameterfil)

Der er mange måder at administrere parameterhemmeligheder på dine produktionsservere. Nogle af dem er:

  • Oprette en hemmelighedsfil og gemme den i en privat s3-spand og trække den samme under implementeringen af ​​din applikation.
  • Indstilling af parametrene i miljøvariabler under implementeringen af ​​din applikation (lagring i s3 igen)
  • At placere hemmelighederne i en hemmelig styringstjeneste (f.eks. //Aws.amazon.com/secrets-manager/) og bruge dem til at få hemmelighederne i din applikation.

Du kan vælge en af ​​disse metoder i henhold til din komfort og brugssag. (Du kan vælge at gemme forskellige hemmelige filer også i lokale miljøer, mellemstationer og produktion.)

Version dine API'er fra dag ét

Dette er noget, du absolut bør overveje fra dag 1. Du ved aldrig, hvor ofte dine forretningsmodeller kan ændre sig, og du skal have forover-bagud kompatibilitet i din applikation. Så du skal versionere dine API'er for at sikre, at alt kører problemfrit for alle.

Du kan have forskellige apps til forskellige versioner og lade nginx håndtere det til din applikation. Eller du kan have versionering i selve applikationen og lade ruterne på din applikationsserver håndtere det. Du kan vælge en hvilken som helst metode til at implementere det - det vigtigste er at have versionversion aktiveret fra starten.

Beslut om hårde og bløde opdateringskontrolversioner til dine frontendklienter

Så hvad er forskellen mellem hårde og bløde opdateringer?

Hårde opdateringer henviser til, når brugeren er tvunget til at opdatere klientversionen til et højere versionsnummer end det, der er installeret på deres mobil.

Bløde opdateringer henviser til, når brugeren får vist en meddelelse om, at en ny version er tilgængelig, og de kan opdatere deres app til den nye version, hvis de vil.

Hårde opdateringer anbefales ikke, men der er tidspunkter, hvor du har brug for at håndhæve dem. Uanset hvad du skal, skal du helt sikkert overveje, hvordan du vil implementere dette til dine applikationer.

Du kan gøre dette ved at implementere eller konfigurere det i Play Store eller App Store. En anden måde er at oprette en API i din backend-applikation, der bliver ramt, hver gang mobilappen startes. Dette sender to nøgler: hard_update -> true / false og soft_update -> true / false, afhængigt af brugerens version og de hårde og bløde opdateringsversioner, der er angivet i dit backend-system.

Et godt sted at gemme disse versioner er i din cache (Redis / Memcache), som du kan ændre på farten uden at skulle bruge din applikation.

Indfør kontinuerlig integration (CI) fra dag et

Scenarie - en af ​​praktikanterne, der arbejder i dit projekt, er ikke dygtig nok til at skrive kode på produktionsniveau. De kan have ændret noget, der kan bryde en eller anden kritisk komponent i dit projekt. Hvordan kan du sikre, at alt er ok i sådanne tilfælde?

Indfør kontinuerlig integration. Det kører linters og test cases på hver begåelse og bryder, hvis nogen regler overtrædes. Dette vil igen blokere trækanmodningen fra at blive flettet, indtil alle fnugregler og testsager er bestået. Det er rart at have ting, og det hjælper faktisk også i det lange løb, så husk det.

Der er mange muligheder på markedet. Du kan enten vælge at implementere en på egen hånd (Jenkins CI / CD), eller du kan bruge TravisCI, CircleCI osv. Til det samme.

Læs op på TravisCI her - //travis-ci.org/

Og CircleCI - //circleci.com/

Aktivér Docker-support (personlig præference)

Opret en Dockerfile og docker-compose.yml til din applikation, så alle kører applikationen ved hjælp af Docker fra starten. En af hovedårsagerne til at bruge en sådan tilgang er at have konsistens på tværs af dit lokale / iscenesættelses- / produktionsmiljø, så ingen udviklere nogensinde kan sige dette igen:

Men det kørte på min maskine.

Det er ikke svært at anvende det fra dag 1. I begyndelsen skal du bare bruge Docker til dit lokale miljø, så opsætningen af ​​din applikation kan være rigtig glat. Men husk, hvordan du kan køre det både med og uden Docker i produktion.

Her er mere info om Docker Hub - //hub.docker.com/

Brug et APM-værktøj

Et applikationsovervågningsværktøj er et must have, hvis du vil overvåge din applikations API'er, transaktioner, databaseforbindelser osv.

Scenarie - din cron-servers harddisk er næsten fuld, og den er ikke i stand til at køre cron-job. Da den ikke kan finde plads på disken, kører dine crons ikke. Så hvordan kan du få besked, når dette sker?

Der er mange APM-værktøjer, som du kan bruge til at overvåge dette. Du kan konfigurere dem efter, hvornår du skal have besked. Du får meddelelser på det medium, du vælger, når et sådant kaos sker på dit system - og tro mig, det sker hele tiden. Så vær bedre forberedt på det. New Relic er en god mulighed.

Læs mere om New Relic her - //newrelic.com/

Brug ElasticSearch til at aktivere applikationer, der dækker hele applikationen i dine klientapps

Ifølge wikipedia,

Elasticsearch er en søgemaskine baseret på Lucene-biblioteket. Det giver en distribueret, multitenant-kompatibel fuldtekst-søgemaskine med en HTTP-webgrænseflade og skemafri JSON-dokumenter. Elasticsearch er udviklet i Java.

I starten vil du blive fristet til at bruge traditionelle databaseforespørgsler til at få resultater i den søgefelt til klientappen. Hvorfor? Fordi det er let.

Men traditionelle databaser er ikke beregnet til sådanne performante forespørgsler. Find ud af et godt tidspunkt at migrere din søgning til ElasticSearch og introducere en datapipeline i dit system. Det føder den elastiske søgning med data og forbinder derefter søgningen fra ElasticSearch til applikationsserveren.

Her er et godt overblik over Elasticsearch for at komme i gang.

Og ElasticSearch Docs - //www.elastic.co/guide/index.html

Sæt en firewall i din produktionsserver

Du skal bestemt gøre dette - det er et must-have. Sæt en firewall i din produktionsserver, og luk alle porte undtagen dem, der skal bruges til API'er (https-forbindelser). Rute API-slutpunkter ved hjælp af en reverse proxy-webserver, som NGiNX eller Apache. Ingen havn skal være tilgængelig for omverdenen end dem, der er tilladt af NGiNX.

Hvorfor skal du bruge 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/

Afslutter

De ovennævnte punkter er baseret på mine egne præferencer, og jeg har udviklet dem gennem årene. Der vil være små forskelle her og der, men begreberne forbliver de samme.

Og i sidste ende gør vi alt dette for at få et glat system bygget fra bunden til at køre i produktion så hurtigt som muligt efter du er kommet op med ideen.

Jeg forsøgte at nedbryde al min viden, som jeg har tilegnet mig gennem årene, og jeg kan tage fejl nogle få steder .Jeg f du tror, du kan tilbyde bedre information , er du velkommen til at kommentere. Og som altid del venligst, hvis du synes, det er nyttigt.