كيف تفكر في البنية قبل الكود System Design للمبتدئين؟

بواسطة /

كثير من المبرمجين المبتدئين يظنون أن “تصميم الأنظمة” أمر يخص مهندسي الخوادم فقط، وأن دور مطور الواجهة الأمامية يبدأ وينتهي عند كتابة العناصر المرئية. هذا غير دقيق. مطور الواجهة الأمامية أيضاً يتخذ قرارات معمارية تؤثر على أداء الموقع بالكامل: أين تُعرض الصفحة؟ من أين تأتي البيانات؟ وماذا يحدث لو تأخر الخادم في الرد؟ هذا الدليل موجه للمبتدئين، وهدفه أن تتعلم كيف تسأل هذه الأسئلة قبل أن تفتح المحرر، مع أرقام وأدوات حقيقية تستخدمها بالفعل في مشاريعك.

محتويات المقال

1. لماذا يحتاج مطور الواجهة الأمامية للتفكير في البنية

عندما تبني واجهة موقع، أنت لا تكتب المظهر فقط، بل تتخذ قرارات تؤثر على تجربة المستخدم بأكملها: من أين تجلب البيانات، هل ستظهر الصفحة سريعاً أم ستنتظر عدة ثوانٍ، وماذا يحدث لو انقطع الاتصال أثناء التحميل. الفرق بين مطور يكتب العناصر المرئية فقط، ومطور يفهم البنية، أن الأول يسأل “كيف أبني هذا العنصر؟”، بينما الثاني يسأل “من أين سيحصل هذا العنصر على بياناته، وماذا يحدث لو تأخرت؟”. السؤال الثاني هو ما يجعل الموقع يعمل بشكل جيد حتى في الظروف غير المثالية، وهو أيضاً ما تقيسه محركات البحث والمستخدمون بأرقام واضحة، كما سنرى في القسم التالي.

2. Core Web Vitals: لغة الأرقام

القرارات المعمارية في الواجهة الأمامية لا تبقى نظرية، جوجل تقيسها فعلياً عبر مجموعة مقاييس اسمها Core Web Vitals، وهي من العوامل المؤثرة في ترتيب الموقع في نتائج البحث. من المفيد أن تعرف الأرقام المستهدفة لكل مقياس:

  • LCP (Largest Contentful Paint): الوقت حتى يظهر أكبر عنصر مرئي في الصفحة. أقل من 2.5 ثانية يعتبر جيداً، وأكثر من 4 ثوانٍ يعتبر ضعيفاً.
  • INP (Interaction to Next Paint): الوقت بين تفاعل المستخدم (ضغطة زر مثلاً) واستجابة الواجهة. أقل من 200 ميلي ثانية جيد.
  • CLS (Cumulative Layout Shift): مدى تحرك عناصر الصفحة فجأة أثناء التحميل. أقل من 0.1 جيد.
  • TTFB (Time to First Byte): الوقت حتى يصل أول رد من الخادم. أقل من 600 ميلي ثانية جيد.
  • FCP (First Contentful Paint): الوقت حتى يظهر أول عنصر مرئي على الشاشة. أقل من 1.8 ثانية جيد.

هذه الأرقام ليست غاية في حد ذاتها، لكنها مقياس عملي يخبرك إذا كانت قراراتك المعمارية (طريقة العرض، حجم الملفات، طريقة جلب البيانات) تصب في مصلحة المستخدم أم لا.

3. أين تُعرض الصفحة: CSR وSSR وSSG وRSC وEdge

بدلاً من التعامل مع أساليب العرض كقائمة خيارات متساوية، من الأفضل التفكير فيها كسلسلة أسئلة تقودك للاختيار المناسب:

  1. هل الصفحة لازم تظهر في نتائج جوجل؟ إذا كانت الإجابة نعم، يميل الاختيار نحو SSR أو SSG بدلاً من CSR وحدها.
  2. هل المحتوى يتغير باستمرار (كل دقيقة مثلاً)؟ إذا كان كذلك، SSR غالباً أنسب من التوليد الساكن.
  3. هل المستخدمون موزعون على دول متعددة؟ هنا يصبح الجمع بين SSG وCDN وEdge Rendering خياراً قوياً، لأن المحتوى يُبنى مسبقاً ويُوزَّع من أقرب نقطة جغرافية للمستخدم.
  4. هل هناك تفاعل كثيف بعد التحميل الأول؟ هنا يدخل السؤال عن SSR مع Hydration، أو React Server Components كبديل أحدث.

