Сила электронных таблиц в реактивном, RESTful API

Будучи в основном технарем, я недавно и по общему признанию был обманут своим собственным отношением к Дильбертеску, когда наткнулся на эту наполненную модным словом статью TechCrunch об эспрессо-логике . Когда-либо беспокоился о моей репутации в социальных сетях (например, reddit и hackernews karma), я думал, что было бы разумно разместить ссылку на эти платформы под названием:

Только что нашел эту статью на TechCrunch. Читается как сгенерированная цепочкой Маркова серия модных слов.

С таким броским заголовком, пост быстро взлетел — и, как и многие другие редакторы, мои мысли были о Geek и Poke:

Компьютерщик и Poke на больших данных. Изображение лицензировано CC-BY 3.0

Но, как и некоторые другие редакторы, я не мог удержаться от перехода на реальный продукт, который претендует на реализацию «реактивного программирования» через API REST и JSON. И я искренне впечатлен идеями этого продукта. На этот раз модные слова поддерживаются программным обеспечением, реализующим их очень хорошо! Давайте сначала углубимся в …

Реактивное программирование

Реактивное программирование — термин, который недавно получил довольно широкое распространение в Typesafe , компании, стоящей за Akka . Это также получило дополнительную популярность с тех пор, как Эрик Мейер (создатель LINQ ) покинул Microsoft, чтобы полностью посвятить свое время своей новой компании Applied Duality . С этими блестящими умами остро на эту тему, мы обязательно услышим больше о Реактивном Манифесте в ближайшем будущем.

Но на самом деле каждый менеджер уже знает преимущества «реактивного программирования», поскольку он работает с самым реактивным и, возможно, самым удивительным программным обеспечением на планете: Microsoft Excel , устройством, тайна которого превосходит только его мощь. Подумайте о том, какой классный Excel. У вас есть сотни правил, формул, ячеек-взаимозависимостей. И каждый раз, когда вы меняете значение, вся электронная таблица волшебным образом обновляется. Это реактивное программирование.

Сила реактивного программирования заключается в его выразительности. Используя очень мало выразительной логики, вы можете выразить то, что в противном случае требует десятков строк SQL или сотен строк Java.

Эспрессо Логик

Имея это в виду, я начал вникать в бесплатную пробную версию Espresso Logic . Обратите внимание, что я нетерпеливый человек, который хочет быстрых результатов, не читая документы. Если вы работаете наоборот, есть несколько интересных ресурсов для начала:

• Тур
• REST API
• Реактивное программирование

В любом случае, демонстрационная версия поставляется с предустановленной базой данных MySQL, содержащей то, что выглядит как типичная схема электронной коммерции, содержащая таблицы customer, employee, lineitem, product, purchaseorder и purchaseorder_audit:

Просмотр схемы в Espresso Logic

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

Live API

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

Представление дерева ресурсов Espresso Logic

Обратите внимание, как я могу легко связать дочерние объекты с их родителями. Теперь этот API все еще немного ограничен. Например, я не мог понять, как перетащить отношения отчетности, где я рассчитываю сумму заказа для каждого клиента и продукта. Тем не менее, я могу переключить тип ресурса с «нормального» на «SQL», чтобы добиться этого с помощью простого старого GROUP BY и агрегатной функции .

Я начал понимать, что на самом деле я управляю и разрабатываю RESTful API на основе доступных ресурсов базы данных! Чуть дальше по меню я нашел пункт «Quick Ref» , который помог мне понять, как вызывать этот API:

Краткий справочник по API

Таким образом, каждый из ранее определенных ресурсов предоставляется через URL, как и следовало ожидать от любого RESTful API. Что действительно приятно, так это то, что у меня есть встроенная версия API и ключ API. Обратите внимание, что с точки зрения OWASP настоятельно не рекомендуется передавать ключи API в запросах GET. Это всего лишь пример использования для быстрого запуска демо-версии и для нечетного теста разработчика. Не используйте это в производстве!

Во всяком случае, я назвал URL в своем браузере с ключом API в качестве параметра (что противоречит моим собственным правилам):

И я получил документ JSON, как это:

Обратите внимание, что у каждого ресурса есть ссылка и контрольная сумма. Контрольная сумма необходима для оптимистической блокировки, которая является встроенной, если вы решите одновременно обновить любой из вышеперечисленных ресурсов. Также обратите внимание на то, как вложенные ресурсы Orders упоминаются как Customers.Orders . Я также могу получить к нему доступ напрямую, позвонив по указанному выше URL.

Живая Логика / Реактивное Программирование

Все идет нормально. Подобные вещи были реализованы в различных программах. Например, Adobe Experience Manager / Apache Sling интуитивно открывает хранилище JCR и через REST. Но идея Espresso Logic действительно начала меня очаровывать, когда я нажал «Live Logic» , и я столкнулся с заранее сконфигурированным набором правил, которые применяются к данным:

