Prisma CMS

Headless CMS with front editor

Улучшил скрипты. Теперь downtime при деплое проекта составляет всего несколько секунд.
Сегодня опять перебои в работе были. Перенес окончательно prisma-cms.com в докер.
За счет отказа от промежуточных таблиц для связей.
К примеру, Есть Топик, и у него есть свойство КемНаписан (Пользователь). В классической реляционной модели мы в таблице Топика просто добавляли колонку типа user_id, которая ссылалась на таблицу Пользователя через его id. Попутно могли настроить первичные/вторичные ключи, чтобы обеспечить целостность данных.
В итоге у нас было по прежнему две таблицы (Топики и Пользователи). В свою очередь через эту связь мы могли получить Пользователя по Топику, и по Пользователю
получить все его Топики.

В ранних версиях призмы эта связь обеспечивалась не через колонку в Топике, а через промежуточную таблицу ПользовательТопик. Таким образом связь выглядела так: Пользователь - ПользовательТопик - Топик.
Это обеспечивало все варианты связей (один-к-одному, один-ко-многим и многие-ко-многим). Но, это все-таки лишняя таблица, с кучей соответствующих минусов (включая усложнение написания SQL-запросов, в том числе и потому что колонки в таких таблицах имели "интуитивнопонятные" названия типа A и B).
Вот так вот этот ад выглядел: http://joxi.ru/brReEnMhYJ1VkA
А это только часть таких таблиц: http://joxi.ru/a2XWaY6ID1dZWm (имена таблиц связей начинаются с подчеркивания).

Сейчас подобных таблиц осталось всего 13 штук.

В принципе, на сами GraphQL-запросы это почти не повлияло (в плане их написания). То есть если мы раньше писали запрос
query { users ( first: 3 ){ id username Resources ( first: 3 ){ id name } } }
то есть получали список пользователей и их публикации, то оно так и осталось. Просто под капотом на уровне самой призмы работа поменялась. Поэтому, если делать совсем не большой сервис, то это можно было и не брать во внимание. Но когда делаешь что-то побольше, да еще и начинаешь чистые SQL-запросы писать, то новая призма конечно же гораздо лучше себя показывает.

А за счет чего уменьшилось количество таблиц?

Roadmap

Сохранение частей шаблонов в отдельные сниппеты с дальнейшим использованием в других шаблонах
Redo/UndoNew 2019-04-15T01:32:29.530Z
Добавить ObjectView, чтобы можно было выбирать существующий запрос и выводить самостоятельные объекты, или вложенные с верхнего уровня
Редактор стилейProgress 2019-04-15T01:36:19.588Z
Integrate unsplash.comNew 2019-04-16T00:55:54.096Z
Интеграция с tilda.ccRejected 2019-04-16T05:30:52.759Z
Render PDF on pageNew 2019-04-16T10:52:08.275Z
Сейчас обновление компонентов и свойств корневого объекта выполняется напрямую в объект. А надо, чтобы через updateObject() клона объекта выполнялось.
Сейчас адреса отдельных роутеров прописываются непосредственно в них. Это очень неюзабельно, потому что при изменении свойства path и несовпадении его с адресом, компонент не рендерится (исчезает из виду). Надо просто скрыть из панели компоненты Route, а набивать их непосредственно в компоненте Switch.
Сейчас приходится указывать key, чтобы при поступлении новых данных шаблона происходила его перерисовка. Очевидно где-то неправильная логика в базовой реализации редактора.
Добавить ObjectImageCompleted 2019-04-20T13:39:19.971Z

Prisma CMS

Headless CMS with front editor

Улучшил скрипты. Теперь downtime при деплое проекта составляет всего несколько секунд.
Сегодня опять перебои в работе были. Перенес окончательно prisma-cms.com в докер.
За счет отказа от промежуточных таблиц для связей.
К примеру, Есть Топик, и у него есть свойство КемНаписан (Пользователь). В классической реляционной модели мы в таблице Топика просто добавляли колонку типа user_id, которая ссылалась на таблицу Пользователя через его id. Попутно могли настроить первичные/вторичные ключи, чтобы обеспечить целостность данных.
В итоге у нас было по прежнему две таблицы (Топики и Пользователи). В свою очередь через эту связь мы могли получить Пользователя по Топику, и по Пользователю
получить все его Топики.

В ранних версиях призмы эта связь обеспечивалась не через колонку в Топике, а через промежуточную таблицу ПользовательТопик. Таким образом связь выглядела так: Пользователь - ПользовательТопик - Топик.
Это обеспечивало все варианты связей (один-к-одному, один-ко-многим и многие-ко-многим). Но, это все-таки лишняя таблица, с кучей соответствующих минусов (включая усложнение написания SQL-запросов, в том числе и потому что колонки в таких таблицах имели "интуитивнопонятные" названия типа A и B).
Вот так вот этот ад выглядел: http://joxi.ru/brReEnMhYJ1VkA
А это только часть таких таблиц: http://joxi.ru/a2XWaY6ID1dZWm (имена таблиц связей начинаются с подчеркивания).

Сейчас подобных таблиц осталось всего 13 штук.

В принципе, на сами GraphQL-запросы это почти не повлияло (в плане их написания). То есть если мы раньше писали запрос
query { users ( first: 3 ){ id username Resources ( first: 3 ){ id name } } }
то есть получали список пользователей и их публикации, то оно так и осталось. Просто под капотом на уровне самой призмы работа поменялась. Поэтому, если делать совсем не большой сервис, то это можно было и не брать во внимание. Но когда делаешь что-то побольше, да еще и начинаешь чистые SQL-запросы писать, то новая призма конечно же гораздо лучше себя показывает.

А за счет чего уменьшилось количество таблиц?