Closed nrbnlulu closed 1 year ago
Hey,
and sorry for the late reply. As I am a complete newbie to the QML ecosystem in qt, please excuse some questions about the general purpose of what you are aiming for with qtql and how you see rath /turms fit into this.
Do you want to have a sort of databinding between a graphql query with a qml view? And that there is a sort of generalized cache (similar to apollos cache), that would act as the model? What would you mean with auto mutations? Also I am not entirely sure why you would like a Qobject for every graphql type, as then you wouldn't get the benefits of typesafe queries?
I like the idea of having a Qt native websockets implementation, but as of now all transport is asynchronous (and i feel like i would like to keep it that way, to easily enable patterns like retry and buffering) so it would require putting the websocket layer behind a threadpool, which i feel would drastically decrease performance.
I am still expirimenting with whats possible and what is not but the main idea is, yes, have a global object pool for each type.
models are QAbstractListModel
that have only one data type, meaning there is only one model for each graphql type.
as then you wouldn't get the benefits of typesafe queries?
In order to expose data to QML you have to either generate roles
for each field you have on the model or use properties for each field.
originally I went for implmenting dynamic roles thats what @define_roles
does BTS... though I had few limitations
This is why I went for generating properties instead of roles even though it might (reduce preformance though I am not sure because pypy might compile it better) It is much more flexible.
Note that this is only type generation no querying and mutations etc are generated yet
as then you wouldn't get the benefits of typesafe queries?
As you can see from the example it is type-safe ~ though there is much more work TBD...
What would you mean with auto mutations?
generated mutation functions ig.
As you can see, no pydantic or dataclasses involved, and desrialization logic is builtin.
Intro
Qt-QML IMO is a big game changer
One of the big disadvantages in Qt-QML is that Qt-C++ API is very repititive and hard to maintain for data-driven applications.
although it is tempting to just use
relay
or otherJS
graphql lib there is a point where you would suffer from preformance issues (:roll_eyes: react-native).Solutions I had so far
To overcome Qt's "great" API I wrote qtgql Initially it was just ment for API hacks i.e
Also I have made generic models so that you won't have to define
roles
data
update
manage signals emition and so much boilerplate code yourself.you would just declare your model like this
GraphQL support
As I have proggresed with the codebase I realized that I can do better and possiblly mimic some features of graphql relay at the cost of making this project more opinionated. So I decided to rename it to
qtgql
(previouslly cuter :cat: ). Some of the current features:Future vision
QObject
withProperty
for each field.Collaboration
@jhnnsrs What is you opinion about possibly merging the two projects or creating a new organization maybe...