DEV Community

Cover image for ما هو Jamstack؟ البنية المفككة حيث الـ API هو المنتج
Yusuf Khalidd
Yusuf Khalidd

Posted on • Originally published at apidog.com

ما هو Jamstack؟ البنية المفككة حيث الـ API هو المنتج

إذا نشرت موقعًا ثابتًا يجلب بيانات حية من خدمات خارجية، فأنت تستخدم بالفعل جزءًا من نمط Jamstack. الفكرة العملية بسيطة: اعرض الواجهة الأمامية مسبقًا، وقدّمها من CDN، وتعامل مع كل سلوك ديناميكي كاستدعاء API. صاغت Netlify هذا النمط تقريبًا في 2015، ورغم أن الاسم أصبح أقل استخدامًا، فإن مبادئه أصبحت جزءًا أساسيًا من تطوير الويب الحديث.

جرّب Apidog اليوم

ماذا يعني Jamstack عمليًا؟

Jamstack اختصار لـ JavaScript و APIs و Markup:

  • JavaScript: يشغّل السلوك الديناميكي في المتصفح، مثل جلب البيانات أو تحديث الواجهة أو التعامل مع المصادقة.
  • APIs: تستبدل الخادم المتجانس بخدمات مستقلة تتواصل عبر HTTP.
  • Markup: صفحات HTML يتم توليدها مسبقًا أثناء البناء وتُقدَّم كملفات ثابتة.

عمليًا، يعتمد Jamstack على قرارين معماريين:

  1. Pre-rendering: توليد HTML والأصول الثابتة قبل وقت الطلب.
  2. Decoupling: فصل الواجهة الأمامية عن الخدمات الخلفية، بحيث تتعامل الواجهة مع APIs بدل الاعتماد على خادم تطبيق واحد.

النتيجة: واجهة أمامية سريعة وسهلة التوزيع، وخدمات خلفية قابلة للاستبدال والتطوير بشكل مستقل.

كيف يعمل الفصل؟

في تطبيق تقليدي، يصل الطلب إلى الخادم، يستعلم الخادم قاعدة البيانات، ثم يولّد HTML في وقت الطلب.

في Jamstack:

  1. يتم بناء الصفحات مسبقًا.
  2. تُرفع الملفات الثابتة إلى CDN.
  3. يجلب المتصفح البيانات الديناميكية عبر APIs عند الحاجة.

مثال مبسط:

async function loadUserProfile(userId) {
  const response = await fetch(`/api/users/${userId}`);

  if (!response.ok) {
    throw new Error("فشل تحميل بيانات المستخدم");
  }

  return response.json();
}
Enter fullscreen mode Exit fullscreen mode

الواجهة الأمامية هنا لا تعرف شيئًا عن قاعدة البيانات. هي تعرف فقط عقد الـ API: المسار، شكل الطلب، وشكل الاستجابة.

هذا يمنحك مرونة واضحة:

  • يمكنك استبدال مزود البحث دون تغيير واجهة الدفع.
  • يمكن لفريق المحتوى إدارة CMS بلا واجهة.
  • يمكن لفريق آخر امتلاك خدمة الدفع أو المصادقة.
  • يمكن نشر الواجهة الأمامية بشكل مستقل عن الخدمات الخلفية.

لكن المقابل هو أن جودة عقود الـ API تصبح حاسمة. إذا تغيّر شكل الاستجابة أو تعطلت خدمة ما، قد تنكسر الواجهة الأمامية حتى لو كانت الملفات الثابتة نفسها سليمة.

وهذا قريب من فكرة API كمنتج. عندما تكون الـ API هي الطريقة الوحيدة لاستخدام الخدمة، فإنها لم تعد تفصيلًا داخليًا؛ بل تصبح الواجهة التي يبني عليها الآخرون. لذلك تتجه البرمجيات نحو النمط اللارأسي، حيث تصبح واجهة برمجة التطبيقات هي المنتج.

