Комментарии 37
Слушай, а ведь и правда это неплохая идея – отсоединить бэк от фронта. Один раз с бэком разобрались, а потом любой фронт можно к этому прикрутить.
я чет думал что последние лет..10 это норма отрасли
==
но вообще идея интересная, хотя мне как беку иногда диковато видеть системы которые проектировали фронтовики, без оглядки на типичные бэковские проблемы с хранением данных, масштабированием обработчиков данных и т.п.
Для маленьких систем которые сделал и забыл — это вполне себе такой подход
ну не 10 уж.. headless если не ошибаюсь в районе 2015 появилась и была не так уж продвинута тк были популярны симфони, зенд, вся эту хурма на php. Традиционно шлепали верстку и ее каждый раз интегрировали. Битриксы...
фронтовики нормально могут построить архитектуру и связи проекта, но вероятно это мне с кругозором так кажется тк я никогда не ограничивался фронтом и лез шире. В страппи можно и контроллеры переназначить, сервисы, роуты. Но я в этом не силен, каюсь)
этот подход для проверки гипотез и возможности не зарывать пару миллионов на старте, понять особенности и позже допустим отстроить проект на nest.
ну не 10 уж… headless если не ошибаюсь в районе 2015 появилась
это headless cms появились наверное
но я писал api которая работает на два фронта и как отдельное api я уже году в 2010м… а вообще помоему этот подход появился как только ajax завезли… т.е. в совсем дремучие времена
Битриксы...
сжечь и закопать :)) битрикс это как раз пример подхода из позапрошлой жизни где шаблоны и html вперемешку с кодом на беке
фронтовики нормально могут построить архитектуру и связи проекта
ааа… ммм… не буду спорить ;))) опыт показывает что фронтовики проект видят с точки зрения кнопочек и формочек для юзера, а не бизнеслогики и того как правильно данные должны лежать
у меня сейчас проект. где в таблице лежат внавалку json файлы с кусками реактовских параметров и какойто мешанине из классов и контролов… его проектировал фронтовик… он ориентируется на то что у него к заявке привязано 10 файлов и 5 кнопок… вот он генерит конфиг для отображения и кладет в базу, а потом тупо селектит… а теперь и у меня задача теперь взять это все и организовать автоматическую обработку этих данных… и что теперь? мне парсить json внутри БД выколупывать оттуда данные и кудато отпавлять? а что делать если таких записей будет 50млн штук?
у меня сейчас проект. где в таблице лежат внавалку json
оу, это как визуальный редактор, который складывает html в таблицу?))) и потихоньку забивает всю базу этим мусором?)
Брать постгрес, там жсон встроен как тип данных.
Ну и поговорить с фронтом...
А можно было взять одного фулстека который когда нет задач на бэкенд делает фронт и не пришлось бы городить огород.
AdonisJS - прям очень близок к Laravel и интеграция с InertiaJS вроде есть. Но я бы выбрал Nuxt скорей всего в вашем случае.
P.S. Бэкендер в диалогах подсадной, слишком адекватно и сдержанно отвечает)
Маленькая команда решила сэкономить на специализированных backend-разработчиках,
Вы не занимаетесь разработкой без бэкенда, вы занимаетесь разработкой бэка силами фронтов, сделав фронтов немножко fullstack-ами. Отказ от backend не увидел нигде.
Увидел варианты, как не нанимать бэкеров и готовить бэк самим)
Laravel + inertia. Вполне себе бэк.
Express + Nest. Тоже точно бэк.
Strapi - система с готовым бэком, который кастомим под свои задачи.
Бро, мы не решили сэкономить. Мы просто не можем себе этого позволить, мы фронтом занимаемся и не хотим сильно вникать в бэкенд. Для этого мы позже найдем спеца, как только будем готовы растить в команде бэк, когда будет плотный поток однотипных конвеерных проектов с прозрачной загрузкой.
А пока, мы про функционал который на рекативных фреймворках можно и самим закрывать)
Список крутой, это все бэк - но вникнуть легче всего фронтам в страпи. Без фанатизма и потраченных месяцев жизни, без переквалификации в фуллстеков.
Мир, дружба, жвачка!
А не рассматривали вариант использовать какой-нибудь Firebase, и просто поверх него фигачить фронты?
Во-вторых, пришлось настраивать окружение под PHP, устанавливать лишние расширения текстового редактора.
Вот это конечно очень весомая причина...
vscode этому не поддается - а переходить на php shorm фронтам - зачем?
Есть WebStorm. Vscode - какой-то хипстерский блокнот по сравнению со Штормами. Да вообще весь гуй на электроне - тормознутая до нельзя штука с кривыми хотекями.
гуй на электроне — тормознутая до нельзя штука с кривыми хотекями.
а для полноценной работы гуя на яве (коим и является вебшторм, да и вообще все джетовские ide)
нужно как минимум 16 гигабайт оперативки и диск ssd
у меня вон на ноуте 6 гигабайт памяти, если запустить три пайшарма, браузер с 20 вкладками, линукс сразу окукливается и oom начинает грохать процессы
по этому и возникают мысли юзать хипстерские блокноты, а то и вообще vim
===
вспоминаю времена VS.net (2001) и C#… комп на 800 целероне с 512 мегабайтами памяти, старый винт udma66 на 10гигабайт… и оно же почти летало…
ВебШторм становится всё хуже и хуже. Чем дальше версия, тем тормознее. Сейчас он при работе начинает выжирать 2-3 ядра полностью (200-300% загрузки системы), а работа в редакторе может отставать от индексации на 3-5 секунд.
Например, я меняю атрибут в ангуляровском компоненте, начинаю писать [someAttribute]="value". Шторм подсвечивает эту строку, и говорит, что "someAt is not allowed here. Ну то есть, для него в индексе пока не полное имя атрибута занесено. Иногда подсвечивает методы как несуществующие, хотя я только что его вставил в класс.
И по сравнению с ним VSCode просто летает. Но при этом, у VSCode немного хуже дела с подсказками, и нету нескольких нужных мне фич. Поэтому рабочие большие проекты у меня в шторме, мелкие пет-проекты в VSC.
А хоткеи настраиваются, если что. Для VSC есть набор хоткеев из jetbrains'овских IDE.
В приложениях на электроне alt всегда открывает меню. Я много гуглил, но не нашел как это выключить, думаю, это "гвоздями приколочено". Поэтому хоткеи не могут нормально работать.
Это на же винде? Я бы сказал, что в таком случае, это жетбрейновские IDE неправильно себя ведут, что позволяют использовать альт в комбинациях, ведь это ломает поведение на уровне ОС, но... Только что проверил - назначил открытие терминала в VSCode на alt+F. Меню "File" не открылось, хотя должно. Так что "хоткеи не могут нормально работать" не правда, как минимум для 11-й винды.
Можно посмотреть в сторону cockpit headless cms, несколько лет назад он мне показался более выгодным по сравнению со strapi
придется осваивать и использовать PHP, плюс придумывать решение по админке (из коробки ее нет).
А чем вот например такая админка не устроила ? На которую ссылка с доки.
https://nova.laravel.com/
Вы фуллстеки, а не "безбекеры", хотя, бесспорно, круче звучит (как бессерверные СУБД). Вордпрессники с купленными темами тоже фуллстеки, хотя по-вашему они скорее "бесфронтеры". Как только потребуется выйти за рамки CMS-конструкторов, cхоластика закончится.
К чему негатив, в моем понимании фуллстек - это крепкий миддл и во фронте, и в бэке. Мы не занимаемся отдельно бэкендом и не предоставляем по нему услуги, мы закрываем бэкенд с минимальным вовчелением в него, мы не пишем руками контроллеры и роуты. Все происходит на уровне интерфейса, создается структура и поддается доработке при необходимости. Методы перезаписываются.
Мы не хотим в фуллстеки, мера временная и позволяет закрывать среднего масштаба проекты. Дальше конечно мы прорастем полноценными бэками, но это планы
Всем привет. Хотел поделиться вот такой штуковиной keystonejs.com, как раз тот случай когда фронт может собрать бэк под свои задачи, в самое короткое время. Получить админку именно под свой проект, не привлекая бэкендера. Я выполнил несколько проектов на ней, мне зашло.
Тема не раскрыта. Хотя и очень интересная. Так как большому количеству проектов походит вариант глупого бэка, и оптимизации некоторых процессов в далёком будущем когда бизнес вырастет.
Дайте больше конкретики по strapi. Есть ли поддержка:
Авторизации/аутентификации
Разграничения доступа к данным, админу можно видеть данные всех клиентов, не админу только свои
Хранения схемы БД под git, а не только UI редактор
Миграций БД (захотели переименовать поле, или превратить айдишник из числа в строку)
Деплоя в Serverless
Сколько кода нужно писать? Как сложно добавить новую сущность или изменить старую (сколько кода и кликов мышкой)?
Спасибо за комментарий, доработал статью и обновил.
Действительно это отлично подходит для проверки гипотез, что бы не зарыть огромный бюджет в то, что возможно не зайдет пользователям.
В Strapi есть многопользовательский функционал из коробки. Можно регистрироваться, авторизовываться и получать JWT-токен. Так же можно управлять доступами к API, отдельными роутами, запрещать или разрешать определенные методы, допустим findOne.
Есть роли, так же из коробки, где мы можем обозначать права и возможности аккаунтов.
Базу можно хранить как SQLite, либо же подцепить PostgreSQL или другие базы данных и работать с env.
Миграции происходят автоматически, как только мы изменяем модель через UI, там же редактируем поля, типы и прочее.
В работе со Strapi написание кода минимальное, все решается путем взаимодействия с UI. Код придется писать там, где нужно кастомизировать логику, перезаписать, к примеру, контроллер или сервис.
Возможно я не совсем понимаю значение Serverless, мы деплоили на хостинги, vds на node.js окружении.
Написание кода - минимальное, все решается путем взаимодействия с UI. Код придется писать там, где нужно кастомизировать логику, перезаписать контроллер, сервис и т д.
Serverless, это когда на каждый запрос, создаётся выделяется сервер и запускается код, а вы платите за время работы этого кода. Если к бэку никто обращается вы не платите ничего, а если резкий наплыв пользователей, то оно само масштабируеься, а вы платите ту же цену за запрос. Готовность под Serverless, это быстрый холодный старт, и низкое время работы без кэшей. Примеры:
https://aws.amazon.com/ru/lambda/
https://selectel.ru/services/cloud/serverless/
https://azure.microsoft.com/ru-ru/products/functions/#overview
Как мы в команде пришли к low-code и закрываем задачи бэка силами фронта