وفيما يلي تعريف مبسط لكل أسلوب:

  • CSR (Client-Side Rendering): يبني المتصفح الصفحة كاملة بعد تحميل الجافاسكريبت. سريع في التنقل لاحقاً، لكن التحميل الأول أبطأ.
  • SSR (Server-Side Rendering): الخادم يبني HTML جاهزاً لكل طلب. أفضل لظهور المحتوى مبكراً ولمحركات البحث.
  • SSG (Static Site Generation): تُبنى الصفحة مرة واحدة وقت النشر، وتُوزَّع جاهزة. الأسرع، لكنه يناسب المحتوى غير المتغير باستمرار.
  • Streaming SSR: يرسل الخادم أجزاء من الصفحة أولاً بأول بدل انتظار اكتمالها كلها، فيرى المستخدم محتوى مبكراً حتى مع صفحات ثقيلة.
  • RSC (React Server Components): مكونات تُنفَّذ على الخادم فقط ولا تُرسَل كجافاسكريبت للمتصفح، ما يقلل حجم الحزمة المرسلة للمستخدم. مناسبة للأجزاء التي لا تحتاج تفاعلاً مباشراً من المستخدم.
  • Edge Rendering: تشغيل منطق العرض على خوادم قريبة جغرافياً من المستخدم (مثل Cloudflare Workers أو Vercel Edge)، فيقل زمن الاستجابة (TTFB) بشكل ملحوظ.
  • Islands Architecture: نمط تتبناه أدوات مثل Astro، حيث تُرسَل الصفحة كـHTML ساكن غالباً، وتتفاعل فقط “جزر” صغيرة محددة بجافاسكريبت، بينما يبقى باقي الصفحة خفيفاً.

4. كيف تحصل الواجهة على البيانات

الواجهة الأمامية غالباً لا تُنشئ الـ API، لكنها تتأثر بشكل مباشر بطريقة تصميمه. في REST قد تحصل على بيانات أكثر مما تحتاجه (Over-fetching)، أو تضطر لطلب بيانات من عدة مصادر لبناء صفحة واحدة (Under-fetching). في GraphQL تطلب بالضبط الحقول التي تحتاجها في طلب واحد، لكن هذا لا يعني أنه الخيار الأفضل دائماً، فتعقيد الإعداد يستحق التفكير فيه أيضاً. مكتبات مثل TanStack Query أو SWR تحل جزءاً كبيراً من هذه المشكلة: تتولى جلب البيانات وتخزينها مؤقتاً وإعادة المحاولة عند الفشل، بدلاً من كتابة هذا المنطق يدوياً في كل مكون. مثال مبسط لنمط Stale-While-Revalidate باستخدام TanStack Query:

import { useQuery } from '@tanstack/react-query';

function ProductPrice({ productId }) {
  const { data, isLoading } = useQuery({
    queryKey: ['product-price', productId],
    queryFn: () => fetch(`/api/products/${productId}/price`).then(res => res.json()),
    staleTime: 60_000, // البيانات تعتبر حديثة لمدة دقيقة
    refetchOnWindowFocus: true,
  });

  if (isLoading) return <span>...</span>;
  return <span>{data.price} ج.م</span>;
}

هنا تظهر الأسعار المخزنة فوراً للمستخدم، بينما تُطلب نسخة محدثة في الخلفية دون أن يشعر بانتظار. من المفيد أيضاً أن يكون لديك منطق لإعادة المحاولة عند فشل الطلب (Retry) بدلاً من الفشل الفوري، ويُفضَّل أن تزيد المهلة بين كل محاولة والتي تليها (Exponential Backoff) بدل تكرار الطلب فوراً بلا فاصل زمني، حتى لا تُثقل على الخادم في حال كان يعاني من ضغط أصلاً. لمن يريد التعمق أكثر في أساسيات جافاسكريبت التي تُبنى عليها هذه الأنماط، شرح JavaScript بالعربي 2026 نقطة بداية جيدة.

