Пример использования: создание высокоуровневой среды для быстрой разработки веб-приложений для финтех

Пример использования: создание высокоуровневой среды для быстрой разработки веб-приложений для финтех

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

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

Фреймворк высокого уровня - что именно мы хотим разработать?

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

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

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

Фреймворк для финтех-приложений - бизнес-требования

Фреймворк будет создан с учетом пары предположений:

• Фреймворк будет ориентирован на конкретные функции. Дизайн вторичен - будут доступны только базовые настройки, такие как изменение цвета или логотипа.
• Основная цель структуры - обеспечить очень быструю разработку новых финтех-приложений, чтобы их можно было предлагать клиентам, которые хотят быстро представить новый продукт (например, для обеспечения новой рыночной ниши или для тестирования MVP).
• Элементы высокого уровня, не требующие кодирования, будут определяться через формы, таблицы и т. Д. С использованием простого интерфейса.
• По большей части, для любого приложения, созданного с использованием фреймворка, с нуля должна быть написана только его бизнес-логика.
• Эффективность создаваемого приложения является приоритетом.

Технические предположения для создания финтех-приложения

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

• Производительность - поскольку мы уделяем приоритетное внимание эффективной производительности и модульности, мы подумали об использовании сервис-ориентированной архитектуры. Мы также могли бы синхронизировать как можно больше данных между сервисами, чтобы ограничить количество запросов.
• Управление данными. Поскольку наша система должна обрабатывать объекты, которые будут определены вне нее, лучше всего передать контроль над ними пользовательскому интерфейсу. Вот почему мы подумали об использовании чего-то вроде graphQL.
• Пользовательский интерфейс. Фреймворки JavaScript с открытым исходным кодом, такие как React или Angular, идеально подходят для создания высокопроизводительных интерактивных пользовательских интерфейсов. Кроме того, в нашей команде есть отличные специалисты в этих областях.
• Безопасность - одним из основных факторов является безопасность наших приложений. Потенциально мы могли бы использовать готовые решения, такие как Keycloak или Gluu.

Это то, что мы знали еще до того, как начали. А теперь давайте посмотрим, что произошло, когда наши идеи воплотились в реальность.

Подход к услугам

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

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

Управление данными - вывод синхронизации данных на новый уровень

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

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

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

Tesseract - единственная в своем роде библиотека для извлечения данных

Библиотека пользовательской выборки данных Tesseract действительно заслуживает нескольких дополнительных слов. Почему? Потому что на рынке нет другого решения, похожего на это. Причина, по которой он был разработан, в первую очередь, заключается в том, что ни одно из существующих готовых решений (таких как Prism, DeepStream или Hazelcast) не соответствовало всем требованиям проекта.

Tesseract функционирует как единый уровень доступа к данным, который соединяет несколько источников данных (базы данных, шины сообщений, сторонние сервисы и т. Д.). Он использует концепцию «живых запросов» для оптимизации передачи данных и повышения производительности (быстрый ответ с помощью моментальных снимков данных) всех приложений, основанных на нем. Уникальные функции включают кэш в реальном времени, многофакторную аутентификацию и авторизацию, а также множество возможных сторонних интеграций.

Переход с JS-фреймворков с открытым исходным кодом на Ext.js

Для создания интерфейсов наших финтех-приложений мы изначально планировали использовать React или Angular. Мы по-прежнему верим, что каждый из них может сделать отличную работу. Однако в конце концов мы решили использовать Ext.js. - проприетарный фреймворк JavaScript от Sencha.

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

Помимо юридических и практических вопросов использования технологий с открытым исходным кодом в этой области, проприетарное программное обеспечение, такое как Ext.js, обычно поддерживается крупной компанией, обеспечивает профессиональную поддержку и очень хорошо написанную документацию. В результате он кажется более надежным для финансовых институтов. Мы связались с командой Ext.js и быстро освоили ее. Мы были достаточно довольны, чтобы это поддержать. И поэтому именно Ext.js обеспечит поддержку пользовательского интерфейса приложений, созданных с помощью нашей высокоуровневой платформы. В дополнение к этому Ext.js также поддерживает Internet Explorer 8 - немногие проекты все еще нуждаются в такой поддержке, но в мире финансов это совсем не редкость.

Кстати, стоит отметить, что способ, которым мы реализовали Ext.js, позволяет легко заменить его на React, Angular, Vue или любой другой основной фреймворк JavaScript, если в этом возникнет необходимость. Мы сделали так, что бэкэнд отправляет клиенту информацию, содержащую структуру, описывающую данный пользовательский интерфейс. Впоследствии Ext.js преобразует данные в свои компоненты. Достаточно легко написать код, который вместо этого преобразует структуры в компоненты React / Angular / Vue. Мы также могли бы написать специальный SPA, который принимает входные данные от служб и строит на их основе пользовательский интерфейс, используя любую заданную структуру JavaScript.

Тем не менее, мы ценим, как много всего «выходит из коробки», когда дело доходит до Ext.js.

Реактивный подход к безопасности - ограничения Keycloak

Как упоминалось ранее, мы рассмотрели множество готовых решений безопасности с централизованным хранением. Больше всего времени мы проводили с Keycloak. Мы дошли до тестирования полной интеграции Keycloak с нашей системой. Однако в конце концов мы решили создать нашу собственную систему безопасности на основе ABAC (управление доступом на основе атрибутов). Почему? Выделяют две основные группы причин:

• Связано с производительностью - Keycloak работает так же, как REST API. В результате было сложно гарантировать, что после того, как мы что-то изменим на его панели, это изменение немедленно отразится в пользовательском интерфейсе. Одним из требований нашего программного обеспечения было отображение любого изменения состояния в режиме реального времени. В конечном итоге Keycloak в нашей реализации будет не чем иным, как базой данных - мы будем использовать только часть его реального потенциала.
• Связанные с клиентом. Здесь много мелких проблем, но в первую очередь большинство клиентов хотят, чтобы их панели управления безопасностью были встроены в их индивидуальное решение. Идея о том, что сотрудникам потребуется входить во внешнее приложение по таким причинам, кажется им подозрительной и неприятной. API Keycloak не предоставлял нам достаточно функций, чтобы полностью обойти их панель.

Результаты

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

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

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

Кроме того, мы отточили множество навыков, которые мы оттачиваем строго в сфере разработки, которые обязательно помогут в будущих проектах:

• Опыт создания очень сложных и масштабируемых приложений, созданных таким образом, чтобы можно было легко переключаться между реализациями («программа для интерфейсов, а не реализации!»).
• Глубокое знание Ext.js и множества способов его использования для быстрого создания эффективных пользовательских интерфейсов.
• Знание создания настраиваемых баз данных и решений безопасности, в которых используются такие технологии, как WebSockets или CQRS.

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

Статья написана Адамом Полаком и впервые была опубликована в Блоге Software House. Посетите блог, чтобы узнать больше о передовых методах разработки и советах по аутсорсингу программного обеспечения.