Closed phortx closed 5 years ago
From looking through the code I think that is quite a departure from the current state. I think we'd be looking at a very small decorator that just receives graphql requests/responses and passes them between Vuex-ORM core and the graphql client.
Another way to say what I'm saying is that plugin-graphql
IS the adapter, and that its job is to shuffle data between the client's lifecycle and vuex-orm's lifecycle.
From looking through the code I think that is quite a departure from the current state. I think we'd be looking at a very small decorator that just receives graphql requests/responses and passes them between Vuex-ORM core and the graphql client.
I don't think so. Yes, it's a bigger change, but something I wanted to do from the beginning.
In my opinion this is not just a small wrapper which passes data from apollo to vuex-orm and back. When you have a look at the QueryBuider and the Transformer classes, which are probably the main logic of this plugin, there's a LOT of stuff going on.
You're right this plugin is a bridge between Apollo and Vuex-ORM, but Apollo is really just some kind of HTTP Client here. It doesn't write the GraphQL queries for us. It's like saying that a ORM is just a thin layer between the database and the application code. It's way more than that, because it has to generate SQL Queries in a sane way. The generation of the GraphQL queries and the transformation of data between those formats is THE purpose of this plugin and a hard job due to the fact that (unlike SQL) there is no one true way how the GraphQL Queries have to look like. And that's something we should solve via different implementations of the QueryBuilder. Call it Adapters, call it Interfaces or call it QueryBuilders, it really doesn't matter.
It's not a change of the concept, just the next logical step in my opinion :)
Thanks for explaining what the vision of the project and its goals are moving forward. I really appreciate that QueryBuilder and Transformer handle a lot of the stuff I would normally not care about implementing when using an ORM. My logic of thinking about this plugin as an adapter to vuex-orm is likely a bit misinformed.
I have an admittedly much more narrow focus on integration with AWS AppSync. In that scope AWS Amplify comes with all the queries, mutations, and schema generated using amplify codegen
. What I'm working on is understanding/implementing an approach for Vuex and GraphQL to stay synchronized.
Ideally this plugin could consume those files, or consider a possible fork that is a specific adapter for AWS AppSync?
Thank you for your feedback :)
Maybe this is possible. I think I will start to change the architecture to support adapters and then we can take a look how we can support AppSync :)
You can track my work on this via this MR: https://github.com/vuex-orm/plugin-graphql/pull/89
I'm open and thankful for suggestions and reviews.
Merged.
Currently this plugin has a strong opinion how the schema should look like, how the types are named, filters are setup and connections are build. This opinion is heavily based on the https://github.com/rmosolgo/graphql-ruby gem and my personal GraphQL Schema design.
However there is no standard way to setup a GraphQL Schema and there are plenty ways to define the schema and name the types.
This plugin should be able to support them all. Currently it supports two connection modes, which is a first approach to achieve this. But a bad one because there is so much more to consider and not only the the connection design.
Therefore I want to have some kind of adapter pattern which tells this plugin how the schema looks like. The adapter would generate the names, tell the plugin how connections work and how filtering works.
There should be builtin adapters for all big implementations like AWS AppSync, graphql-ruby, graphene and so on.
I will put some work in this within the next weeks. Stay tuned.