Serverless funkcijos su Vercel ir Next.js

Kas yra serverless ir kodėl tai turėtų jus dominti

Prisimenu, kai pirmą kartą išgirdau terminą „serverless” – galvojau, kad tai kažkoks marketingo triukas. Kaip gali būti be serverio, jei viskas veikia serveriuose? Pasirodo, čia daugiau apie tai, kad jums nereikia galvoti apie serverių administravimą, skalabilumą ar infrastruktūrą. Jūs tiesiog rašote kodą, o kažkas kitas rūpinasi visu tuo techniniu šlamštu.

Serverless funkcijos – tai nedideli kodo gabalai, kurie vykdomi pagal poreikį. Užuot palaikę visą laiką veikiantį serverį, kuris laukia užklausų (ir ėda jūsų pinigus net kai niekas jo nenaudoja), serverless funkcijos „pabunda” tik tada, kai jų reikia. Tai tarsi taksi užsakymas vietoj nuosavo automobilio pirkimo – mokate tik už tai, ką naudojate.

Vercel su Next.js šioje srityje yra tikras žaidimo keitėjas. Jie padarė serverless funkcijų kūrimą tokį paprastą, kad net juniorui programuotojui tai neturėtų sukelti galvos skausmo. Bet nepersišokime per daug į priekį.

Next.js ir Vercel simbiozė

Next.js yra React framework’as, kurį sukūrė Vercel komanda (anksčiau vadinta Zeit). Tai jau daug ką pasako apie jų integraciją – jie gimė kartu ir veikia kaip gerai suderintas mechanizmas.

Kai deployinate Next.js projektą į Vercel, magija vyksta automatiškai. Kiekvienas API route, kurį sukuriate savo projekte, automatiškai tampa serverless funkcija. Nereikia jokių papildomų konfigūracijų, YAML failų ar sudėtingų setup’ų. Tiesiog sukuriate failą tinkamoje vietoje, ir viskas veikia.

Štai paprasčiausias pavyzdys. Sukuriate failą pages/api/hello.js:

export default function handler(req, res) {
  res.status(200).json({ message: 'Labas, pasauli!' })
}

Ir viskas. Jūsų API endpoint’as gyvuoja adresu /api/hello. Kai kas nors jį iškviečia, Vercel sukuria konteinerį, paleidžia jūsų funkciją, grąžina rezultatą ir išjungia konteinerį. Visa tai vyksta per milisekundes.

Praktiniai panaudojimo atvejai, kurie tikrai veikia

Teorija teorija, bet kur gi tai naudoti realiame gyvenime? Leiskite pasidalinti keliais scenarijais, kuriuos pats esu įgyvendinęs.

Formų apdorojimas ir email siuntimas – klasikinis atvejis. Turite kontaktų formą svetainėje ir norite siųsti email’us. Vietoj to, kad palaikytumėte visą backend’ą, sukuriate vieną serverless funkciją:

import nodemailer from 'nodemailer'

export default async function handler(req, res) {
  if (req.method !== 'POST') {
    return res.status(405).json({ error: 'Tik POST metodas' })
  }

  const { name, email, message } = req.body

  // Email siuntimo logika su nodemailer
  const transporter = nodemailer.createTransport({
    // jūsų SMTP konfigūracija
  })

  try {
    await transporter.sendMail({
      from: email,
      to: '[email protected]',
      subject: `Nauja žinutė nuo ${name}`,
      text: message
    })

    res.status(200).json({ success: true })
  } catch (error) {
    res.status(500).json({ error: 'Nepavyko išsiųsti' })
  }
}

Duomenų gavimas iš išorinių API – dažnai reikia pasislėpti API raktus arba apeiti CORS problemas. Serverless funkcija čia idealiai tinka. Jūsų frontend’as kreipiasi į jūsų API, o jūsų funkcija – į išorinį servisą.

Vaizdų optimizavimas ir apdorojimas – Next.js turi puikų Image komponentą, bet kartais reikia daugiau. Galite sukurti funkciją, kuri priima vaizdą, jį apdoroja (resize, compress, watermark) ir grąžina rezultatą.

Webhook’ai – jei integruojate mokėjimo sistemas (Stripe, PayPal) ar kitus servisus, jiems reikia endpoint’o, į kurį siųsti pranešimus. Serverless funkcija čia kaip tik.

