Блог

Я делаю проект, в котором я вызываю один API, этот данный сервис API будет обрабатывать все предоставленные данные и разделять их на разные коллекции.

Приведенный пример

service.js

 async function create(params, origin) {
  const { param1 , param2 , param3 } = params
   
  const collection1 = new db.Collection1(param1)

  await collection1.save()


  const collection2 = new db.Collection2(param2)

  await collection2.save()


  const collection3 = new db.Collection3(param3)

  await collection3.save()
}
  

Мои вопросы:

1. Какова наилучшая практика? Должен ли я создать общую схему модели, которая группирует все коллекции с параметрами «param1, param2, param3», и вставить ее в коллекцию, затем вызвать другую функцию, которая разбивает все значения на Collection1, Collection2….

2. Как я могу обработать, если одна вставка коллекции выдает ошибку, чтобы удалить все ранее вставленные коллекции? Например, значения param2 недопустимы, но param1 и param3 являются, как я могу обработать удаление коллекции 1 и 3 и выдать ошибку? Каков наилучший способ добиться этого?

В целом все приведенные выше примеры упрощены, речь идет как минимум о более чем 10 коллекциях и более чем 15 параметрах.

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

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

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

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

Это может сработать, если вы разрабатываете самостоятельно как полный стек, но если у вас есть команда, в которой вы выполняете серверную часть, а кто-то другой выполняет запросы из интерфейса, и он сталкивается с проблемой, ему будет намного сложнее сообщить вам, какой путь => обработчик не удался, потому что вы в основном скрываете несколько обработчиков в одном пути => [handler1, halder2, handler3]. Если вы подумаете об этом, такое поведение вызывает ваш второй вопрос.

Другое дело, что вы делаете, если кому-то нужно выполнить только одну вставку из того массива вставок, который вы пытаетесь выполнить? Вероятно, в конечном итоге вы создадите отдельные пути / маршруты, что означает, что вы копируете существующий код.

Я думаю, что это лучше для объединения / упорядочивания разных запросов от интерфейса. Это намного лучше и элегантнее, следует за DRY, проверка и очистка действительно проще в кодировании, и это дает потребителю вашего api свободу композиции.