Add fallback request

[mxiao-cll]

OPDTA-6402

We want a single endpoint to have the ability to invoke two transports and return value from 2nd transport if there is no data in the 1st transport.

• Added fallbackTransport on the endpoint to specify fallback for a given primary
• Call both transport and prioritize primary
• Include the transport name in the output

[github-actions]

👋 mxiao-cll, thanks for creating this pull request!

To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team.

Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks!

[github-actions]

NPM Publishing labels 🏷️

🟢 This PR has valid version labels and will cause a minor bump.

[alejoberardino]

I don't think this is the best way to approach this. In this implementation we're making the incoming requests more complex and adding more blocking paths that could inject artificial delays or error out in ways we're not expecting.
I see this much better suited on the transport layer, specifically only the writer side, and the simplest approach is probably to have a transport that composes two inner transports, only uses one subscription set, and at least at first doesn't try anything too smart and keeps both e.g. the ws connection and a polling to the rest backend where both write to the cache.

[mxiao-cll]

I don't think this is the best way to approach this. In this implementation we're making the incoming requests more complex and adding more blocking paths that could inject artificial delays or error out in ways we're not expecting. I see this much better suited on the transport layer, specifically only the writer side, and the simplest approach is probably to have a transport that composes two inner transports, only uses one subscription set, and at least at first doesn't try anything too smart and keeps both e.g. the ws connection and a polling to the rest backend where both write to the cache.

artificial delays

• Both requests are being fired at the same time, there would only be a slight to none delay when primary fails

error out

• We try catch everything, there is no unexpected errors

where both write to the cache

• I think this is even harder to debug having two things over-write each other. The current setup only kicks in when primary fails, and when it kicks in we have deterministic view that only one transport is in-charge

Also according to Nik

Does Finage guarantee that their REST endpoint and WS endpoint would return the same price at the same time for the same ticker?
 - not guaranteed, no
 - but should be the case almost all the time
 - It should not be sufficiently different to cause rubberbanding

[alejoberardino]

Both requests are being fired at the same time, there would only be a slight to none delay when primary fails
error out

Still a delay that is introduced that would otherwise not exist

We try catch everything, there is no unexpected errors

Sorry if it wasn't clear, wasn't talking about exceptions, but any kind of unexpected behavior as a cause of this change, potential race conditions, locks, etc. I usually also like to think that these framework changes may be used in wildly different ways in the actual EA implementations that could break our assumptions

I think this is even harder to debug having two things over-write each other. The current setup only kicks in when primary fails, and when it kicks in we have deterministic view that only one transport is in-charge

Using the transports would maintain the same pattern debugging-wise that adapters already have, and by manipulating at the reader side you're still hiding the why data was not available on the primary transport (maybe more?).

On a different topic, just thought of the Streams Go images and I think this may break behavior for them due to how they're implemented, but not super sure

[dskloetc]

Approving, but please make sure Alejo's concerns are addressed or not a concern.