Programmering

9 grunde til at oprette din webapp med Jamstack

At opbygge en fleksibel og iterabel applikation på kort tid kan være udfordrende. Kendte skyer som AWS, Azure og GCP hjælper med at levere skalerbare webapplikationer med lave omkostninger inden for få uger. Vælg en administreret database, flyt applikationskoden til Docker-containere eller back-end-funktioner, og implementer alt på eventuelle kodeændringer. Sådan ser moderne applikationsudvikling ud, ikke?

I dette indlæg vil jeg beskrive de vigtigste ting, der er nødvendige for at udvikle og sende software i et fantastisk tempo med en Next.js-applikation skrevet i TypeScript, implementeret via Vercel og bakket op af en serverløs database kaldet FaunaDB. Jeg vil forklare hver af disse ting i detaljer ved at tilføje et par eksempler her og der. Jeg kan varmt anbefale at prøve dem alle. Alle har generøse gratis niveauer og kan bruges af et lille udviklerhold på op til tre medlemmer.

Brugen af ​​udviklingscentrerede implementeringsplatforme i kombination med serverløse tilbud er opsummeret som Jamstack. "J-A-M" betyder JavaScript, API'er og markering. Mere om Jamstack kan findes på //jamstack.org/.

Implementering er en detaljeret implementering

Antallet af tjenester, som jeg kan bruge i en sky, er overvældende. På dette tidspunkt har AWS 250 forskellige tjenester. Jeg er nødt til at definere, hvordan jeg opretter forbindelse til og opsætter implementeringer til mine nye funktioner, til mit ikke-produktionsmiljø og til mit produktionsmiljø

Hvis jeg arbejder på et projekt med flere udviklere parallelt, vil jeg bare sende en URL til min kollega for at dele min nuværende funktionsgren.

Derudover er jeg nødt til at oprette domæner og underdomæner, skalere tjenesten, overføre offentlige slutpunkter, administrere databaseforbindelser, oprette hemmelighedsstyring osv.

Vercel-platformen forbinder problemfrit med versionskontrolsystemer som GitHub eller GitLab. Jeg forbinder simpelthen mit lager og tilpasser min nameserver-værtsnavnindstilling, og jeg er færdig.

I mit nuværende projekt har jeg defineret nogle praktiske npm-opgaver, der bruges i hver build for at sikre, at vores software både fungerer og lever op til softwarestandarder og bedste praksis:

{

"scripts": {

"tsc": "tsc", // check typesikkerhed

"lint": "eslint", // gør analyse af statisk kode

"lint: ci": "eslint --max-advarsler = 0",

"lint: fix": "eslint --fix",

"test": "jest --watch", // udføre tests

"test: ci": "spøg --ci",

"test: coverage": "jest --coverage",

"checks": "npm-run-all lint: ci tsc test: ci",

"dev": "env-cmd next dev", // start lokalt dev-miljø

"start": "næste",

"start-port": "næste start -p $ PORT",

"build": "næste build",

"now-build": "npm-run-all checks build", // CI build

"serve": "næste start",

  }

}

Som standard kører Vercel nu-build opgave på hver bygning. Dette udløser nogle andre opgaver, der statisk kontrollerer vores kode, kører alle tests og bygger vores software.

På grund af det faktum, at alt bare fungerer, får jeg en masse implementeringsplatformfunktioner ud af kassen. Jeg drager fordel af kommende forbedringer, uden at de giver mig nogen problemer i fremtiden.

$config[zx-auto] not found$config[zx-overlay] not found