💡 Move STAC backend to stac-fastapi-pgstac

[dchandan]

Description

The recently merged STAC implementation (#297) uses a (i) lightweight implementation of the STAC API stac-app that is based on stac-fastapi and (ii) a PgSTAC backed. It is not clear what advantage this setup provides since there is a dedicated, community-supported stac-fastapi implementation using the PgSTAC backend called stac-fastapi-pgstac that could be used within Birdhouse.

Is there a need to continue using CRIM's stac-app? This could have been a legacy decision, which is why I am opening this issue to solicit input on whether we should change the implementation to use stac-fastapi-pgstac.

Concerned Organizations

Francis and I had useful discussion on moving away from the CRIM implementation a little while back. @fmigneault what are your current thoughts on this?

[fmigneault]

The last update I found regarding stac-app is detailed here: #297 (comment)
I would prefer using the official image if all required extensions are implemented in it to take advantage of the community bugfixes.
From the information I got, the stac-app was only used "temporarily" to patch missing elements from the official STAC FastAPI.

I can see a big difference between https://github.com/crim-ca/stac-app/blob/main/filters.py and https://github.com/stac-utils/stac-fastapi-pgstac/blob/main/stac_fastapi/pgstac/extensions/filter.py, so I'm not sure how many items (if any) would still need to be added.

There are also a few differences in the Dockerfile definitions between https://github.com/crim-ca/stac-app/blob/main/Dockerfile and https://github.com/stac-utils/stac-fastapi-pgstac/blob/main/Dockerfile. We would need to see if the code changes since then work with the latest official image.

[dchandan]

@fmigneault I recall you were mentioning about proposing the stac-fastapi community about using a pluggable architecture that would allow end users to add new features, such as that in https://github.com/crim-ca/stac-app/blob/main/filters.py without needing to create a separate app. Are you still leaning towards that?

[fmigneault]

It depends on how reactive and willing is the stac-fastapi community to integrate proposed changes / new extensions.
If the process is fast, then I wouldn't add this extra complexity. If integrating new extensions slows us down because of their processes, then the capability to inject custom extensions would be more suitable.

[fmigneault]

Relates to #373 (comment)