التدفق

يعتمد go-like نموذج التدفق الموجود أصلاً في منصة Web. فالطلب المتدفق هو Request قياسي، والاستجابة المتدفقة هي Response قياسية قد يحمل جسمها ReadableStream<Uint8Array>. لا يضيف المشروع فئة تدفق خاصة، ولا DSL للإطارات، ولا قناة ثنائية الاتجاه وهمية فوق هذه الواجهات.

ينتمي تدفق HTTP العام إلى @go-like/web وإلى Handler الأصلي لإطار العمل. يحمل الاستدعاء الأحادي جسم JSON واحداً. وتدفق الخادم مع stream: true هو SSE على POST /<service>/<endpoint> مع accept: text/event-stream، وليس بروتوكول إطارات ثنائي الاتجاه. المعالج async *. ينتظر العميل await للحصول على ServerStream ثم for await. يُغلق بـ close() أو await using. القيمة الافتراضية لـ streamKeepAlive هي 15000 مللي ثانية، و0 يُبقي التعليق الأول فقط. maxSendMessageBytes افتراضياً 4 MiB ويحسب حدث SSE بترميز UTF-8 كاملاً؛ التجاوز هو resource_exhausted / HTTP 429. يتقدّم Memory برسالة واحدة على الأكثر، والجلب المسبق في HTTP محدود وليس 1:1 مع for await. لا تُنفّذ في المولّد أثراً يفترض أن الحدث قد سُلّم. ومع deadline يكتب العميل Go-Like-Timeout-Ms. يعيش Context الطلب حتى انتهاء جسم الاستجابة. يبقى client-streaming وbidi في @go-like/transport-grpc-buf/native.

هذا الفصل مهم لأن أجسام Web تُقرأ مرة واحدة. ينبغي للـ middleware ألا يقرأ الجسم إلا إذا كان سيوفر بديلاً عنه، ويجب أن ينتقل الإلغاء عبر إشارة الطلب وعبر Context الموجود في أول المعاملات. تتحقق طبقة النقل أيضاً من أن مقاطع التدفق هي Uint8Array؛ فإذا وصل مقطع غير صالح أصبح ذلك خطأ بروتوكول واضحاً، لا بيانات فارغة بصمت.

مرّر معالج Fetch الأصلي لإطارك إلى @go-like/web لنقاط HTTP العامة. تستطيع Hono وElysia وH3 إنشاء SSE أو استجابات متدفقة أو ترقيات WebSocket خاصة ببيئة التشغيل مباشرة. يحافظ go-like فقط على هوية Request وResponse والتدفق والخطأ الأصلية، ولا يحاول إعادة تعريفها.

ينظّف contextHandler سياق Context الخاص به عند اكتمال Handler وإرجاع Response، وليس عند نهاية تدفق body. يجب أن يتابع المنتج طويل العمر request.signal أو سياق إلغاء يملكه صراحةً.

يوفّر @go-like/protoc-gen-like شيفرة Protobuf RPC مولّدة تضع Context أولاً، باستخدام Protobuf-ES. يوفّر @go-like/transport-grpc-buf عبر Fetch استدعاءات Connect/gRPC-Web الأحادية وتدفق استجابات الخادم؛ ويضيف /native معيار gRPC بالأنماط الأربعة، بما فيها تدفق طلبات العميل والتدفق ثنائي الاتجاه. هذا مسار مستقل عن Transport SPI الأحادي.

اجتاز gRPC المُدار في Node 26.12.1 وBun 1.4.4 اختبار تصريف التدفق مع مستهلك بطيء. سُجّل سابقاً بقاء مؤقّت deadline في Connect 2.1.2 بعد إلغاء تدفق استجابة متوقف مؤقتاً، وعدم وصول إلغاء Fetch في Bun 1.4.2 إلى خادم صامت بعد أول جزء. راجع الأدلة والقيود؛ لم يتحقق هذا التشغيل من إصلاح هذين القيدين السابقين.