duckontheweb
commented
3 years ago I could see work done to generalize and implement a link injection mechanism so that other libraries can write hooks into the STAC objects returned by stac-fastapi so that the link/asset injection logic can live in that external project
This would be useful for us. We have some additional endpoints in our the MLHub API that we might want to inject into the landing page links, and I could see it being helpful when we set this up behind a reverse proxy. Having a similar mechanism for asset hrefs would also be useful to us. We replace all asset links with encoded URLs that we then decode in a separate route so that we can track general usage statistics. In our current STAC API, we have to capture the response and replace all of these, but if there were an easier/faster way to do this that would help us out.
What's the status of this PR? IMO stac-fastapi shouldn't host its own tiler - the titiler-pgstac is a good example of standing up a tiler that uses STAC but a separate service that can be deployed independently. In our implementation of stac-fastapi, we override the pgstac backend core client in order to iterate over collections/items and inject tiler links where appropriate. I think this approach allows stac-fastapi to concentrate on just the STAC API endpoints, but allows customization by users if they want to add titiler or other tiling capability. I could see work done to generalize and implement a link injection mechanism so that other libraries can write hooks into the STAC objects returned by stac-fastapi so that the link/asset injection logic can live in that external project. But I don't think we should create tilers directly in stac-fastapi.
Originally posted by @lossyrob in https://github.com/stac-utils/stac-fastapi/issues/97#issuecomment-886217367