Hvad er Middleware? Definition og eksempler på brugssager

Middleware er et almindeligt anvendt udtryk i webudvikling. Det kan betyde mange ting afhængigt af konteksten, hvilket gør udtrykket lidt forvirrende.

I denne artikel starter vi med at definere udtrykket og fortsætter derefter med en diskussion om nogle forskellige brugssager.

Efter at have læst denne artikel vil du være i stand til at blive mere involveret i tekniske og arkitektoniske samtaler med dine jævnaldrende. Du vil også være mere i stand til at designe sikre og pålidelige API'er og datastrømme.

Definition af Middleware

Middleware er en software, der fungerer som en mellemmand mellem to applikationer eller tjenester for at lette deres kommunikation.

Du kan tænke på det som en proxy, der kan fungere som en dataakkumulator, oversætter eller bare en proxy, der videresender anmodninger.

Almindelige brugssager til Middleware

1) Oversætter

Der er mange dataudvekslingsformater, såsom JSON, XML og Protobuf. Selvom vi for det meste bruger JSON i dag, har hver af dem deres egne brugssager.

For eksempel er Protobuffere kendt for at være mere performante end JSON, men de er ikke læsbare for mennesker. Så du bruger muligvis Protobuffers til interne tjenester, og du bruger muligvis JSON, når API-forbrugeren er en browser.

Du kan også tjekke min artikel om Protobuffers, hvis du er interesseret i at lære mere om dem.

Lad os sige, at vi har brug for disse to tjenester, der taler forskellige protokoller, for at kommunikere med hinanden.

Vi kan oprette en middleware, der bruger et datakonverteringsbibliotek og oversætter anmodningerne til et format, som den modtagende tjeneste kan forstå.

2) Akkumulering-duplikering af data

Microservice-arkitektur er et populært arkitektonisk mønster, der ofte anvendes i moderne applikationer.

Hvis du ikke er fortrolig med mikrotjenestearkitekturen, betyder det grundlæggende, at din applikation består af mange små apps eller tjenester, der er uafhængige af hinanden og fungerer sammen ved at kommunikere over internettet.

For eksempel kan du i et e-handelsprojekt have en mikroservice til lagring og hentning af produkter, en anden mikroservice til søgning og en anden til godkendelse og lagring af brugere. Og hver har sin egen database.

Lad os sige, at vi vil implementere vores søgning på en måde, så den søger efter både brugere og produkter.

Hvis dette var en monolitisk applikation, kunne vi blot skrive en forespørgsel for at søge i hver tabel og deltage i resultaterne. Men nu kører vores databaser på forskellige servere.

Dette problem har flere løsninger, og vi vil se på to af dem.

Akkumulerende data

Vi kan bruge en middleware til at sende anmodninger til begge servere og bede dem om at søge i deres databaser efter brugernavne og produkter, der matcher det søgte ord.

Derefter kan vi akkumulere resultaterne fra begge servere og returnere dem til klienten. Bemærk, at antallet af anmodninger stiger lineært, når vi øger antallet af servere (og vi skal også flette disse data).

Kopiering af data

Vi kan gemme duplikatdata på vores søgeserver, så den kan søge direkte i dem i stedet for at anmode om fra produkt- og brugerservere. Dette er mindre effektivt med hensyn til hukommelse, men meget hurtigere - og hastighed er afgørende for søgetjenester.

Hvis de tabeller, vi har brug for, er produkt og bruger, kan vi også oprette disse tabeller på vores søgeserver. Når vi derefter gemmer en ny bruger i vores brugerdatabase, gemmer vi også en kopi på søgeserveren.

Vi har et par muligheder: først kan vi kalde søgeserverens gemningsmetoder fra bruger- og produktservernes gemningsmetoder for at duplikere dataene. Eller vi kan oprette en middleware til lagring, som gør følgende:

  • Når en gemningsanmodning ankommer, skal du ringe til produkt- / brugerserverens gem og søgeserverens gem.
  • Hvis den første gemning mislykkes, skal du ikke ringe til den anden (dette holder databaserne konsistente).

Lad os se på designdiagrammerne uden og med en middleware. For det første ser det sådan ud uden:

Ser grimt ud, ikke? Faktisk er det grimt, og det vil gøre din kode mere kompliceret og tæt koblet.

Her er den samme løsning med en middleware:

I dette scenarie ringer klientsiden bare til middlewaren for at gemme et produkt eller en bruger, og den håndterer resten.

Der er ingen kode relateret til duplikering af data hverken i produkt- eller brugerserverne eller på klientsiden. Middleware tager sig af de ting.

3) API-sikkerhed

For enhver frontend-klientsides kode kan vi se de udgående anmodninger enten i browserens konsol eller via en proxy.

Vi talte om en brugerserver, der tager sig af login og tilmelding. Hvis vores frontend-kode direkte sender anmodningerne til den pågældende server, er adressen på vores godkendelsesserver eksponeret. Efter at have lært IP-adressen på vores backend, kan angribere bruge værktøjer til at finde vores slutpunkter og scanne vores server for sårbarheder.

Vi kan bruge middleware som en proxy til at skjule vores godkendelsesserver's URL. Vores frontend kommunikerer med middleware, og den videresender anmodningen til godkendelsesserveren og returnerer svaret tilbage.

Denne tilgang giver os også mulighed for at blokere alle anmodninger til vores godkendelsesserver undtagen anmodningerne fra vores middlewares URL. Dette gør vores godkendelsesserver meget mere sikker.

Dette var ikke muligt tidligere, fordi vores frontend kommunikerede med godkendelsesserveren. Da frontend betyder klientens computer, kunne vi ikke anvende et IP-filter.

4) Eksponering af offentlige API'er

I den foregående del lærte vi, at mellemværker kan bruges til at begrænse adgangen til vores API.

Lad os nu se på den anden side af ligningen: Hvad hvis vi vil give begrænset adgang til vores API? Måske er vi softwareingeniør i en bank, og banken planlægger en hackathon. Vi bliver nødt til at give adgang til vores API, ikke?

Men da vi er en bank, kan vi selvfølgelig ikke give adgang til hele API'en og tillade enhver operation. Dette betyder, at vi skal finde en måde at give begrænset adgang på.

Til dette formål kan vi implementere en middleware, der kun afslører nogle af slutpunkterne og omdirigerer anmodningerne til vores faktiske API. Derefter leverer vi denne API til udviklerne ved hackathon.

Konklusion

I dette indlæg startede vi med at definere, hvad middleware er og forsøgte at kategorisere brugen af ​​mellemværker i webudvikling.

Husk, at dette ikke er en komplet liste over brugssager, men jeg håber stadig, at det var nyttigt for dig.

Tak fordi du læste. Hvis du kunne lide artiklen, opfordrer jeg dig til at tjekke min blog. Du kan også abonnere på min mailingliste for at få besked, når jeg offentliggør et nyt indlæg :)