Правила просмотра

Я быстро просмотрел руководство, чтобы понять, правильно ли я понял. Эти правила на самом деле напоминают правила, которые я могу ввести в любом программном обеспечении для работы с электронными таблицами. Например, создается впечатление, что столбец customer.balance рассчитывается как сумма всех purchaseorder.amount_total имеющих paid значение false , и т. Д.

Итак, если я продолжу эту цепочку lineitem.product_price то lineitem.product_price что lineitem.product_price является общей зависимостью всех других вычисляемых значений. При изменении этого значения весь набор обновлений должен проходить через мой набор правил, чтобы окончательно изменить customer.balance :

В зависимости от того, насколько вы хакер консоли, вы можете написать свой собственный вызов PUT, используя curl , или вы можете использовать REST Lab из Espresso Designer, который поможет вам правильно настроить все параметры. Итак, если мы хотим изменить позицию с предыдущего вызова:

Давайте просто попробуем обновить это, чтобы иметь цену 30:

Использование лаборатории REST для выполнения запросов PUT

И вы можете видеть в ответе, есть сводка транзакций, которая показывает, что Customers.Orders.TotalAmount был изменен с 50 на 60, Customers.Balance изменился с 105 на 95, и была записана запись аудита. Сама запись аудита также определяется правилом, как и любое другое правило. Но есть также обычный файл журнала, который показывает, что действительно произошло, когда я запустил этот запрос PUT:

Представление журнала, показывающее все выполненные вставки и обновления

Представьте себе, что вам нужно поместить все эти операторы INSERT и UPDATE в правильный порядок и правильно управлять кэшированием и транзакциями! Вместо этого все, что мы сделали, это определили некоторые правила. Полный обзор доступных типов правил приведен на этой странице руководства Live Logic.

Вне сферы возможностей этого поста

… До сих пор мы рассматривали самые очевидные особенности Espresso Logic. Но есть и другие. Пара примеров:

Серверный JavaScript

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

Поддержка хранимых процедур

Люди, стоящие за Espresso Logic, являются «наследниками», такими же, как мы в Data Geekery . Их целевая аудитория может уже иметь тысячи сложных хранимых процедур с большим количеством бизнес-логики. Они не должны быть переписаны на JavaScript. Но так же, как таблицы, представления и ресурсы REST, они предоставляются через API REST, принимая параметры GET для параметров IN и возвращая JSON для параметров и курсоров OUT .

С точки зрения jOOQ, просто замечательно , что кто-то еще воспринимает хранимые процедуры так же серьезно, как и мы.

Безопасность на уровне строк / столбцов

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

• Обзор безопасности
• Начало работы с безопасностью

Вывод: запросы против обновления или постоянства на основе правил

В нашем блоге jOOQ и на наших маркетинговых веб-сайтах (например, hibernate-alternative.com ) мы всегда поддерживаем два основных варианта использования при работе с базами данных:

• Запросы: у вас есть очень сложные запросы для расчета таких вещей, как отчеты. Для этого идеально подойдет SQL (например, через jOOQ )
• Обновление: у вас очень сложная модель предметной области с множеством элементов и дельт, которые вы хотите сохранить за один раз. Для этого идеально подходят Hibernate / ORM

Но сегодня Espresso Logic показала нам, что есть еще один вариант использования. Тот, который покрыт методами реактивного программирования (или « программирования электронных таблиц »). И это:

• Постоянство на основе правил: у вас очень сложная модель предметной области с множеством элементов и множеством правил, которые вы хотите проверять, вычислять и синхронизировать постоянно. Для этого и SQL, и ORM являются решениями на неправильном уровне абстракции.

Этот «новый» вариант использования на самом деле довольно распространен во многих корпоративных приложениях, где сложные бизнес-правила в настоящее время изложены в миллионах строк императивного кода, который очень трудно расшифровать и еще сложнее проверить / изменить. Как вы можете перепроектировать свои бизнес-правила из миллионов строк старого кода, написанного на языке COBOL ?

В Data Geekery мы всегда ищем новые технологии. Espresso Logic — молодой стартап с новым продуктом. Тем не менее, как уже упоминалось, они представляют собой стартап с начальным финансированием , очень убедительной и инновационной идеей и огромным рынком унаследованных приложений на языке COBOL, которые хотят начать изучать «сексуальные» новые технологии, такие как RESTful API, JSON, реактивный программирование. Это может просто сработать! Если вы еще не достаточно просмотрели, изучите этот учебник , который включает в себя расширенные примеры, такие как «сводка цен на ведомости материалов», «взрыв комплекта ведомостей материалов», «сводка бюджетов», «аудит изменений заработной платы» и многое другое.

Мы обязательно будем следить за будущими улучшениями платформы Espresso Logic !