بيانات وقت البناء مقابل بيانات وقت التشغيل

أهم قرار في Jamstack هو: متى تجلب البيانات؟

بيانات وقت البناء بيانات وقت التشغيل من جانب العميل
متى تعمل؟ مرة واحدة أثناء عملية البناء عند تحميل الصفحة في المتصفح
مناسبة لـ منشورات المدونة، الوثائق، كتالوجات المنتجات، المحتوى بطيء التغير عربات التسوق، ملفات المستخدمين، الأسعار، البيانات الشخصية أو الحية
طريقة التقديم مدمجة داخل HTML ثابت على CDN تُجلب عبر JavaScript باستدعاء API
المفاضلة قد تصبح قديمة حتى البناء التالي قد تؤخر العرض الأولي وتحتاج إلى API متاحة دائمًا

مثال عملي:

  • منشور مدونة: اجلبه أثناء البناء وولّد HTML ثابتًا.
  • صفحة حساب المستخدم: اجلبها وقت التشغيل لأنها تختلف حسب المستخدم.
  • صفحة منتج: قد تجمع بين الاثنين؛ بيانات المنتج الأساسية أثناء البناء، والمخزون أو السعر الحي عبر API.

مثال في Next.js يوضح الفكرة:

// بيانات وقت البناء
export async function getStaticProps() {
  const posts = await fetch("https://cms.example.com/posts").then(res =>
    res.json()
  );

  return {
    props: { posts },
    revalidate: 60
  };
}
Enter fullscreen mode Exit fullscreen mode

ومثال لبيانات وقت التشغيل:

import { useEffect, useState } from "react";

export function Cart() {
  const [cart, setCart] = useState(null);

  useEffect(() => {
    fetch("/api/cart")
      .then(res => res.json())
      .then(setCart);
  }, []);

  if (!cart) return <p>جارٍ تحميل السلة...</p>;

  return <pre>{JSON.stringify(cart, null, 2)}</pre>;
}
Enter fullscreen mode Exit fullscreen mode

القاعدة العملية:

اعرض مسبقًا كل ما يمكن عرضه مسبقًا، واستدعِ APIs فقط لما يجب أن يكون مباشرًا أو شخصيًا.

سلسلة الأدوات في التطبيق

مشروع Jamstack نموذجي يتكون من:

  1. إطار أو مولد مواقع ثابتة

    • Gatsby
    • Hugo
    • Jekyll
    • Eleventy
    • Next.js

  2. مصدر بيانات

    • CMS بلا واجهة
    • API داخلية
    • خدمة SaaS خارجية
    • خدمة بحث
    • خدمة دفع
    • خدمة مصادقة

  3. منصة نشر

    • CDN
    • استضافة ملفات ثابتة
    • وظائف Serverless أو Edge للأجزاء الديناميكية

تدفق العمل المعتاد:

CMS / APIs
   ↓
Build Step
   ↓
Static HTML + Assets
   ↓
CDN
   ↓
Browser
   ↓
Runtime API Calls
Enter fullscreen mode Exit fullscreen mode

مثال بنية شائع:

frontend/
  pages/
  components/
  lib/api.js

services/
  auth-api
  payment-api
  search-api
Enter fullscreen mode Exit fullscreen mode

ملف مساعد لاستدعاءات API:

const API_BASE_URL = process.env.NEXT_PUBLIC_API_BASE_URL;

export async function apiGet(path) {
  const response = await fetch(`${API_BASE_URL}${path}`);

  if (!response.ok) {
    throw new Error(`API error: ${response.status}`);
  }

  return response.json();
}
Enter fullscreen mode Exit fullscreen mode

ثم تستخدمه في الواجهة:

const products = await apiGet("/products");
Enter fullscreen mode Exit fullscreen mode

