Версия 5.0.0

[debabin]

В рамках релиза 4.0.0 мы добавили flat configs, идея реворка была очень простая. Создать композицию для запросов, теперь пользователям легко группировать конфиги запросов.

export const flatMockServerConfig: FlatMockServerConfig = [
  {
    baseUrl: '/api'
  },
  {
    baseUrl: '/auth',
    interceptors: {
      response: (data) => data
    },
    configs: [
      {
        method: 'get',
        path: '/users',
        routes: [
          {
            data: [{ id: 1, emoji: '🎉' }]
          }
        ]
      },
      {
        operationType: 'query',
        operationName: 'GetUsers',
        routes: [
          {
            data: [{ id: 1, emoji: '🎉' }]
          }
        ]
      }
    ]
  }
];

Данный конфиг нам нужно отображать для main view, которая отвечает за поиск и отображении информации по запросам, а также для view 404, чтобы подсказывать пользователям пути запросов. И даже уже на этом этапе видно, что конфиг нужен в нескольких форматах, ведь отображать мы его хотим для пользователя в том же виде, что он и заполнил. А вот для ошибок нам нужен просто одномерный массив rest и graphql конфигов.

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

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

Внешний формат

  {
    baseUrl: '/auth'
    configs: [
      {
        method: 'get',
        path: '/users',
        routes: [
          {
            data: [{ id: 1, emoji: '🎉' }]
          }
        ]
      },
      {
        operationType: 'query',
        operationName: 'GetUsers',
        routes: [
          {
            data: [{ id: 1, emoji: '🎉' }]
          }
        ]
      },
      interceptors: {
         response: (data) => data
      }
    ]
  }

Внутренний формат

[
  //
  {
    component: {
      name: 'smart request',
      baseUrl: '/test',
      interceptors: {
         response: (data) => data
      }
    },
    method: 'get',
    path: '/users',
    routes: [
       {
           data: [{ id: 1, emoji: '🎉' }]
        }
     ]
  },
  //graphql
  { 
    component: {
      name: 'smart request',
      baseUrl: '/test',
      interceptors: {
         response: (data) => data
      }
    },
    operationType: 'query',
    operationName: 'GetUsers',
    routes: [
          {
            data: [{ id: 1, emoji: '🎉' }]
          }
     ]
  }
];

[debabin]

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

[debabin]

Entities

Мы также в будущих релизах хотели бы сделать entities еще гибче.

Сейчас entities с помощью checkMode function можно сделать какой угодно, но простыми средствами нельзя сделать например проверку, что сущность начинается на что-то и заканчивается на что-то.

В данный момент checkMode работают как одно правило и их нельзя комбинировать. Хотелось дать пользователям еще более гибкую систему.

entities: {
  headers: {
    auth: entity(
      [{ exist: true }, { startWith: ['token', 'token'], oneOf: true }], 
      { exist: true }, 
      { startWith: 'token' }
    )
  }
}

Пример выше показывается комбинацию, которая будет равна: "существует и начинается на что-то из списка" или "просто существует" или "начинается с токен"

[debabin]

Database

Ранне мы хотели позволит пользователь также легко использовать наш мок для создания mvp. Мы взяли концепт json-server с их автогенерацией роутов. Но на практики мы получили, что это отдельная фича задает нам больше вопросов, когда мы хотим работать еще и с маршрутами.

Яркий пример это "orm", сейчас "orm" тесно привязана к нашей database, которая завязаны на конкретные ключи, фильтры и тд. Мы ограничили себя и пользователя.

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

Вывод напрашивается следующий, что нынешняя database и database с которой мы хотели бы работать с orm, это разные базы и их необходимо разделить.

Database сейчас станет отдельной сущностью в нашем инструменте и более не будет вмешиваться в flat конфиги