Универсальный CRUD бекенд для фронтенда?

Question

[OnYourLips]

Для проекта знакомого человека нужен примитивный бекенд, CRUD на десяток ресурсов, авторизация и простая аутентификация. Основные сложности проекта будут на фронтенде.
Бекендщиков в команде нет, но есть хороший фронтендщик.

Какие инструменты могут выступить в роли бекенда для такого проекта?

Кто может дать фидбек по PostgREST, Firebase, Horizon REST API, Hasura GraphQL, Graphcool и аналогам? Что в мейнстриме?

Comments

[sim3x]

То что кажется примитивным со сторны фронта на беке может обслуживать много кода

Если там все действительно просто, то вам с головой хватит FIrebase
Но при миграции на свое решение вам будет больно

Все что вы будете хостить у себя - потребует бекендера и теряется весь смысл ограничений "готовыми простыми решениями"

[OnYourLips]

sim3x,

Все что вы будете хостить у себя - потребует бекендера и теряется весь смысл ограничений "готовыми простыми решениями"

почему потребуется?
Я, как бекендщик, не согласен.

[sim3x]

OnYourLips, кто будет настраивать, деплоить и следить за всем хозяйством?

[OnYourLips]

sim3x, бекендщики и фронтендщики в таких вещах разбираются одинаково (как правило плохо или удовлетворительно). Обычно такое делают админы/девопсы.

[sim3x]

OnYourLips,
Тогда для ваших фронтендщиков нет никакой проблемы накатать на коленке апи и установить постгрес и суть вопроса пропадает впринципе

[OnYourLips]

sim3x, И этот фронтенд будет такого же поганого качества, как и фронтенд, сделанный бекендщиком.

[OnYourLips]

sim3x, к тому же и стоимость выйдет значительно больше базового готового решения

[Mikhail Osher]

OnYourLips sim3x вижу возникла дискуссия по поводу кто может/должен деплоить, и могу сказать, что тут очень очень разные мнения у людей в целом.
Лично мне всегда казалось, что бэкендщик мид уровня просто обязательно должен уметь паковать/деплоить своё приложение. А-ля арендовать vps, зайти по ssh, настроить там что надо через всякие supervisor/ansible/pm2/capistrano/etc... Делать сложные scalable решения не обязательно, но как минимум базовый деплоймент чтобы умел.
Соответственно, для фронтэнд это будет уметь собрать своё статическое приложение и задеплоить его на сервер.
И бувально на той неделе на кухне спросил я порядка 5-6 коллег, что они думают по поводу "должен ли мид бэкенд уметь деплоить?", на что ребята свелись к мнению, что не должен.
На этом моменте я просто завис)

[Ivan Yakushenko]

Mikhail Osher, с какой радости? К примеру, я хочу просто писать код. Мне это нравится и иногда из этого получается что-то более менее адекватное. Сколько раз пытался разобраться во всех прелестях девопса - с матами и криками ломал клавиатуру (образно). Кучу раз натыкался на то, что лично для меня написать сервис/скрип/приложение гораздо проще, чем затем его задеплоить куда-то. Нашел для себя несколько шаблонных решений + есть под рукой несколько фрилансеров-админов. Сейчас появляется куча стэндалон решений, готовых сборок и пр., т.е. все, что бы отделить и разделить бэк, деплой, фронт на разные отрасли и в каждой отрасли появляется все больше решений. Серьезно, я как-то за пару часов написал нужный по заказу код, а потом почти целый день пытался его запустить на сервере, так не должно быть, в том плане, что какого хрена после написания рабочего кода я должен думать о том, что он где-то как-то должен запускаться, ровно так-же как фронтов не должно волновать, как будут обрабатываться их формы и бэков не должно волновать, как будут выглядеть на фронте их обработки.

[OnYourLips]

Mikhail Osher, профессионально не должен, для этого есть отдельная профессия - девопс инженер, на на каком-то базовом уровне (собрать приложение под продакшен, переместить его на другой компьютер и запустить) обязан.
Соответственно фронтендщик, о котором мы говорим, все это делать конечно же умеет.

Ivan Yakushenko, максимальной экспертизой о том, как собрать свое приложение, обладает разработчик. Девопс занимается уже автоматизацией этих действий.
От девопс-инженера не требуется знать тонкости стека разработки, а от разработчика не требуется знать инструменты автоматизации. Но сама культура девопса заставит их работать вместе в рамках своей компетенции.

[Mikhail Osher]

OnYourLips, я и говорю, что для хотя бы для себя любимого надо уметь это делать. Когда я начинал работать, слова "девопс" не было. Всё сами настраивали. А сейчас уже новомодные эти профессии появились, и люди даже не переживают, как их творение в прод уходит.

[OnYourLips]

