Remove proxy to a2o API

[geohacker]

Based on conversation with @atruskie, we should remove the proxy to a2o API. This is not required immediately. Once the JWT token feature lands on the a2o API, we will remove the proxy and have the frontend directly query a2o.

cc @willemarcel @oliverroick @sdenton4

[geohacker]

@oliverroick for the audio download endpoint, I remember you ran into a CORS issue with the a2o API. Was on requests originating from localhost?

[oliverroick]

yeah correct, the CORS issues was when sent requests directly to the A2O API

[atruskie]

Ok I think perhaps this issue should be tweaked. It's not bad that the proxy exists - the caching for high demand is a good enough reason - but I raised two issues yesterday:

1. The token mechanism you're currently using should not be expected to work as is in the future. The tokens are meant to be short lived access tokens. After I ship the correct behaviour, you will need a mechanism that regularly "logs ins" and refreshes the token.

   • JWT access (stable tokens) are rolling out in the same patch, but I wouldn't count on it working - it is an internal feature at this stage (they would in theory work, but we don't have the time to finish that for you).
   • More importantly: do you even need a token at all? Most of the data you're accessing should be available by public/anonymous authorization?

2. For future integrations we want to ensure using the embeddings and search APIs are not accessing data from our A2O API.

   • because the net result is a loop: our API querying an external service which is turn querying our API....
   • So, I asked if there was a clear delineation between the embeddings/search and metadata/proxy APIs?
     • I believe the answer here is, "yes" based on what you've told me, and the code I've skimmed through the /search/ and embed APIs not query the A2O API at all
     • So, this is a non-issue

As for CORS access: let me know what domain and I'll update the policy.

[geohacker]

Thank you for clarifying @atruskie. I think I got it mixed up a bit.

More importantly: do you even need a token at all? Most of the data you're accessing should be available by public/anonymous authorization

This would be great, actually. We can remove the current token and test out. Like you say, I don't think there are any endpoints we use that probably need auth.

/search/ and embed APIs not query the A2O API at all

Yes that's correct.

So all good here. In terms of next actions:

• [ ] DevSeed to remove the token and see if all requests work
• [ ] Eventually remove the dependency of the proxy for the frontend