DocRaptor منتج كفء. إنه يغلّف Prince، وهو محرك HTML-to-PDF من الدرجة الأولى، داخل REST API مستضافة مع إعادة محاولات، ومهام غير متزامنة، ووثائق جيدة. موجود منذ أكثر من عقد، وبالنسبة إلى فرق كثيرة هو الخيار البديهي عندما لا تريد تشغيل Prince بنفسك.

gPdf أداة من نوع مختلف. لا يقبل HTML أصلًا؛ يأخذ JSON منظمًا ويصيّر PDF مباشرة على Cloudflare Edge. فرق السعر المعلن عند 100,000 صفحة شهريًا هو 5 دولارات/شهر (gPdf Basic) مقابل 89 دولارًا/شهر (DocRaptor Basic)، أي نحو 18×. هذا الفرق ليس عرضًا افتتاحيًا. إنه بنيوي. يشرح هذا المقال لماذا تنتج البنية هذا السعر، وأين يناسب كل منتج فعليًا.

المعماريتان جنبًا إلى جنب

الطبقة	DocRaptor (HTML → PDF)	gPdf (JSON → PDF)
الإدخال	HTML + CSS، مع امتدادات Prince للوسائط المطبوعة	JSON `DocumentRequest`
محرك التصيير	Prince، محرك C++ مترجم	محرك Rust مخصص، مترجم إلى WebAssembly
الاستضافة	خوادم DocRaptor المركزية في منطقة مركز بيانات أمريكية	Cloudflare Workers في كل CF colo، أكثر من 300 مدينة
البداية الباردة	تجمع workers على الخادم	تشغيل V8 isolate خلال رقم أحادي من المللي ثانية
الحوسبة لكل تصيير	مرور تخطيط على HTML/CSS، ثم ترقيم صفحات في Prince	تنضيد مباشر، من دون مرور تفسير للتخطيط
p50 لكل تصيير	نحو 250-800 ms wall-clock، شبكة + تصيير	نحو 3-8 ms، شبكة + تصيير
حتمية الإخراج	عالية، لأن Prince ناضج	متطابقة على مستوى البايت: JSON نفسه → البايتات نفسها

إذا قرأت العمودين بوصفهما “طابعة HTML عامة” مقابل “محرك مستندات مخصص”، فقد فهمت القرار المعماري. كل شيء آخر، من زمن الاستجابة إلى التكلفة وحتى قوائم الميزات، يتبع هذا الاختيار.

ضريبة Prince

Prince جيد. لكنه يقوم أيضًا بعمل لا تحتاجه معظم مسارات الفواتير والإيصالات والملصقات: تنفيذ CSS Paged Media، مثل قواعد page-break والرؤوس الجارية والحواشي والإحالات المتقاطعة وصناديق المحتوى المولّد، لأي HTML عشوائي يرسله المستخدم.

هذه العمومية لها تكلفة وقت تشغيل. لكي يقسم المحرك مستند HTML عشوائيًا إلى صفحات، عليه أن:

يقرأ HTML ويتحقق منه
يقرأ CSS cascade ويحلها، ربما مع امتدادات Prince الخاصة
يبني شجرة التصيير
يشغّل تخطيطًا متعدد المرور، خصوصًا للجداول الممتدة عبر صفحات أو الأعمدة المتوازنة
يحل الإحالات المتقاطعة عبر الصفحات
يخرج كائنات PDF

معظم هذه المراحل هي تكلفة قبول HTML كمدخل. إذا كان إدخالك بيانات منظمة أصلًا، كما يحدث غالبًا لأن الفاتورة موجودة ككائن JSON قبل تغليفها في HTML، فأنت تدفع مقابل هذه المراحل في الحوسبة وزمن الاستجابة في كل تصيير، وهي لا تضيف قيمة إلى الناتج.

يتجاوز gPdf خطوة تفسير التخطيط بالكامل. يحدد JSON DocumentRequest تخطيط الصفحة هيكليًا من البداية، مثل { pages: [{ size, elements: [...] }] }. ينضّد المحرك العناصر، ويقسم الجداول والقوائم إلى صفحات بصورة حتمية، ثم يخرج PDF. لا CSS cascade لحله، ولا float layout لحسابه، ولا مرحلة حل للإحالات المتقاطعة.

النتيجة: الفاتورة نفسها من صفحة واحدة التي تستغرق نحو 300 ms في DocRaptor تستغرق نحو 3 ms في gPdf. نحن لسنا أسرع لأننا كتبنا Prince أسرع؛ نحن أسرع لأننا لا نفعل معظم ما يفعله Prince.

“رخيص جدًا ليكون حقيقيًا” اعتراض شراء حقيقي

نحتاج إلى مواجهة هذا مباشرة لأنه يظهر في كل مكالمة B2B تقريبًا.

“5 دولارات/شهر لـ 100,000 عملية تصيير. DocRaptor يكلّف 89 دولارًا. Anvil يكلّف 0.10 دولار لكل PDF، أي 10,000 دولار للحجم نفسه. ما الخطأ لديكم؟”

هناك ثلاثة أسباب صريحة تجعل هذا السعر ممكنًا:

1. لا نشغل متصفحًا

يوزع DocRaptor تكلفة بنية Prince على العملاء. أما gPdf فيوزع تكلفة Cloudflare Worker واحد، وهي تقريبًا 0.50 دولار لكل مليون request على Workers Bundled. مع إدخال على شكل JSON، يستغرق محرك التصيير لدينا نحو 1.5 ms CPU لكل تصيير. حتى مع هامش 50% تبقى التكلفة في نطاق السنتات لكل ألف تصيير. الحساب نفسه هو السعر.

2. لا نشغل control plane

لا توجد مهام غير متزامنة، ولا callbacks، ولا قائمة إعادة محاولات، ولا تخزين مستندات، ولا واجهة روابط معاينة، ولا قاعدة بيانات متعددة المستأجرين. كل تصيير هو رحلة واحدة إلى دالة عديمة الحالة والعودة. هذا يزيل سطح تشغيل كاملًا تسعّره معظم شركات “PDF API”، وهو أيضًا السطح الذي يبرر أسعارها.

3. النموذج يستبعد تلقائيًا أعباء العمل التي قد نخسر فيها

إذا كان مستندك يحتاج فعلًا إلى HTML-to-PDF، مثل عقد قانوني من 60 صفحة أو تقرير CSS Grid معقد، فستصطدم بنموذج JSON في الساعة الأولى وتذهب إلى DocRaptor. لا نحتاج إلى تسعير دفاعي لهذه الأعباء لأنها توجه نفسها إلى الأداة الأخرى. علينا فقط تسعير الذيل الطويل والضيق من أعباء “بيانات منظمة إلى مستندات”، حيث تكون تكلفة التصيير الواحدة صغيرة فعلًا.

بجمع هذه الأسباب: 5 دولارات لكل 100,000 ليست loss leader، بل تكلفة البضاعة المباعة الفعلية مضافًا إليها هامش. يمكننا إبقاءها كذلك لأن الحوسبة الأساسية رخيصة إلى هذا الحد عندما لا تشحن متصفحًا.

متى يكون DocRaptor الخيار الصحيح

نحاول ألا نكتب مقارنات تخدمنا فقط. الحالات التي يفوز فيها DocRaptor فعلًا:

إدخالك HTML لا تتحكم فيه بالكامل. تقارير يولدها المستخدمون، قوالب طرف ثالث، أو Markdown من CMS تم تحويله إلى HTML. لا تريد كتابة JSON mapper لمدخلات عشوائية.
تحتاج ميزات CSS Paged Media التي يدعمها Prince. رؤوس/تذييلات جارية لكل فصل، إعادة تدفق حواشٍ معقدة، named-page selectors، جداول محتويات مولدة، فهارس. لدى gPdf مكافئات منظمة للجزء الشائع، لكن إذا كنت تعيش داخل @page :left selectors، فـ Prince صديقك.
لديك فريق محتوى يكتب HTML/CSS، لا JSON. لا تفرض سير تأليف JSON على فريق غير هندسي. سيكرهون ذلك.
تريد async + callbacks + document storage كخدمة. يخزن DocRaptor ملفات PDF الناتجة ويعطيك signed URLs للتسليم. gPdf عديم الحالة تمامًا؛ الكود لديك يخزن النتيجة.

إذا كنت في أي من هذه الحالات، ابق على DocRaptor. إنه الأداة الصحيحة.

متى يكون gPdf الخيار الصحيح

الصورة المعاكسة:

إدخالاتك هي بيانات منظمة أصلًا، مثل صفوف قاعدة بيانات أو حمولات JSON API أو رسائل queue.
زمن الاستجابة مهم، مثل checkout تفاعلي، أو طباعة ملصقات في الوقت الحقيقي، أو إنشاء كشوف عند الطلب.
تهتم بـ إعادة إنتاج مطابقة على مستوى البايت للاختبارات أو مسارات التدقيق أو احتفاظ الفاتورة الإلكترونية.
أنت حساس للتكلفة عند أي حجم فوق بضعة آلاف تصيير شهريًا.
تحتاج باركودات مثل GS1-128 وQR وData Matrix وPDF417 وAztec وMaxiCode بدقة دون الملليمتر. يدعم Prince تقنيًا باركودات SVG، لكن جعلها دقيقة حتى 0.1 mm عبر HTML/CSS ليس أمرًا بسيطًا.
تحتاج PDF/A (1b/2b/3b/4) أو مرفقات Factur-X / ZUGFeRD للامتثال.
لا تريد تشغيل pipeline من JSON إلى HTML إلى PDF عندما يمكنك تشغيل pipeline من JSON إلى PDF.

الهجرة ميكانيكية، لا استراتيجية

القلق الشائع هو: “الانتقال يعني إعادة كتابة كل القوالب”. غالبًا لا. معظم قوالب HTML-to-PDF هي 20% تخطيط، وهذا يصبح بنية JSON مرة واحدة، و80% إدراج بيانات، وهذا هو نفسه تمامًا أيًا كان محرك التصيير.

المسار العملي:

اختر نوع مستند واحدًا للهجرة. ابدأ بالأعلى حجمًا، فهو أكبر توفير وأصغر نطاق تأثير.
خذ واجهة البيانات الخاصة بقالب HTML، أي المتغيرات التي يدرجها، واكتب دالة صغيرة باسم mapToDocumentRequest(data).
كرر العمل داخل Playground حتى يطابق الإخراج المطلوب.
نفذ A/B في الإنتاج: وجّه 5% من الحركة إلى gPdf لمدة أسبوعين. قارن ملفات PDF وقارن الفواتير.
تقدم أو تراجع بناءً على البيانات، لا على الانطباع.

رأينا فرقًا تنجز هذا في sprint واحد وتخفض 90% من فاتورة PDF في الشهر التالي. ورأينا فرقًا أخرى تكتشف أن عبء عملها هو فعلًا حالة HTML-to-PDF وتبقى على DocRaptor، وهذا أيضًا قرار صحيح.

TL;DR

	DocRaptor	gPdf
الأفضل في	HTML → PDF لمحتوى عشوائي	JSON → PDF لمستندات منظمة
السعر (100,000 صفحة/شهر)	$89	$5
p50 للتصيير	250-800 ms	3-8 ms
منشور على Edge	لا، مركزي	نعم، أكثر من 300 Cloudflare colo
async + storage	نعم، مضمّنة	لا، عديم الحالة تصميميًا
PDF/A + Factur-X	عبر امتدادات Prince	مدمج

إذا كانت مستنداتك بيانات منظمة متنكرة في HTML من أجل محرك التصيير، فأنت تدفع مقابل خطوة ترجمة لا تحتاج إلى الوجود. جرّب Playground: صِف فاتورة واحدة بـ JSON، وصيّرها في المتصفح خلال أقل من 5 ms، وانظر هل تطابق الفجوة إحساسك.