U prošlosti sam često primjećivao uobičajeni pristup gdje su programeri (uključujući i mene, naravno) koristili isti API za čitanje i pisanje u svakom slučaju. Štaviše, često smo se oslanjali na isti izvor podataka, kao što je MySQL/PostgreSQL, za rukovanje obje operacije.  To znači pisati u iste kolone i čitati iz njih, što često dovodi do problema s optimizacijom indeksa na poljima koja su bila jako upitna.  Tako, na primjer, često bismo prilagođavali indekse kako bismo prilagodili nove filtere ili poboljšali performanse upita, a polja koja se koriste s operatorima kao što je LIKE predstavljala su posebne izazove zbog svog utjecaja na performanse.  Ove promjene često dovode do daljnjih prilagođavanja pozadine, uključujući modificiranje API-ja kako bi se otkrila ažurirana funkcionalnost, mjerena vremena zbog dodatnih JOIN-ova i tako dalje...   Kako bi se riješio izazov u vezi sa dodavanjem novih filtera i stvari u API, bilo je pokušaja da se optimizira proces korištenjem alata i standarda kao što su   i, naravno,   . Apicalypse GraphQL  Ova rješenja su imala za cilj da pojednostave generiranje API upita i smanje ručni napor potreban za implementaciju novih filtera i funkcionalnosti, nudeći dinamičniji pristup rukovanju pristupom podacima, ali su imali visoku krivulju učenja.   Sa usponom CQRS (Command Query Responsibility Segregation), počeo je da se pojavljuje novi pristup. Ovakav način razmišljanja podstakao je upotrebu odvojenih izvora za pisanje i čitanje. Pisanje može emitovati događaje, a čitanje može izgraditi poglede iz tih događaja na određenim mjestima. Čak i kada bi se čitanjem i pisanjem upravljalo unutar iste baze podataka (ali različitim tabelama), ovo razdvajanje je donijelo značajne prednosti i, naravno, moglo se riješiti drugog izazova - JOIN-ova i upita za pretraživanje na modelima domena, kao što su modeli čitanja obično u obliku denormaliziranih JSON-ova.   Međutim, ovo je izazvalo još jedan problem. Kod čitanja, morali smo skalirati zapise, što znači da je jedini razlog zašto smo morali skalirati instance naše aplikacije od X do Y bio zbog čitanja. Ovaj problem bi se mogao djelomično ublažiti keširanjem, a u svijetu mikroservisa mogli bismo imati namjenske mikroservise za čitanje.   ali...  Ipak, ovo nije bilo idealno rješenje za druge arhitektonske stilove kao što su modularni monoliti, gdje takvo razdvajanje možda neće biti u skladu s filozofijom dizajna sistema. Druga stvar je bila, kada je API nestao, cijeli proizvod je nestao, a imajući na umu da se većina proizvoda oslanja na više čitanja nego upisivanja, to bi moglo nepotrebno utjecati na poslovanje (osim donjeg API-ja naravno ;) )  Dakle, šta ako bismo mogli pitati te "preglede", također poznate kao modeli čitanja, direktno bez uključivanja API-ja i rukovanja opterećenjima? Ovdje na scenu stupaju rješenja kao što su   ,   i druga, koristeći obrazac koji se zove "Valet Key". Koristeći ovaj obrazac, frontendovi mogu direktno pristupiti modelima optimiziranim za čitanje, smanjujući ovisnost o backend API-jima. Naravno, frontend i dalje mora "tražiti" API za "Valet ključ", ali frontend može keširati ključeve, tako da čak i kada je API isključen, frontend i dalje može komunicirati i prikazivati sadržaj.  Meilisearch AppSearch  Sa ovim pristupom, možemo se fokusirati na čitanu bazu podataka i ne brinuti o rukovanju prometom za čitanja u našem API-ju. "Valet Key" dostavljen frontendu preko našeg API-ja je osiguran na način da ga frontend ne može promijeniti. Uključuje unaprijed definirane filtere i indekse.  Ako frontend zahtijeva dodatne mogućnosti, može ih zatražiti preko API-ja, gdje API može potvrditi da li da ih dozvoli. I dalje je manje poziva.   Neke prednosti koje mogu vidjeti su:    : Otklanja promet čitanja iz API-ja, omogućavajući mu da se fokusira na osnovne operacije. Smanjeno opterećenje API-ja    : baze podataka za čitanje ili usluge pretraživanja bolje su optimizirane za rukovanje velikim prometom, smanjujući potrebu za skaliranjem pozadinskog dijela aplikacije. Skalabilnost    : SaaS ili opcije koje se sami hostuju omogućavaju timovima da odaberu ono što najbolje odgovara njihovoj infrastrukturi. Fleksibilnost    : unaprijed definirani filteri i indeksi osiguravaju da frontend može pristupiti samo dozvoljenim podacima, minimizirajući rizike. API može poništiti ključeve. Sigurnost    : Smanjuje potrebu za stalnim ažuriranjima API-ja za nove filtere ili mogućnosti pretraživanja. Efikasnost programera    : Direktan pristup modelima optimiziranim za čitanje pruža brže odgovore na upite za korisnike. Poboljšane performanse   Ali, uvek postoje nedostaci:    : Podaci se mogu pojaviti nakon nekog vremena zbog prirode eventualne konzistentnosti u čitanim modelima. Eventualna konzistentnost  Dodatno održavanje: Uvodi dodatnu komponentu koja zahtijeva praćenje i upravljanje.    : Šeme moraju biti pohranjene u kodu ili na zajedničkom mjestu, jer će različiti timovi iz različitih konteksta možda morati da popune isti dokument (npr. zaposlenik e-poštom, ali i dostupnim kreditima i kuponima). Iako nije direktno vezan za ovaj obrazac, on dodaje složenost. Složenost šeme  Cijena SaaS verzije ili samostalnog održavanja  Dakle, ovaj pristup nije srebrni metak i uvodi svoj skup izazova, ali ako ste u redu s nedostacima, onda mala promjena na frontendu vjerovatno neće zahtijevati uključivanje pozadinskog tima, pojednostavljenje procesa razvoja i poboljšanje ukupna agilnost i naravno skalabilnost bi trebali biti lakši.

This story contains new, firsthand information uncovered by the writer.

Read My Stories

Techlead

Ovaj audio je proizveden na originalnom jeziku priče!

Novi frontend hak mijenja performanse API-ja na bolje

About Author

KOMENTARI

HANG TAGS

OVAJ ČLANAK JE PREDSTAVLJEN U

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps