Kako narediti katero koli aplikacijo NodeJS App Server brez

Upam, da imate radi brez strežnika toliko kot jaz, ker je to še ena objava na to temo.

Zdaj, če govorimo o preprostem API-ju REST API brez strežnika, je vaša nastavitev na AWS: Lambda + API Gateway povsem očitna.

Kako pa je z drugimi (mikro) storitvami, ki jih ima morda vaš backkend? Veste, ni najboljša ideja, da bi vse svoje prijavne kode postavili v eno samo monolitno funkcijo AWS Lambda.

Izziv

Programske module enostavno uporabljamo kot brez strežnikov mikroservice, ki morajo medsebojno komunicirati. Prednostno bi moralo komunikacijo med storitvami urejati nekakšen ACL.

Poskus 1. Gateway API

To je prva misel, ki sem jo imel, ko sem poskušal rešiti težavo: samo izpostaviti vse mikroservice prek API-ja Gateway. Težava je ... Ustvarjeni API-ji so javni.

Zakaj je to problem? Na primer, ne želimo, da je storitev za obračunavanje izpostavljena celotnemu svetu, tudi če je dostop omejen s pomočjo neke vrste pooblastila.

No, API lahko naredite zasebnega, vendar so varnostne politike precej omejene:

Če želite dovoliti, da se vaši API-ji varno prikličejo, uporabite pravilnike o vhodnih vratih API
* uporabniki iz določenega računa AWS
* določeni obseg IP naslova vira ali bloki CIDR
* določene virtualne zasebne oblake (VPC) ali končne točke VPC (v katerem koli računu)

Zaradi tega je zelo težko nadzorovati komunikacijo med takšnimi storitvami. Edini način tega je, da storitve postavite v ločene VPC-je, preveč dela.

Poskus 2. Lambda

Zakaj ne bi vsako mikroservis postavili v ločeno AWS Lambda? Bo to rešilo težavo?

Da, v resnici bo to mikroservis brez strežnika, zato boste lahko s pomočjo pravilnikov IAM prilagodili dostop med storitvami, toda… To ni "enostavno".

Vem, da je dandanes povsem normalno, da ima kot enoto za uvajanje drobno funkcijo. V primeru, da ima vaša storitev več kot 1 končno točko / metodo / funkcijo, se šteje, da je v redu, če jo uporabite kot več Lambdas.

Razumem njegove prednosti, vendar žrtvujete enostavnost vzdrževanja in razvoja. Prav tako mi ni všeč ideja, da bi bila storitev nameščena kot nabor Lambda funkcij. Predstavljajte si, več ločenih funkcij, ki se ukvarjajo z obračunavanjem? To ni več omejen kontekst. Čeprav obstajajo primeri, ko je taka natančnost morda koristna, vendar je to redek primer.

Poskus 3. Debela Lambda

Ali lahko dejansko postavimo niz končnih točk kot ena sama Lambda (brez uporabe API-ja Gateway, seveda)?

Če bi to lahko storili, bi dobili vse prednosti prejšnje možnosti, lahko pa bi izbrali tudi natančnost naših enot za razporeditev.

Želim, da je naslednje: vsaka storitev, ki jo je mogoče uporabiti, mora biti preprost navaden objekt JS z metodami. To je precej nepomembno doseči tako, da med objektom in AWS Lambda dodate nekaj vrstic kode lepila.

Tu je moja izvedba tega: aws-rpc. Ta modul nodejs izpostavi funkcijo lambdaHandler, kjer samo posredujete predmet, in je samodejno izpostavljen vsem, ki lahko dostopajo do Lambde:

import {lambdaHandler} iz 'aws-rpc';
uvoz {TestServiceImpl} iz './TestServiceImpl';
// to je vaša enota za uvajanje
// to je tisto, ki ga navedete kot funkcijo za ravnanje z Lambdo
export const handler = lambdaHandler (nov TestServiceImpl ());

Zdaj lahko "upravljavec" postavite kot AWS Lambda. Tukaj je, kako prikličete njegove metode:

uvoz {TestService} iz './TestService';
const odjemalec = počakajte createClient  ("LambdaName", "test");
console.log (počakajte client.test ());

Upoštevajte, da morate za ustvarjanje metod za objekt odjemalca odjemalca prenesti vsa imena metod createClient, kot smo to storili v primeru.

To je potrebno, ker JS nima nobenih informacij o izvajanju o TypeScript vmesnikih. Lahko bi ga izvajal s pomočjo abstraktnih razredov, vendar mi ni všeč, da ¯ \ _ (ツ) _ / ¯.

Bonus! Vse lahko izvajate lokalno!

Verjamem, da je zelo pomembno, da je vaše lokalno razvojno okolje čim bolj udobno. Zato sem dodala tudi možnost zagon storitve in odjemalca lokalno, ne da bi na AWS uporabila karkoli (glej funkcije runService in createClient). Za primere si oglejte repozitorij na GitHubu.

Povzetek

To je zelo enostavno, da se izgubite v storitvah, ki jih ponujajo ponudniki oblakov, in nadgradite vašo infrastrukturo.

Vedno izberem najbolj enostavno in nazorno rešitev, na katero se lahko domislim. Vedno se spomnite tudi, da je veliko tehnik in praks mogoče ponovno uporabiti z drugih platform (ideja o maščobnem NodeJS Lambda se zgleduje po tako imenovanih kozarcih maščob iz sveta Java).

Če vam je bila ta tema všeč, si oglejte tudi te:

  • Morate se naučiti, kako narediti najboljšo arhitekturo brez strežnika
  • Kako ustvariti brezplačen CI / CD plinovod brez strežnika: 3 enostavna primera
  • Kako enostavno ponoviti DynamoDB po regijah
  • Kako narediti večregionalno aplikacijo (in plačati nič)
  • Naj bo Java Web App Server brez strežnika

Komentarji, všečki in delitve so zelo cenjeni. Na zdravje!