Daniela Matos de Carvalho
Feb 4 · 3 min read

We at YLD are using Slack together with missions.ai, allowing our employees to get some relevant information about them or about other people in the company and removing TOIL so our operations staff have more time to do other things. It helps to answer questions such as “How much hardware budget do I still have?” or “Is the person X on holidays?”, or simply to request business cards.

We are grabbing some data about the person from different data sources such as BambooHR, Slack and also some master spreadsheets with other metadata. We decided to go with a GraphQL + Apollo solution for the API and our schema is similar to the following:

Problem

We are currently adding more missions to our list and we saw that querying employee by email is not sufficient for our requirements. What if we want to get an employee information by a field other than email (e.g. slackId)?

What we want is something such as the following:

Unfortunately this is not possible in GraphQL! What exactly do we want?

  • query by employee email or slackId
  • email or slackId are required

1st Solution

One possible solution is to add two different queries and resolvers:

This works and it is an explicit solution: everyone that reads this piece of code understands exactly what it does. However, if we have 10 other fields we might want to query (e.g Github handle or Twitter handle, which are both unique values) we can end up with a messy solution that is not scalable.

2nd Solution

Another solution we can think of is having both fields for the same resolver as follows:

In this case we miss the required (!) field filter in the query and that validation has to be done inside the resolver:

This could also be confusing if you just look at the Query defined in the GraphQL schema. Moreover, if we have multiple parameters to filter from we would have the same issue for all of them. This solution is also confusing and not scalable.

3rd Solution

We ended up using another solution: GraphQL Input Types. With input types you can specify types of inputs ("fields") that can be used in your query. We created a new input type:

We use EmployeeSearch in our query referring it as a required field (!). This way we are specifying that at least one of the fields should be used to perform the query.

This is a solution that is more declarative and clear when we look at the schema. Furthermore, it is widely used in projects like Gatsby (check GraphQLInputObjectType used in Gatsby for details). In comparison with the former solutions presented, using Input Types is more scalable but has the disadvantage of having to filter by field inside the resolver. Also, we should not forget that the resolver must give an Error if either email or slackId are not sent to query employee:

We ended up using input types and making our schema clean and mean. In order to make it even prettier we followed some open-crud specification ideas, which is used by interesting projects like Prisma or GraphCMS.

Enjoy input types!


YLD Blog

YLD's latest thoughts on Software Engineering, Design, leadership and Digital Products

Thanks to Carlos Vilhena

Daniela Matos de Carvalho

Written by

Full-stack Developer @YLDio, @requirelx organiser, @hapijs (bossy) lead maintainer, photography amateur and origami fan :D

YLD Blog

YLD Blog

YLD's latest thoughts on Software Engineering, Design, leadership and Digital Products

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade