هل من الممكن استخدام Discourse كعنصر واحد ضمن تطبيق Rails أكبر؟
أهدافي:
مشاركة قاعدة البيانات: أود جدًا أن يستخدم تطبيق Rails الخاص بي نفس قاعدة البيانات التي يستخدمها Discourse.
مشاركة تسجيل الدخول: يعني، سيكون رائعًا لو تمكّنت من استخدام نظام تسجيل الدخول في Discourse، وإعادة استخدام ملف تعريف الارتباط للجلسة (session cookie) لمصادقة المستخدمين في أماكن مختلفة داخل تطبيقي.
إضافة مجموعة من المسارات الجديدة إلى مكوناتي.
مكافأة: تخصيص معيّنات العرض (view helpers) في Discourse التي توجه المستخدمين المسجّلين إلى تلك المكونات الإضافية (ربما يمكنني فعل ذلك بالكامل عبر الإعدادات، لكنني أتساءل هل توجد معيّنات Rails قابلة للتجاوز يمكن استخدامها لتخصيص المعلومات على مستوى الموقع بأكمله)؟
رأيت المنشور حول استخدام HAProxy لوضع Discourse خلف وكيل وتوجيهه إلى مسار في نطاق معين. هذا ليس ما أريده لأنني أحببت تجنب تكرار إطار عمل Rails في تطبيق آخر (ولست متأكدًا من مدى سهولة إعادة استخدام جلسة المستخدم في تطبيق آخر). هل من الممكن استخدام Discourse كعنصر في تطبيق Rails أكبر؟
هذا رائع. يسعدني أن أعرف مسبقًا أن هذا ليس أمرًا موصى به، مما يوفر عليّ عناء المحاولة والفشل بشكل ذريع!
حسنًا، يبدو أن أفضل طريقة هي استخدام تطبيقين من ريلز (ديسكورش وتطبيقي المخصص) خلف وكيل عكسي.
بعد التفكير، يبدو أن الاحتفاظ بقاعدتي بيانات هنا هو الخيار الأفضل للتأكد من أن تطبيقي لا يقوم بتحديث قاعدة بيانات ديسكورش بطريقة غير مقصودة من قبل مطوري ديسكورش.
هممم، لست متشائمًا جدًا. يمكن أيضًا القول إن هذا قد يكون إضافة ضخمة جدًا.
إضافة Custom Wizard كبيرة لدرجة أنها تكاد تكون تطبيقًا منفصلًا (خاصة في الواجهة الأمامية).
هناك الكثير من العناصر العامة المفيدة المدمجة في Discourse يمكنك إعادة استخدامها، مثل إطار عمل حسابات المستخدمين ووظيفتها، وخط أنابيب النشر، وما إلى ذلك.
كما يمكنك تكييف العديد من حالات الاستخدام مع Discourse في الواجهة الأمامية. فالمنشورات هي صفحاتك وما إلى ذلك.
فوائد وجود تطبيق منفصل: يمكننا دعمك بشكل أفضل هنا، ولن تؤدي أي تحديثات تجريها منصة Discourse إلى تعطيل جانب التطبيق الخاص بك.
فوائد جعل الموقع “إضافة كبيرة لمنصة Discourse”: ستحصل على جميع الميزات والمساعدات المتاحة في Discourse (بما في ذلك كل أدوات إدارة المستخدمين)، وهو أمر لا يمكن الاستهانة به.
سيكون ذلك رائعًا اعتمادًا على ما تبنيه - أعتقد أن @justin يريد أن يحذرك من العبء المحتمل للصيانة الذي تتحمله. لا يمكننا دعمك بشكل كامل إذا كنت تبني مباشرة فوق Discourse، كما أن جميع أدواتنا الداخلية ومخططات البيانات الخاصة بنا خاضعة للتغيير (Subject To Change)، لذا فقد يكون الأمر أكثر متاعب مما يستحق. (بالطبع، يعتمد ذلك على ما تبنيه! فقد يكون الأمر يستحق المتاعب بسهولة أيضًا )
نعم، هذا صحيح جدًا. يتطلب الأمر خبرة لكتابة الإضافات التي تكون مرنة أمام التغييرات الأساسية. ستحتاج إلى تطوير بعض عناصر التطبيق لمواكبة التغييرات في Discourse. لكن يمكن تحقيق ذلك.
ألقِيتُ نظرةً عابرةً على الإضافات. أفضل استخدام إطار عمل JavaScript مختلف عن Ember (أنا معجب بـ Svelte)، وأقلق قليلاً من أن هذا قد يضيف طبقة أو واجهة إلى تطبيق Discourse المبنى على Rails (الذي لا أعرفه جيدًا) ويجعل استكشاف الأخطاء وإصلاحها أكثر تعقيدًا بالنسبة لي. أميل إلى الحفاظ على هذا كتطبيق منفصل. أعرف Rails جيدًا (وكذلك كيفية عمل وكيل لتطبيقات Rails)، لكنني لا أعرف Discourse بعد، وأشعر أن العقبات ستكون أقل إذا سرت في هذا المسار.
)