5. التخزين المؤقت: المتصفح وCDN وSWR

التخزين المؤقت يحدث في الواجهة الأمامية على أكثر من مستوى. المتصفح يخزّن الصور وملفات التنسيق والجافاسكريبت تلقائياً حتى لا يعيد تحميلها في كل زيارة. وإذا استخدمت شبكة توزيع محتوى (CDN)، تُخزَّن نسخة من الملفات الثابتة على خوادم قريبة جغرافياً من المستخدم، فتصل إليه أسرع بكثير. فوق هذين المستويين، نمط Stale-While-Revalidate الذي رأيناه في القسم السابق هو أيضاً استراتيجية تخزين مؤقت، لكنها على مستوى بيانات الـ API نفسها، لا الملفات الثابتة فقط. المشكلة الشائعة أن البيانات القديمة قد تبقى ظاهرة بعد أن تتغير فعلياً، لذلك من المهم تحديد بوضوح متى يجب تحديث هذا التخزين، سواء بمدة زمنية ثابتة أو بحدث معين يُبطل الكاش.

6. حجم الملفات وسرعة التحميل

كل مكتبة تضيفها للمشروع تزيد حجم الجافاسكريبت الذي يجب أن يحمّله المتصفح قبل أن يعرض أي شيء. على اتصال بطيء، هذا الفرق قد يعني ثوانٍ إضافية قبل أن يرى المستخدم الصفحة، وهو ما ينعكس مباشرة على رقم LCP الذي ذكرناه سابقاً.

تقسيم الكود (Code Splitting): بدلاً من تحميل التطبيق كاملاً دفعة واحدة، تُحمَّل كل صفحة أو ميزة فقط عند الحاجة إليها فعلياً. في React، يمكن تحقيق هذا عبر React.lazy مع Suspense:

import { lazy, Suspense } from 'react';

// لا تُحمَّل مكتبة الدفع إلا عند فتح صفحة إتمام الشراء فعلياً
const CheckoutForm = lazy(() => import('./CheckoutForm'));

function ProductPage() {
  const [showCheckout, setShowCheckout] = useState(false);

  return (
    <div>
      <ProductDetails />
      <button onClick={() => setShowCheckout(true)}>إتمام الشراء</button>

      {showCheckout && (
        <Suspense fallback={<p>جارِ التحميل...</p>}>
          <CheckoutForm />
        </Suspense>
      )}
    </div>
  );
}

تحسين الصور: الصور غالباً تمثل بين 60% و80% من الحجم الإجمالي للصفحة، ما يجعلها أكبر فرصة لتحسين الأداء. من الممارسات المفيدة هنا استخدام صيغ حديثة مثل WebP أو AVIF بدلاً من JPEG أو PNG التقليدية، وتحميل الصور بأحجام مختلفة حسب حجم الشاشة عبر خاصية srcset، وتأجيل تحميل الصور الموجودة أسفل الشاشة (Lazy Loading) حتى يصل المستخدم إليها فعلياً:

<picture>
  <source
    srcset="product-400.avif 400w, product-800.avif 800w"
    type="image/avif"
  />
  <source
    srcset="product-400.webp 400w, product-800.webp 800w"
    type="image/webp"
  />
  <img
    src="product-800.jpg"
    srcset="product-400.jpg 400w, product-800.jpg 800w"
    sizes="(max-width: 600px) 400px, 800px"
    loading="lazy"
    alt="اسم المنتج"
  />
</picture>

أطر عمل مثل Next.js توفر مكوناً جاهزاً (next/image) يقوم بهذا تلقائياً. ولمن يريد مراجعة أساسيات التنسيق التي تتحكم في حجم الصورة على الصفحة دون أن تسبب قفزات مفاجئة في التخطيط، شرح CSS بالعربي 2026 يغطي هذه النقطة بالتفصيل، وهي مرتبطة مباشرة برقم CLS.

