В данной статье описан принцип работы библиотеки, ее возможности и потенциал в использовании в современных приложениях, а именно ее архитектура и API. Следует упомянуть, что она open-source и реализована на языке Typescript и пока предназначена для Node.js приложений, но планируется в дальнейшем увеличить количество поддерживаемых платформ и языков.

Основная концепция библиотеки - перенести разработку приложений на более высокий уровень абстракции, чем уровень программного кода.

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

Во-вторых, системный код, который должен управлять всей структурой системы, переносится из пользовательских классов/модулей, которые вызывают данное API, формируя стек или список стеков вызовов функций (если учитывать многопроцессорность), и по сути были написаны один раз и вряд ли будут переписываться при других вариантах использования в рамках текущего приложения, в отдельный модуль, сгенерированный библиотекой и позволяющий гибко конфигурировать поведение программы.

Как это делается? Допустим, у нас есть уже готовое API, в нем есть сотни функций, которые мы планируем связать для получения полноценного приложения. Обычно мы должны были создавать исполняемые файлы, в котором нужно было описать последовательность вызовов, которые после компиляции/интерпретации формировали процесс выполнения уже готовой программы. Данная библиотека предлагает иное решение задачи.

С помощью графического интерфейса программист-пользователь создает диаграммы (будут доступны несколько типов диаграмм на выбор) для описания структуры текущего программного обеспечения согласно стандартов UML. Возьмем, к примеру, элементарную блок-схему, описывающую алгоритм последовательных действий. В каждом блоке схемы будет возможность "вытянуть" любой класс или модуль из прикладного API, вызвать функцию или список функций выбранного модуля. Как только мы это сделали, библиотека сохранит данные с графического интерфейса в локальный кэш, ведь мы можем еще не раз вернуться к модификации структуры программы.

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

Изначально планировался только один модуль библиотеки, который отвечает за формирования сценария программы. Суть данного модуля заключается в том, что он получает исходники, в котором описаны только лишь классы и модули, которые хранят в себе наборы функций и ничего больше. Этого достаточно, чтобы в дальнейшем осуществлять их вызовы с передачей конкретных аргументов. Поэтому после сканирования текущего API генерируется специальный файл конфигурации в JSON-формате, который полностью описывает проект в виде набора интерфейсов.

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

Как только JSON-файл был сгенерирован, у модуля библиотеки есть все необходимые данные для того, чтобы продолжить создание программы. Остается только написать сценарии (так я назвал конфигурацию, которая отвечает за последовательность функций, которую определяет программист-пользователь) и библиотека сможет сгенерировать скрипт выполнения программы на Node.js платформе.

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

Разумеется, как можно было понять после описания первого модуля, никто не будет вручную писать файлы конфигурации конкретного формата, определенного библиотекой. Это очень неудобно и слишком громоздко, что существенно затруднит разработку, а библиотека была создана как раз для противоположных целей. Для этого я предоставил третий модуль, написанный на React.js, который и является своего рода посредником между API библиотеки и программистом. Его суть заключается в визуализации планов архитектуры приложения программиста и трансформацию в сценарии, которые будут выполняться на движке библиотеки. Таким образом, достаточно лишь предоставить готовое API определенной прикладной задачи, и настроить схему программы так, как это нужно программисту.

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

1) Можно ли обеспечить параллельное выполнение нескольких методов;

2) Можно ли обеспечить выполнение нескольких сценариев одновременно;

3) Можно ли написать сценарий, который будет в себя включать другие сценарии;

4) Можно ли обращаться к нескольким API одновременно и строить совместные сценарии выполнения.

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

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

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

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

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

Сейчас очень много разных языков, разных платформ и и разного API. Каждый из них был создан для выполнения своей конкретной задачи. Именно поэтому я и решил написать программное обеспечение, которые облегчит разработку, позволив разработчику динамически менять систему под свои потребности. К сожалению, пока я это привязал к конкретному стеку технологий – Typescript, Node.js, React.js, и тем не менее, используемая мной концепция может найти реализацию и в других языках и платформах, чем я и планирую заняться в будущем.

Литература:

1. Martin Fowler. Inversion of Control Containers and the Dependency Injection pattern

2. Robert E. Filman; Tzilla Elrad; Siobhán Clarke; Mehmet Aksit. Aspect-Oriented Software Development.

3. Andreas Holzinger; M. Brugger; W. Slany. Applying Aspect Oriented Programming (AOP) in Usability Engineering processes