Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Firestore DB Support #50

Closed
SamuelBradley opened this issue Dec 5, 2019 · 3 comments
Closed

Firestore DB Support #50

SamuelBradley opened this issue Dec 5, 2019 · 3 comments
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@SamuelBradley
Copy link

Hi,

This library looks fantastic and I'm going to try and use it for the easy mongodb integration with FastAPI.
What I would be interested in (and may look to contribute myself) is a FirestoreClient (GCP's serverless document db) that could work as a drop in replacement for the mongodb client as I'm seeking to support both in a project i'm working on. I can see the intention of your design is to provide a nice abstraction to the DB technology, this use case would put that to the test with a second implementation.

@levchik levchik added enhancement New feature or request help wanted Extra attention is needed labels Dec 5, 2019
@levchik
Copy link
Contributor

levchik commented Dec 5, 2019

Hi @SamuelBradley,

Thanks for your interest in this library. Adding more "backends" to support multiple DBs is a great idea if we can actually support those longterm. We're gonna face some issues for quite some time after initial release and it is crucial to be able to fix bugs and plan for new essential features.

I'm not very familiar with Cloud Firestore, but as far as I can see there is a separate (from mongodb) official library for interacting with it (firebase-admin). And I don't see any async-flavoured client libraries for the DB so at least that might be a big problem. If you've got info on how to use Firestore with pymongo package that might help estimating amount of work needed for integration.

Other than that, I indeed have plans to write abstraction or even consider some existing NoSQL ORMs (if you can call them that at all). I had an idea to separate non-DB and DB related functionality into two different packages so that if you don't need any of the DB stuff you could omit that. So that is also something to think about in terms of what this library (or possible several libraries) is all about.

So yeah, if you're interested let's collaborate on that.

@SamuelBradley
Copy link
Author

Ahh you may be right about the async being a challenge, google's cloud libraries seem to be quite particular about their python 2.7 support. Also no obvious compatibility with the Mongo libraries you are using. Probably not a good choice for a 2nd "NoSQL ORM" implementation, but might be easier to implement as a 3rd once there is a proven abstraction between multiple implementations.

I may of jumped the gun a bit :) but i'm still excited to use the library looks like it's going to make working with mongo really easy.

@levchik
Copy link
Contributor

levchik commented Dec 6, 2019

Our db module should be easy to use for popular functionality like CRUD & Pagination but for more complicated structures it could be challenging to make queries (relations with other collections for example or event custom grouping). I guess it will be difficult to make such queries anyway, but yeah, it is something to bear in mind.

And if you decide to give it a try I would appreciate any feedback.

@levchik levchik closed this as completed Dec 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants