Mimic Pyth Pro latest price endpoint

[hacheigriega]

Motivation

Injective OP is currently using POST /v1/latest_price REST endpoint of Pyth Pro through standard upstream module. This PR provides a way to mimic that endpoint through the Pyth Lazer module.

Explanation of Changes

We make fetchFromModule optional for Pyth Lazer module route schema. If it is omitted in the route configuration, the module will use this new POST body-based request handling.

Testing

{
	"modules": [
		{
			"type": "pyth-lazer",
			"name": "pyth",
			"pythLazerApiKeyEnvKey": "PYTH_LAZER_API_KEY",
			"priceFeedIds": [{ "name": "BTC/USD", "id": 1 }],
			"priceFeedsCleanupTtl": "20 seconds",
			"priceFeedsCleanupInterval": "10 seconds"
		}
	],
	"routes": [
		{
			"type": "pyth-lazer",
			"moduleName": "pyth",
			"path": "/v1/latest_price",
			"method": "POST",
			"channel": "real_time"
		}
	]
}

curl -sX POST http://localhost:5384/proxy/v1/latest_price \
  -H "Content-Type: application/json" \
  -d '{"priceFeedIds": [1,5]}' | jq

curl -sX POST http://localhost:5384/proxy/v1/latest_price \
  -H "Content-Type: application/json" \
  -d '{"priceFeedSymbols": ["Equity.US.AMD/USD"]}' | jq

Related PRs and Issues

Supersedes #137

[Thomasvdam]

I'm not entirely sure if this is what we want/need but it might be sufficient if we're mindful of the limitations.

If I remember correctly the original idea of this was to enable the module to serve as a drop in replacement of a 'regular' Pyth Pro REST proxy. All Fast data proxies for Pyth Pro are currently using the REST interface so there are some latency concerns there. This implementation only provides support for a single route so we'd have to make sure that this is the only thing existing OPs are using and be mindful that future OPs can't use any other REST endpoints.

[hacheigriega]

This implementation only provides support for a single route so we'd have to make sure that this is the only thing existing OPs are using and be mindful that future OPs can't use any other REST endpoints.

Currently Injective seems to be the only one using Pyth Pro DP. While the DP is configured to support any paths, the only path that is being used is the POST /v1/latest_price route that this PR tries to mimic.

[Thomasvdam]

This implementation only provides support for a single route so we'd have to make sure that this is the only thing existing OPs are using and be mindful that future OPs can't use any other REST endpoints.

Currently Injective seems to be the only one using Pyth Pro DP. While the DP is configured to support any paths, the only path that is being used is the POST /v1/latest_price route that this PR tries to mimic.

In that case it could be worth considering to update the OP and injective data proxy.. Then remove all Pyth Pro REST references from the oracle-programs and from now on only use the Websocket module? What's your take?

[hacheigriega]

In that case it could be worth considering to update the OP and injective data proxy.. Then remove all Pyth Pro REST references from the oracle-programs and from now on only use the Websocket module? What's your take?

If we're allowed to do that, yeah that would certainly be preferable to this PR. I assumed @jasperdg implemented this because modifying the OP and injective DP was not an option

[mariocao]

Any update on this PR?
My take is that I don't think we can or should change the already deployed OPs, but make it backwards compatible.

[hacheigriega]

Any update on this PR? My take is that I don't think we can or should change the already deployed OPs, but make it backwards compatible.

I am thinking to spin up a new data proxy to test using the existing OP inputs, and, if this works, we replace our Pyth Pro DP deployments with this. From the OP's perspective, nothing should change.