Next.js: 貧乏人のRESTAPIとしてファイルシステムを使用する

作成日 2016年11月10日  ·  3コメント  ·  ソース: vercel/next.js

SlackやさまざまなGitHubの問題で、ある種のバックエンドソリューションを求めている人がたくさんいます。 「データのフェッチは開発者次第」という

したがって、/ api / posts.jsonは、GETコレクションエンドポイントhttp://example.com/api/posts/を自動的に作成しますhttp://example.com/api/posts/123/またはhttp://の形式のGETエンドポイントとしても公開され

実装者側(つまり、 @ nkzawaとzeitチームの他のメンバー)の複雑さへの欲求に応じて、この基本的なREST APIは読み取り専用または書き込み可能のいずれかであり、最後のケースでは貧乏人のデータベースとして機能します。 これは恐らく恐ろしい制限(同時実行の問題?)に悩まされるでしょうが、それでも小規模な少量のサイトには使用可能であり、初心者にとっては貴重です。

これにより、next.jsは初心者向けのワンストップフルスタックwebdevソリューションになり、micro、express、koa / koa2、hapi、feathersJSのいずれかを使用して作成する方法を選択して学習する必要があるという認知的過負荷を排除できます。 APIを自分で(バックエンドにnode.jsを使用する場合)、またはRethinkDB + Horizo​​n、Firebase、Parse、Graph.coolなどのサービスとしてのバックエンドの使用方法を選択して学習します。 JSON RESTAPIまたはGraphQLAPI。 もちろん、これらのアプローチのいくつかは本番環境での展開に適していますが、ユーザーが組み込みのファイルベースのJSON REST APIを使い始めると、実際のサードパーティの自己構築APIに簡単に移行できるようになります。

たぶん、これはコンポーネントAPIに関する@rauchgの提案と調整することができます。詳細は#149です。

最も参考になるコメント

私はMeteorでかなり良い経験をしました。 フルスタックフレームワークは、長期的には機能しません。 私たちは難しい方法でそれを学びます。

これはプロトタイピング段階ではかなり良い解決策になるでしょうが、それがこのプロジェクトで行っていることではないことを願っています。
バックエンド/データはかなり複雑な仕事です。 他の何かにそれをさせることは常により良いです。

Nextの説明で述べたように、私たちの焦点はこれにあるべきだと思います。

サーバーでレンダリングされたReactアプリケーションの最小限のフレームワーク

全てのコメント3件

私はMeteorでかなり良い経験をしました。 フルスタックフレームワークは、長期的には機能しません。 私たちは難しい方法でそれを学びます。

これはプロトタイピング段階ではかなり良い解決策になるでしょうが、それがこのプロジェクトで行っていることではないことを願っています。
バックエンド/データはかなり複雑な仕事です。 他の何かにそれをさせることは常により良いです。

Nextの説明で述べたように、私たちの焦点はこれにあるべきだと思います。

サーバーでレンダリングされたReactアプリケーションの最小限のフレームワーク

私は反対意見を理解していますが、認知的過負荷が現実であり、多くの人々が選択によって麻痺しているという事実は残っています。 node.jsの初心者は、JSON RESTAPIを構築するための多数のオプションに戸惑います。 next.jsに最小限のものがあると、多くの初心者がすぐにnext.jsを新しい種類のフルスタックの1つとして使用できるようになります(最大の意味ではなく、バックエンドとフロントエンドの両方をサポートするという意味で)ユニバーサルReactwebdevツールECMAScript6を完全に採用します。

microは確かにmicroであることを忘れないでください。約100行のコードです。 最小限のRESTAPIの作成をサポートするために、microをnext.jsにマージまたは組み込むのは簡単です。

これは、next.jsがマイクロにはない神経を非常に明確に打ったことを考えると、特に魅力的です。 数字は嘘ではありません。リリースから2週間弱で、next.jsはGitHubで241の問題とプルリクエストを生成しました。 これらの数値をマイクロの数値と比較してください。ほぼ2年前に最初のコミットが作成されたプロジェクトについて、73の問題とプルリクエスト(現在開いているものはありません)。

現在、最小限のnode.jsWebフレームワークの世界には大きな空白があります。 Express、Koa、Koa2、Hapi、FeathersJSのいずれも、next.jsのように、ES6、React、ユニバーサルレンダリング、直感的なルーティングを採用していません。 Express開発が死んでいるように見えることは言うまでもなく、KoaはKoa 2への移行に悩まされており、コミットグラフを見ると、開発者のエネルギーをあまり生み出していないようです。 FeathersJSはExpressに関連付けられており、Koaへの移行でさえ、Koa自身の問題を継承することになります。 そのため、現在よりエンタープライズなWebアプリをターゲットにしているように見えるHapiが残り、私が見る限り、ユニバーサルReactやプレーンReactをサポートすることは言うまでもなく、ES6をまだ採用していません。

next.jsプロジェクトが本当に大きくなる機会があります。 私はすでに、Facebook独自のcreate-react-appに、開発者の魅力という点でそのお金のための実行を与えているのを見ています。

最後のポイントとして、Armin Ronacherがエイプリルフールのジョークとして彼の最小限のWebフレームワークであるFlaskをリリースしたときに、Pythonの世界で何が起こったのかを考えてみてください。 彼の考えでは、それは彼のWerkzeugサーバーを彼のテンプレート言語Jinja2と結婚させるいくつかのシンタックスシュガーにすぎませんでした。 幸いなことに、彼は、Flaskの即時の人気の中で、自分が何かに取り組んでいることを認識するのに十分な機敏性を備えていました。 その結果、(一見)どこからともなく、FlaskはすぐにPythonの世界でWeb開発者にとってDjangoの強力な2番目の選択肢になりました(そしてDjangoのようなモノリシックな統合された巨大なものを避けている多くの人にとって最初の選択肢になりました)。

ユーザーの話を聞いてください。 サーバーサイド機能を求める人はたくさんいます。このアイデアは、ファイルベースのJSON REST APIの組み込みサポートを含めるように簡単に拡張でき、PHPの見事な再利用という同じユーザーフレンドリーな精神を支持しています。 API。

@arunodaに完全に同意します。 Next.jsの最大の_機能_は、それが_バックエンドではない_ということです。 @getifyが_middle-end_と呼ぶものに近いです。 ユニバーサルレンダリングフロントエンド。

これと組み合わされた最良のアーキテクチャは、Next.jsがgetInitialPropsデータサービスを_queries_することです。 RESTマイクロサービス、API、GraphQLは、このアーキテクチャを補完するものです。

そうは言っても、ユーザーランドでこれを達成できるはずなので、#25を見てください。 ルートを自動的に登録し、初期化するカスタムサーバーに結合できます。

このページは役に立ちましたか?
0 / 5 - 0 評価