1) خلال السنوات الأربع إلى الخمس الماضية جربت العديد من بنى تطبيقات سولانا، وفكرت أنه حان الوقت لكتابة النتائج. تبدأ بأقل تعقيدا وتضيف تعقيدا متزايدا تدريجيا. ها هي: بنية تطبيقات سولانا، موضوع نقاشي.

2) لنبدأ بالوضع السهل. ربما هذا هو شكل أول تطبيق لك من سولانا. واجهة أمامية بسيطة للتفاعل تؤسس اتصالا مع RPC. لا حاجة لخادم API. RPC هو خادمك. في الأيام الأولى، كانت هذه المقالات مليئة بمعلومات الحساب، ومنطق البناء المخصص للتحويلات، وغيرها. لاحقا، عندما يتأثر الأداء، تضيف طبقات من التخزين المؤقت والدفعات. هنا يأتي دور getMultipleAccounts. ربما تضيف أيضا اشتراكات websocket + polling لتحديث واجهة المستخدم بشكل مباشر. هذه البنية تجعل النماذج الأولية سريعة للغاية. لا يوجد تقريبا أي ديفاتورز. تكاليف الخادم ضئيلة (فقط نشر على Vercel، إلخ). لكن فيه بعض العيوب الكبيرة.

3) أول مشكلة تواجه هي الاستعلامات المعقدة. في هذه البنية، كل ما لديك هو RPC سولانا الأصلي. هذا يعني أنك بحاجة إلى التعامل مع سولانا كما يعرضها RPC — كقاعدة بيانات NoSQL تعاني من مشكلة في الموقف. الاستعلامات النقاطية ليست مشكلة. يمكنك حتى أن تكون مبدعا جدا باستخدام أجهزة المساعد الرقمي الشخصي لتمرير بيانات برنامجك كما لو كانت قاعدة بيانات بيانية. لكن بمجرد أن تحتاج إلى إجراء أول معدل تراكمي لك، ستواجه ألم بأقصى حد. الواجهة ليست مريحة على الإطلاق. إذا كان لديك أي نوع من البيانات ذات الطول الديناميكي، فلا يمكن استخدامها على الإطلاق. اعتمادا على مزود RPC الخاص بك، قد يكون بطيئا بشكل لا يصدق. حتى بدون GPAs، هذا النهج عادة أبطأ بكثير من تطبيق الويب 2 التقليدي الذي يحتوي على عرض على جانب الخادم وقاعدة بيانات عادية.

4) المشكلة الثانية التي واجهتها هي قابلية نقل منطق بناء المعاملات. مع هذا الإعداد، كل منطق بناء المعاملات إما (أ) في كود الواجهة الأمامية أو (ب) في المكتبات التي يستوردها الكود. في حالة (أ)، أي شخص يريد بناء معاملات خارج واجهتك المائية سيواجه أقصى المشاكل (وهذا يشملك، عندما تحتاج حتما إلى المزيد من التطبيقات). في حالة (ب) أي تغييرات في منطق بناء المعاملات تتطلب نشر مكتبة، وتحديث الجميع لحزما، ثم تحديثات واجهة المستخدم. الاعتماد بشكل كبير على أدوات Anchor مثل حل الحسابات يمكن أن يقلل من كمية المنطق التي تحتاج إلى نقل — لكن المشكلة لا تزال قائمة. هذا يسلبك المرونة، ويجعل من الصعب تغيير نقاط نهاية العقود الذكية مع ضمان استمرار جميع إصدارات منطق بناء الإرسال الخاص بك.

5) المشكلة الثالثة التي تواجهها هي أن واجهات المستخدم عادة ما تكون سيئة في تقديم المعاملات، خاصة مع منطق إعادة المحاولة. يمكن للمستخدم التنقل بعيدا عن الصفحة، أما تكساس فتتوقف عن إعادة المحاولة. تميل المعاملات الكبيرة إلى صعوبة في الحصول عليها. من الصعب تصحيح الأخطاء من بعيد لماذا لا تهبط الأحداث.

6) المشكلة الأخيرة هنا أنك لست الوحيد الذي يمتلك هذه البنية. ال RPC ثمين، ويجب عليك ببساطة عرض رابط RPC الخاص بك في الواجهة الأمامية. الآن، ستدخل في لعبة قط وفأر لتتأكد من أن لا أحد يسرق RPC الخاص بك ويرفع تكاليفك.

7) فما التالي؟ عادة حتى لو لم تكن تعالج قابلية نقل الرسائل، ستحتاج إلى معالجة استفسارات القوائم. GPA سيء، ونحن جميعا نعلم ذلك. لذا يمكنك بناء هندسة هجينة. في هذه البنية، تحتفظ بالقدرة على النموذج الأولي بسرعة، لكنك تدفع الاستعلامات الصعبة إلى واجهة برمجة التطبيقات (API). مثال ملموس وجميل على ذلك هو الحوكمة — حيث يتم إنشاء مقترحات تحمل مجموعة من العلامات ("اقتصادي"، "تقني"، إلخ). GPA لا يمكنه التصفية حسب الوسم.

8) هذه البنية لم تحل مشكلة قابلية نقل المعاملات، أو قيام الناس بسحب RPC الخاص بك. لكن على نطاق واسع، يمكنك على الأقل حل مشكلة معدل GPA البطيء/المستحيل. هذا يطرح مشكلة جديدة — الفهارسات. المزيد عن هذا لاحقا.

