Vercel և Netlify

01Ինչ են դրանք իրականում անում

Պատկերացրու այս պլատֆորմները որպես build server, CDN և serverless runtime՝ Git-ով իրար կպցված։ Երբ push ես անում, պլատֆորմը clone է անում repo-ն, ճանաչում framework-ը, գործարկում build հրամանը և բաժանում արդյունքը։ Static ֆայլերը (HTML, CSS, JS, նկարներ) գնում են գլոբալ CDN՝ երկար caching-ով։ Server կոդը (API route-եր, server-rendered էջեր, server action-ներ) փաթեթավորվում է function-ների մեջ, որոնք աշխատում են ըստ պահանջի մեկ կամ մի քանի region-ում։ Middleware-ը կամ edge function-ները աշխատում են cache-ից առաջ՝ թեթև runtime-ի վրա օգտատիրոջը մոտ։ Յուրաքանչյուր deployment immutable է և ունի իր URL-ը․ «production»-ը պարզապես alias է, որը ցույց է տալիս դրանցից մեկը։ Հենց դրա համար է rollback-ը ակնթարթային․ alias-ը հետ ես տեղափոխում ավելի հին deployment-ի վրա, ոչինչ նորից build չի արվում։ VPS-ի համեմատ այլևս չես մտածում սերվերների մասին, բայց մտածում ես function-ի տևողության, region-ների, caching header-ների և հաշվի մասին։

• Static asset-ներ → CDN։ Server կոդ → function-ներ։ Middleware → edge։
• Յուրաքանչյուր deploy immutable է, production-ը alias է։
• Preview deployment-ներ յուրաքանչյուր branch-ի կամ pull request-ի համար։

02Project-ի կարգավորում քայլ առ քայլ

Ստեղծիր account, import արա repository-ն GitHub-ից, GitLab-ից կամ Bitbucket-ից և ընդունիր ճանաչված framework-ի կարգավորումները։ Առաջին deploy-ը սովորաբար աշխատում է առանց փոփոխությունների։ Հետո արա իրական կարգավորումը։ Dashboard-ում environment variable-ներ ավելացրու ըստ միջավայրի (Production, Preview, Development) և երբեք թույլ մի տուր, որ preview build-երը օգտագործեն production secret-ներ կամ production բազան։ Ավելացրու քո custom domain-ը․ apex domain-ը ուղղիր A record-ով կամ ALIAS-ով, իսկ www subdomain-ը՝ CNAME-ով, ինչպես պլատֆորմն է ցուցում․ certificate-ները տրվում են ավտոմատ։ Պաշտպանիր preview-ները պլատֆորմի deployment protection-ով, եթե դրանք դեռ չթողարկված աշխատանք են ցույց տալիս։ Function-ի region-ը դիր նույն region-ում, ինչ բազան։ Վերջում միացրու CLI-ը լոկալ աշխատանքի համար․ այն քաշում է environment variable-ները և կարող է լոկալ վերարտադրել պլատֆորմի build-ը։

1# Vercel
2npm i -g vercel
3vercel link              # connect this folder to a project
4vercel env pull .env.local
5vercel                   # preview deploy
6vercel --prod            # production deploy
7 
8# Netlify
9npm i -g netlify-cli
10netlify link
11netlify dev              # local server with functions and redirects
12netlify deploy --prod

03Rendering և caching՝ static, ISR, SSR, edge

Որտեղ է render արվում էջդ, որոշում է արագությունն ու արժեքը։ Static էջերը build են արվում մեկ անգամ և սպասարկվում CDN-ից՝ ամենաարագ և գրեթե անվճար։ Incremental Static Regeneration-ը (ISR) սպասարկում է cache արված էջը և revalidate ժամկետից հետո այն վերագեներացնում ֆոնում, կամ ըստ պահանջի, երբ քո CMS-ը կանչում է revalidation endpoint-ը, ուստի ստանում ես static արագություն թարմ բովանդակությամբ։ Server-side rendering-ը function է գործարկում յուրաքանչյուր request-ի վրա․ անհրաժեշտ է անհատականացված էջերի համար, բայց յուրաքանչյուր request արժե function-ի ժամանակ։ Middleware-ը աշխատում է cache-ից առաջ յուրաքանչյուր համապատասխան request-ի վրա, ուստի այն շատ փոքր պահիր՝ redirect-ներ, rewrite-ներ, auth cookie-ի ստուգումներ, A/B bucketing։ Երկու պլատֆորմներն էլ հարգում են ստանդարտ Cache-Control header-ները, իսկ Vercel-ը նաև կարդում է CDN-Cache-Control և Vercel-CDN-Cache-Control՝ միայն CDN-ի կանոնների համար։ Netlify-ը օգտագործում է Netlify-CDN-Cache-Control և աջակցում է cache tag-եր նպատակային purge-ի համար։ Լավ կանոն՝ default-ով render արա static, բովանդակության համար՝ ISR, SSR՝ միայն այնտեղ, որտեղ response-ը իսկապես կախված է request-ից։

