Найти в Дзене
IT FROM BIT

Итак, я выбрал веб-фреймворк для следующего проекта

В новом проекте обязательно будет GraphQL API, какая-то простая авто-сгенерированная админка на первых порах, чтобы ручками в базу самому ничего не писать, и система авторизации и аутентификации. БД MongoDB, чтобы не морочиться с миграциями. Сначала изучил текущее состояние столь любимого Ruby on Rails. В целом, он развивается очень вдохновляющими темпами, особенно порадовала инициатива Webpacker — интеграция webpack 3+ в общий пайплайн работы со статикой. Потом посмотрел на ежегодные сравнения производительности, востребованности и пр. Node.js vs Rails 😔 Всё же скорость работы, адаптация, единая платформа для клиента и сервера и тот факт, что JS — это мой основной язык программирования, перевесили хипарскую атмосферу расслабленности и всевозможности Rails. Тем не менее, если мне однажды ещё раз придётся работать с проектом на этой платформе, я не буду ни секунды переживать.) Также в качестве дани уважения заглянул и к Meteor JS. В целом, ребята довольно близки к желаемому, там дейс

В новом проекте обязательно будет GraphQL API, какая-то простая авто-сгенерированная админка на первых порах, чтобы ручками в базу самому ничего не писать, и система авторизации и аутентификации. БД MongoDB, чтобы не морочиться с миграциями.

Сначала изучил текущее состояние столь любимого Ruby on Rails. В целом, он развивается очень вдохновляющими темпами, особенно порадовала инициатива Webpacker — интеграция webpack 3+ в общий пайплайн работы со статикой. Потом посмотрел на ежегодные сравнения производительности, востребованности и пр. Node.js vs Rails 😔 Всё же скорость работы, адаптация, единая платформа для клиента и сервера и тот факт, что JS — это мой основной язык программирования, перевесили хипарскую атмосферу расслабленности и всевозможности Rails. Тем не менее, если мне однажды ещё раз придётся работать с проектом на этой платформе, я не буду ни секунды переживать.)

-2

Также в качестве дани уважения заглянул и к Meteor JS. В целом, ребята довольно близки к желаемому, там действительно очень мощная система, упрощающая создание real-time приложений. Смущают только следующее пункты:

  • Весь real-time завязан на чтении лога операций из Mongo DB. Сложно сформулировать, почему меня это смущает. Вероятно, потому что это не то, для чего этот механизм придумывался.
  • Ребята планируют, но еще не до конца отказались от собственного пакетного менеджера Atmosphere.
  • Слабоватые пакеты для авто-генерации админки.
  • Базовые штуки типа пользователей и авторизации надо писать самому. Это несложно и не очень-то долго, но всё же.

-3

Раз уже вспомнили Meteor, то посмотрим и как там у дела у ближайшего конкурента в сфере real-time (всё становится лучше с real-time 😉) — Feathers JS. Да, это скорей просто фреймворк для создания API без админки и прочего, но зато модель организации real-time куда более правильная на мой взгляд и одновременно очень простая. Каждая сущность выражается в виде канала. Все изменения с сущностью транслируются real-time за счет подвешивания внутри библиотеки на изменения в этих каналах. Получается система, свободная от определённой БД. Есть минусы в основном связанные с масштабированием такого приложения. Это, к слову, всё же возможно, но скорей всего в реальном приложении надо будет разбивать пользователей на регионы.

Впрочем, я замечтался. Пока посмотреть в глаза своёму страху — погуглим "node js graphql admin framework".

-4

Количество разных проектов пугает. Один выглядит лучше другого. Но как-то же надо упорядочивать действительность? В качестве критериев выбрал достаточную зрелость проекта, звездочки на GitHub, количество Issue и PR там же, наличие жизни в блоге, ну и, конечно же, дополнительные фичи.

-5

