редакции
Руслан Раянов
SQL Driven. Учетная система с ориентацией на SQL
Что есть полный стек разработки?
Самописные системы разрабатываются на базе полного стека разработки с N слоями:
- проектируется база данных
- создается слой доступа к данным
- создается слой бизнес-логики
- разрабатывается API или слой контроллеров
- делается верстка
- к ней подключается динамика за счет front end программирования.
Это довольно трудоемко, сложно. Но этому есть причина. Коробочные решения не дают гибкости, а для дальнейшего развития системы очень важно иметь возможность легко развивать систему без серьезных ограничений.
Когда то давно мы создали модуль метрик, который генерировал некие отчеты в виде вложенных показателей. Каждый отчет — это данные в таблицах + некая хранимая процедура для извлечения данных.
Движок модуля подхватывал эти данные и хранимку и выводил все что нужно пользователю.
Это привело нас к идее, а почему бы и другие все модули не попробовать сделать по подобному принципу — формы, таблицы, графики, дашборды и прочее.
Что дает в итоге такой подход:
во-первых, можно менять бизнес-логику на лету (просто поменяв хранимую процедуру). В случае обычного N-слойного приложения необходима перекомпиляция и обновление программы.
во-вторых, что следует из первого — это скорость внесения изменений. Очень важно иметь возможность быстро вносить изменения, а не ждать разработчиков по 2 недели, когда они внедрят изменения в систему.
в-третьих, основная сложность ложится на 1 слой и локация ошибки с высокой степенью вероятности находится только в 1 слое — SQL процедурах. Это упрощает поиск ошибок и минимизирует количество сбоев на front end.
Как это выглядит изнутри
Возьмем к примеру вывод таблицы.
На входе — это сниппет
Ваш JS движок обрабатывает подобные компоненты и запрашивает у базы описание по компонентам и данные для них (все через знанимые процедуры).
Полученные данные JS движок выводит в виде таблицы. Данные удовлетворяют неким правилам/стандартам. Например для таблиц у нас правила примерно выглядят так:
процедура GetItems выдает в SELECT 1 данные таблицы, в SELECT 2 — данные о пагинации, в SELECT 3 — настройки вывода таблицы.
К примеру если в select 3 передать select 1 compact — то таблица будет выведена в компактном режиме. Если необходимо реализовать какие-то действия с данными таблицы, то это также вызов некой хранимой процедуры с заданными параметрами и заданным выводом. Процедуры делятся на системные (обслуживают компоненты и внутренние потребности системы) и пользовательские (задают вывод данных). Редактирование процедур происходит через интерфейс панели управления, т.е. нет необходимости искать каждый раз хранимую процедуру в SQL Server Management Studio. Какие дополнительные плюсы дает подобный подход? 1. Быстродействие. Вы рабочаете с чистым SQL без лишних прослоек в виде ORM. Это дает хорошее быстродействие и оно ограничивается по сути быстродействием вашего написанного SQL запроса. 2. Созданный функционал — это по сути только SQL и данные в таблицах (что также можно представить в виде SQL скрипта). Вы можете легко переносить между разными системами SQL для отдельных компонентов. Это возможность наращивать кодовую базу и адаптировать ее в других подобных приложениях. 3. Не нужна компиляция. Поменяли процедуру — получили сразу в системе другой результат. По сути разработка идет в realtime, параллельно с использованием. 4. Локализация ошибок — большинство ошибок лежат в вашем SQL, а не разбросаны по всему стеку. Есть проблема? Проверяем работы процедуры в SQL Management Studio и анализируем вход и выход. 5. Поняв общий подход, систему можно развивать, добавляя новые блоки и модули без необходимости менять исходный код программы. 6. Уменьшение требуемых компетенций для поддержки системы. В нашем случае мы сводим все к 2 компетенциям — знание SQL и Bootstrap. 7. Уменьшение количества велосипедов. Программисты не могут больше делать в системе 3 вида по разному сделанных таблиц. Все унифицируется и разработка идет быстрее. Конечно не все так просто и есть свои сложности, например, некоторые функции не так просто реализовать в SQL (вычисление хеша для кириллицы) или передача вызова из хранимой процедуры в код веб-приложения. Где-то приходится идти на компромиссы (например есть ограничения верстки отдельных элементов). Однако в целом такой подход позволяет решать ключевые задачи — быстро создавать необходимый функционал и иметь гибкие возможности по дальнейшему развитию. P.S. В предыдущей статье мы рассказали историю создания нашей системы Falcon Space, основанной на данном подходе. Конструктор учетных систем и личных кабинетов — https://falcon.web-automation.ru/
Плюсы и минусы подхода
