Флаги функций - Должны ли они быть выставлены клиентским приложениям?

Question

Я рассматриваю возможность использования флагов функций в веб-приложении с javascript / html и собственными мобильными клиентами и пытаюсь принять обоснованное решение по следующим вопросам:

Должны ли флаги функций быть открытыми дляклиентские приложения?

Обсуждая это с другими, появилось 2 подхода к тому, как клиенты работают с флагами функций, а именно:

1) Клиенты вообще ничего не знают о флагах функций.

Конечные точки на стороне сервера, которые отвечают данными, будут включать дополнительные данные, чтобы сообщить, была ли функция включена или выключена.

Например, для вымышленной конечной точки, /posts, данные могут быть возвращены, как, например,

расширенная функция пользовательского интерфейса включена:

{
  enhanced_ui: true,
  [1,2,3,4,5]
}

расширенная функция пользовательского интерфейса отключена:

{
  enhanced_ui: false,
  [1,2,3,4,5]
}

2) Клиенты могут получить доступ к конечной точке,и спросите о состоянии флага функции.

например, /flagstates

{
  'enhanced_ui:true
}

Клиенты затем используют это для скрытия или отображения функций по мере необходимости.

Некоторые мысли:

Подход № 1 имеет меньше времениving parts - для реализации гейтов вообще не требуются библиотеки на стороне клиента.

Однако возникает вопрос - когда обновляются динамические флаги, как клиенты узнают?Мы можем внедрить pub / sub для получения уведомлений и перезагрузки клиентов, тогда они будут автоматически получать новые обновленные данные.

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

Answer 1

Это то, что меня заинтересовало, так как у меня есть требование для реализации флагов / переключателей функций в продукте, над которым я работаю.Я исследовал эту область в течение прошлой недели, и я поделюсь своими выводами и мыслями (я не утверждаю, что они являются наилучшей практикой в ​​любом случае).Эти выводы и мысли будут в значительной степени основаны на ASP.Net Zero и ASP.Net Boilerplate , так как я нашел, что они наиболее близки для примера реализации того, что я ищу.

Должны ли флаги функций быть доступны клиентским приложениям?

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

"features": [
    {
      "parentName": "string",
      "name": "string",
      "displayName": "string",
      "description": "string",
      "defaultValue": "string",
      "inputType": {
        "name": "string",
        "attributes": {
          "additionalProp1": {},
          "additionalProp2": {},
          "additionalProp3": {}
        }, 
      ....

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

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

Наконец, когда ваши пользователи будут просматривать ваше приложение, если вы визуализируете пользовательский интерфейс для арендатора, у которого включена функция EnhancedUI , вам необходимо знать, включена ли эта функция.В ASP.Net Zero это делается с помощью так называемого IPermissionService, который реализован как на переднем, так и на заднем концах.В бэкэнде служба разрешений будет в основном проверять, разрешено ли пользователю доступ к некоторому ресурсу, что в контексте переключения функций означает проверку, включена ли функция для данного арендатора.Во внешнем интерфейсе (Angular) служба разрешений извлекает эти разрешения ( /api/services/app/Permission/GetAllPermissions):

{
  "items": [
    {
      "level": 0,
      "parentName": "string",
      "name": "string",
      "displayName": "string",
      "description": "string",
      "isGrantedByDefault": true
    }
  ]
}

Это может затем использоваться для создания некоторого вида RouteGuard, если что-то не включено или не разрешеновы можете соответствующим образом перенаправить, например, на страницу Upgrade your edition .

Надеюсь, это даст вам несколько идей для размышления.