VOL12: Pessimistic Locking, WebSockets and ACID
ايه هو الـ Pessimistic Locking؟
يعتبر الـ Locking من أهم الآليات اللي بنعتمد عليها في الـ Databases بشكل أساسي عشان نتحكم في الـ Concurrent Access للبيانات من خلال أكثر من Transactions، فلو كان هناك عدد من الـ Transactions بيحاول يوصل للبيانات دي في نفس الوقت فأكيد هيحصل نتيجة لده تضارب بنسميه Conflicts.
نقدر نتخيل الـ Locking كأنه زي القفل اللي بنقفل بيه على أي حاجة عشان نمنع أي حد من الوصول ليها. فالـ Databases أحيانًا بتحط قفل على الـ Row أو الـ Record لما يكون فيه Transaction شغال عليه عشان تمنع أي حد من الوصول للـ Row ده, اكنه دخل (الحمام وقفل وراه الباب) ..
الـ Pessimistic Locking جاي من اسمه انه شخص متشائم، بيعمل حسابه دايما على أسوء الظروف وبناء عليه بيفكر لقدام وبياخد احتياطه مسبقا.
الـ Pessimistic Locking في قواعد البيانات بيمنع الـ Conflicts الناتجة من الـ Concurrent Updates واللي بتحصل بشكل Frequent أو متكرر. فلما بنيجي نعمل عملية تحديث لـ Row أو Record معين، فالـPessimistic Locking بتحط قفل على الـRow أو الـRecord ده عشان تمنع عمليات الـ Updates التانية من انها توصل لنفس الـ Row أو الـ Record في نفس الوقت.
ممكن نتخيل أن القفل ده عبارة عن اشارة حصرية فقط لعملية الـ Update الحالية , وبالتالي مش ممكن لأي عملية تانية انها توصل لنفس البيانات اللي شغالين عليها وده لانها بتكون مقفول عليها بالقفل لحد ما العملية الحالية تنتهي.
الفرق بين الـ WebSockets والـ HTTP Req/Res
الـ WebSockets جت عشان تسمح بمشاركة البيانات بين الطرفين بشكل بيحصل in-real time بمعنى ان دلوقتي باه عندي وسيلة تواصل ثنائية الاتجاه او بنقول عليه Bi-Directional Communication وده معناه ان دلوقتي اصبح عندي الـ Server والـ Client الاتنين يقدروا يكلموا بعض في نفس الوقت.
خلونا نرجع لمثال الرسالة بتاعة مكتب البريد , بدل ما كنا هنبعت الرسالة ونستنى وقت ما معين لحد ما يجيلنا الرد , دلوقتي باه عندنا Messenger نقدر من خلاله نبعت الرسالة ونحصل على الرد بشكل لحظي ونتكلم في نفس الوقت مع بعض من غير منبعت كل شوية رسالة ونستنى الرد عليها.
وبالنسبة لمثال التليفون فاحنا في وقتنا الحالي نقدر نتكلم في التليفون احنا الاتنين في خط واحد ونسمع بعض ونتكلم في نفس الوقت
هو ده فرق الـ WebSockets عن البروتوكول التقليدي للـ HTTP Request Response.
اي هي الـ Web Sockets ؟
هي عبارة عن Communication Protocol مزدوجة الاتجاه بنقول عليها Full-Duplex Communication Channels وده كله من خلال TCP Connection واحد بس. وبالتالي بتسمح بعملية الـ Real-time والـ Event-Driven Connections بين الـ Client والـ Server.
وعشان كده هنعرف كمان شوية في استعمالاتها انها كويسة اوي مع الـ Paradigms دي جدا.
ACID Properties in DBMS
من المفاهيم الاساسية والشهيرة في الـ Relational Databases هي الـ ACID فورقة وقلم وتعالوا نعرف هي إيه وليه مهم إن قاعدة البيانات تكون بتحققها.
ال ACID ببساطة عبارة عن اختصار ل 4 قواعد لازم تحققهم قاعدة البيانات و العمليات اللي بتتم عليها بغض النظر عن أي Software or Hardware Failure أو حتى Power Failure.
و ال 4 قواعد دي هي الضمان إن ال Database دي والبيانات اللي فيها صحيحة وموثوق فيها و دا عامل أساسي في مجال البرمجيات ككل "صحة البيانات".
ال 4 قواعد هما:
Atomicity
Consistency
Isolation (Safe Concurrent Transactions Execution)
Durability(Committed Transactions Must Be Durable)
Polymorphic React Components
من الصعب دعم جميع الخيارات والمكونات المحتملة التي قد يرغب المطور في استخدامها ضمن مكتبة مُكونات (ui components library) أو نظام تصميم مُعين (Design System).
في هذا المقال سنستعرض كيف يمكن لمكونات React متعددة الأشكال (Polymorphic React components) أن تساعد في التغلب على هذا التحدي. سنتطرق إلى الإمكانيات التي توفرها هذه المكونات لتصميم واجهات مستخدم ديناميكية ومرنة تُلبي متطلبات متنوعة بكفاءة عالية.
طُرق إنشاء مُكونات رياكت مُتعددة الأشكال
يُعتبر التعدد الشكلي (Polymorphism) طريقة حيث يُمكن لعنصر واحد أن يتخذ أشكالا متعددة، مثل زر (Button) يُمكن أن يعمل أيضا كرابط (Link). استخدام هذه الطريقة بكفاءة يُمكن أن يُسهم في تقليل الجهد اللازم لصيانة عدة نسخ مختلفة من المكونات؛ فبدلاً من امتلاك مكونين منفصلين لكل من الزر والرابط، نستطيع الاعتماد على مكون واحد (Button) مرن يُمكنه القيام بالوظيفتين.
من الطرق الشائعة لتطبيق التعدد الشكلي في React هي استخدام نمط "as" ونمط "asChild".
تُعتبر المكونات متعددة الأشكال شائعة جدا، حيث تستخدمها العديد من المكتبات (libraries) وأنظمة التصميم (design systems). من مكتبات CSS-in-JS مثل Styled Components، مرورا بمكتبات المكونات مثل Chakra UI، وصولا إلى أنظمة التصميم مثل React Spectrum، تُظهر هذه الأدوات كيف يمكن للمكونات المتعددة الأشكال أن تُسهم بشكل فعال في تبسيط تطوير واجهات المستخدم وتعزيز المرونة.
نمط as
أحد الأمور الشائعة في تطوير واجهات المستخدم هي جعل رابط (Link) يبدو و كأنه زر (Button) من ناحية التنسيقات فقط لكنه يبقى مُحافظ على سلوكه الطبيعي (Navigation).
أحد الحلول التي تسمح لنا بذلك هي باستخدام نمط "as". هذا النمط يستفيد من خصائص JSX حيث أن React تتعامل مع العناصر التي تبدأ بحروف كبيرة كأنواع عناصر (element type)، مما يمكننا من التحكم في نوع العنصر المُراد تقديمه عبر متغير.
في التطبيق العملي، يمكننا توظيف هذه الميزة بتعيين القيمة من خاصية "as" إلى متغير يُدعى Component (اسم المُتغير هنا اختياري، يمكنك استخدام أي اسم تريده طالما أن الاسم يبدأ بحرف كبير). هذا يسمح لنا بتغيير نوع العنصر ديناميكيا بناءً على الخاصية المُعطاة. على سبيل المثال:
في المثال أعلاه، إذا كانت قيمة الخاصية "as" هي "a"، فإن نوع العنصر سيكون وسم رابط (anchor tag) و ليس وسم زر (button tag).
نمط as و TypeScript
للتأكد من أن المستخدم للمُكون يقوم بتمرير قيمة صحيحة للخاصية "as"، يمكننا استخدام أحد خواص التايبسكريبت Generics، والسماح له بالتوريث من ElementType. و بهذا الشكل خاصية "as" يمكن أن تتضمن الآن أنواع عناصر صالحة، مثل <a> أو <button>:
المثال أعلاه بسيط و في حالة عدم الحاجة إلى تمرير الـ ref و هو ما نفعله في العادة في المُكونات المُتعلقة بالمشروع بحد ذاته، لكن إذا ما كُنا نبني مكتبة مُكونات ففي الغالب نحتاج إلى التعامل مع تمرير الـ ref حتى تكون مُكوناتنا مرنة و قابلة للاستخدام في عديد السياقات خصوصا إذا ما كُنا نريد التعامل مع 3rd packages مثل charts… و عليه يُمكن أيضا أن تجد هذا النمط بصيغ مُختلفة في طريقة دعم الـ TypeScript.