What is the difference between the two backends ?

[hall-b]

The documentation presents two backends:

• sqlalchemy
• pgstac

I understand they rely on two different libraries. However, why do we need both of them? Why do you maintain 2 different backends?
How to know which backend we should select? Would it be possible to have some documentation to highlight the difference between both? Finally, does it make sense to have both backends up and running in a production environment or should we run only one of them ?

I couldn't find any information on this so if someone could clarify all this, it would be great.

Thanks in advance for your replies.

[gnosys-ccoupal]

great question. I'm curious about this as well.

[gnosys-ccoupal]

One thing I think I have observed is with Alchemy, since it is an ORM, there are migrations you can run to host the db elsewhere. I have not yet determined how to run the "migrations" to install the database features for pgstac into a seperate hosted db (e.g. functions like get_collection()).

[duckontheweb]

One thing I think I have observed is with Alchemy, since it is an ORM, there are migrations you can run to host the db elsewhere. I have not yet determined how to run the "migrations" to install the database features for pgstac into a seperate hosted db (e.g. functions like get_collection()).

These migrations are part of the pypgstac Python package (see #413(comment) for details). It does seem like it would be helpful to have something in the stac-fastapi documentation that explains how to run these for consistency with the SQLAlchemy backend.

[coupster74]

being new, I didn't even put together the fact that pypgstac was a direct dependency. That clears things up a bunch, thank you.

[duckontheweb]

This is a slight variation on the original question, but I wonder if it would make sense to move the backends to separate repos. Given that there are now a few other backends out there (ElasticSearch, MongoDB, etc.) with different repos it seems a bit arbitrary to be packaging both the core/abstract API code and these 2 backend implementations together. It seems like having them in this repo adds complexity to the Makefile, Docker infrastructure, and testing code, and it also adds some development burden because any changes need to be applied to both backends.

Could we instead have a single stac-fastapi-core repo that includes the stac_fastapi.api, stac_fastapi.types, and stac_fastapi.extension packages and move the 2 backends to their own repos?

[geospatial-jeff]

I think moving the backends into their own repos is a great idea, I see many benefits:

• Enforce better separation of concerns between API layer and backend implementations.
• Allow us to version everything more independently than we can right now.
• Force us to improve testing on the core packages; most of core is tested through a backend implementation instead of directly which is not ideal.
• As you mention, core should be easier to maintain if it doesn't include backends. Changing anything in core right now requires updating the backend implementations as well, and very few people know how both backends work which slows development down.
• De-incentivizes forking; I'd much rather have users pip install stac-fastapi + a backend implementation than forking this repo

[gadomski]

I'm going to close this as fixed by #555.