Скорей всего я выберу Strapi. Уже год как я подписан на их рассылку, темпы развития проекта очень радуют:

  • Весьма симпатичная админка (react-based) с системой пользователей и разграничения прав. Её можно, конечно же, расширять самим. Эта админка, кстати, одна из основных selling points;
  • Создание типов объектов;
  • GraphQL API;
  • REST API (на всякий случай);
  • Куча других полезных штук типа CSRF, gzip и пр.

-6

Стоит упомянуть Loopback — настолько продвинутая платформа создания API, что IBM купил её, сделал крутую графическую админку с функциями деплоя на Bluemix (прокаченная PaaS от IBM) и микросервисами, и назвал API Connect. Я начинал один проект на этой платформе и очень порадовался CLI генерации схем сущностей, подключения к различным БД и довольно удобной разработческой админки API Browser. Ребята готовят loopback v4, где из коробки всё на TypeScript, будет поддержка GraphQL и прочее. Обязательно вернусь к нему через полгода-год.

Есть ещё пара интересных проектов, которые я особо не рассматривал в виду их молодости или смерти:

  • Crudl — очень похож на strapi по набору функций, админкой, но видно, что всё еще активно разрабатывается 1 версия.
  • RethinkDB + Horizon — это БД и JS фреймворк с админкой к этой БД. Очень похоже на MeteorJS, только "сделано правильно", т.к. БД изначально фокусируется на real-time. К сожалению, эти проекты перестали получать финансирование, сайт horizon лежит 😞, планы сообщества туманны.

Есть ещё огромная пачка платформ-сервисов, которые нельзя у себя хостить, но в остальном они подходят под требования. В целом, идея использования стороннего сервиса весьма приятна, т.к. тебе не нужен админ, не надо думать о масштабировании и отказоустойчивости. С другой стороны, если у тебя pet project и есть цель понять, как в целом устроено полноценное веб-приложение, то эти платформы не стоит использовать.

При рассмотрении этих платформ голова начинает конкретно пухнуть. Особенно ей плохо, когда начинаешь смотреть на платформы-монстры: Google Cloud, IBM Bluemix, Microsoft Azure, Amazon. Есть хоть один человек на свете, который познал всю мощь этих платформ и может сказать, что лучше?😵

Мне нравится Google Firebase — в нём есть почти всё (кроме GraphQL), но с тех пор, как проект купил Google всё предоставляется по подписке, у себя хостить нельзя. Очень крутая интеграция с другими сервисами Google. Но, честно говоря, я стал всё меньше понимать фокус проекта. Раньше это было real-time DB с админкой, теперь это ВСЁ (аналитика, чаты, куча разных типов хранилищ + типы хранилища от самого Google Cloud, performance monitoring, хостинг типа Amazon Lambda и пр.). В голове рисуется картинка, как Google аки Кракен затаскивает проект себе в пасть и проект становится вторым Кракеном.

Выглядит неплохо Scaphold — платформа, полностью построенная вокруг создания и работы с GraphQL API. В качестве БД — Amazon Aurora MySQL и S3. Только вот что-то страница сетевого статуса лежит 😮

С платформами в целом мне видится три проблемы:

  • Действительно большая путаница с назначением тех или иных сервисов.
  • Сложность расчета конечной стоимости проекта, когда он начнет получать какую-либо нагрузку.
  • Неясность с дата центрами. Все эти платформы западные и сомневаюсь, что хороший пинг до РФ в приоритете.

* * *

Для себя я провожу подобный обзор примерно один-два раза в год уже лет 10, когда впервые начал отвечать за полный цикл создания веб-приложений, которые должны действительно работать. Жалею, что раньше не записывал всё это в виде постов. Думаю, сегодняшний пост может стать началом хорошей традиции. 🙂

Конечно же, хотелось бы всё это обсудить с тобой, дорогой читатель. Пиши мне в Twitter или Facebook. В Дзене начнем общаться немного позже. 😉