While you are asking a GraphQL question (a domain to which I claim less than little expertise in) I’m sensing the possibility that you may have some inconsistencies on the detail level of the underlying model that are manifesting themselves when you are trying to formulate a higher level abstraction.
Right now those details are clear as mud.
So far it seems that an alarm is an instance of an event or possibly an event is part of an alarm.
I am mixing ‘event’ related functionality with alarm functionality.
By your description both concepts are coupled.
- Is it that all alarms are events but not all events are alarms OR
- An event is part-of an alarm - if so what are alarm’s non-event parts (if any)?
create a new “event-alarm” endpoint, which works more like a Rest endpoint, i.e. it is more monolithic, less ‘normalised’
Is there any value to exposing your notion of an “event” via the GraphQL interface? You may have good reason to only expose an API to a concrete and segregated set of event types, alarm being one of them without ever exposing a generic event interface.
Then there is the separate decision of representation, e.g. does alarm have an embedded “event” field or do you denormalize the event data into the general alarm data.
About Face 3: The Essentials of Interaction Design (2007), p.31
Your database tables are simply a projection of the “domain model” into the relational realm, possibly adjusted to accommodate non-functional requirements (e.g. performance with reference to the queries and updates being issued). The design of your GraphQL interface should likely be guided by the “domain model” - not the currently implemented datamodel in your database.
