building-envelope-data / api

API specification to exchange data about building envelopes
MIT License
3 stars 1 forks source link

Update `database.graphql` and `/queries/` #311

Closed christoph-maurer closed 1 year ago

christoph-maurer commented 1 year ago

database.graphql does not contain mutation yet. When it is updated, we could add the ExampleMutationQueryFromSW.txt to /queries/database/.

I could use the queries with which I have created the data sets of the TestLabDB to create /queries/database/tutorial.graphql.

@simon-wacker Is it better to have only one file tutorial.graphql in /queries/database/ and /queries/metabase/ or is it better to have several files covering the full functionality? Currently, we have only one file in /queries/metabase/ and several files in /queries/database/.

simon-wacker commented 1 year ago

database.graphql declares only what is needed for the metabase to communicate with databases. In our case, what is needed is querying for data and nothing else. Mutations do not need to be enforced (because the metabase will never try to add data or other information to databases) and they should not be enforced (because the workflows of adding data to databases varies from institution to institution; for example, some institution may have a complicated process consisting of various steps to submit new data like LBNL has and another institution may only serve data through a GraphQL endpoint to conform to our GraphQL schema to be connectable to the metabase but handles data submission through REST endpoints or other means). The mutations you linked above currently work for the primitive reference implementation and this is where those sample mutations belong.

Whether we need one tutorial.graphql file or multiple *.graphql files depends on what we want to achieve. In general, there are different GraphQL requests for different purposes and whose outputs depend on the state of the application. For the reference implementation, a tutorial could exist of various GraphQL requests that need to be executed in a specific order and whose results like generated UUIDs need to be fed into subsequent requests. In that case, I would suggest using multiple *.graphql files. For the simple reason that this step by step process cannot be put into one valid *.graphql file (its contents need to conform to the GraphQL operation specification). For individual and independent examples, I would suggest putting each into its own file with a speaking name.

christoph-maurer commented 1 year ago

For the reference implementation, a tutorial could exist of various GraphQL requests that need to be executed in a specific order and whose results like generated UUIDs need to be fed into subsequent requests. In that case, I would suggest using multiple .graphql files. For the simple reason that this step by step process cannot be put into one valid .graphql file (its contents need to conform to the GraphQL operation specification). For individual and independent examples, I would suggest putting each into its own file with a speaking name.

Thank you for the clarification @simon-wacker !