Environment kintamieji ir saugumo aspektai

Vienas dalykas, kurį būtina suprasti dirbant su serverless funkcijomis – jūsų kodas vykdomas serveryje, ne naršyklėje. Tai reiškia, kad galite saugiai naudoti API raktus ir kitus slaptus duomenis.

Vercel dashboard’e galite pridėti environment variables. Pavyzdžiui, jei naudojate OpenAI API:

// .env.local (lokaliam developmentui)
OPENAI_API_KEY=jūsų-slaptas-raktas

// pages/api/ai-chat.js
export default async function handler(req, res) {
  const apiKey = process.env.OPENAI_API_KEY
  
  // Jūsų logika su OpenAI
}

Svarbu: niekada neįtraukite .env.local į git repository. Pridėkite jį į .gitignore. Vercel production aplinkoje kintamuosius nustatote per dashboard’ą.

Dar vienas security patarimas – visada validuokite įeinančius duomenis. Serverless funkcijos yra viešai prieinamos, tad bet kas gali jas iškviesti. Naudokite bibliotekų kaip joi ar zod validacijai:

import { z } from 'zod'

const schema = z.object({
  email: z.string().email(),
  message: z.string().min(10).max(1000)
})

export default async function handler(req, res) {
  try {
    const validData = schema.parse(req.body)
    // Tęskite su validuotais duomenimis
  } catch (error) {
    return res.status(400).json({ error: 'Neteisingi duomenys' })
  }
}

Cold starts problema ir kaip su ja gyventi

Štai dalykas, apie kurį niekas nemėgsta kalbėti serverless pasaulyje – cold starts. Kai jūsų funkcija ilgą laiką nebuvo iškviesta, Vercel turi ją „pažadinti”. Tai gali užtrukti nuo kelių šimtų milisekundžių iki kelių sekundžių.

Ar tai problema? Priklauso. Jei kuriate admin panel’ę, kuri naudojama kartą per dieną – turbūt ne. Jei tai kritinis API endpoint’as, kuris turi atsakyti per 200ms – galbūt taip.

Keletas strategijų, kaip sumažinti cold start’ų poveikį:

Optimizuokite funkcijos dydį – kuo mažiau dependencies, tuo greičiau funkcija pakraunama. Venkite importuoti visą biblioteką, jei reikia tik vienos funkcijos:

// Blogai
import _ from 'lodash'

// Gerai
import debounce from 'lodash/debounce'

Naudokite Edge Functions – Vercel siūlo Edge Functions, kurios vykdomos arčiau vartotojo ir turi žymiai greitesnį cold start. Tiesa, jos turi kai kurių apribojimų (ne visas Node.js API veikia).

Warming strategijos – galite periodiškai „pinginti” savo funkcijas, kad jos išliktų „šiltos”. Naudokite cron job’us arba išorinius servisus kaip UptimeRobot. Bet tai jau šiek tiek prieštarauja serverless filosofijai ir kainuos daugiau.

Debugging ir lokalus development

Viena iš geriausių Next.js savybių – lokalus development’as veikia beveik identiškai kaip production. Kai paleidžiate npm run dev, jūsų API routes veikia taip pat, kaip veiks Vercel.

Bet debugging gali būti sudėtingesnis. Štai keletas patikrintų metodų:

Console.log yra jūsų draugas – taip, žinau, skamba primityviai, bet serverless aplinkoje tai dažnai efektyviausias būdas. Vercel dashboard’e galite matyti real-time logus.

Naudokite Vercel CLI – galite paleisti vercel dev vietoj next dev. Tai simuliuoja Vercel aplinką dar tiksliau ir leidžia testuoti environment variables.

Error handling – visada wrappinkite savo kodą į try-catch blokus ir grąžinkite prasmingus error messages:

export default async function handler(req, res) {
  try {
    // Jūsų logika
  } catch (error) {
    console.error('Klaida API funkcijoje:', error)
    
    // Development aplinkoje grąžinkite detalią informaciją
    if (process.env.NODE_ENV === 'development') {
      return res.status(500).json({ 
        error: error.message,
        stack: error.stack 
      })
    }
    
    // Production aplinkoje – bendrą pranešimą
    return res.status(500).json({ 
      error: 'Įvyko serverio klaida' 
    })
  }
}

