Next.js: Используйте файловую систему как REST API для бедняков

Созданный на 10 нояб. 2016 · 3Комментарии · Источник: vercel/next.js

Я вижу, как многие люди в Slack и по разным вопросам на GitHub просят какое-то бэкэнд-решение. Хотя я могу посочувствовать заявлению @rauchg о том, что «выборка данных зависит от разработчика», наличие базового решения, которое быстро помогает новичкам начать работу с next.js, будет стоить золота. С помощью простого расширения замечательной идеи «файловая система как API» мы могли бы представить папку api /, содержащую файлы .json, которые затем автоматически открывались бы как JSON REST API.

Таким образом, /api/posts.json автоматически создаст конечную точку сбора GET http://example.com/api/posts/. В зависимости от того, содержит ли коллекция posts.json массив верхнего уровня или словарь, отдельные элементы коллекции также будут отображаться как конечные точки GET в форме http://example.com/api/posts/123/ или http: // example.com/api/posts/abc/.

В зависимости от аппетита к сложности со стороны разработчика (например, @nkzawa и остальная часть команды zeit) этот базовый REST API может быть либо только для чтения, либо с возможностью записи, выступая в последнем случае как база данных для бедняков. Это, вероятно, будет страдать от ужасных ограничений (проблемы параллелизма?), Но, тем не менее, будет полезно для небольших сайтов с небольшим объемом и будет полезно для новичков.

Это позволило бы next.js стать универсальным полнофункциональным веб-разработчиком для начинающих и избавиться от когнитивной перегрузки, связанной с необходимостью выбирать и изучать, как использовать один из micro, express, koa / koa2, hapi или перьев для создания API самостоятельно (при условии, что мы хотим использовать node.js для бэкэнда) или выбрать и изучить, как использовать некоторый Backend-as-a-Service, такой как RethinkDB + Horizon, Firebase, Parse, Graph.cool или какую-либо другую базу данных, предоставляющую JSON REST API или GraphQL API. Некоторые из этих подходов, конечно, будут гораздо лучшим выбором для производственных развертываний, но как только пользователи начнут работать со встроенным файловым JSON REST API, они легко смогут перейти на реальный сторонний пользовательский API.

Возможно, это можно согласовать с предложением @rauchg по компонентному API, подробно описанным здесь: # 149.

Источник

olifante

👎3 ❤1

Самый полезный комментарий

У меня довольно хороший опыт работы с Meteor. Фреймворки с полным стеком не будут работать в долгосрочной перспективе. Мы узнаем это на собственном горьком опыте.

Это будет неплохое решение для этапа прототипирования, но я надеюсь, что это не то, к чему мы стремимся в этом проекте.
Backend / data - довольно сложная работа. Всегда лучше позволить чему-то другому делать это.

Я думаю, что мы должны сосредоточиться на этом, как это упоминалось в описании Next.

Минималистичный фреймворк для серверных приложений React

arunoda 11 нояб. 2016

👍14 ❤3

Все 3 Комментарий

Я думаю, что мы должны сосредоточиться на этом, как это упоминалось в описании Next.

Минималистичный фреймворк для серверных приложений React

arunoda 11 нояб. 2016

👍14 ❤3

Я понимаю возражение, но факт остается фактом: когнитивная перегрузка - это реальность, и многие люди парализованы выбором. Новичков в node.js сбивает с толку множество вариантов создания JSON REST API. Наличие чего-то минимального в next.js позволило бы многим новичкам немедленно начать использовать next.js как один из нового поколения fullstack (в том смысле, что он поддерживает как бэкэнд, так и интерфейс, а не в максималистском смысле) универсальные инструменты веб-разработки React, которые полностью принять ECMAScript 6.

Не будем забывать, что микро - это действительно микро: около 100 строк кода. Было бы тривиально объединить или включить micro в next.js для поддержки создания минимального REST API.

Это особенно привлекательно, если учесть, что next.js явно задел нерв, которого нет у micro. Цифры не лгут: всего за две недели с момента выпуска next.js сгенерировал 241 ошибку и запрос на вытягивание на GitHub. Сравните эти цифры с микро: 73 проблемы и запросы на вытягивание (и ни один в настоящее время не открыт) для проекта, первая фиксация которого была создана почти два года назад.

В настоящее время существует огромный вакуум в мире минимальных веб-фреймворков node.js. Ни один из Express, Koa, Koa2, Hapi, FeathersJS не поддерживает ES6, React, универсальный рендеринг и интуитивно понятную маршрутизацию так, как это делает next.js. Не говоря уже о том, что разработка Express кажется мертвой, а Koa увяз в переходе на Koa 2 и, судя по графикам фиксации, не вызывает особой энергии у разработчиков. FeathersJS привязан к Express, и даже переход на Koa приведет только к унаследованию собственных проблем Koa. Остается Hapi, который в настоящее время, похоже, нацелен на большее количество корпоративных веб-приложений, и, насколько я мог видеть, до сих пор не принял ES6, не говоря уже о поддержке универсального React или даже простого React.

Есть шанс, что следующий проект next.js станет действительно большим. Я уже вижу, что это дает возможность использовать собственное приложение create-response-app от Facebook за свои деньги с точки зрения привлекательности для разработчиков.

В качестве последнего момента рассмотрим, что произошло в мире Python, когда Армин Ронахер выпустил Flask, свой минимальный веб-фреймворк, как апрельскую шутку. По его мнению, это было не более чем синтаксический сахар, соединяющий его сервер Werkzeug с его языком шаблонов Jinja2. К счастью, он был достаточно проворным, чтобы признать в немедленной популярности Flask, что он что-то понял. В результате, появившийся (казалось бы) из ниоткуда, Flask быстро стал сильным вторым выбором после Django для веб-разработчиков в мире Python (и первым выбором для многих, кто сторонится монолитных интегрированных гигантов, таких как Django).

Слушайте пользователей. Многие люди требуют серверной функциональности, идею, которую можно легко расширить, включив в нее встроенную поддержку файлового JSON REST API, поддерживающего тот же удобный для пользователя дух его блестящего переназначения лучшей идеи PHP: файловая система как API.

olifante 11 нояб. 2016

👍6

Я полностью согласен с @arunoda. Самая большая черта Next.js - это то, что он не является серверной частью. Это ближе к тому, что @getify называет _middle-end_. Универсальный интерфейс рендеринга.

Лучшая архитектура, которая сочетается с этим, - это службы данных Next.js _queries_ в getInitialProps . Микросервисы REST, API и GraphQL - отличные дополнения к этой архитектуре.

При этом, пожалуйста, посмотрите № 25, так как он должен позволить вам сделать это в пользовательской среде. Вы можете автоматически регистрировать маршруты и связывать их с настраиваемым сервером, который вы инициализируете.