Обтекание ElasticSearch SDK на фасаде, чтобы добавить дополнительную информацию о некоторых вызовах

Question

Для этого требуется немного знаний о фонах, поэтому я приношу свои извинения, если не достаточно ясен.

У меня есть служба ES (ElasticSearch), которая открывается через дополнительный API.

Вторичный API отвечает за проверку права собственности и доступ к контенту, это делается с помощью стандартных HTTP Authorization и двух идентификаторов в app_code и brand_code.

Мы это реализуется за счет того, вторичный API принять запрос, состоящий из двух "parts":

1. Два идентификатора, используемые для проверки прав собственности и доступа.
2. Обычный ES-запрос, который мы передаем непосредственно нашей службе ES, если авторизация может быть проверена.

Запрос:

{ 
    app_code: mobile, 
    brand_code: fashion, 
    query: { 
     // Standard ES Query 
    } 
} 

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

Но было бы глупо разработать пользовательский SDK для ES, поскольку это уже сделано и open source'd. Поэтому мы попытались обернуть текущий ES SDK в виде «facade-sdk», который будет просто включать app_code и brand_code с каждым запросом.

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

TL: DR - Необходимо обернуть другой SDK, чтобы отправить дополнительную информацию по каждому запросу. В настоящее время используется подход к фасаду, но в результате слишком много обслуживания.

Есть ли фасады правильный путь? Возможно, нам не хватает более простого варианта или это просто необходимое усилие?

Answer 1

Решил этот вопрос, указав идентификаторы (app_code и brand_code), просто продленные на каждый запрос, встроенный в SDK.

Это было возможно из-за того, что был создан ElasticSearch SDK, в основном как оболочка для обычного HTTP-клиента, обеспечивающего очень мало необходимой структуры данных.

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