Starlette/FastAPI integration about oso HOT 4 OPEN

Please consider Starlette integration instead since FastAPI is based on Starlette.

from oso.

Hey @apadhi20 - sorry for the slow response here. A FastAPI integration is not something we're working on, but I could imagine it being a useful tool for folks out in the wild.

Fair warning: our priority right now is some more internal changes for Oso Cloud, so I think the integration would best be built as a third-party library (as opposed to living inside the oso repo like flask-oso and sqlalchemy-oso).

If you hop into our slack, we'd be happy to help you out if you run into any snags 👍

from oso.

Hey @toxadx, thanks for the suggestion! Will do!

from oso.

For a little bit of background, over a year ago now (phew, time really flies), I was part of a team using FastAPI and we were introduced to Oso while looking for a authorization solution for our SaaS product. I had a short meeting with Graham and Leina and we discussed a FastAPI integration. If I remember correctly it seemed unnecessary or at the very least not a priority because the python library was still in its infancy and was very easy to use. Along those lines, it was unclear that a dedicated library would have much benefit. I have come across some free time at the moment and have still kept up with the development of both Oso and FastAPI and would like to take a crack at contributing to this issue if still needed. I have a few thoughts on the necessity and scope of this integration that I would like to open up for discussion.

1. Looking at the flask-oso library as a reference, the relative popularity does show that there is no detriment in coupling Oso with an API framework. Integration with the already well-documented features of FastAPI would ease any apprehension that new or old users of FastAPI may have with using Oso. As such, I have began formulating a plan that would use the flask-oso library as a point of reference and essentially replicate the functionality into a library that would take into account the design of FastAPI and make the experience of adding Oso fairly seamless (integration with dependencies, Security, prebuilt authentication schemes, etc...)
2. SQLAlchemy is also a very popular choice for FastAPI users as it is well documented and integrates very well with the design of FastAPI. Obviously, the sqlalchemy-oso seems like a natural choice even when using FastAPI and there does not seem like there would be anything to add with a FastAPI specific extension. This suggested fastapi-oso extension would be targeted towards users who are not using SQLAlchemy but using FastAPI. I am very open to feedback on this point.
3. I don't have much experience using Starlette independently beyond FastAPI but as it stands, I do not see Starlette being an appropriate place to position an integration. Starlette is very un-opinionated and does not provide anything beyond requiring scopes related to authorization. A Starlette integration would not allow any additional features and it seems like the python oso library can adequately handle the design of a Starlette API. Not to mention the significant difference in popularity between FastAPI and Starlette independently (based on Github stars). As I see it now, a Starlette integration would need to be independent to the FastAPI one and would just present unnecessary maintenance overhead.

Finally I would love to hear the opinions, if any, of the oso team and whether or not this has been an issue that has been picked up by the internal team. Don't want to be stepping on any toes if that is the case. (Sorry for the verbose response)

from oso.