Next.js: استخدام نظام الملفات مثل REST API للرجل الفقير

لدي تجربة جيدة مع Meteor. لن تعمل أطر المكدس الكاملة على المدى الطويل. نحن نتعلمها بالطريقة الصعبة.

سيكون حلاً جيدًا لمرحلة النماذج الأولية ، لكنني آمل ألا يكون هذا ما نذهب إليه في هذا المشروع.
الخلفية / البيانات مهمة معقدة للغاية. من الأفضل دائمًا السماح لشيء آخر بفعل ذلك.

أعتقد أن تركيزنا يجب أن يكون على هذا النحو المذكور في وصف التالي.

إطار أضيق الحدود لتطبيقات React التي يقدمها الخادم

أفهم الاعتراض ، لكن الحقيقة تبقى أن الحمل المعرفي هو حقيقة واقعة ، ويصاب كثير من الناس بالشلل بسبب الاختيار. يشعر القادمون الجدد إلى node.js بالحيرة من كثرة الخيارات لبناء واجهة برمجة تطبيقات JSON REST. إن الحصول على شيء بسيط في next.js سيسمح للكثير من المبتدئين بالبدء فورًا في استخدام next.js كواحد من سلالة جديدة من الحزم الكاملة (بمعنى أنه يدعم كلاً من الواجهة الخلفية والواجهة الأمامية ، وليس بالمعنى الأقصى) أدوات React webdev العالمية التي احتضان ECMAScript 6.

دعونا لا ننسى أن الميكرو هو بالفعل ميكرو: حوالي 100 سطر من التعليمات البرمجية. سيكون من السهل دمج أو دمج micro في next.js من أجل دعم إنشاء الحد الأدنى من واجهة برمجة تطبيقات REST.

يكون هذا جذابًا بشكل خاص عندما تفكر في أن next.js قد أصاب بوضوح شديد عصبًا لم يفعله الميكرو. الأرقام لا تكذب: في غضون ما يزيد قليلاً عن أسبوعين منذ إصداره ، أنتج next.js 241 مشكلة وسحب الطلبات على GitHub. قارن هذه الأرقام بالميكرو: 73 إصدارًا وطلبات سحب (ولم يتم فتح أي منها حاليًا) ، لمشروع تم إنشاء التزامه الأول منذ ما يقرب من عامين.

يوجد حاليًا فراغ كبير في عالم الحد الأدنى من أطر عمل الويب node.js. لا تتضمن أي من Express و Koa و Koa2 و Hapi و FeathersJS ES6 و React والعرض الشامل والتوجيه البديهي بالطريقة التالية. كي لا نقول شيئًا عن حقيقة أن تطوير Express يبدو أنه قد مات ، وأن Koa غارق في الانتقال إلى Koa 2 ولا يبدو أنه يولد الكثير من طاقة المطور ، بالنظر إلى الرسوم البيانية للالتزام. يرتبط FeathersJS بـ Express ، وحتى الانتقال إلى Koa لن يؤدي إلا إلى وراثة مشاكل Koa الخاصة. هذا يترك Hapi ، الذي يبدو حاليًا أنه يستهدف المزيد من تطبيقات الويب الريادية ، وبقدر ما أستطيع أن أرى أنه لا يزال لم يتبنى ES6 ، ناهيك عن دعم React العالمي أو حتى React العادي.

هناك فرصة سانحة لأن يصبح مشروع next.js كبيرًا حقًا. لقد رأيت بالفعل أنه يمنح تطبيق الإنشاء والتفاعل الخاص بـ Facebook فرصة للحصول على أموال من حيث جاذبية المطور.

كنقطة أخيرة ، ضع في اعتبارك ما حدث في عالم Python عندما أصدر Armin Ronacher Flask ، وهو الحد الأدنى من إطار الويب الخاص به باعتباره مزحة خادعة في أبريل. في عقله ، كان الأمر أكثر بقليل من بعض السكر النحوي الذي يتزوج خادم Werkzeug مع لغته النموذجية Jinja2. لحسن الحظ ، كان رشيقًا بما يكفي ليدرك في شعبية Flask الفورية أنه كان على وشك تحقيق شيء ما. والنتيجة هي أنه (على ما يبدو) من العدم ، أصبح Flask سريعًا خيارًا ثانيًا قويًا لـ Django لتطوير الويب في عالم Python (وهو الخيار الأول للعديد من الذين يتجنبون العملاقة المتكاملة المتجانسة مثل Django).

استمع إلى المستخدمين. هناك العديد من الأشخاص الذين يطالبون بوظائف جانب الخادم ، وهي فكرة يمكن توسيعها بسهولة لتشمل دعمًا مدمجًا لواجهة برمجة تطبيقات JSON REST القائمة على الملفات والتي تتبنى نفس الروح السهلة الاستخدام لإعادة التخصيص الرائع لأفضل فكرة PHP: نظام الملفات باعتباره API.

أتفق تمامًا معarunoda. الميزة الأكبر لـ Next.js هي أنها ليست خلفية. إنه أقرب إلى ما يسميه getify بـ _middle-end_. واجهة عرض عالمية.

أفضل بنية مقترنة بهذا هي خدمات بيانات Next.js _queries_ في getInitialProps . تعد خدمات REST الصغيرة وواجهات برمجة التطبيقات و GraphQL مكملات رائعة لهذه البنية.

هذا قيل ، يرجى مشاهدة # 25 لأنه يجب أن يسمح لك بإنجاز هذا في أرض المستخدم. يمكنك تسجيل المسارات تلقائيًا وإقرانها بالخادم المخصص الذي تقوم بتهيئته.