Closed (fixed)
Project:
GraphQL Compose
Version:
2.4.x-dev
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Reporter:
Created:
4 Jul 2024 at 10:14 UTC
Updated:
23 Jan 2026 at 09:41 UTC
Jump to comment: Most recent
Problem/Motivation
The simple question is: does this module support mutations out of the box?
There is a mutation for Comments (see CreateComment.php) available but not for Nodes or other entity types. Not sure if the Comment mutations are used as a PoC or not.
So, to summarize my questions:
1) What is the plan with Mutations?
2) Is it a functionality provided by another module so we do not bother on this module?
3) Is there a ready to use Plugin/Class etc on this module we could extend to create Mutations?
Proposed resolution
Create built-in Mutations per entity type (similar to the Queries).
Done on https://www.drupal.org/project/graphql_compose_mutations
Issue fork graphql_compose-3458995
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
almunningsHey, cool chat prompt!
I'm a "write as I think" kind of responder, so forgive me if I ramble.
Mutations are a bit of a clean slate right now.
The comments mutation was a start at it, but it was just to compliment the comments module.
I often found myself torn in two states of mind about starting any deeper integration.
Most of my use cases for writing content back to Drupal have been ad-hoc or really specific. The most useful one I can think of, which I haven't got here is webforms.
I've not yet felt the burning desire to go and create nodes and the node content ui in a headless ui.
If we were to address generic entity mutations, it would be pretty generic, and possibly limited by the nested complexity horrors of things like paragraphs.
Theres also the suggestion that you can just write your mutations in graphql without compose, and you can leverage the compose types for returning content.
I've got a sample module on a repo that I gave someone in Slack.
https://github.com/almunnings/drupal-graphql-sample-mutation
My personal opinion is yes to webforms, and yes to basic entity/fields, and "oh lordy" to extended contrib support.
Do we have any good examples of mutations for nested entity structures (like paragraphs) written by anyone else? Something we could leverage as best practice? I feel like I'd just wing it with some data producer mapped monster.
Comment #3
jmolivas commentedI kinda like the idea of mutations, this could be a separated submodule
graphql_compose_mutationswe definitely need to make sure we are careful to avoid the data producer monster.Comment #4
theodorosploumisI do have a ready mutations module (with exactly that name) but I need some time to create the PR.
In fact, I do have many other submodules I created based on the graphql_compose module but need some work to make them at least ready for review.
Comment #5
jmolivas commentedWhat other submodules and which features are you working on theodorosploumis?
Comment #6
theodorosploumisHere are the modules we are working on. The most interesting are the debug, file_upload, mutations, logout, register, reset_password. The other ones are self explained. They are simply entity related with some minor customizations and extensions on fields.
- graphql_compose_activities
- graphql_compose_debug
- graphql_compose_files
- graphql_compose_file_upload
- graphql_compose_flaggings
- graphql_compose_logout
- graphql_compose_messages
- graphql_compose_mutations
- graphql_compose_posts
- graphql_compose_private_messages
- graphql_compose_profiles
- graphql_compose_register
- graphql_compose_reset_password
Comment #7
jmolivas commented@theodorosploumis Are any of those modules publicly published?
I am interested on the mutations module(s) my goal is to build a PoC adding https://puckeditor.com/ to the https://drupal-decoupled.octahedroid.com/ project?
Comment #9
theodorosploumisIt's not 100% ready but I will create a MR on this issue with what I have for Mutations up to now.
It misses testing and several meta files probably.
Comment #10
theodorosploumisSince I have most of the modules mentioned on #6 ready I have a question.
Should I create a single merge request for all of them together or open an issue for each one? I think the second is better, right?
Comment #11
jmolivas commentedAgree 2nd make sense but not sure how much overhead will add
Comment #12
theodorosploumisComment #15
omarlopesinoI find this issue pretty useful for my use case. I want to build an API and having generic mutations helps a lot to get all the job done.
Don't mind me adding to the MR some improvements:
- Retrieve uuid in generic entity queries.
- Allow reading graphql compose configuration to use the same field names than in the rest of graphql queries.
Comment #17
jmolivas commentedThank you all participating on this issue?
Will be any appetite to manage this as external module "graphql_compose_mutations" to avoid adding more complexity to the "graphql_compose" module?
I did created the project https://www.drupal.org/project/graphql_compose_mutations let me know if people participating in this issue is interested to move and manage code to that place
Comment #18
theodorosploumis@jmolivas Yes. Please add me as a maintainer on the new module. I will push the code there (I have some updates also that are not on current MR)
After that I was planning to publish all the graphql_compose_* modules this year.
Comment #19
jmolivas commented@theodorosploumis I added you as maintainer, let me know once you push the code to take a look and try it.
I think the mentioned modules at https://www.drupal.org/project/graphql_compose/issues/3458995#comment-15... could be submodules of the "graphql_compose_mutations"
Comment #20
theodorosploumisSince we have published the module on https://www.drupal.org/project/graphql_compose_mutations this issue will be closed.
Comment #22
almunningsAwesome work guys.
Thanks for taking the reins on this one!
Credit assigned and added to module info.