باك إند TypeScript الحديث: Hono وElysiaJS وشو بعد NestJS

ليش وقفنا نبدأ مشاريع جديدة بـ NestJS

NestJS فريمورك ممتاز. بنينا أنظمة enterprise عليه (Vendure مبني على NestJS من تحت، ونحن نحب Vendure). بس للخدمات الجديدة المستقلة، انتقلنا لـ Hono. مش لأن NestJS سيء. لأن Hono أفضل لطريقة شغلنا الحالية.

التحول صار تدريجياً. بدأنا خدمة API جديدة، فكرنا بـ NestJS، وسألنا حالنا: هل فعلاً نحتاج decorators وmodules وproviders وcontainer الـ dependency injection المستوحى من Angular لـ API فيه 15 endpoint؟ الجواب كان لا. احتجنا فريمورك HTTP سريع يشتغل على أي runtime، عنده دعم TypeScript جيد، وما يفرض عليك بنية محددة.

Hono وفرلنا هالشي. بعدها جربنا ElysiaJS على Bun لخدمة تحتاج أداء عالي. وهذا وفرلنا شي مختلف. هالمقالة مقارنة صريحة من شخص يشغل الثلاثة في الإنتاج.

لسياق أوسع عن طريقة تعاملنا مع هندسة البرمجيات، هالدليل يغطي مبادئنا. وكيف هالفريمووركات تنسجم مع بنية التجارة، شوف دليل Vendure للإنتاج.

الفريمووركات الثلاثة

Hono: الفريمورك اللي يشتغل في كل مكان

Hono فريمورك ويب مبني للـ edge. يشتغل على Node.js وBun وDeno وCloudflare Workers وAWS Lambda وVercel Edge وFastly. نفس الكود ينتشر على أي runtime بدون تعديلات.

import { Hono } from 'hono';
import { cors } from 'hono/cors';
import { jwt } from 'hono/jwt';
import { logger } from 'hono/logger';

const app = new Hono();

// الـ Middleware
app.use('*', logger());
app.use('*', cors({ origin: ['https://app.example.com'] }));
app.use('/api/*', jwt({ secret: process.env.JWT_SECRET! }));

// المسارات
app.get('/api/products', async (c) => {
    const products = await productService.findAll();
    return c.json({ data: products });
});

app.get('/api/products/:id', async (c) => {
    const product = await productService.findById(c.req.param('id'));
    if (!product) return c.json({ error: 'Not found' }, 404);
    return c.json({ data: product });
});

app.post('/api/products', async (c) => {
    const body = await c.req.json();
    const product = await productService.create(body);
    return c.json({ data: product }, 201);
});

export default app;

ليش يعجبنا

قابلية التنقل بين الـ Runtimes. ننشر نفس كود Hono على Lambda (API Gateway) وBun (container) وCloudflare Workers (edge). بدون أي تعديل على الكود بين الـ runtimes. هي نقطة قوة Hono الفريدة. ما في فريمورك ثاني يقدر يسوي هالشي.

14KB الأساس. البدايات الباردة على Lambda أقل من 100ms. بدايات NestJS الباردة بين 2-5 ثواني. للنشر على serverless، هالفرق هو كل تجربة المستخدم.

بدون رأي عن البنية. Hono يعطيك routing وmiddleware وcontext. انت تقرر كيف تبني الخدمات والـ repositories ومنطق العمل. للـ APIs الصغيرة للمتوسطة (5-50 endpoint)، هذا بالضبط اللي تحتاجه. ما تحتاج نظام modules لـ 20 مسار.

تكامل مع tRPC. نستخدم Hono + tRPC لأنظمة TypeScript الكاملة. أمان أنواع من البداية للنهاية من السيرفر للعميل بدون GraphQL:

import { trpcServer } from '@hono/trpc-server';
import { appRouter } from './trpc/router';

app.use('/trpc/*', trpcServer({ router: appRouter }));

وين يقصر

ما في DI مدمج. للتطبيقات الكبيرة اللي فيها 50+ خدمة ورسوم بيانية معقدة للاعتماديات، لازم تجيب حاوية DI خاصتك (tsyringe, inversify) أو تربط الاعتماديات يدوياً. هذا مقبول للخدمات الصغيرة. يصير متعب للكبيرة.

نظام middleware أصغر. NestJS عنده passport وclass-validator وclass-transformer وswagger ومئات الحزم المجتمعية. نظام Hono ينمو بس لسا ما وصل. رح تكتب middleware مخصص أكثر.

