Когда большинство людей думают о сборочных линиях, они думают о Генри Форде и модели Т. Многие ошибочно предполагают, что он был изобретателем. Но до Model T самая первая сборочная линия использовалась для массового производства Oldsmobile Curved Dash. Изобретателем был Рэнсом Олдс. Поворот, который Генри Форд применил к сборочной линии, заключался в том, чтобы преобразовать ее из статичной сборочной линии в движущуюся сборочную линию.

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

Шаблон конвейера использует упорядоченные этапы для обработки последовательности входных значений.

Концепции

Процесс

Процесс — это один канал в конвейере. У него одна работа, и он справляется с ней хорошо. Он изменяет запрос.

Запрос полезной нагрузки

Полезная нагрузка запроса — это объект, который передается от процесса к процессу. Он видоизменяется каждым процессом и представляет собой простое хранилище без бизнес-логики.

Полезная нагрузка ответа

Полезная нагрузка ответа — это окончательный вывод данных. Это готовый объект.

Псевдокод

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

Это начальная полезная нагрузка запроса. Изначально у него 4 параметра, у двух есть значения, а у двух нет.

{
  "user_id": 1,
  "name": "John Smith",
  "user": null,
  "job": null
}

FetchUserProcess

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

{
  "user_id": 1,
  "name": "John Smith",
  "user": {
    "id": 1,
    "name": "Johnathan Smith",
    "job_id": 1
  },
  "job": null
}

ОбновлениеИмяПользователяПроцесс

Этот процесс изменит имя пользователя с Johnathan Smith на John Smith..

{
  "user_id": 1,
  "name": "John Smith",
  "user": {
    "id": 1,
    "name": "John Smith",
    "job_id": 1
  },
  "job": null
}

FetchJobProcess

Последним шагом нашего конвейера будет поиск работы для Джона Смита.

{
  "user_id": 1,
  "name": "John Smith",
  "user": {
    "id": 1,
    "name": "John Smith",
    "job_id": 1
  },
  "job": {
    "id": 1,
    "title": "Programmer"
  }
}

HydrateResponsePayloadProcess

Наконец, на этом этапе наш RequestPayload преобразуется в ResponsePayload.

{
  "user_id": 1,
  "name": "John Smith",
  "user": {
    "id": 1,
    "name": "John Smith",
    "job_id": 1
  },
  "job": {
    "id": 1,
    "title": "Programmer"
  }
}
... converts to ...
{
   "name": "John Smith",
   "title": "Programmer"
}

Вывод

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

Я перенесу это из псевдокода в реальные примеры в следующем посте. А пока вы можете следить за моим прогрессом, поскольку я удаляю компоненты из предыдущей версии GoSteady и объединяю их в новый пакет композитора с открытым исходным кодом. Этот пакет станет основой того, как GoSteady будет обрабатывать CRUD и аутентификацию.