Tidigare märkte jag ofta ett vanligt tillvägagångssätt där utvecklare (inklusive mig själv förstås) använde samma API för både läsning och skrivning på varje fall. Ännu mer så förlitade vi oss ofta på samma datakälla, såsom MySQL/PostgreSQL, för att hantera båda operationerna.  Detta innebär att man skriver till samma kolumner och läser från dem, vilket ofta leder till problem med att optimera index på fält som var mycket efterfrågade.  Så till exempel skulle vi finna att vi ofta justerar index för att passa nya filter eller förbättra frågeprestanda, och fält som används med operatörer som LIKE utgjorde särskilda utmaningar på grund av deras inverkan på prestanda.  Dessa ändringar leder ofta till ytterligare justeringar av backend, inklusive modifiering av API:er för att exponera den uppdaterade funktionen, uppmätta tider på grund av ytterligare JOINs och så vidare...   För att möta utmaningen med att lägga till nya filter och sånt i API:t gjordes försök att optimera processen med hjälp av verktyg och standarder som   och, naturligtvis,   . Apicalypse GraphQL  Dessa lösningar syftade till att effektivisera generering av API-frågor och minska den manuella ansträngning som krävs för att implementera nya filter och funktioner, och erbjöd ett mer dynamiskt tillvägagångssätt för att hantera dataåtkomst, men de hade en hög inlärningskurva.   Med framväxten av CQRS (Command Query Responsibility Segregation) började ett nytt tillvägagångssätt dyka upp. Detta tankesätt uppmuntrade användningen av separata källor för att skriva och läsa. Skriver kan avge händelser, och läsningar kan bygga vyer från dessa händelser på särskilda platser. Även om läsningar och skrivningar hanterades inom samma databas (men olika tabeller), gav denna separation betydande fördelar, och kunde naturligtvis bli av med den andra utmaningen - JOINs och sökfrågor på domänmodeller, som läsmodeller är vanligtvis i en form av denormaliserade JSONs.   Detta väckte dock ett annat problem. Med läsningar var vi tvungna att skala skrivningar, vilket betyder att den enda anledningen till att vi var tvungna att skala instanser av vår applikation från X till Y var på grund av läsningar. Det här problemet kan delvis mildras med cachning, och i en värld av mikrotjänster kan vi ha dedikerade mikrotjänster för läsningar.   Men...  Ändå var detta inte en idealisk lösning för andra arkitektoniska stilar som modulära monoliter, där sådan separation kanske inte passade väl med systemets designfilosofi. En annan sak var, när API låg nere var hela produkten nere, och med tanke på att de flesta produkterna är beroende av fler läsningar än skrivningar, kan det påverka verksamheten i onödan (bortsett från down API förstås ;) )  Så, tänk om vi kunde fråga dessa "vyer", även kända som läsmodeller, direkt utan att involvera API:et och hantera belastningar? Det är här lösningar som   ,   och andra kommer in i bilden och utnyttjar ett mönster som kallas "Valet Key". Genom att använda det här mönstret kan frontends komma åt läsoptimerade modeller direkt, vilket minskar beroendet av backend-API:er. Naturligtvis måste frontend fortfarande "be" API efter "Valet key", men frontend kan cache-nycklar, så även när API är nere kan frontend fortfarande kommunicera och visa innehåll.  Meilisearch AppSearch  Med detta tillvägagångssätt kan vi fokusera på läsdatabasen och inte oroa oss för att hantera trafiken för läsningar i vårt API. "Valet Key" som tillhandahålls till frontend via vårt API är säkrad på ett sätt som frontend inte kan ändra den. Den innehåller fördefinierade filter och index.  Om gränssnittet kräver ytterligare funktioner kan det begära dem via API:t, där API:et kan validera om de ska tillåtas. Det är fortfarande färre samtal.   Några fördelar jag kan se är:    : Avlastar lästrafiken från API:t, så att den kan fokusera på kärnverksamheten. Minskad API-belastning    : Läsdatabaser eller söktjänster är bättre optimerade för att hantera hög trafik, vilket minskar behovet av att skala applikationens backend. Skalbarhet    : SaaS-alternativ eller alternativ som tillhandahålls av sig själv gör det möjligt för team att välja den bästa passformen för sin infrastruktur. Flexibilitet    : Fördefinierade filter och index säkerställer att frontend endast kan komma åt tillåten data, vilket minimerar riskerna. Nycklar kan ogiltigförklaras av API:et. Säkerhet    : Minskar behovet av ständiga API-uppdateringar för nya filter eller sökfunktioner. Utvecklareffektivitet    : Direkt åtkomst till läsoptimerade modeller ger snabbare frågesvar för användare. Förbättrad prestanda   Men det finns alltid nackdelar:    : Data kan visas efter en tid på grund av typen av eventuell konsistens i läsmodeller. Eventuell konsistens  Ytterligare underhåll: Introducerar en extra komponent som kräver övervakning och hantering.    : Scheman måste lagras i kod eller en gemensam plats, eftersom olika team från olika sammanhang kan behöva fylla i samma dokument (t.ex. anställd med e-post, men även med tillgängliga krediter och kuponger). Även om det inte är direkt knutet till detta mönster, lägger det till komplexitet. Schemakomplexitet  Kostnad för SaaS-version eller underhåll av egen värd  Så, det här tillvägagångssättet är inte en silverkula och introducerar sin egen uppsättning utmaningar, men om du är okej med en nackdel, kommer en liten förändring på frontend troligen inte att kräva att backend-teamet involveras, effektivisera utvecklingsprocessen och förbättra övergripande smidighet och självklart skalbarhet bör vara lättare.

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

Read My Stories

Techlead

Det här ljudet är producerat på berättelsens originalspråk!

Ett nytt frontend-hack förändrar API-prestanda till det bättre

About Author

KOMMENTARER

HÄNG TAGGAR

DENNA ARTIKEL PRESENTERAS I

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps