graphback
graphback copied to clipboard
aerogear
Transactions
In looking through the documentation, I don't believe there is any significant mention of transactions for queries and mutations. Transactions will be very important to support, since they open up a variety of use cases for concurrent applications that update a shared database. I personally have a use case for them in the app that I'm building with graphback, but due to the limited filtering capabilities of the generated schema and the lack of transactions, it's not feasible to actually use graphback for this part of my app, thus I'll have to drop down and execute raw SQL queries against my database, which is not desirable.
Amazing feedback. I have good news - next release going to extend our filtering capabilities soon to cover cases like:
- OrderBY
- Where for mutations
- Some advanced db specific queries.
We still want to keep our promise to have small generated schema. The reason, why we do not provide full query capabilities is that Graphback is designed to work seamlessly with the existing GraphQL servers. This means that if someone wants transactions or some advanced queries like Group By etc. then it is actually much easier to implement it knowing that there is Knex or Mongo under the hood.
We want to reduce boilerplate but also avoid "anemic mutations" or complex queries on client side that could by wrapped by yet another mutation/query on sever.
In terms of the transactions I do think that we should support them out of the box, however, I will need to see what will be the desired way. Creating another field in mutation is not desired. Maybe we can have @transaction
Will full query capabilities be possible with a plugin? I think it is very important to make the query capabilities as powerful as possible. Could the core graphback plugin be simple, while having an advanced graphback plugin to provide the extra capabilities? It seems strange to me that graphback would provide just a little bit of CRUD without finishing the job. What is the point of the CRUD then? It's not very useful as is, because anything beyond simple use-cases can't be supported.
I fear that graphback wouldn't really be used for CRUD if the CRUD isn't fully capable. Personally, I can't consider fully adopting graphback until it can take over all are very close to all of the CRUD for my application.
Could the core graphback plugin be simple, while having an advanced graphback plugin to provide the extra capabilities?
That sounds like an amazing idea. However, we could simply have extra CRUD flags to disable enable features to minimize the amount of code we will need to maintain.
TL;DR - We already started adding more CRUD capabilities and going to tackle more advanced CRUD capabilities in next release
Just checking, have the new CRUD capabilities been added in the latest release, or are we still waiting?
Just checking, have the new CRUD capabilities been added in the latest release, or are we still waiting?
It is not fully released yet, but a preview is available to try out in version 0.14.0-dev1!
I will hold off for the day. We hoping to release more refined version today.