This requires a little bit of background knowledge, so I apologize if I am not clear enough.
I have an ES (ElasticSearch) service that is exposed through a secondary API.
The secondary API is responsible for checking ownership and access to content, this is done through standard HTTP Authorization
and two identifiers an app_code
and a brand_code.
We have this implemented by having the secondary API take a request composed of two "parts":
Request:
{
app_code: mobile,
brand_code: fashion,
query: {
// Standard ES Query
}
}
We have a lot of external developers needing to use our ElasticSearch service - as thus we want to help streamline their practices by providing a SDK.
But it would be silly to develop a custom SDK for ES, as this has already been done and open source'd. So we attempted to wrap the current ES SDK in a "facade-sdk" of sorts, that would simply include the app_code and brand_code with every request.
This however results in a lot of maintenance as we now have to take every method in the original ES-SDK and modify it to now also include the other two identifiers.
TL:DR - Need to wrap another SDK to send additional information with every request. Currently taking a facade approach but ending up with too much maintenance.
Is facades the right way to go about it? Are we possibly missing some easier option or is it just a necessary effort?
Solved this question by having the identifying (app_code
and brand_code
) simply extended on every query built inside the SDK.
This was possible due to the way the ElasticSearch SDK was built, basically as a wrapper for a regular HTTP client, enforcing very little of the required structure on the data.
This meant that we could simply have the external developers use the SDK, and have them directly extend the data with the required parameters.