Consider sharing implementation with graphene-django

Bắt đầu bằng cách so sánh phần triển khai trùng lặp trong graphene-django và graphene-sqlalchemy, sau đó xem xét các issue được liên kết về overfetching, quyền, filtering và các truy vấn N+1. Công việc được xem là hoàn tất khi đạt được thống nhất về ranh giới của một thư viện dùng chung và kế hoạch cho các tích hợp dành riêng cho ORM; issue không nêu tệp, test hay entry point nào.

Problem

I was surprised to see that graphene-django shares a considerable amount of code with this library. Almost line-for-line in some instances if you blur your eyes to the types. Unfortunately that means it also shares some common bugs, missing features, etc...

Worse-off for this library, the graphene "team" seems to prefer graphene-django by a 3-0 vote. Which might explain why that package has additional features over this one 😉. Not to mention, there also several graphene-django-* packages that tack on to grpahene-django[1]

Both libraries essentially represent the same thing: gluing your Python SQL ORM into graphene types. (Note that these aren't the only players on the field either [2])

Proposal

Find the middle ground for "here's how to take a declarative ORM and transform it into graphene types", and have graphene-django and graphene-sqlalchemy fill in the ORM-specific slots (how do I convert this ORM field type to a graphene field type?, etc...) and add additional features offered by that ORM.

This means that contributors who can bring valuable graphene expertise can contribute without heavy knowledge of an ORM, and aren't splintered across repos. Valuable features can be added to a single scaffold repo and then be filled by the implementation-specific repos much easier.
It would also mean core features/issues are located in one library.

I've outlined below (what I think) the key features that a shared library should attempt to solve, in addition to reducing the amount code copied between the two libraries.

Similar issues/features

(there's more issues/features duplicated between the two, but those are the "big ones" IMO that stop these libraries form being true works of art)

drawbacks

With maintenance being scattered, it might be hard to find the right people to create/maintain such a library. Furthermore, maintenance/contributions would need to generic enough to satisfy several downstream libraries. However, from what I've seen scouring the issues and related libraries, there's no shortage of people willing to solve the hard problems. 👍

notable parties

@syrusakbary @jnak @Nabellaleen @Cito @patrick91 (plus whoever else y'all wanna tag)

[1] graphene-django-tools, graphene-django-optimizer, etc...
[2] @coleifer who authored Peewee showed interest in support (graphene#289) but recently said it wasn't being pursued (peewee#1790)