Comments 24
Хотелось найти просто комплексную CMS, написанную на javascript, использующую GraphQL и обеспечивающую сразу и бэк, и фронт. Но вот не нашел я такой.
Плохо искали :)
JS:https://github.com/search?l=JavaScript&o=desc&q=cms&s=stars&type=Repositories
TS:https://github.com/search?l=TypeScript&o=desc&q=cms&s=stars&type=Repositories
GraphQL: github.com/birkir/prime
Но лучше бэк и фронт делать разным людям, т.к. очень много нюансов что в Express что в React. Универсальную CMS сделать очень сложно, особенно ту, что не тормозит :)
Нет, искал я усиленно. Но не нашел. Дайте четкую ссылку на «просто комплексную CMS, написанную на javascript, использующую GraphQL и обеспечивающую сразу и бэк, и фронт». То, что видится по вашим ссылкам, это классические API-first CMS без готового фронта.
Не спорю, нюансов очень много. И именно поэтому и хотелось, чтобы бэк отвечал и за фронт, а фронт зависел от бэка. Не жестко, но хотя бы чтобы они друг друга понимали. Вот это я и пытаюсь обеспечить.
А на сколько тормозит или нет, можете посмотреть вживую: prisma-cms.com Конечно далеко от идеала, но вроде не особо тормознутое. А при навигации вглубь вроде вообще норм (когда уже в режиме SPA).
Но лучше бэк и фронт делать разным людям, т.к. очень много нюансов что в Express что в React. Универсальную CMS сделать очень сложно, особенно ту, что не тормозит :)
Не спорю, нюансов очень много. И именно поэтому и хотелось, чтобы бэк отвечал и за фронт, а фронт зависел от бэка. Не жестко, но хотя бы чтобы они друг друга понимали. Вот это я и пытаюсь обеспечить.
А на сколько тормозит или нет, можете посмотреть вживую: prisma-cms.com Конечно далеко от идеала, но вроде не особо тормознутое. А при навигации вглубь вроде вообще норм (когда уже в режиме SPA).
Дайте четкую ссылку на «просто комплексную CMS, написанную на javascript, использующую GraphQL и обеспечивающую сразу и бэк, и фронт».
github.com/search?l=JavaScript&q=wordpress&type=Repositories
Все уже написано, QL конечно нет :)
Нисколько не критикуя хотел бы заметить, что у вас много противоречий в постановке задачи. Современная разработка — это про узкую специализацию и старые подходы «все в одном» потихоньку уходят в прошлое. Соответственно, привлечь желающих к работе над ядром будет трудновато.
Wordpress разве был переписан на JS? *Риторический вопрос*. Я же говорил про JS. No php.
Согласен с вами. И именно поэтому проект — это не один комплексный репозиторий, а множество отдельных компонентов. Хотите просто API? Берите любые prisma-cms модули и используете их по отдельности или совместно в рамках единого проекта. Недостаточно этих модулей? Возьмите @prisma-cms/module-boilerplate за основу и напишите свой собственный серверный модуль, который будет работать с другими prisma-cms модулями. Вот вам собственное API.
Хотите сразу еще и фронт получить, возьмите готовую сборку сайта. Здесь уже собраны и сконфигурированы все необходимые модули и можно еще свои добавить.
Нужен для фронта собственный новый компонент? Вот тоже есть заготовка: github.com/prisma-cms/component-boilerplate. При чем при запуске она будет работать в dev-режиме в prisma-cms окружении. А продакт будет просто как компонент для prisma-сайта.
Конечно все это еще далеко от идеала, надо еще допиливать все и документацию писать. Но концепт такой.
Современная разработка — это про узкую специализацию и старые подходы «все в одном» потихоньку уходят в прошлое.
Согласен с вами. И именно поэтому проект — это не один комплексный репозиторий, а множество отдельных компонентов. Хотите просто API? Берите любые prisma-cms модули и используете их по отдельности или совместно в рамках единого проекта. Недостаточно этих модулей? Возьмите @prisma-cms/module-boilerplate за основу и напишите свой собственный серверный модуль, который будет работать с другими prisma-cms модулями. Вот вам собственное API.
Хотите сразу еще и фронт получить, возьмите готовую сборку сайта. Здесь уже собраны и сконфигурированы все необходимые модули и можно еще свои добавить.
Нужен для фронта собственный новый компонент? Вот тоже есть заготовка: github.com/prisma-cms/component-boilerplate. При чем при запуске она будет работать в dev-режиме в prisma-cms окружении. А продакт будет просто как компонент для prisma-сайта.
Конечно все это еще далеко от идеала, надо еще допиливать все и документацию писать. Но концепт такой.
Не легче было дописать плагин под существующие? Просто ещё один велосипед уйдёт в века, сколько таких было…
Еще раз: под какие существующие? Дайте ссылку на «комплексную CMS, написанную на javascript, использующую GraphQL и обеспечивающую сразу и бэк, и фронт».
Уже несколько раз просил это. Народ продолжает предлагать что-то, но не ясно что. Я так и не увидел то, что подходит под мои критерии, а они довольно четко поставлены.
Уже несколько раз просил это. Народ продолжает предлагать что-то, но не ясно что. Я так и не увидел то, что подходит под мои критерии, а они довольно четко поставлены.
К слову, почему же меня так сильно беспокоит чтобы фронт и бэк работали как-то совместно, хотя сейчас тренд все-таки разделять их. Как раз потому что, как вы и сказали, «очень много нюансов». И очень высокий темп разработки сейчас (постоянно новые версии компонентов появляются, фишки новые и т.д. и т.п.). Пересобирать проекты приходится чуть ли не каждый день (где-то баги новые, где-то фичи). И вот не хотелось бы, чтобы каждый пилил под себя фронт с нуля, а мог взять чужие готовые наработки и допиливать к ним что-то свое. А если бага в ядре где-то, то рапортавать и получать в дальнейшем обновления. И хочешь или нет, но все же фронт зависит от бэка в той или иной мере. Другой вопрос, когда это полезное взаимодействие, а когда это кандалы. Я стараюсь делать так, чтобы фронт обязательно работал именно на основе API, не зависел от серверного рендеринга и был свободен от собственных HTML-примесей (чтобы можно было без проблем свое собственное оформление прикручивать).
На примере того же хабра: здесь фронт годами не меняется. Причины понятные: работает — не лезь. И я не говорю сейчас за то, плохо он сделан или хорошо. Я сейчас только про концепцию. Вот у меня в параллельной вкладке был выведен список комментариев (в тот момент еще один на модерации). Я ответил в другой вкладке, а в первой после этого кликнул справа стрелочки «Обновить». Вот что получилось:
Уверен, бага известна и ей совсем не один день. Но у хабра фронт и бэк жестко связаны (php же, они не могут на гитхаб выложить фронт отдельно от бэка). И получается, что если сами не поправили, то никто другой не может поправить даже при желании. А так все кому не лень могли бы участвовать в улучшении хабра, да еще и при желании у себя блог качественный развернуть. Хабру-то все равно плохого ничего не было бы, база-то в собственности остается.
На примере того же хабра: здесь фронт годами не меняется. Причины понятные: работает — не лезь. И я не говорю сейчас за то, плохо он сделан или хорошо. Я сейчас только про концепцию. Вот у меня в параллельной вкладке был выведен список комментариев (в тот момент еще один на модерации). Я ответил в другой вкладке, а в первой после этого кликнул справа стрелочки «Обновить». Вот что получилось:
Задвоение контента
Уверен, бага известна и ей совсем не один день. Но у хабра фронт и бэк жестко связаны (php же, они не могут на гитхаб выложить фронт отдельно от бэка). И получается, что если сами не поправили, то никто другой не может поправить даже при желании. А так все кому не лень могли бы участвовать в улучшении хабра, да еще и при желании у себя блог качественный развернуть. Хабру-то все равно плохого ничего не было бы, база-то в собственности остается.
UFO just landed and posted this here
А почему вы хотите как раз совместной работы, если это создаёт только сложности?
Это не создает только сложности. У медали две стороны. Где-то сложности, а где-то автоматизация и т.п. Но проекты, которые дают только бэк без какой-либо хотя бы базовой реализации фронта — это тоже не круто и не очень подходит для реальных проектов. Я пытаюсь сделать так, чтобы был хоть какой-то фронт, работающий в связке с бэком, идущий из коробки. Но при этом фронт взаимодействует через API, а не имеет жесткой связки с бэком, и их можно использовать по отдельности, без всякой привязки друг к другу. По сути эту концепцию пытаются и вот эти ребята развивать: habr.com/ru/post/444330
И два года назад (и до этого еще 8 лет) я сидел на MODX CMF (под которую тоже много своих костылей изобрел). И вот три года мы затеяли один довольно масштабный проект, под который, как мне казалось, я смогу использовать MODX. Но как оказалось, не смог…
В итоге я решил, что надо искать что-то новое, более удобное, позволяющее как-то все это упростить. Еще раз уточню, что на тот момент я был php бэкэндщиком
А почему не попробовали решить эту же задачу на полноценном фреймворке, например Larave/Yii/Symfony и т.п.?
И вот каждый раз, когда под новую идею надо было добавить какую-то новую сущность, прописать/изменить поля для имеющихся, создать/удалить/изменить связи между этими сущностями (соответственно с изменением структуры базы данных), у меня в какой-то момент стало уходить по несколько часов на изменение этих сущностей. Ведь помимо того, что надо было прописать эти изменения в схеме, надо было изменить базу данных (практически вручную), актуализировать API, переписать программный код и т.д и т.п.
Доктрина без особых усилий умеет так делать — создаете сущности, меняете в процессе их связи, поля и т.п… А миграции генерируются на основе разницы между тем что в сущностях и тем что в базе быстро и безболезненно.
Опять же мне кажется немного странным — вроде по вашим словам больше 8 лет работы с пыхом и для решения более сложных задач логично было бы использовать инструменты опять же на пыхе, благо их сейчас на каждый случай куча написано. Почему именно переход на обертки над prisma, а не что-то на уже знакомом языке, как здесь например?
А почему не попробовали решить эту же задачу на полноценном фреймворке, например Larave/Yii/Symfony и т.п.?
Скорее всего причина в том, что сначала перемены коснулись фронта (внедрение реакта). В процессе весьма утомляла задача увязывать друг с другом два отдельных языка — js и php. Из-за этого никак не оставляло чувство отделенности фронта от бэка. С полным переходом на js эта грань практически стерлась и мне настолько все это понравилось, что я полностью отказался от php. Возвращаться больше не хочу к нему.
… Почему именно переход на обертки над prisma, а не что-то на уже знакомом языке, как здесь например?
Причина та же: полный переход на js и отказ от php.
В процессе весьма утомляла задача увязывать друг с другом два отдельных языка — js и php
Можно было бы их разделить — оставить на php только api, а фронтэнд сделать отдельным приложением.
При наличии отдельного фронтэндщика так даже будет проще. Ну и всякие тяжелые вычисления или просто тормозные куски можно переписать на Go например, а фронтэнд об этом и не узнает.
С другой стороны если пилить проект одному или это будет прототип то да, склеить кучку пакетов под типовую логику будет быстрее. Но значит и проект не особо большой раз его один человек тащит, в таком случае можно писать на чем угодно, лишь бы удобно было
Можно было бы их разделить — оставить на php только api, а фронтэнд сделать отдельным приложением.
Это и без меня много уже кто реализовал. А мне хотелось именно чтобы все в комплексе было. Лично меня не устраивает отдельно одно и другое. Опять-таки, я не говорю, что я изобрел что-то правильное и все должны делать так. Я говорю лишь о том, что я хочу именно так, говорю почему я так хочу и что у меня получилось.
С другой стороны если пилить проект одному или это будет прототип то да, склеить кучку пакетов под типовую логику будет быстрее. Но значит и проект не особо большой раз его один человек тащит, в таком случае можно писать на чем угодно, лишь бы удобно было
Так уже получилось, что да, в основном я работаю один. При этом проекты не простые. И если не касаться дизайна, то все остальное делаю я. И у меня была потребность вот в таком комплексном решении. Может еще какие одиночки есть, кому это может пригодиться.
тогда подкину идейку — приделайте еще и что-нибудь на facebook.github.io/react-native, тогда получится полный комплект — генерим бекэнд, фронтэнд и до кучи клиентов под мобилки. Получится реально полезно если кто-то один захочет по быстрому запилить прототип чего-то
У меня есть небольшой опыт с react-native (одно приложение для пропускной системы). Оно на более ранней версии этой платформы, но в принципе не особо сложно запилить ее. Но честно сказать, желания нет… Вероятно, под это можно было бы даже отдельную статью написать, как я запускал свое react-native приложение. Интересный эксперимент получился. Дев-версия велась на expo.io и в целом все ОК было. Но когда я собрал прод и залил на гуглоплей, тот мне такой «а версия API минимум 26 должна быть, так что не опубликую». И в проекте expo до сих пор куча тикетов на счет старой версии API. И даже на оффсайте у них тогда говорилось, что мол мы пока не можем и не очень-то хотим подтягиваться до актуальной версии API. Итог: у меня есть приложение, но я не могу его сдать клиенту.
Сейчас точно не скажу каким именно образом я его в итоге пересобрал (ибо приложение опубликовано 10.09.2018, подзабыл уже), но собирал я его родным Android Studio. Но там такой прикол был, что и студио не хотел просто так кушать этот проект, какие-то ему там зависимости не нравились, ибо устаревшие были. Вот и получалось: для студии expo устаревший, а для expo студия слишком новая. И получилось у меня два бранча: dev для разработки с expo (ибо с ней разработка удобней, hot reload, console debug и т.п.), и prod для сборки конечного приложения студией.
Но был и положительный момент от перехода на студию: приложение, собранное экспой, весило 30+ метров, но что самое неприятное: на старом телефоне с android 4.4 или 4.2 (LG P500) сильно все тормозило, вот прям ооочень. Собранное же на студии приложение весит 10 метров и даже на этом старом телефоне работает вообще без тормозов.
Но как я и сказал, двигаться в этом направлении нет желания. Слишком много танцев с бубнами. Я остановился на PWA, благо в react-scripts сейчас PWA из коробки идет.
Сейчас точно не скажу каким именно образом я его в итоге пересобрал (ибо приложение опубликовано 10.09.2018, подзабыл уже), но собирал я его родным Android Studio. Но там такой прикол был, что и студио не хотел просто так кушать этот проект, какие-то ему там зависимости не нравились, ибо устаревшие были. Вот и получалось: для студии expo устаревший, а для expo студия слишком новая. И получилось у меня два бранча: dev для разработки с expo (ибо с ней разработка удобней, hot reload, console debug и т.п.), и prod для сборки конечного приложения студией.
Но был и положительный момент от перехода на студию: приложение, собранное экспой, весило 30+ метров, но что самое неприятное: на старом телефоне с android 4.4 или 4.2 (LG P500) сильно все тормозило, вот прям ооочень. Собранное же на студии приложение весит 10 метров и даже на этом старом телефоне работает вообще без тормозов.
Но как я и сказал, двигаться в этом направлении нет желания. Слишком много танцев с бубнами. Я остановился на PWA, благо в react-scripts сейчас PWA из коробки идет.
Очень согласен с Вашим мнением, что именно в JavaScript (а не в PHP) происходит всё самое интересное для вэба, это другая вселенная, на совсем другом уровне. А у нас по-прежнему в wordpress копаются в массе своей.
и так же не мог найти готовое решение, движок, CMS для интернет-магазинов на JS для frontend и backend.
Так что тоже оставлю ссылочку на github — github.com/cezerin2
CMS для магазинов на React + MongoDB + NodeJS. Так называемое PWA приложение, api-центричное.
Готовое решение, в смысле всё в одном: backend (api) + frontend (магазин, SSR + React) + admin dashboard (админка на чистом клиентском react, без серверного кода).
А не как обычно, вот Вам api, а всё остальное — Ваше дело.
Зачем мне api, если мне нужен готовый магазин, с frontend'ом для посетителей, с админкой для управления магазином.
и так же не мог найти готовое решение, движок, CMS для интернет-магазинов на JS для frontend и backend.
Так что тоже оставлю ссылочку на github — github.com/cezerin2
CMS для магазинов на React + MongoDB + NodeJS. Так называемое PWA приложение, api-центричное.
Готовое решение, в смысле всё в одном: backend (api) + frontend (магазин, SSR + React) + admin dashboard (админка на чистом клиентском react, без серверного кода).
А не как обычно, вот Вам api, а всё остальное — Ваше дело.
Зачем мне api, если мне нужен готовый магазин, с frontend'ом для посетителей, с админкой для управления магазином.
Да, видел его, давно уже смотрел. К сожалению, он заточен именно под магазины. Нет, я не хочу сказать, что он плох, я хочу только сказать, что мне хотелось более универсальное решение. То есть, к примеру, я не могу на базе этого быстро запилить небольшую CRM, блог, или типа того.
Второй момент, почему я окончательно от него отказался: API не на GraphQL. Слишком многое в запросах вшито жестко.
Именно по этой причине я оттолкнулся от prisma.io, ибо есть возможность выбирать конечную базу данных (а можно и несколько), возможность клипать микросервисы (можно строить целые сети из призма-серверов, в которых на определенные запросы можно прописывать форвардинги запросов на другие призма-серверы) и т.д. и т.п. То есть там очень большой простор для творчества.
Второй момент, почему я окончательно от него отказался: API не на GraphQL. Слишком многое в запросах вшито жестко.
Именно по этой причине я оттолкнулся от prisma.io, ибо есть возможность выбирать конечную базу данных (а можно и несколько), возможность клипать микросервисы (можно строить целые сети из призма-серверов, в которых на определенные запросы можно прописывать форвардинги запросов на другие призма-серверы) и т.д. и т.п. То есть там очень большой простор для творчества.
Ну да, универсальность — это хорошо, но очень сложно.
Очень сложно будет допилить проект до рабочего решения, которое будет доступно простым пользователям, а-ля wordpress.
Но конечно всё очень круто выглядит.
Очень важно, imho, что б всё было «user friendly», так сказать.
Очень сложно будет допилить проект до рабочего решения, которое будет доступно простым пользователям, а-ля wordpress.
Но конечно всё очень круто выглядит.
Очень важно, imho, что б всё было «user friendly», так сказать.
Да, никто не говорил, что это будет просто :)
Но работа ведется давно, и есть определенные моменты, которые говорят, что скорее всего получится что-то вменяемое сделать. В следующей статье напишу подробную инструкцию по запуску сайта с нуля на базе prisma-cms. Там на самом деле особо сложного ничего нет. Будет что пощупать и уже более предметно решить на сколько это интересное или неинтересное решение.
Но работа ведется давно, и есть определенные моменты, которые говорят, что скорее всего получится что-то вменяемое сделать. В следующей статье напишу подробную инструкцию по запуску сайта с нуля на базе prisma-cms. Там на самом деле особо сложного ничего нет. Будет что пощупать и уже более предметно решить на сколько это интересное или неинтересное решение.
Кстати, вообще про CMS на базе JS вопросов довольно много и на тостере: www.google.ru/search?q=CMS+на+JS+site%3Atoster.ru
Но там я тоже за все это время так и не нашел четкого ответа. Один фиг все сводится к ответам типа «Возьмите это классное решение для бэка и вот это классное решение для фронта и напишите свой классный костыль для их совместной классной работы».
Но там я тоже за все это время так и не нашел четкого ответа. Один фиг все сводится к ответам типа «Возьмите это классное решение для бэка и вот это классное решение для фронта и напишите свой классный костыль для их совместной классной работы».
Да. Тоже не понимаю этого. Нет готовых решений.
А-ля wordpress целиком и полностью основанном на современной разработке, современных подходах, библиотеках и на современном JavaScript.
Но всё-таки этот момент приближается, я считаю.
Именно благодаря npm, готовым библиотекам, лёгкому встраиванию всего этого в свой проект.
Хорошо, что уже ушли от «велосипедов» и появляется какая-то стандартизация в том числе и на уровне frontend'a.
А-ля wordpress целиком и полностью основанном на современной разработке, современных подходах, библиотеках и на современном JavaScript.
Но всё-таки этот момент приближается, я считаю.
Именно благодаря npm, готовым библиотекам, лёгкому встраиванию всего этого в свой проект.
Хорошо, что уже ушли от «велосипедов» и появляется какая-то стандартизация в том числе и на уровне frontend'a.
Но стандарты еще только развиваются. И вряд ли они будут. Тем не менее да, унификация какая-то наблюдается. Но проблем еще куча. Могу перечислить некоторые, которые сейчас доставляют вполне определенные неудобства.
1. SSR. До сих пор стандарта нет даже близко.
2. Отложенная загрузка модулей. Вот появилось React. Lazy loading. Но:
а.
То есть в режиме SSR это не работает. Только может к концу года реализуют.
б. Вот так работать будет:
А вот так не будет:
Уточню вытекающую проблему: хромает динамика, не можете просто так в продакте подключить произвольный модуль, например, в цикле.
Можно заюзать webpack dynamic import, но:
а. Не сможете только модули-файлы проекта использовать, не сможете подключить динамически произвольный компонент из node_modules.
б. Функция экспериментальная и очень нестабильная в продакте. В деве у меня все модули подключались, а в проде только два из 10+ появилось в списке.
Все это ограничивает динамическое расширение конечного проекта. Пока что путь только один: переустановка модулей на сервере, пересборка и hot reload. То есть многого из того, что хотелось бы использовать и кажется вполне разумным, на самом деле на сегодня просто недоступно. Но по сравнению с двумя годами ранее ситуация действительно много лучше, а еще через два года скорее всего вообще все необходимое будет доступно.
1. SSR. До сих пор стандарта нет даже близко.
2. Отложенная загрузка модулей. Вот появилось React. Lazy loading. Но:
а.
Note:
React.lazy and Suspense is not yet available for server-side rendering. If you want to do code-splitting in a server rendered app, we recommend Loadable Components. It has a nice guide for bundle splitting with server-side rendering.
То есть в режиме SSR это не работает. Только может к концу года реализуют.
б. Вот так работать будет:
const OtherComponent = React.lazy(() => import('./OtherComponent'));А вот так не будет:
const path = './OtherComponent';
const OtherComponent = React.lazy(() => import(path));Уточню вытекающую проблему: хромает динамика, не можете просто так в продакте подключить произвольный модуль, например, в цикле.
Можно заюзать webpack dynamic import, но:
а. Не сможете только модули-файлы проекта использовать, не сможете подключить динамически произвольный компонент из node_modules.
б. Функция экспериментальная и очень нестабильная в продакте. В деве у меня все модули подключались, а в проде только два из 10+ появилось в списке.
Все это ограничивает динамическое расширение конечного проекта. Пока что путь только один: переустановка модулей на сервере, пересборка и hot reload. То есть многого из того, что хотелось бы использовать и кажется вполне разумным, на самом деле на сегодня просто недоступно. Но по сравнению с двумя годами ранее ситуация действительно много лучше, а еще через два года скорее всего вообще все необходимое будет доступно.
Прекрасная статья! Я сам был такой же. «Переписать!»… «Да там буквально ж не долго...» В итоге написал 2 CMS и бросил их. Потому что:
Дело было давно. В 2008 я соскочил с PHP на Python+Django. Стало гораздо легче. Но всё равно — нет идеала, и к сожалению, так будет всегда.
- Вы одиноки. Нет документации. Нет времени её писать. Вы пишете новый код.
- Сложно научить нового сотрудника, потому что нет документации. Код ждёт.
- Брать новые проекты сложно, потому как нет программистов, поскольку нет документации, из-за того, что вы пишите код.
Дело было давно. В 2008 я соскочил с PHP на Python+Django. Стало гораздо легче. Но всё равно — нет идеала, и к сожалению, так будет всегда.
Рад, что вам понравилась статья :)
Вообще о написании своей CMS я задумывался еще в 2007-ом, но в начале 2008-го познакомился с MODX и понял, что многое из того, что мне нужно, есть там. И сразу передумал писать. Но потом все то, что было написано выше… Но случай у меня чуть отличается от вашего, потому что есть свои проекты, которые я пишу на prisma-cms, поэтому даже если какое-то время не будут подключаться сторонние разработчики по причинам, справедливо описанным вами, я все равно ее буду развивать. А потом вполне возможно кто-то еще начнет подключаться.
Вообще о написании своей CMS я задумывался еще в 2007-ом, но в начале 2008-го познакомился с MODX и понял, что многое из того, что мне нужно, есть там. И сразу передумал писать. Но потом все то, что было написано выше… Но случай у меня чуть отличается от вашего, потому что есть свои проекты, которые я пишу на prisma-cms, поэтому даже если какое-то время не будут подключаться сторонние разработчики по причинам, справедливо описанным вами, я все равно ее буду развивать. А потом вполне возможно кто-то еще начнет подключаться.
Sign up to leave a comment.
Headless CMS. Почему я пишу свою