إذا بدا هذا قريبًا من نهج MACH، فذلك صحيح. MACH يعني:

  • Microservices
  • API-first
  • Cloud-native
  • Headless

يتقاطع Jamstack مع MACH خصوصًا في مبدأي API-first و Headless. الفرق أن Jamstack يركز أكثر على بناء وتقديم الواجهة الأمامية، بينما يركز MACH على تركيب النظام الخلفي من خدمات مستقلة.

أين يتناسب Jamstack اليوم؟

مصطلح Jamstack لم يعد قويًا تسويقيًا كما كان. Netlify أزالت المصطلح من موقعها الأساسي في 2023 واتجهت إلى تعبير "الويب القابل للتركيب". كما توقف تقرير حالة Jamstack السنوي في 2024 لأن المجتمع انتقل إلى مصطلحات أوسع.

لكن الممارسة نفسها لم تختفِ.

ما زال المطورون يستخدمون:

  • العرض المسبق.
  • التسليم عبر CDN.
  • الواجهات الخلفية المعتمدة على APIs.
  • CMS بلا واجهة.
  • وظائف Serverless.
  • أطر هجينة مثل Next.js.

الفرق أن الحدود أصبحت أقل صرامة. كثير من التطبيقات اليوم تجمع بين:

  • Static Generation
  • Server-Side Rendering
  • Incremental Static Regeneration
  • Client-side Fetching

لذلك لم يعد Jamstack يعني "كل شيء ثابت فقط". المعنى العملي اليوم هو: واجهة أمامية مفصولة تعتمد على APIs، مع استخدام العرض المسبق حيثما كان مناسبًا.

أين تدخل جودة الـ API في المكدس المفصول؟

في Jamstack، أي شيء غير ثابت يتحول إلى API. لذلك يصبح عقد الـ API طبقة حرجة في النظام.

هنا يتناسب Apidog. هو ليس CMS ولا منصة استضافة ولا إطار Jamstack، لكنه يساعدك في إدارة طبقة الـ API التي تعتمد عليها الواجهة الأمامية.

خطوات عملية لتحسين هذا الجزء:

1. صمّم العقد أولًا

قبل بناء الواجهة أو الخدمة، عرّف الـ API باستخدام OpenAPI. هذا يضمن أن فريق الواجهة وفريق الخلفية متفقان على شكل الطلبات والاستجابات.

مثال استجابة:

{
  "id": "prod_123",
  "name": "Keyboard",
  "price": 99.99,
  "inStock": true
}
Enter fullscreen mode Exit fullscreen mode

هذا هو جوهر تطوير API-first.

2. استخدم Mock API قبل اكتمال الخلفية

في مشروع مفصول، لا يجب أن ينتظر فريق الواجهة اكتمال الخدمة الخلفية. يمكنك تشغيل خادم وهمي من المواصفات، ثم تبني الواجهة على بيانات قريبة من الواقع.

مثال:

const API_BASE_URL =
  process.env.NODE_ENV === "development"
    ? "https://mock.example.com"
    : "https://api.example.com";
Enter fullscreen mode Exit fullscreen mode

بهذا يستطيع فريق الواجهة العمل بالتوازي مع فريق الخلفية.

3. اختبر العقود في CI

إذا تغيّر شكل الاستجابة، يجب اكتشاف ذلك قبل النشر. شغّل اختبارات API داخل خط أنابيب CI حتى لا تصل الاستجابات المكسورة إلى الواجهة الثابتة.

مثال تدفق CI مبسط:

name: API Tests

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test-api:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run API tests
        run: apidog run
Enter fullscreen mode Exit fullscreen mode

الفكرة ليست الأداة بحد ذاتها، بل المبدأ:

لا تنشر واجهة أمامية تعتمد على API لم يتم اختبار عقدها.

4. أبقِ التوثيق قريبًا من التنفيذ

في البنية المفصولة، التوثيق ليس رفاهية. هو الطريقة التي يعرف بها كل فريق كيف يستخدم الخدمة.

