Backend

اختيار الـ Format المناسب للـ Data Serialization أصبح موضوع حيوي حاليًا خصوصًا في التعامل مع الأنظمة اللي بتتميز بكونها Large-Scale واللي الأداء فيها حيوي ومهم جدًا. ومن أشهر الـ Formats اللي فضلت موجودة على مر السنين

لما نتعلم أوامر Linux، هنقدر اننا نـ Automate أغلب مهام الشغل اليومي بتاعتنا ونسهل حاجات كتير في شغلنا، وكمان هنقدر نتحكم في كل حاجة في النظام بتاعنا بسهولة.

الـ Materialized View مش مجرد Query بتتنفذ كل مرة زي الـ Views العادية. ولكن هي بتنفذ الـ Query مرة واحدة بس وتخزن النتيجة فعليًا في جدول جديد جوا الـ Database.

عشان نضمن الـ Data Integrity فالـ MySQL بيحتاج يعمل Lock على البيانات قبل ما يعمل Update على أي Record موجود ، لو فيه عمليات متعددة (Multiple Processes) بتحاول تعمل Update للبيانات في نفس الجدول في نفس الوقت، فممكن يحصل "deadlock"

الـ Sticky Session هو Terminology اشتهر خصوصًا في التطبيقات اللي بنحتاج فيها الـ Server يحافظ على الـ Session بينه وبين الـ Client ، فكل الـ User Request بتبدأ تروح لنفس الـ Server خلال مدة الـ Session بتاعته.

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

بنحتك بشكل كبير بقواعد البيانات ، وأصبح من المهم دلوقتي أن يكون عندنا مهارة قوية في التعامل مع الـ SQL ونكون فاهمين كويس ازاي نكتب Queries تكون قوية و Efficient

الـ N+1 Problem هي مشكلة في طريقة تعاملنا مع قواعد البيانات ، ومن المشاكل اللي لازم احنا كمطورين ناخد بالنا منها لانها ليها ضريبة كبيرة أوي خصوصا في التعامل مع البيانات الكبيرة.

تعالوا نشوف مع بعض بعض التحديات اللي فريق المهندسين في لينكدإن واجهوها مع JSON والعملية اللي استخدموها لتقييم حلول جديدة وفي النهاية اختيارهم لـ Google Protocol Buffers (Protobuf) كبديل