7. تنظيم البيانات: حالة الخادم وحالة المتصفح

من المفيد التمييز بين نوعين من البيانات داخل أي تطبيق. حالة الخادم (Server State): بيانات مصدرها الأساسي هو الـ API، مثل قائمة المنتجات أو بيانات المستخدم، وهذه البيانات تحتاج تزامناً مع الخادم وتُدار غالباً بأدوات مثل TanStack Query. حالة المتصفح (Client State): بيانات محلية بحتة، مثل هل القائمة الجانبية مفتوحة أم لا، أو محتوى حقل بحث لم يُرسَل بعد. خلط النوعين معاً في نفس المكان غالباً هو سبب تعقيد إدارة الحالة الذي يشتكي منه كثير من المبرمجين. عندما تحتاج نفس البيانات في أجزاء بعيدة عن بعضها من الواجهة، وتضطر لتمريرها عبر عدة مستويات من المكونات، هذا مؤشر جيد على أن الوقت مناسب للتفكير في أداة مركزية لإدارة الحالة، وليس بالضرورة من اليوم الأول لكل مشروع صغير.

8. التعامل مع الفشل

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

  • Error Boundaries: مكون يلتقط الأخطاء التي تحدث في المكونات الفرعية، ويعرض واجهة بديلة بدل أن ينهار التطبيق بالكامل.
  • Skeleton Screens: عرض هيكل تقريبي للصفحة أثناء التحميل بدلاً من مؤشر تحميل دوّار (Spinner) فقط، ما يعطي المستخدم إحساساً بأن المحتوى قادم فعلياً.
  • Retry Strategy: إعادة محاولة الطلب الفاشل تلقائياً بدلاً من عرض رسالة خطأ فورية، خصوصاً في حالات الانقطاع المؤقت للاتصال.
  • Graceful Degradation: تصميم الواجهة بحيث تستمر أجزاء منها في العمل حتى لو فشل جزء آخر، بدلاً من أن يعتمد ظهور الصفحة كاملة على نجاح كل طلب.

مثال مبسط لـError Boundary في React (الطريقة الأصلية بالـ Class Component، مع الإشارة إلى أن المكتبات الحديثة مثل react-error-boundary تُبسّط هذا في Function Components):

class ErrorBoundary extends React.Component {
  state = { hasError: false };

  static getDerivedStateFromError() {
    return { hasError: true };
  }

  componentDidCatch(error, info) {
    console.error('حدث خطأ في الواجهة:', error, info);
  }

  render() {
    if (this.state.hasError) {
      return <p>حدث خطأ غير متوقع، حاول تحديث الصفحة.</p>;
    }
    return this.props.children;
  }
}

// الاستخدام
<ErrorBoundary>
  <ProductReviews />
</ErrorBoundary>

9. مثال مفصل: صفحة منتج في متجر إلكتروني

لنطبق ما سبق على مثال واقعي: صفحة منتج يجب أن تظهر في نتائج البحث، وتحتوي في نفس الوقت على زر “أضف إلى السلة” التفاعلي. رحلة الطلب هنا تمر بعدة طبقات:

رحلة طلب صفحة المنتج — تصميم الأنظمة للواجهة الأمامية
رحلة طلب صفحة المنتج من المستخدم حتى قاعدة البيانات
  • طريقة العرض: SSR أو RSC، حتى تقرأ محركات البحث اسم المنتج وسعره فوراً دون انتظار تنفيذ جافاسكريبت.
  • البيانات: بيانات المنتج تُجلب وقت بناء الصفحة على الخادم، أما حالة السلة (Client State) فتُدار من جهة المتصفح بعد ظهور الصفحة.
  • التخزين المؤقت: صور المنتج وملفات التنسيق تُخزَّن على الـCDN. السعر والمخزون، إن كانا يتغيران باستمرار، يحتاجان استراتيجية Stale-While-Revalidate بدل التخزين الثابت.
  • حجم الملفات: مكتبة معالجة الدفع لا تحتاج تحميلها إلا عند ضغط المستخدم على “إتمام الشراء”، عبر Code Splitting كما رأينا سابقاً.
  • التعامل مع الفشل: لو فشل تحميل التقييمات مثلاً، يظل باقي الصفحة (السعر وزر الشراء) يعمل بشكل طبيعي بفضل Error Boundary منفصل لكل قسم.