1// app/blog/[slug]/page.tsx (Next.js App Router)
2export const revalidate = 3600; // regenerate at most once per hour
3 
4export async function generateStaticParams() {
5  const posts = await fetch("https://cms.example.com/posts").then((r) => r.json());
6  return posts.map((p: { slug: string }) => ({ slug: p.slug }));
7}
8 
9export default async function Post({ params }: { params: Promise<{ slug: string }> }) {
10  const { slug } = await params;
11  const post = await fetch("https://cms.example.com/posts/" + slug, {
12    next: { tags: ["post-" + slug] },
13  }).then((r) => r.json());
14  return <article><h1>{post.title}</h1></article>;
15}

04Function-ներ՝ սահմանափակումներ և ինչպես է աշխատում billing-ը

Երկու պլատֆորմներն էլ քո server կոդը գործարկում են որպես function-ներ, հիմնականում Node.js-ի վրա։ Vercel-ում function-ները default-ով օգտագործում են Fluid compute․ մեկ instance-ը կարող է սպասարկել շատ միաժամանակյա request-ներ, ինչը նվազեցնում է cold start-երը և արժեքը I/O-ծանր աշխատանքի համար, օրինակ՝ բազա կամ AI API կանչելիս։ Billing-ը ըստ ակտիվ CPU ժամանակի, provisioned հիշողության և invocation-ների է, ուստի ցանցին սպասելու ժամանակը շատ ավելի քիչ արժե, քան մաքուր տևողությունը։ Edge Functions-ը և middleware-ը աշխատում են ավելի թեթև V8 runtime-ի վրա․ Vercel-ն այժմ function-ների մեծ մասի համար խորհուրդ է տալիս Node.js runtime-ը։ Netlify Functions-ը ներքևում աշխատում են AWS Lambda-ի վրա, իսկ Netlify Edge Functions-ը՝ Deno-ի վրա edge-ում։ Netlify-ը օգտագործում է credit-ների վրա հիմնված plan մոդել․ deploy-երը, compute-ը, bandwidth-ը և request-ները յուրաքանչյուրը credit-ներ են ծախսում ամսական սահմանաչափից։ Երկուսն էլ ունեն առավելագույն տևողություն, request body-ի չափի և հիշողության սահմանափակումներ ըստ plan-ի, ուստի երկար job-երի տեղը queue-ում կամ այլ տեղ գտնվող background worker-ում է։

05Plan-ներ և գնային թակարդներ

Vercel-ի Hobby plan-ը անվճար է, բայց միայն անձնական, ոչ կոմերցիոն օգտագործման համար․ client-ների և ընկերությունների project-ներին պետք է Pro, որի գինը ըստ seat-ի է՝ ամսական usage credit-ով, ապա pay-as-you-go։ Նոր Pro թիմերը ստանում են default spend budget alert-ներով և սահմանին project-ները pause անելու տարբերակով․ այն միացված պահիր։ Netlify-ն ունի Free, Personal և Pro plan-ներ ամսական credit-ների սահմանաչափով․ երբ credit-ները վերջանում են, կայքերը կարող են pause լինել, եթե ավելին չգնես կամ auto recharge չմիացնես։ Թակարդները երկուսում էլ նման են՝ viral էջ, որը server-render է արվում յուրաքանչյուր request-ի վրա, մեծ չօպտիմիզացված նկարներ կամ վիդեո, որոնք սպասարկվում են որպես bandwidth, bot-եր, որոնք խփում են դինամիկ route-երին, image optimization հազարավոր source նկարների վրա, և preview build-եր, որոնք գործարկվում են զբաղված monorepo-ի ամեն commit-ով։ Client-ի որոշումից առաջ գները ստուգիր պաշտոնական pricing էջերում․ երկու ընկերություններն էլ պարբերաբար փոխում են իրենց մոդելները։

• Vercel-ի Hobby-ն ոչ կոմերցիոն է․ client-ի աշխատանքին պետք է Pro։
• Առաջին օրից միացրու spend limit-ներ կամ budget alert-ներ։
• Cache արա ագրեսիվ․ cache չարված SSR-ն է, որտեղ հաշիվները աճում են։

