Запуск архитектуры Low-code приложения

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

Архитектурные шаблоны в стандартных приложениях

Есть несколько общих закономерностей. Разработчики могут их даже не увидеть. Вот два из этих паттернов:

  • кодирование структуры данных на несколько / все уровни приложения.
  • кодируйте бизнес-правила / решения в приложение (уровень).

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

Введите младший код

Платформы с низким и нулевым кодом хранят эти структуры данных и бизнес-правила на другом «слое». На самом деле они означают, что они не написаны на языке, отличном от языка приложения, И что этот новый язык мгновенно используется приложением для определения поведения. Так почему бы не использовать это в качестве архитектурного стандарта в своем веб-приложении?

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

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

Большой и маленький, это можно сделать

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

Более интересно то, что этот тип архитектуры также работает в настраиваемом приложении. Менее чем с 1000 строками * PHP / html / twig ademo можно написать приложение, которое подключается к Neo4j, определяет модель данных, выполняет CRUD для экземпляров и выполняет базовые действия с этими экземплярами.

* введите здесь желаемый язык.

Зачем использовать архитектуру с низким кодом?

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

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

Почему Neo4j?

Конечно, вы должны выбрать лучшее для среды вашего приложения, но если начинать с нуля: Neo4j имеет очень простую в использовании структуру данных и язык запросов. Помимо того, что его легко масштабировать, переносить и поддерживать. Это позволяет быстро разрабатывать приложения. Кроме того, его можно расширить с помощью сторонних (например, ElasticSearch) или ваших собственных (настраиваемый поиск / агрегирование /…) алгоритмов. Так что, если вы хотите изо всех сил, вы можете.

Если вас интересует наглядный пример, прокрутите до вывода.

Заключение

В иллюстративном примере ниже должно быть (не более 1000 строк) php / html / twig. Фактически, при достижении 1000 строк вы должны были иметь возможность добавлять связи, редактировать, проверять типы и разбивать на страницы.

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

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

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

Дальнейшее чтение:

Если вы хотите узнать больше, оставьте мне сообщение.

Иллюстративный пример

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

  1. Создайте структуру метаданных. Это позволяет пользователю использовать структуру данных в вашем приложении.
  2. Сохраните MetaType и его MetaAttributes. Это сохраняет структуру метаданных в базе данных.
  3. Перечислите все метатипы. Показывает пользователю список всех структур.
  4. Создать экземпляр метатипа. Позволяет пользователю создать экземпляр одного из метатипов, имеющихся в базе данных.
  5. Сохраните данные экземпляра. Запишите данные в базу данных в соответствии со структурой метаданных.
  6. Список всех экземпляров MetaType. Показывает список всех экземпляров, созданных для одного MetaType.

Что не включено: настройка приложения / css /…, полные примеры кода для всех уровней, обширная функциональность для ввода / проверки / разбивки на страницы /…

Начнем с первого в списке.

Шаг 1. Создайте структуру метаданных

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

(MetaType)-[:hasAttribute]->(MetaAttribute)
(with cardinality: 1..n)
(MetaType)-[:hasRelationTo]->(MetaRelation)-[:toType]->(MetaType)
(with cardinality 1..n and 1..1)

Другие предположения:

MetaType has two standard attributes: an ID and a Name.
MetaAttribute has a Type

Для создания MetaType в форме всегда есть что-то похожее на это:

<form name="addtype" method="POST">
  <h3>New MetaType</h3>
<div class="input-group">
   <span class="input-group-addon">Name</span>
   <input type="text" class="form-control" name="metatypename">
   <span class="input-group-btn">
    <button class="btn btn-secondary" type="submit" id="submit">Save</button>
   </span>
  </div>
  <br>
  <h4>Attributes</h4>
  <div class="input-group">
   <div id="attrplaceholder">
    <div class="input-group">
     <span class="input-group-addon">Name</span>
     <input class="form-control" type="text" name="dummy1" value="Name" readonly>

    </div>    <button class="btn btn-secondary" type="button" id="addattr">Add Attribute</button>    
   </div>
  </div>

Приведенный выше фрагмент html-формы пока не делает ничего особенного. Он позволяет вводить MetaType.Name и Save. attrplaceholder -div имеет поле ввода только для чтения с «Name» в нем. Чтобы добавить атрибуты, необходим некоторый код для кнопки Добавить атрибут:

$("#addattr").click(function (e) {
     //Append a new row of code to the "#attrplaceholder" div
     $("#attrplaceholder").append('<div class="input-group"><span class="input-group-addon">Name</span><input class="form-control" type="text" name="attr_name[]"><span class="input-group-addon">Type</span><select class="form-control" name="attr_type[]">{% include 'snippets/attrtypeoptions.html' %}</select><span class="input-group-btn"><button type="button" class="btn btn-secondary delete">Delete</button></span></div>');
     });

Да, это похоже на беспорядок (спасибо за комплимент), но делает следующее:

  1. Он добавляет поле ввода в attrplaceholder с именем и типом.
  2. Тип - это раскрывающийся список со всеми известными типами (который я поместил в фрагмент HTML и включил здесь для удобства чтения).
  3. Сохраняет информацию об имени и типе всех атрибутов в массивах attr_name [] и attr_type [].

Результат должен (функционально) выглядеть примерно так:

Примечания:

  • поле Описание. Я счел полезным сделать поле Описание обязательным для каждого MetaType.
  • кнопку Удалить. В моей концепции это часть Javascript, которая просто удаляет группу, определяющую атрибут.
  • Аналогичный раздел формы можно добавить для MetaRelation. И поскольку я предполагал, что вы можете увидеть шаблон и повторить его для MetaRelations, его здесь нет ... (я бы посоветовал сначала полностью реализовать только MetaAttributes, прежде чем выполнять MetaRelations, поскольку у них есть некоторые дополнения, которые нужно учитывать, например получение всех метатипов для отношения [: toType].)

Шаг 2 - Сохраните MetaType и его MetaAttributes

При нажатии кнопки submit эти данные могут быть проанализированы и записаны в базу данных. Пропуская обязательную логику приложения для перехвата POST и прочего, должен быть какой-то запрос для записи атрибутов в базу данных. Поскольку используется Neo4j, это выглядит примерно так:

MERGE (newtype:MetaType {id:{uniqueID}, name:{typename})
and for every attribute:
MERGE (newtype)-[:HasAttribute]->(:MetaAttribute {name:{attr_name}, type:{attr_type})

Это сохраняет данные из формы в базе данных и позволяет читать их снова.

Шаг 3 - Список всех метатипов

Нет, я не собираюсь объяснять вам это, но сделайте следующее: создайте форму, которая извлекает все узлы типа MetaType и перечисляет их на странице. (И если вы хотите сделать это многоразовым, убедитесь, что он есть, чтобы MetaType можно было заменить любой другой меткой.)

Теперь, когда вы можете показать все созданные вами метатипы, создайте кнопку, которая ведет к форме для создания экземпляра этого метатипа.

Шаг 4 - Создайте экземпляр MetaType

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

MATCH (n:MetaType)-[:HasAttribute]->(a:MetaAttribute) WHERE n.name = {MetaTypeName} RETURN a.name AS name,a.attrtype AS type ORDER BY a.name

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

Результат этого запроса отправляется во внешний интерфейс, где он будет проанализирован в форму, которая позволяет пользователю вводить только атрибуты, необходимые для этого MetaType.

В приведенном ниже примере с использованием twig / html атрибуты передаются как переменная attrlist и анализируются в полях ввода HTML. (Чтобы позже добавить редактирование экземпляров, значения также можно передать и заполнить поле input value.)

{% for attritem in attrlist %}
     <div class="input-group">
         <input class="form-control" name="{{ attritem['name'] }}" type="{{ attritem['type'] }}"/>  
     </div> 
     <br>
{% endfor %}

После синтаксического анализа форма (функционально) будет выглядеть примерно так:

Шаг 5 - Сохраните данные экземпляра

Когда экземпляр будет сохранен, вы получите данные, аналогичные сообщению MetaType. На этот раз его нужно сохранить как Instance, а не как MetaType.

В этом примере используется MetaType Appointment. Итак, теперь, когда мы хотим сохранить встречу, мы собираемся присвоить новому узлу Neo4j ярлык «Встреча». После получения данных POST сборка запроса PHP может выглядеть так:

$q = 'MERGE (newInstance:'.$metaType.' {uniqueID:{uniqueID}) ';
//standard attributes first (in php)
$query = $query.'SET newInstance.name="'.$data['name'].'" ';
//for all attributes, create a set statement (in php)
foreach($Attributes as $field) {
      $query = $query.'SET newInstance.'.$field['name'].' = "'.$data[$field['name']].'" ';
}

Примечания:

  • Аналогичный раздел можно добавить сюда для сохранения MetaRelation. Это не здесь.
  • Здесь вы можете выполнять всевозможные проверки и проверки типов, если хотите.

Шаг 6 - Список всех экземпляров метатипа

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

Вау, вы дошли до этого места! Один хлопок для вас! ;-)

Если хотите, узнайте больше или отправьте мне сообщение: