[EIC] Give an option to bring your own STAC API

[hanbyul-here]

EIC will use the datasets from VEDA and GHGC, so there should be ways for the data to bring its stac api endpoint.

• This functionality might be needed for NetCDF layer: [DEMO NOT FOR MERGE] Adding support for NetCDF datasets in CMR #714
• For the page that needs to aggregate all the datasets (ex. analysis page), this will make some overheads.

Also tagging @danielfdsilva because this will affect new a&e page.

[j08lue]

cc @abarciauskas-bgse

Related previous effort: NASA-IMPACT/veda-config#301

[hanbyul-here]

I talked with @slesaad about this issue. I am trying to make a decision between passing STAC endpoint from the dataset level, or having some kinds of dictionories like @slesaad 's implementation there. If NetCDF layer requires its own unique STAC endpoint per dataset, it will make more sense to just pass the stac endpoint from mdx level. Can you give me some insights about this matter? @abarciauskas-bgse

[j08lue]

just pass the stac endpoint from mdx level

👌 , IMO

[abarciauskas-bgse]

I think these approaches are actually pretty equivalent

1. The dictionary solution makes it cleaner to reuse catalog endpoints whereas directly passing. We could add the GES DISC cloudstac endpoint to the dictionary approach easily. Another benefit of the dictionary approach is it feels a bit more explicit which catalogs the dashboard supports.
2. The stac endpoint in the mdx makes it completely transparent what the STAC endpoint is

🤷🏽‍♀️ are there other stakeholders or use cases which might influence this decision?

[j08lue]

I really do not have a strong opinion on this - we can make any of these choices and still revise it later, if we learn new things.

One argument speaking for MDX-based endpoint specification:

We have before moved away from central config + external reference (in dataset/story config) in the case of dataset filters / tags. The rationale was that maintaining the content in two different places was an obstacle for our content contributors, who were often focused just on the piece of content they were adding, and we would rather sacrifice the better stability / guaranteed consistency of a central config for a more accessible configuration for our users. I think this also applies to catalog endpoints.

So I would say let's go with MDX-based config for now. If it breaks all the time or makes a set of endpoints harder to maintain, we can still pivot. But if you want to make a different call or put together a quick ADR - please do. 😄

[hanbyul-here]

I think we should put more thoughts into introducing a 'catalog' concept to dashboard, so I made the layer responsible to bring their own stacapiendpoint + tileendpoint for now.
Closed via #744