А что если бизнес в наше время ускорился до таких скоростей, что классический способ построения приложений уже не о правдывает себя. Мы возложили на команду разработки беклог, и ждем когда они его реализуют. Что если разработчики приложения должны подумать о том, чтобы создать конструктор на базе своего приложения, и дать возможность пользователям кастомизировать свой UI/UX по их потребности. Пусть будет базовый интерфейс приложения by-default используемый неподготовленным юзером. Но для подготовленного юзера всегда будет возможность залезть под капот и настроить любой скрин этого приложения кастомно. Да это будет более сложное взаимодействие, чем мы привыкли в Web 2.0 и скорее всего придется выучить тот или иной скриптовый или декларативный язык конфигурации этого приложеняи конструктора. Пользователю не надо ждать, когда команда разработки закончит свой беклог, им уже создали конструктор - надо лишь только разобраться как что устроено и сделать свою кастомизацию.
Я все свои pet проекты пишу теперь такими конструкторами. Всегда есть некоторый скрипт/конфиг, который позволяет без перекомпиляции приложение поменять его свойство. Даже в этом блоге есть зародыши такой возможности - могу использовать режим верстки, или погрузиться в увлекательный мир HTML и сверстать все по-инженерному. Уверен множество приложений имеют такой advanced тулинг стоит присмотреться. Я лишь рекомендую довести это до максимума и внедрить новый подход в разработку ПО. И дело не только в обработке данных, которые передаю на вход из фронтенда в бекенд. Можно пойти дальше и дать возможность влиять на бизнесс логику.
Может показаться, что это не безопасно. Открывая больше дверей мы делаем более уязвимыми наши сервера. Но сейчас могу так же открыть Inspect вкладку браузера и на любой страничке посмотреть множество запросов и выполнить большую часть из их независимо от других. Могу написать свой UI поверх существующего API. Часто разработчики сами открывают свои API и документацию на него. Но это не совсем то, что предлагаю. Я хочу иметь возможность влиять на то как будет работать мое приложение путем задания сценария бизнесс логики.
Возьмем например этот блог. В нем есть ряд скринов, где-то в настройках могу настроить блог включая или выключая определенные фичи. Я могу настроить внешний вид всех страничек в конструкторе. На этом этапе мне не нужно еще быть инженером - все достаточно визуально.
Так кажется, стоит мне отредактировать любой блок, как я тут же увижу html/js/css код.
То есть если я лезу в настройки приложения, я вероятнее всего должен быть инженером.
Если посмотреть в другие настройки - я могу так же изменить HTML в который все будет собираться в результате.
Это то о чем я говорю. Но опять же очень глубоко спрятано и сделано достаточно сложно. Сложно в обе стороны. Для разработчиков скринов настройки блога это еще один скрин, который стоит времени разроаботчика - взять тот же drag & drop конкретных блоков. Надо ли это мне инженеру? Ну мне было бы проше отредактировать текстовый файл конфигурации. Надо ли это юзеру без навыков кодирования? Скорее всего он сюда не доберется, а добравшись будет делать что-то что ему расскажут в видео мануале или посте в блоге, который он нагуглит - "...хотите добавить кнопочку с рассылкой, скопируйте этот текст и вставьте его сюда...". Мне же этот скрин не позволяет сделать чуть больше, чем позволено. Там есть зашита общая структура блога: сверху navbar, ниже crosscol, потом идут основной main и справа от него sidebar. Я уверен что и этот темплейт где-то зашит в коде. Я бы хотел иметь возможность редактировать его.
Но если мы пойдем дальше. Вот у меня есть список постов в блоге. И я хочу его видеть в другом виде.Могу ли я сейчас повлиять на это? Нет
Пойдем дальше. Покусимся на бизнеслогику. После публикации поста он появляется в блоге, прием можно сделать отложенную публикацию. А что если я хочу тут добавить дополнительный флоу - скажем написать email или вызвать какой-то rest api чтобы сообщить о факте публикации? А что если я хочу иметь возможность так же делать какие-то полезные мне действия при каждом открытии поста читателем? Что если я хочу рендерить пост по разному, в соответствии с тем какое время суток? Что если я хочу не в html формате хранить мой пост, а в markdown? Что если я хочу хранить свои посты не в базе blogger, а на github? Могу ли я сейчас на это все влиять? Нет конечно. Потому я отправляюсь в opensource мир и ищу блог, который мне больше всего подойдет. А если не найду оного - сажусь писать свой конструктор.
Самая лучшая метафора того, как мне кажется будет уходить web в ближайшие годы - конструктор лего. Есть книжечка, где описано как построить домик с озером. Есть другая книжечка, в которой написано как построить космический корабль. И есть большой мешок с кубиками разных размеров. Пользуясь этой метафорой я предлагаю пользователю все в собранном виде вместе с этими книжечками, что дает возможность ему пользоваться функционалом сразу. Но если в будущем пользователь захочет пристроить лазерную пушку снятую с косчического корабля на крышу своего загородного домика с озером - у него есть такая возможность.
На сегодня все мои pet приложения так или иначе реализуют этот подход. И я могу сказать что это достаточно сильно меняет и подход в разработке и архитектуру. Когда вы делаете конструктор - все должно быть разбираемо и собираемо обратно, причем в другой форме. Детализация компонентов должна быть проработана в том месте, где требуется гибкость. Главная идея, чтобы при пересборке приложение все еще оставалось в изначальном домене: если это изначально был blog, то после переконфигурирования это будет все так же blog, а не какая-то скажем crm. Решить, где добавлять конфиг, что бить на компоненты, насколько мелко декомпозировать, а что оставить проприетарным монолитом - хорошие вопросы.
Сейчас например я работаю над микросервисом по построению LLM цепочек для решения своих несложных задач автоматизации рутины с помощью LLM. Все эти цепочки вынесены в конфиг, который является кастомизацией yaml формата. Я слежу за тем, чтобы конфигурирование цепочки оставалось простым. Но все же без инженера в них не разобраться. Потому есть многочисленные демо решения - файлики с уже созданными цепочками, в которых делается что-то полезное, что может быть относительно быстро исправлено не инженером и реализовано под свои нужды.
Другой мой пет проект - CRM система ведения кандидата по воронке стафинга и онбординга на проект. Сама воронка состоит из шагов, каждый из которых описан в markdown и превращается в html страничку которую видит тот или иной коллега - кандидат, его менеджер, рекрутер, HR специалист и так далее. Все они делают на страничке что-то с данными, завязанными на этого конкретного кандидата - выступают consumer или supplier этих данных. Некоторые шаги могут быть пропущены в заивсимости от определенных conditions. Так как на разных проектах последовательность шагов может быть иной - я как delivery менеджер этого проекта настраиваю эту цепочку сам. На выходе я получаю отдельный проект с набором markdown страничек где описан весь флоу (что полезно для KT другому менеджеру кто прижет на мое место), я могу добавлять улучшения в этот флоу и видеть в git историю изменений. Будучи загружена в приложегние эта цепочка превращается в конкретные скрины, странички, поля ввода/вывода, формы, таблички, реакции на сторонние сервисы как то отправка email и так далее. Для этого мне пришлось добавить свои новые теги к существующим в markdown. Конечно же пиать этот скрипт воронки придется тому, кто по-инженгерному разберется в нем. Но я точно знаю, что delivery manager IT компании точно сможет найти в своей команде инженера-волонтера, кто поможет ему в этом разобраться в свободное от работы время.
Еще один pet проект - блог. Я хочу переехать с blogspot и писать посты в markdown. Я хочу иметь возможность концигурировать свой блог подобно тому, как описывал это в этом посте выше. Скажем я хочу иметь возможность разместить 1 линку на youtube видео, и настроить в конфиге фильтр, который в зависимости от ссылки на видео будет вставлять либо youtube embed html блок, либо подобный блок другого видео хостинга. Причем я хочу описать это один раз и в одгом месте, а не копипастить постоянно этот код в каждый мой пост. Я хочу сохранять мои посты в git репозитории с версиированием, а блог система пускай поднимает его из git repo по моему запросу.
Другой мой проект Codenjoy хоть и не конфигурируется в скриптовом формате, но все же c самого начала позволяет создавать новые игрушки очень быстро. Все сделано для того, чтобы сегодня (максимум завтра) вечером появилась новая игра, если ты того пожелаешь. Да - тебе придется кодить на java. Но все API построено таким образом, чтобы это было максимально просто.
Есть и другие, о них я расскажу в другой раз.
Сообщения
