Should we return the new version from the design upload service?
Problem to solve
The return type of the design upload mutation is essentially {errors :: [Error], designs :: [Design]}, but as I discovered playing around with the front-end for deletion, the new version is really useful as a return value too. Since each mutation produces a new version, after each mutation, the front-end app has to query to find out what the new version is.
Intended users
This is to improve the lives of our lovely frontend developers in the groupknowledge team.
Further details
Fixing this would the following benefits:
- better, code (and primarily less of it).
- better performance (fewer API calls, fewer network requests, lower server and DB load)
- happier devs
Proposal
Along with the designs, the mutation should return a new field: version :: DesignManagement::Version. The client can request whatever fields they want to on that, and then that can be inserted directly into the app's runtime state. I implemented this for deletion, and it works extremely well.
Permissions and Security
A user who has the right to perform the mutation has the right to see what the new version is. No new permissions are necessary.
Testing
This needs backend implementation and testing, and then a frontend issue to make use of this functionality.
What does success look like, and how can we measure that?
When we send a design upload mutation, we don't have to send a second query to get the new version state.
What is the type of buyer?
This is for premium users, as all ~"design management" features.