For a computed column for example?

@agartha you can "emulate" computed columns by defining two functions for the create and update trigger

Great idea. Thanks!

cheers! Just be aware that the computed field must be provided in the mutation itself

For more complex cases, I can always use 'proxy types'. IncomingCustomer with only firstname and lastname, and creating an actual Customer record with all the necessary fields in the event (could be asynchronous too). That way, I don't have that limitation.

that's an interesting pattern, too! need to remember that one 👍

Bonus pattern: that's also what I do when I have logic that is not directly related to a type. I create a generic 'queue' type, with event_type and JSON payload fields, then a server-side subscription with a filter for each event_type. That way, I create my own message queue, with any business logic that I need right within the console, and with the same client side logic.

haha that's genius! Didn't you just start out with Graphcool and already dealing with these patterns?

Well, just started with graphcool, not just started with GraphQL, and with a background as back-end/integration developer (BizTalk), so I'm used to bending OOB functionalities to fit my needs 🙂

man that sounds great! seems like you have a lot insights to share

A blog series 'Thinking out of the box with out of the box functionalities' 😄

😄 I like the title