06Ինչպես է աշխատում request-ի ճանապարհը՝ routing, cache և function-ներ

Request-ը հասնում է ամենամոտ edge location-ին։ Նախ գործարկվում են պլատֆորմի routing կանոնները՝ redirect-ներ, rewrite-ներ և header-ներ քո framework-ից կամ config ֆայլերից։ Ապա գործարկվում է middleware-ը, եթե համապատասխանում է։ Հետո ստուգվում է CDN cache-ը՝ URL-ով և ցանկացած cache key-ով կամ Vary header-ով։ Cache hit-ը վերադառնում է անմիջապես և արժե միայն CDN request և bandwidth։ Miss-ը կանչում է function-ը իր կարգավորված region-ում, որը կարող է հեռու լինել edge-ից, ուստի յուրաքանչյուր miss վճարում է edge-ից region ճանապարհի և քո բազայի round trip-երի համար։ Stale-while-revalidate-ը թույլ է տալիս CDN-ին սպասարկել հնացած բովանդակություն՝ այն ֆոնում թարմացնելով։ Cookie-ները caching-ի թաքնված թշնամին են․ response-ը, որը կախված է session cookie-ից, չպետք է կիսվի, ուստի էջերը բաժանիր cache արված shell-ի և փոքր անհատականացված մասերի, որոնք բեռնվում են client-ում կամ stream են արվում։

1// next.config.ts: long cache for a public API route, revalidated in the background
2import type { NextConfig } from "next";
3 
4const config: NextConfig = {
5  async headers() {
6    return [
7      {
8        source: "/api/public/:path*",
9        headers: [{ key: "Cache-Control", value: "public, s-maxage=300, stale-while-revalidate=86400" }],
10      },
11    ];
12  },
13};
14 
15export default config;

07Բազաների հետ connection-ներ serverless function-ներից

Function-ները scale են լինում՝ ավելի շատ instance-ներ ստեղծելով, և յուրաքանչյուր instance, որը բացում է իր TCP connection-ները դեպի Postgres, բեռնվածության տակ կարող է սպառել բազայի connection limit-ը։ Երեք գործիք է լուծում սա։ Առաջին՝ բազայի առջև pooler դիր՝ PgBouncer, managed provider-ի pooled endpoint կամ Prisma Accelerate, և օգտագործիր transaction mode։ Երկրորդ՝ edge և կարճակյաց function-ների համար նախընտրիր serverless-ի համար նախագծված driver-ներ, օրինակ՝ serverless Postgres provider-ների HTTP կամ WebSocket driver-ները։ Երրորդ՝ Vercel Fluid compute-ով մեկ instance-ը շատ request-ներ է սպասարկում, ուստի module-level փոքր pool-ը արդյունավետ վերաօգտագործվում է․ օգտագործիր waitUntil կամ attachDatabasePool helper-ները, որպեսզի պարապ connection-ները փակվեն, նախքան instance-ը suspend լինի։ Միշտ function-ի region-ը դիր բազայի կողքին․ մեկ region-ային թռիչք յուրաքանչյուր query-ի համար, բազմապատկած էջի տասը query-ով, 50 և 500 միլիվայրկյանի տարբերությունն է։

08Անվտանգություն՝ secret-ներ, preview-ներ և edge

Environment variable-ները գաղտնագրված են պահման ժամանակ, բայց client-ի համար prefix ունեցող ամեն ինչ (NEXT_PUBLIC_, PUBLIC_, VITE_) ներդրվում է browser bundle-ի մեջ․ դրանք դիտարկիր որպես public։ Զգայուն variable-ները սահմանափակիր միայն Production-ով և նշիր որպես sensitive, որպեսզի dashboard-ից հետ կարդալ հնարավոր չլինի։ Preview-ները իրական հարձակման մակերես են․ fork-ից եկած pull request-ը կարող է build-ի ժամանակ կոդ գործարկել քո secret-ներով, ահա թե ինչու պլատֆորմները default-ով secret-ները չեն տալիս fork build-երին․ այդպես էլ պահիր։ Չթողարկված աշխատանքի preview-ների համար օգտագործիր deployment protection (գաղտնաբառ, SSO կամ Vercel Authentication) և ավելացրու X-Robots-Tag noindex header, որպեսզի դրանք երբեք index չարվեն։ Login-ի և API route-երի համար միացրու firewall-ի և bot protection-ի հնարավորությունները, իսկ թանկ endpoint-ների համար ավելացրու rate limiting, քանի որ յուրաքանչյուր չարաշահող request գանձվող function ժամանակ է։