Mikhail Osher, девопса не было, и автоматизацией занимались админы, а экспертизой по сборке обладали разработчики. Ничего не изменилось, просто слова "девопс" не существовало.

Answer 1

[Константин Китманов]

loopback делает отличные CRUD над любой общеупотребительной БД. Модели описываются просто, лаконично и гибко. Из коробки куча методов для поиска и фильтрации, плюс Swagger.

Answer 2

[lukoie]

1 strapi (node)
2 microwebber (lara)

Answer 3

[grinat]

Я как-то делал универсальное api https://github.com/grinat/faap которое покрывает crud. Генерить ничо не надо, все само, используется express + монга. В общем суть этой штуки, если нам нужен блог с записями и комментами, то отправляем запросы:
post /post создаем пост
get /post получаем посты, фильтрация, пагинация и проч идет в комплекте
post /comment создаем коммент
get /comment получаем их список. Вместо post/comment можно подставить любое название. То есть на фронте придумываем название коллекции и отправляем данные, они записываются в базу и доступен весь crud, есть авторизация(bearer token)/загрузка файлов/фльтры по полям/выборки от-до/сортировка/даже есть полнотекстовый поиск. Как побочный эффект всей это динамики, нет никакой валидации, но ее можно вручную прописывать. Сам использую в качестве мок сервера, демки продуктов на ней разворачивал, для пет проектов использую, но для прода не рекомендую, так как нет встроенной валидации, можно ручками ее писать, но тогда на мой взгляд вся суть этого приложения теряется. В репе есть примеры, доки в swagger/open-api и проч.

Comments

[OnYourLips]

Да, вы правильно поняли, что я хочу, вот только я хочу готовое решение с комьюнити.

[grinat]

OnYourLips, когда я искал, то их не было, либо аналоги jsonplaceholder(то есть надо генерить схемы) либо фреймворки.
Вообще для таких целей лучше и быстрее всего монга плюс koa/express, либо go плюс монга. Монга избавит от гемора с миграциями и требованиями описания схемы, koa/express очень простые и там не нужны модели/сервисы/репозитории и прочий хлам смысла в котором на простом бэке нет, в go потребуется модели описывать, а в целом все также как и в koa/express. Если у фронта нулевой опыт в бэке, то лучше go никто еще не придумал, он не даст выстрелит в ногу и там сложно ударится в абстракции, которые будут ясны только фронту и больше никому, он поощряет простоту, это идеальный язык для новичка, и там есть аналоги nodemon, например fresh(то есть hot reload к которому привыкли все фронты).

[OnYourLips]

grinat, у фронтендщика есть небольшой опыт в nodejs, но проблема не обучить, а не потратить лишнего времени.

Answer 4

[xppa]

Недавно наткнулся на библиотеку Python Eve
Для запуска необходимо совсем мало:

1. Указать строку подключения к БД: нативно MongoDB, можно использовать бесплатный экземпляр на cloud.mongodb.com с ограничением в 512 МБ, но также заявлено наличие адаптеров на другие базы
   
2. В файле конфигурации описать модели хранимых данных с помощью JSON Schema и указать другие необходимые параметры
   
3. Написать буквально 5 строк на Python для запуска сервера
   

В итоге получается максимально похоже на RESTful сервер. Примеры работы и вообще статья про использование тут
Авторизация тоже заявлена на официальном сайте, только подключить и настроить

Comments

[OnYourLips]

Спасибо, вот только выбор стал еще сложнее за счёт увеличения количества кандидатов :)

[xppa]

OnYourLips, плюсом этого кандидата будет то, что его можно поднять очень быстро и без затрат и попробовать\посмотреть :)

Answer 5

[Niki-tos]

Из быстроразвертываемых graphql CRUD оболочек (Prisma/Graphcool, Postgraphile, Hasura и самописные ) мне лично понравилась Hasura, сейчас ввожу в продакшн.

Comments

[OnYourLips]

Из graphql тоже в её сторону смотрел, как на самый популярный вариант. А если нужно ввести какой-то свой обработчик? Меня смущает крайне хипстерский выбор стека технологий.

[Niki-tos]

Никто не мешает поднять рядом express со своими обработчиками и бизнес логикой. 3 года graphql в продакшене, полет отличный, и всегда можно откатиться на REST.

Answer 6

[Mikhail Osher]

https://api-platform.com/ - CRUD, REST/GraphQL, Authorization, Customizable AF, Built on top of Symfony

Answer 7

[Дмитрий Быкадоров]

Я пользовался https://www.dreamfactory.com/ на нескольких небольших проектах. Умеет делать CRUD по популярным СУБД, можно делать ресурсы на внешние API, писать скрипты (в том числе и на JS). Есть как сервис, но можно поставить и к себе на сервер.