we can switch to a another graphql UI, such as https://github.com/graphql/graphql-playground, but I don’t want to change the data format as it makes things more complicated when the different between events / REST / graphql and so on differs too much.
First of all, thank you for your interest. I think it would be very useful to switch to this editor, which provides more possibilities. But I think you should consider making improvements on the data side as well. Modeling expressions such as “flatData, data, queryContents” on the client side is very difficult and takes an ugly dimension. It should be much simpler. we love you and your support. thanks.
Hi, there is also Banana Cake Pop, not sure yet what is the best.
What is your concrete suggestion for data, I know that the extra dimension sucks, but what is the alternative? If you make it flat you can have consistency issues with the naming, so you have at least to add an extra query with a new model.
At the same time, I think it is necessary to improve the results of the queries. Maybe here we can think together and produce a better result. Existing outputs require us to produce additional internal classes while creating GraphqlRequestModel and GraphqlResponseModel both in terms of traffic and client side. For example: like “flatData” or “iv”.
Every new type costs memory. It is really sums up and I have added a lot of improvements already to keep that low. This is also the reason why I have not moved to HotChocolate yet, which is in my opinion the better GraphQL library: https://github.com/ChilliCream/hotchocolate/issues/3012
When moving everything from flatData to the root level, the meta fields like id and so on have to be moved to a sub property to avoid conflicts, like __meta or so (even “meta” is not safe).
When the different models between rules, scripts, REST and graphql differ too much I have a hard time explaining that.
Actually, I can guess, very radical changes are required. But how does it work on other cms? Products such as GraphCMS and Strapi produce very successful outputs.
For example GraphCMS does not let you create a field with name “id”. I am not sure if this is the best decision they have made, because they will have a hard time when introducing new meta fields.
In general I would say you have these options:
Prefix custom fields (as done in Squidex)
Prefix meta fields with nested object. Because of backwards compatibility we would have to use something like __meta.id or so.
Block some fields (cannot be done later anymore, therefore sucks)
Prefix meta fields (e.g. with __ or so). Sucks because in Javascript and other dynamic languages you usually do not have a deserializer.
So for me only 1 and 2 would work, so what is the point by moving from 1 to 2?
I had a closer look. GraphCMS uses GraphiQL as well with a few adjustments. Together with this library. But even the demo looks very clunky, so it takes a lot of effort to integrate everything properly. Not on my roadmap at the moment.
But there is an example and relatively easy to implement with a PR (I hope)
The company I work for is also very intense in our own development plans. There is a huge increase in our business due to the pandemic. Therefore, I want to be interested if I get the opportunity. Actually, this is a need, but I believe that you can develop such things much faster because you have more information on the system than I do. But since I know what it means to develop open source software, it doesn’t feel right to expect everything from you. I wish my whole day was free and I could develop something together.