Not really, apart maybe from a few GraphQL-specific security best practices such as http://stackoverflow.com/questions/37337466/how-do-you-prevent-nested-attack-on-graphql-apollo-server/37338465
Isn’t that precisely because chat apps haven’t yet been overrun with marketing and spam like email? In other words the more people use product like yours, the worse those results will get…
Oh I agree. I think I just didn’t think of putting everything in a single
input argument at the time. But in any case it doesn’t matter too much, because we use generic
edit mutations, so in practice you only have to write your mutation code once. Which I realize goes against your other principle… ;)
In Vulcan this mutation would have three arguments: the post ID, an object that specifies fields to update ($set), and an object that specifies fields to remove ($unset). But I definitely agree with the general principle of keeping a small number of arguments!
Well it requires Apollo to work, so you can’t really use it without it… But on the other hand I would say the value it provides goes beyond strictly being an Apollo toolkit, since you get features like form generation, permissions and groups, callbacks, etc. that aren’t really related to Apollo.
What about reducers? Is it a good idea to have two very different methods of achieving the same thing? I feel like Apollo should probably have a stronger opinion on which one it wants you to use…