Наверняка многие слышали понятие MVP (Минимально жизнеспособный продукт вики). На хабре тоже много статей про MVP, но в основном это или просто описание что такое MVP и для чего оно, или различные success и не очень story. Но я не нашел ни одной статьи, где бы описывалось на чем кто свое это MVP делал. Но ведь считается, что блоги личные проще делать на одном движке, интернет-магазины на другом и т.п. (каждый подставит свое название любимого движка для этих целей). Но почему тогда не определен более удобный движок для MVP? Я не дам четкого ответа на этот вопрос, но поделюсь своими мыслями чем именно для создания MVP хороша моя Prisma CMS, о которой я писал здесь пару месяцев назад. Кому интересно, прошу под кат.

Что интересно, по большому счету MVP можно сравнить с более продвинутым прототипированием вики. При этом для прототипирования есть специальное ПО, и я когда-то давно даже пользовался тем же самым Axure. Но чего мне не хватило в Axure и из-за чего я практически сразу от него отказался? (Я не знаю, может сейчас он стал более продвинутым и решены эти вопросы, но на тот момент не было).

1. Отсутствует работа с реальными данными. То есть я меня есть в прототипе раздел Пользователи, но я не могу по API получить данные пользователей и вывести их в цикле в своем шаблоне. Да и вообще в принципе нет возможности работать с реальными данными (создавать записи, читать их).
2. Проходя этап прототипирования и переходя непосредственно к разработке, нельзя использовать созданные в прототипе шаблоны. То есть после того, как прототип был создан и согласован с заказчиком и когда перешли к программированию, на прототип мы могли только что смотреть глазами, более ничего с ним сделать нельзя было. А так хотелось накидать прототип и далее уже использовать его в разработке.

Были и еще моменты, но вот эти два самых главных. Получалось, что этапы прототипирования и программирования жили своей самостоятельной жизнью и никак друг на друга не влияли. А хотелось бы, чтобы этап прототипирования плавно переходил непосредственно в программирование. А в рамках текущей статьи можно и вовсе предложить, что прототипирование перетекает в создание MVP, а далее уже, в случае успеха, MVP развивать до конечного полноценного продукта. Ведь если так подумать, то создание MVP не всегда гарантирует то, что в дальнейшем будет более полный продукт. Ведь в чем смысл создания MVP? Во-первых, с минимальными издержками реализовать идею, чтобы можно было попробовать в работе, а во-вторых, чтобы изучить спрос и решить для себя стоит ли дальше вкладываться и развивать это до полноценного продукта. И вот получается, что нужен инструмент, который позволил бы быстро создавать прототипы/MVP, а с другой стороны в случае успеха MVP можно было бы развивать проект далее без особых ограничений.

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

• Практически вся работа выполняется на фронте через собственный WYSIWYG фронт-редактор.
• УРЛы реализованы на react-router, что позволяет адресность так же прописывать прям во фронте в редакторе, а не на сервере.
• API реализовано на GraphQL, что позволяет и запросы писать во фронте, а не на сервере. При этом встроен GraphiQL, что упрощает процесс написания запросов.
• Плюс к этому есть генерируемые фильтры, постраничность и прочие полезные плюшки.

И все это openSource, то есть это не SaaS, за который надо постоянно платить (еще и не имея всего в собственном распоряжении). Это можно разворачивать на своем сервере и кастомизировать под себя.

Прежде чем я опишу процесс установки его на свой сервер и процессы кастомизации, предлагаю посмотреть запись процесса создания отдельного раздела на сайте. Он почти 15 минут, но достаточно посмотреть первые 4 минуты, этого более чем достаточно для того, чтобы получить представление о Prisma CMS, и при наличии интереса перейти к дальнейшему чтению топика, а может и попробовать развернуть движок у себя.


Итак, установка Prisma CMS на сервер (я использую ubuntu, желательно минимум 4Gb ОЗУ и диск SSD).

Предполагается, что вы уже знакомы с node-js, npm/yarn, react и graphql.

1. Устанавливаем необходимое ПО

Если в терминале вставлять сразу все, выполнение может оборваться, так что лучше построчно выполнять.

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

sudo apt update
sudo apt install mc
sudo apt install git

curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash -
sudo apt-get install -y nodejs

sudo npm i -g yarn

sudo apt-get install software-properties-common python-software-properties
sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
sudo apt-add-repository 'deb https://apt.dockerproject.org/repo ubuntu-xenial main'
sudo apt-get update

sudo apt-get install -y docker-engine

sudo curl -L https://github.com/docker/compose/releases/download/1.18.0/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

2. Клонируем репозиторий

mkdir /var/www
cd /var/www
git clone https://github.com/prisma-cms/boilerplate
cd boilerplate
yarn --ignore-engines

3. Запускаем докер-контейнеры с MySQL и prisma (prisma — это отдельный продукт, не мой, но с которым сильно связана серверная часть, смотрите github.com/prisma/prisma).

docker-compose -f src/server/scripts/docker/prisma/docker-compose.yml up -d

Если вам захочется смотреть в базу данных через phpMyAdmin, установим и его.

docker run -d --link prisma_mysql_1:db --network prisma_default -p 8090:80 phpmyadmin/phpmyadmin

Будет висеть на порту 8090. По умолчанию логин/пароль root/prisma

4. Деплоим схему

endpoint=http://localhost:4466/my-project/dev yarn deploy

my-project/dev соответственно можно писать свои и на одном сервере создавать много проектов.

Важно! На продакшене порт 4466 должен быть закрыт фаерволом, к нему не должно быть прямого доступа извне.

5. Запускаем API-сервер

APP_SECRET=MyStrongSecret endpoint=http://localhost:4466/my-project/dev yarn start-server

После запуска вы можете открыть API-интерфейс server-ip:4000.

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

6. Запускаем фронт

Открываем еще один терминал и в той же папке выполняем

yarn start

Запустится фронт на порту 3000. Теперь можно преступать непосредственно к «программированию» фронта. Открываете server-ip:3000. При заходе, пока еще для фронта нет ни одного сохраненного шаблона, для вас будет выведена кнопка авторизации. Логика в том, чтобы зарегистрироваться и начать оформлять сайт. Кто первый — того и тапки сайт. Вот так это примерно выглядит:

7. Билдим скрипты и запускаем SSR (Servcer-Side Rendering)

Запуск через yarn start — это dev-режим, подходит для первого запуска (проверки, что все работает) и для программирования непосредственно JS-части. А для боя конечно же нужнен собранный фронт. Прерываем запущенный yarn start через Ctrl+C и билдим скрипты.

yarn build

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

Когда билдинг закончится, запускаем собранный фронт.

yarn start-ssr

Теперь и запуск значительно быстрее, и скрипты меньше в размерах.

Заключение

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

В любом случае, повторюсь, на мой взгляд, как движок для MVP очень даже может сгодиться — быстро накидать что-то и показать клиенту. При этом если переходить к разработке конечного продукта, даже если фронт не устраивает, можно его полностью выкинуть и переписать по-своему, при этом база данных и серверная логика никуда не денется. Ведь это headless-cms. Но я рассчитываю на то, что со временем фронт будет доведен до вполне приемлемого уровня.

Если у сообщества будет интерес, я тогда еще отдельно напишу топики про то как кастомизировать фронт (добавлять свои блоки для фронт-редактора) и как кастомизировать сервер (расширять схему, добавлять свои сущности, дописывать резолверы и т.п.). Уже наработано довольно много средств для быстрого выполнения подобных задач.

Исходники проекта

Всем спасибо за внимание!