يجب أن يوضح توثيق الـ API:

  • المسارات.
  • معاملات الطلب.
  • شكل الاستجابة.
  • أكواد الأخطاء.
  • أمثلة حقيقية.
  • حدود الاستخدام إن وجدت.

إذا كانت الواجهة الأمامية لا تستطيع استهلاك الخدمة إلا عبر API، فالتوثيق جزء من تجربة التطوير نفسها.

قائمة تحقق قبل اعتماد Jamstack

استخدم هذه القائمة قبل اختيار هذا النمط:

  • هل يوجد محتوى يمكن توليده مسبقًا؟
  • هل البيانات الشخصية أو الحية محدودة ومعزولة؟
  • هل APIs موثقة ومستقرة؟
  • هل توجد استراتيجية للتعامل مع فشل API؟
  • هل تحتاج إلى SSR لبعض الصفحات؟
  • هل يمكن تشغيل اختبارات API في CI؟
  • هل توجد سياسة واضحة لإعادة البناء عند تغير المحتوى؟
  • هل يمكن للفرق العمل بعقود API بدل الاعتماد على كود مشترك؟

مثال للتعامل مع فشل API في الواجهة:

async function getRecommendations() {
  try {
    const response = await fetch("/api/recommendations");

    if (!response.ok) {
      return [];
    }

    return response.json();
  } catch {
    return [];
  }
}
Enter fullscreen mode Exit fullscreen mode

لا تجعل فشل خدمة ثانوية يكسر الصفحة بالكامل.

الأسئلة المتكررة

هل Jamstack هو نفسه الموقع الثابت؟

لا. الموقع الثابت هو HTML مُنشأ مسبقًا فقط. Jamstack يبدأ من HTML ثابت، لكنه يستخدم JavaScript وAPIs لإضافة سلوك ديناميكي مثل تسجيل الدخول، عربات التسوق، البحث، وبيانات المستخدم.

هل Jamstack مات؟

المصطلح تراجع، لكن الممارسة لم تمت. العرض المسبق، التسليم عبر CDN، والواجهات الخلفية المعتمدة على API أصبحت جزءًا عاديًا من تطوير الويب الحديث.

كيف يختلف Jamstack عن البنية التقليدية؟

في البنية التقليدية، يعرض الخادم الصفحة في وقت الطلب وغالبًا يكون مرتبطًا مباشرة بقاعدة البيانات. في Jamstack، تُنشأ الصفحات مسبقًا، وتُجلب البيانات الديناميكية عبر APIs، مما يفصل الواجهة الأمامية عن الخلفية.

ماذا تفعل APIs في Jamstack؟

توفر كل ما لم يتم عرضه مسبقًا: المحتوى الحي، البحث، المدفوعات، المصادقة، بيانات المستخدم، والأسعار. لذلك يجب تصميم واجهات برمجة التطبيقات هذه ومحاكاتها واختبارها قبل الاعتماد عليها في الواجهة.

الخلاصة

Jamstack هو نمط لبناء واجهات مفصولة: اعرض ما تستطيع مسبقًا، قدّمه من CDN، واجعل السلوك الديناميكي عبر APIs. الاسم أصبح أقل استخدامًا، لكن النمط نفسه أصبح شائعًا في الويب الحديث.

إذا كانت واجهتك الأمامية مجرد عميل، فإن جودة APIs هي ما يحدد استقرار التجربة. صمّم العقود أولًا، شغّل Mock APIs للفرق المتوازية، اختبرها في CI، وأبقِ التوثيق محدثًا. يمكنك تنزيل Apidog لتصميم ومحاكاة واجهات برمجة التطبيقات التي تعتمد عليها واجهتك المفصولة، أو قراءة المزيد حول سبب كون واجهة برمجة التطبيقات الخاصة بك هي المنتج الآن.

Top comments (0)