AR
RU
EN
ES
ZH
FR
DE
PT
HI
GraphQL مقابل REST في TypeScript: مبارزة العمالقة أم اختيار حسب المهمة؟
\n\nعندما تكتب بلغة TypeScript، تصبح مسألة بنية الخادم أكثر إلحاحًا. لا تريد فقط "أن يعمل"، بل تريد أن تطير الأنواع، وأن تُلتقط الأخطاء في مرحلة التجميع، وأن يكون الكود قابلاً للتنبؤ. وهنا يقف المطور أمام خيار أبدي: REST المُختبر عبر الزمن أم GraphQL المرن والعصري؟ كلتا التقنيتين تتعاملان بشكل ممتاز مع TypeScript، لكن كل منهما تملي أسلوبها الخاص في التطوير.
\n\nفي هذه المقالة، لن نطيل الحديث أو نكرر الحقائق البديهية. سنقوم بتحليل GraphQL مقابل REST في TypeScript من خلال أمثلة محددة، مع الكود، ونقاط الضعف، والسيناريوهات التي يتفوق فيها أحد النهجين على الآخر. هيا بنا!
\n\nREST: الصديق القديم الذي لا يخيب
\n\nREST (نقل الحالة التمثيلية) هو أسلوب معماري حيث يكون لكل مورد (مستخدم، منشور، تعليق) عنوان URL خاص به. تطلب /api/users/1 وتحصل على المستخدم. بسيط وقابل للتنبؤ. في مشاريع TypeScript، غالبًا ما يتم تنفيذ REST عبر Express أو Fastify أو NestJS.
التصنيف في REST مع TypeScript
\nالألم الرئيسي في REST هو ضعف الارتباط بين الخادم والواجهة الأمامية. ترسل JSON، وتتساءل الواجهة الأمامية: "ماذا جاء؟". ينقذ TypeScript الموقف من خلال الأنواع المشتركة أو OpenAPI (Swagger).
\n\nمثال: خادم Express مع TypeScript
\n\nimport express, { Request, Response } from 'express';\n\ninterface User {\n id: number;\n name: string;\n email: string;\n}\n\nconst app = express();\napp.get('/api/users/:id', (req: Request, res: Response) => {\n const user: User = { id: +req.params.id, name: 'Alice', email: 'alice@example.com' };\n res.json(user);\n});\nالواجهة الأمامية (fetch):
\n\ninterface User {\n id: number;\n name: string;\n email: string;\n}\n\nasync function getUser(id: number): Promise<User> {\n const res = await fetch(`/api/users/${id}`);\n return res.json() as Promise<User>;\n}\nالمشكلة: إذا غيّر الخادم هيكل User، فإن الواجهة الأمامية لن تعلم بذلك إلا في وقت التشغيل. الأنواع في الواجهة الأمامية هي مجرد نسخة. الحل: توليد الأنواع من مواصفات OpenAPI.
\n\nإيجابيات REST في TypeScript
\n- \n
- سهولة التخزين المؤقت: يعمل تخزين HTTP المؤقت (CDN، المتصفح) بشكل افتراضي. \n
- هيكل واضح: URL = مورد، الطرق = إجراءات (GET, POST, PUT, DELETE). \n
- دعم واسع: أي عميل (متصفح، curl، Postman) يفهم REST. \n
- عتبة دخول منخفضة: حتى المبتدئ سيفهمه في ساعة. \n
سلبيات REST
\n- \n
- Over-fetching و Under-fetching: إما تسحب حقولًا إضافية أو تقوم بعدة طلبات. \n
- هيكل صارم: للحصول على المستخدم + منشوراته، تحتاج إلى طلبين أو حلول بديلة (حقل expand). \n
- تصنيف ضعيف: بدون OpenAPI، الأنواع في العميل هي مجرد "وعد شرفي". \n
GraphQL: المرونة والتحكم
\n\nGraphQL هي لغة استعلام تمنح العميل الحق في تحديد البيانات التي يريد الحصول عليها بنفسه. نقطة نهاية واحدة (/graphql)، طلب واحد - وتحصل بالضبط على ما طلبت. TypeScript و GraphQL هما ثنائي مثالي: يتم إنشاء الأنواع تلقائيًا من المخطط.
التصنيف في GraphQL مع TypeScript
\nأولاً، يتم كتابة المخطط (SDL):
\n\ntype User {\n id: ID!\n name: String!\n email: String!\n posts: [Post!]!\n}\n\ntype Post {\n id: ID!\n title: String!\n content: String!\n}\n\ntype Query {\n user(id: ID!): User\n}\nثم يتم إنشاء الأنواع (عبر graphql-codegen):
// generated.ts\nexport type User = {\n __typename?: 'User';\n id: string;\n name: string;\n email: string;\n posts: Array<Post>;\n};\n\nexport type Post = {\n __typename?: 'Post';\n id: string;\n title: string;\n content: string;\n};\nالمدونات
توصيات الكتب
اقرأ أيضًا