ما في اتفاقيات للتطبيقات الكبيرة. modules في NestJS تعطيك بنية تتوسع لـ 100+ ملف. Hono ما يفرض بنية. للفرق اللي فيها مطورين مبتدئين، غياب الاتفاقيات ممكن يودي لأكواد غير متسقة.

ElysiaJS: لما أداء Bun مهم

ElysiaJS مبني خصيصاً لـ Bun. يستغل واجهات Bun الأصلية وربط FFI وسيرفر HTTP المحسن عشان يحقق أداء ما تقدر فريمووركات Node.js توصله.

import { Elysia, t } from 'elysia';
import { swagger } from '@elysiajs/swagger';
import { jwt } from '@elysiajs/jwt';

const app = new Elysia()
    .use(swagger())
    .use(jwt({ name: 'jwt', secret: process.env.JWT_SECRET! }))
    .get('/products', async () => {
        return productService.findAll();
    })
    .post('/products', async ({ body }) => {
        return productService.create(body);
    }, {
        body: t.Object({
            name: t.String(),
            price: t.Number({ minimum: 0 }),
            description: t.Optional(t.String()),
        }),
    })
    .listen(3000);

ليش مثير للاهتمام

تحقق مدمج مع TypeBox. الـ schemas معرفة inline، وتولد تلقائياً مستندات OpenAPI. ما تحتاج مكتبة تحقق منفصلة. الأنواع تتدفق من الـ schema للـ handler للـ response.

أداء أصلي على Bun. ElysiaJS على Bun يتعامل مع 2-3 أضعاف الطلبات بالثانية مقارنة بـ Express على Node.js لواجهات JSON البسيطة. لأحمال العمل الخفيفة حسابياً والثقيلة بالـ I/O (معظم الـ APIs)، الفرق أقل دراماتيكية بس لسا ملموس.

استنتاج أنواع من البداية للنهاية. نوع body الطلب يُستنتج من schema الـ TypeBox. نوع الـ response يُستنتج من الـ handler. العميل يقدر يستخدم Eden (عميل ElysiaJS الشبيه بـ tRPC) لاستدعاءات API آمنة الأنواع.

وين يقصر

Bun فقط. إذا تحتاج تنشر على Node.js أو Lambda أو Cloudflare Workers، ElysiaJS مش خيار. Bun جاهز للإنتاج بس مش مدعوم بشكل عام في كل بيئات الاستضافة.

نظام بيئي أصغر. توافق حزم Bun جيد بس مش 100%. بعض حزم Node.js تستخدم إضافات أصلية ما يدعمها Bun. تعريفات قواعد البيانات، مكتبات معالجة الصور، وبعض مكتبات التشفير الأصلية ممكن تكون مشكلة.

أقل اختباراً في المعارك. Bun وElysiaJS أجدد. المجتمع أصغر. لما تواجه حالة حدية، في إجابات أقل على Stack Overflow وناس أقل حلت نفس المشكلة.

Drizzle مقابل Prisma مقابل TypeORM: واقع الـ ORM

اختيار الفريمورك نص القرار. اختيار الـ ORM النص الثاني.

خياراتنا للـ Stack

Hono + Drizzle + tRPC: لواجهات TypeScript الجديدة. خفيف، سريع، أمان أنواع من البداية للنهاية. صياغة Drizzle الشبيهة بـ SQL تعطينا تحكم صريح بالاستعلامات بدون ثقل طبقة التجريد في TypeORM أو ثقل محرك Prisma.

// Drizzle: شبيه بـ SQL، صريح، آمن الأنواع
const products = await db
    .select()
    .from(productsTable)
    .where(and(
        eq(productsTable.tenantId, tenantId),
        eq(productsTable.status, 'active'),
        gt(productsTable.price, 1000),
    ))
    .orderBy(desc(productsTable.createdAt))
    .limit(20);

NestJS + TypeORM: لإضافات Vendure والتطبيقات الكبيرة enterprise وين نظام الـ modules وحاوية DI يبررون ثقلهم. TypeORM يتكامل بعمق مع NestJS وVendure.

Prisma: لما نحتاج هجرات مولدة تلقائياً والفريق يقدر توثيق Prisma وتجربة المطور أكثر من التحكم الخام بالاستعلامات.

مرونة النشر

هنا وين اختيار الفريمورك يأثر أكبر تأثير عملي.

إذا تنشر على containers بس، الثلاثة يشتغلون تمام. إذا تنشر على serverless أو edge، Hono هو الفريمورك الوحيد اللي يعطيك كل الخيارات. ElysiaJS حصري لـ Bun. NestJS حصري لـ Node (عملياً).