Kaštų optimizavimas ir limitai

Serverless skamba pigiai, bet kaštai gali greitai išaugti, jei nežinote, ką darote. Vercel free tier yra gana dosnus – 100GB bandwidth ir 100 valandų serverless funkcijų vykdymo laiko per mėnesį. Bet jei jūsų projektas tampa populiarus, turite būti atsargūs.

Function execution time – free plane funkcijos gali vykti iki 10 sekundžių, Pro plane – iki 60 sekundžių. Jei jūsų funkcija daro sudėtingus skaičiavimus ar ilgai laukia išorinio API, gali viršyti limitą.

Sprendimas? Optimizuokite arba padalinkite į mažesnes funkcijas. Arba naudokite background jobs – bet tai jau už Vercel ribų.

Bandwidth – jei grąžinate didelius JSON objektus ar failus, bandwidth greitai išsenka. Naudokite pagination, compression, cache headers.

export default async function handler(req, res) {
  const data = await getDuomenis()
  
  // Nustatykite cache headers
  res.setHeader('Cache-Control', 's-maxage=3600, stale-while-revalidate')
  
  // Compression automatiškai veikia, bet galite būti explicit
  res.setHeader('Content-Encoding', 'gzip')
  
  res.status(200).json(data)
}

Invocation count – kiekvienas funkcijos iškvietimas skaičiuojamas. Jei turite endpoint’ą, kurį frontend’as kviečia kiekvieną kartą, kai vartotojas pajudina pelę – tai problema. Naudokite debouncing, throttling, cache strategijas.

Kai serverless nebėra tinkamas sprendimas

Būkime sąžiningi – serverless nėra sidabrinė kulka. Yra situacijų, kai tradicinis serveris yra geresnis pasirinkimas.

Long-running procesai – jei reikia apdoroti vaizdo įrašą 20 minučių, serverless funkcija čia netiks. Reikia background worker’ių ar dedikuotų serverių.

WebSocket connections – serverless funkcijos nėra skirtos ilgalaikiams connection’ams. Jei kuriate real-time chat’ą ar multiplayer žaidimą, reikės kitų sprendimų.

Stateful operacijos – serverless funkcijos yra stateless. Negali saugoti duomenų tarp iškvietimų. Reikia išorinės duomenų bazės ar cache (Redis, PostgreSQL).

Labai didelė apkrova – jei turite konstantiškai didelį traffic’ą, tradicinis serveris gali būti pigesnis. Serverless pricing modelis geriau veikia su nepastovia apkrova.

Ateities perspektyvos ir kas laukia toliau

Serverless technologijos sparčiai vystosi. Edge computing tampa vis populiaresnis – funkcijos vykdomos dar arčiau vartotojo, geografiškai paskirstytuose mazguose. Vercel Edge Functions jau dabar leidžia tai daryti.

Middleware funkcionalumas Next.js 12+ versijose atveria naujas galimybes. Galite vykdyti kodą prieš request’ą pasiekiant jūsų puslapį – autentifikacijai, redirect’ams, A/B testams.

Deno ir Bun runtime’ai siūlo greitesnius cold start’us ir mažesnę memory footprint. Vercel jau eksperimentuoja su alternatyviais runtime’ais.

Bet svarbiausia – serverless funkcijos tampa vis labiau mainstream. Tai nebėra tik startup’ų žaislas. Dideli enterprise projektai pradeda migruoti į hybrid architektūras, kur dalis funkcionalumo vykdoma serverless.

Jei dar neišbandėte serverless su Vercel ir Next.js, dabar puikus laikas pradėti. Sukurkite paprastą projektą, išdeployinkite, pažaiskite su API routes. Pamatysite, kaip greitai galite eiti nuo idėjos iki veikiančio produkto. Ir kai suprasite šį workflow’ą, grįžti prie tradicinių serverių bus sunku – tarsi iš iPhone grįžti prie mygtukinio telefono.

Technologijos keičiasi, bet principai lieka. Serverless – tai apie efektyvumą, paprastumą ir fokusavimąsi į tai, kas svarbu: jūsų produktą ir vartotojus. Infrastruktūra turi būti neregima, o Vercel su Next.js tai puikiai įgyvendina.