9) أخيرا، لديك ما أسميه "كومة سولانا المؤسسية". لم تعد تعامل سولانا كقاعدة بيانات NoSQL. بدلا من ذلك، أنت تعامل الأمر كحافلة فعاليات. الواجهة الأمامية لا تعرف شيئا عن نموذج بيانات سولانا. يقوم الخادم ببناء المعاملات ويمررها إلى واجهة المستخدم للتوقيع، ثم يرسلها إلى سولانا نفسها. يتعامل مع هذا كحدث وينتظر أن ينتشر إلى المفهرسين الذين سيغيرون البيانات الأساسية. هذا الإعداد يتمتع بقابلية نقل المعاملات بشكل ممتاز - يمكن لأي شخص الوصول إلى واجهة برمجة التطبيقات الخاصة بك بمعايير نظيفة واستعادة المعاملات/التعليمات. هذا يجعل واجهة المستخدم سريعة للغاية — من حيث واجهة المستخدم، فهي في الأساس web2. يمكنك الاستفادة الكاملة من SSR. RPC مجرد - لا أحد يستطيع سرقة اعتماداتك. لكن هذا الإعداد له مشاكله

10) أول مشكلة ستواجهها هي ألم مؤشر الدرس. على الرغم من أن هذا تم التخفيف في السنوات القليلة الماضية (بفضل فرق Triton وHelius وStreamingFast)، إلا أنني ما زلت أتغلب على مؤشر المؤشر بانتظام بمفتاح ربط. ستفوت الرسائل. عندما تفوت رسالة، تصبح واجهة المستخدم في حالة غريبة (مثال: أرسلت لك NFT، وعلى السلسلة استلمتها، وقاعدة بياناتي تقول إنني ما زلت أملكها). هذه الأنواع من المشاكل مزعجة جدا عند التصحيح. هل هو خطأك؟ هل هو مزود بياناتك؟ من يعرف! ها قد ضاعت فترة بعد الظهر.

11) المشكلة التالية التي ستواجهها هي التوقيت. عندما تستخدم RPC مباشرة لكل شيء، يسمحون لك بتمرير الالتزامات والتعامل مع أحدث البيانات. مع المؤشر، كل هذا يدوي. هذا يعني أنه عند بناء المعاملات، قد تكون تبنيها بناء على بيانات قديمة. تعيد معاملة محكوم عليها بالفشل. يمكنك حل مشكلة البيانات القديمة باستخدام مزودي البيانات الذين يعطونك بيانات سريعة جدا (مثل تدفق ليزر هيليوس). لكن بعد ذلك عليك التعامل يدويا مع إعادة التنظيم. أي أن البيانات التي تفهرسها يجب أن تكون غير مفهرسة إذا لم يتم تمرير ذلك الإرسال فعليا. هذا كابوس.

12) يمكنك "اختراق" مشاكل التوقيت من خلال بناء معاملات فقط باستخدام بيانات من RPC، واستخدام بياناتك المفهرسة فقط لتغذية واجهة المستخدم. لكن مع ذلك، سيظل المستخدمون يواجهون مشاكل مع وجود تناقضات محتملة بين واجهة المستخدم والسلسلة. أي الواجهة الأمامية تقول إنني أملك هذا الNFT ويمكنني نقله، ثم يصرخ الواجهة الخلفية في وجهي ويقول لا أستطيع.

13) المشكلة الأخيرة التي تواجهها في هذا الإعداد هي التكلفة، وإذا كنا نتحدث عن دراما ميلودرامية "موت اللامركزية". حلم الويب 3 كان ألا أضطر لنشر الكثير من الخوادم المركزية. الآن لقد نشرت ما يكفي من البنية التحتية لتحصل على وظيفة مهندس رئيسي في ورشة ويب 2. يكلف مالا. هذا يكلف وقتا. وكل شيء مركزي جدا. ما مدى اللامركزية في بروتوكلك إذا كانت أفضل طريقة للتفاعل معه هي عبر واجهة برمجة تطبيقات ويب 2؟ وهناك حوالي 72 مطورا على سولانا يعرفون كيف يتفاعلون معه بدون تلك الواجهة.

14) في النهاية، لن أموت على أي تلال حول اللامركزية. ما هو الأفضل للمستخدمين غالبا ما يكون الخيار الأفضل. الإعداد "المؤسسي" يؤدي إلى تطبيقات ويب سريعة وحديثة وفصل واضح للمخاوف. من الجانب السلبي، فهي تضيف تكلفة ديفوب وتجعلك أقل مرونة. أنصح معظم الشركات الناشئة بالبدء بطريقة الإرسال المباشر إلى RPC إلا إذا كنت تبني شيئا يحتاج صراحة إلى أن يكون سريعا أو يحتوي على دلالات استعلام معقدة. الوقت المناسب للوصول إلى السوق. يمكنك دائما توظيف مهندس متوسط المستوى لاحقا ووضعه في زنزانة الفهرسة.

15) فين. إذا وجد أي منكم إعدادا أفضل، أخبرون. كل هذه هي الأشياء التي جربتها. أنا أستمتع كثيرا بتجربة إعداد المؤسسات مؤخرا.