لكيف ننشر خدماتنا على البنية التحتية السحابية بما فيها Kubernetes وLambda ودوال edge، هالصفحة تغطي نهجنا.

متى NestJS لسا الخيار الصح

رغم تفضيلنا لـ Hono بالمشاريع الجديدة، NestJS هو الخيار الصح لما:

• تبني إضافات Vendure. Vendure هو NestJS. نظام الإضافات، الخدمات، الـ resolvers، والـ guards كلها تستخدم أنماط NestJS. مقاومة الفريمورك أسوأ من استخدامه.
• فريقك يعرف Angular. نمط module/provider/controller في NestJS يشبه Angular. إذا فريقك جاي من Angular، منحنى التعلم شبه صفر.
• تحتاج نظام middleware كبير. استراتيجيات Passport، class-validator، توليد Swagger التلقائي، GraphQL code-first. NestJS عنده كل هالشي مدمج أو متكامل بشكل جيد.
• التطبيق رح يكبر لـ 100+ ملف. modules في NestJS تعطي بنية تتوسع. بدون اتفاقيات (Hono, ElysiaJS)، الفرق الكبيرة تحتاج انضباط للحفاظ على التسق.
• تحتاج دعم WebSocket. NestJS فيه بوابات WebSocket مدمجة بنفس نمط الـ decorators. دعم WebSocket في Hono أكثر يدوية.

أخطاء شائعة

1. تختار Hono وبعدين تعيد بناء NestJS. إذا انتهيت وانت مضيف حاوية DI وrouting مبني على decorators ونظام modules ونمط guard لـ Hono، فعلياً بنيت NestJS أسوأ. استخدم NestJS.

2. تختار ElysiaJS للإنتاج قبل ما تقيم توافق Bun. تأكد إن كل اعتمادياتك تشتغل على Bun. الإضافات الأصلية، تعريفات قواعد بيانات محددة، وبعض مكتبات التشفير ممكن ما تشتغل.

3. تتجاهل أوقات البداية الباردة على serverless. NestJS على Lambda ما ينفع لواجهات API للمستخدمين بدون provisioned concurrency. Hono على Lambda سريع كفاية بدونها.

4. تستخدم TypeORM مع Hono. TypeORM مصمم لأنماط DI في NestJS. بدون DI، إدارة اتصالات TypeORM والـ repositories تصير غريبة. استخدم Drizzle أو Prisma مع Hono.

5. التبديل المبكر للفريمورك. إذا تطبيق NestJS حقك يشتغل وفريقك منتج، لا تبدل لـ Hono عشان بس تكون حديث. بدل لما يكون عندك سبب واضح (نشر serverless، دوال edge، خدمة مستقلة جديدة).

6. بدون طبقة تحقق. Hono ما يتضمن تحقق من الطلبات. استخدم Zod middleware أو ابني واحد خاص فيك. إطلاق API بدون تحقق من المدخلات ثغرة أمنية.

النقاط الأساسية

• Hono أكثر فريمورك TypeScript باك إند تعدداً. 14KB أساس، يشتغل على كل runtime، بدايات باردة سريعة، بدون رأي عن البنية. خيارنا الافتراضي لواجهات API المستقلة الجديدة.

• ElysiaJS يقدم أفضل أداء على Bun. تحقق مدمج، تجربة مطور ممتازة، أمان أنواع من البداية للنهاية. بس كونه حصري لـ Bun يحدد وين تقدر تنشره.

• NestJS لسا الخيار الصح للتطبيقات الكبيرة enterprise ولـ Vendure. Modules وDI وguards ونظام بيئي ضخم. منحنى التعلم يستاهل على المقاس الكبير.

• Drizzle هو الـ ORM المفضل عنا مع Hono. صياغة شبيهة بـ SQL، استعلامات صريحة، حزمة خفيفة. Prisma للفرق اللي تفضل عملاء مولدين تلقائياً. TypeORM لـ NestJS/Vendure.

• هدف النشر يحدد اختيار الفريمورك. Serverless وedge يحتاجون Hono. الـ Containers تشتغل مع أي شي. Bun الأصلي يحتاج ElysiaJS.

• لا تبدل فريمورك بدون سبب. إذا NestJS يشتغل عندك، استمر فيه. بدل لما تحتاج serverless أو edge أو خدمة مستقلة جديدة وين النهج الخفيف فعلاً أفضل.

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