یادداشت خواندن
The Jamstack Book: Beyond Static Sites with JavaScript, APIs, and Markup را به خاطر مدل مرزیاش نگه میدارم.
مسئله فقط ساخت سایت static نیست. مسئله این است که بفهمیم کدام بخش کار میتواند زودتر، در زمان build، آماده شود و کدام بخش واقعاً به API و runtime نیاز دارد. برای پروژههای محتوایی، ابزارهای کوچک و تیمهایی که نمیخواهند زیرساخت سنگین را زود وارد بازی کنند، همین مرز تصمیمساز است.
نکتهی اصلی
Jamstack برای من قبل از اینکه یک stack باشد، یک مرز طراحی است:
چه چیزی میتواند پیش از request ساخته شود، و چه چیزی واقعاً باید هنگام تعامل کاربر زنده بماند؟
وقتی این مرز درست انتخاب شود، سایت محتوایی سادهتر میشود. build، CDN، Git و APIهای کوچک کنار هم مینشینند و پروژه لازم نیست برای هر صفحه یک server runtime سنگین نگه دارد.
چه چیزی از کتاب میماند
کتاب از سایتهای static شروع میکند، اما همانجا نمیماند. دربارهی static site generatorها، Headless CMS، APIها، serverless functionها، فرمها، auth و migration حرف میزند. ارزشش در همین ترکیب است: Jamstack را نه مثل «فقط HTML»، بلکه مثل یک مدل عملی برای جدا کردن بخشهای پایدار و پویا نشان میدهد.
برای پروژههایی مثل سایتهای شخصی، notebookهای فنی، landingهای کوچک، و ابزارهای محتوایی، این نگاه هنوز مفید است. مخصوصاً وقتی ownership محتوا و سادگی deploy مهمتر از داشتن admin panel بزرگ باشد.
trade-off
Jamstack قرار نیست همهی مسئلههای وب را حل کند. اگر محصول پر از state زنده، permission پیچیده یا دادهی شدیداً پویا باشد، بخشهای runtime دوباره برمیگردند.
اما برای محتوایی که میشود زودتر ساخت و با CDN تحویل داد، سادهکردن request path ارزش زیادی دارد. همین ایده در Mohetios.dev هم مهم است: محتوا تا جای ممکن build-time بماند و backend فقط جایی وارد شود که واقعاً نیاز است.
منابع
- Manning Publications: The Jamstack Book