Why does `shared-libs/outbound` use `shared-libs/couch-request`?

Development
1

Maybe another way to ask this is if the purpose of shared-libs/couch-request is to wrap all HTTP requests made by CHT code or just requests made to Couch??? :thinking:

It just smells a bit weird when the outbound code uses couch-request to post data to an external service. :person_shrugging:

Is there some kind of logging/proxying benefit we get out of this, or could outbound just use its own global.fetch? Should we just rename couch-request?

I see the outbound code was originally updated from request-promise-native > couch-request back in this mega PR which initially added couch-request. However, the description on that PR specifically notes:

Note: Have not changed the use of request-promise-native outside of calls to Couch.\

This make me wonder if the change was even intentional…

Now I am reviewing this new PR which add support for new headers on outbound requests, but needs to make a bunch of changes to couch-request to be able to handle them… Just wondering if it would be more simple to not run outbound through couch-request.

CC @diana @twier @magp18

2

I think the “couch-request” is probably poorly named, as it gradually replaced all instances of request-promise-native. It is clearly more generic than “send requests to Couch”, and is indeed used for just about all requests.
It handles a lot of the boilerplate required to have a good fetch interface. If you switched outbound to not use it, a bunch of that boilerplate would need to be duplicated.

That said, outbound requests are special, and there is a possibility that they will require more and more special cases, so I am of two minds. I don’t think outbound should exert ownership over couch-request and add a bunch of logic there only it uses.

3

:+1: Got it. Thanks Diana! I think this is basically what I needed to confirm.

For outbound, the main change we are looking to add to shared-libs/couch-request is support for sending requests via a proxy. To me, this feels like something probably only relevant to outbound (where we need to communicate with external services).

I will look into how feasible it is to keep the proxy logic in the outbound code while still leveraging shared-libs/couch-request. (Though, TBH, it is not much logic anyway, so probably not the end of the world to just bake it in… :person_shrugging: )