Next.js: 使用文件系统作为穷人的 REST API

我对 Meteor 有很好的体验。 从长远来看，全栈框架是行不通的。 我们通过艰难的方式学习它。

这将是原型阶段的一个很好的解决方案，但我希望这不是我们这个项目的目的。
后端/数据是一项非常复杂的工作。 让其他人这样做总是更好。

我认为我们的重点应该是在 Next 的描述中提到的。

服务器渲染的 React 应用程序的简约框架

我理解反对意见，但事实仍然是认知超负荷是现实，许多人因选择而瘫痪。 node.js 的新手对构建 JSON REST API 的众多选项感到困惑。 在 next.js 中拥有一些最小的东西将允许许多初学者立即开始使用 next.js 作为一种新的全栈（从它支持后端和前端的意义上说，而不是在最大化的意义上）通用的 React webdev 工具完全拥抱 ECMAScript 6。

我们不要忘记，micro 确实是 micro：大约 100 行代码。 将 micro 合并或合并到 next.js 以支持创建最小的 REST API 将是微不足道的。

当您考虑到 next.js 非常明显地触动了 micro 所没有的神经时，这尤其吸引人。 数字不会说谎：在发布后的两周多时间里，next.js 在 GitHub 上产生了 241 个问题和拉取请求。 将这些数字与 micro：73 个问题和拉取请求（目前没有打开），对于一个大约两年前创建第一次提交的项目。

目前在最小的 node.js Web 框架的世界中存在着巨大的真空。 Express、Koa、Koa2、Hapi、FeathersJS 都没有像 next.js 那样包含 ES6、React、通用渲染和直观路由。 更不用说 Express 开发似乎已经死了，Koa 陷入了向 Koa 2 过渡的泥潭，似乎没有产生太多开发人员的精力，看看它的提交图。 FeathersJS 是和 Express 绑定的，即使迁移到 Koa 也只会导致继承 Koa 自身的问题。 剩下的 Hapi，目前似乎面向更多企业级 Web 应用程序，据我所知，它还没有接受 ES6，更不用说支持通用 React 甚至普通 React 了。

next.js 项目有机会变得非常大。 我已经看到它在开发者吸引力方面让 Facebook 自己的 create-react-app 竞争。

最后一点，考虑一下当 Armin Ronacher 发布 Flask 时 Python 世界发生的事情，Flask 是他的最小 Web 框架作为一个愚人节玩笑。 在他看来，这只不过是将他的 Werkzeug 服务器与他的模板语言 Jinja2 结合起来的一些语法糖。 幸运的是，他足够敏捷，能够从 Flask 的迅速流行中认出他正在做某事。 结果是，Flask 突然（似乎）突然出现，很快成为 Python 世界中 Web 开发者 Django 的第二选择（并且是许多避开像 Django 这样的整体集成庞然大物的人的首选）。

听听用户的意见。 有很多人要求服务器端功能，这个想法可以很容易地扩展到包括对基于文件的 JSON REST API 的内置支持，它支持相同的用户友好的精神，即其对 PHP 最佳想法的辉煌再利用：文件系统作为应用程序接口。

我完全同意@arunoda。 Next.js 最大的_特性_是它_不是后端_。 它更接近@getify所谓的 _middle-end_。 通用渲染前端。

与此结合的最佳架构是getInitialProps中的 Next.js _queries_ 数据服务。 REST 微服务、API 和 GraphQL 是对这种架构的很好的补充。

这就是说，请注意 #25，因为它应该允许您在用户空间中完成此操作。 您可以自动注册路由并将它们耦合到您初始化的自定义服务器。