كل قرار من هذه القرارات اتُخذ قبل كتابة أي سطر كود، وكل واحد منها يؤثر على تجربة المستخدم وظهور المنتج في محركات البحث في آن واحد. ولمن يبني واجهات تعتمد على شبكة تنسيق جاهزة قبل الوصول لهذا المستوى من التخصيص، شرح Bootstrap 5 بالعربي 2026 نقطة انطلاق جيدة لفهم التصميم المتجاوب أولاً.

10. أخطاء شائعة عند المبتدئين

الخطأ الأول: اختيار الأداة قبل فهم طبيعة المشروع. استخدام نفس التقنية في كل مشروع، دون سؤال ما إذا كان المحتوى يحتاج الظهور في محركات البحث أم لا. الخطأ الثاني: تجاهل الاتصال البطيء. غالباً يُختبر الموقع على اتصال إنترنت سريع فقط، بينما جزء كبير من المستخدمين يستخدمون اتصالاً متقطعاً أو أجهزة أضعف. الخطأ الثالث: بناء نظام إدارة حالة معقد من اليوم الأول. ليس كل مشروع يحتاج أداة ضخمة لإدارة الحالة، خصوصاً إذا كان جزء كبير من البيانات هو أصلاً حالة خادم يمكن لمكتبة جلب بيانات أن تتولاها. الخطأ الرابع: قياس الأداء مرة واحدة فقط عند الإطلاق. الأداء يتغير مع كل ميزة جديدة تُضاف، فمن المفيد قياسه بشكل دوري وليس مرة واحدة فقط.

11. كيف تقيس أداء موقعك

الحديث عن الأرقام دون أدوات لقياسها غير مكتمل. من الأدوات المتاحة مجاناً:

  • Lighthouse: مدمجة في أدوات مطوري Chrome، تعطيك تقريراً فورياً عن الأداء وCore Web Vitals لأي صفحة تفتحها.
  • PageSpeed Insights: أداة من جوجل تجمع بين بيانات مخبرية وبيانات حقيقية من مستخدمين فعليين لموقعك.
  • WebPageTest: تتيح اختبار الموقع من مواقع جغرافية وأنواع اتصال مختلفة، مفيدة لمعرفة تجربة المستخدمين البعيدين عن خادمك.
  • Chrome UX Report (CrUX): بيانات ميدانية مجمّعة من مستخدمين حقيقيين لمتصفح كروم، تعكس التجربة الفعلية بدل بيئة اختبار مثالية.

12. خلاصة

الفكرة التي أريد إيصالها ليست قائمة أدوات تحفظها، بل عادة تكتسبها: قبل أن تبدأ في كتابة المكونات، اسأل نفسك أين ستُعرض الصفحة، من أين ستأتي البيانات، وماذا سيحدث لو تأخر الاتصال أو فشل الطلب، ثم تحقق من إجابتك بالأرقام لا بالانطباع فقط. لست بحاجة لمعرفة كل شيء من أول مرة، وأنا شخصياً ما زلت أتعلم أموراً جديدة باستمرار. لكن السؤال الذي غيّر طريقة تفكيري كان بسيطاً: “ماذا سيحدث لو كبر هذا التطبيق فجأة، أو كان المستخدم على اتصال ضعيف؟”. إذا استطعت الإجابة عن هذا السؤال قبل كتابة أول سطر كود، فأنت بالفعل تفكر كمهندس أنظمة، لا كمبرمج يكتب عناصر مرئية فقط. ما أكثر قرار في تصميم الواجهة الأمامية ندمت أنك اتخذته متأخراً في أحد مشاريعك؟

اكتشاف المزيد من كود التطور

اشترك للحصول على أحدث التدوينات المرسلة إلى بريدك الإلكتروني.

Related Posts

اترك رد

Scroll to Top