Why We Chose GraphQL for a Hybrid Remote Setting
What is Hybrid Remote and how can you be successful doing it
In a Hybrid Remote setting, the company might have a central HQ office, and a few satellite sites and/or remote employees. This means some employees come to the office daily, while others work remotely from remote sites or from the comforts of their home.
Working in this kind of setting brings a lot of challenges, but it can also be very rewarding.
The PROs and CONs of Hybrid Remote
The benefits come in many forms, some examples are:
- Opens up talent recruitment opportunities outside of areas of high demand
- Allows to increase the number of time zones you can be available for customer support
However, with Hybrid Remote there are some challenges as well:
- Employees might have less access to information
- Fewer career and development opportunities
- Feeling of being a satellite office
When working in a remote setting, one of the main things to consider is how to communicate information across remote teams and sites.
Good documentation and communication are paramount to success.
A few questions might arise from the above:
- What to document?
- How does good documentation look like?
- Where should I document?
- How documentation should be used?
These don’t have easy answers and doing it well involves building a process around it, but in a nutshell it requires cultivating an organizational atmosphere where contribution and peer review are welcomed and appreciated.
Technology that serves as documentation
This might seem odd, but technology can play a big part in the documentation effort. A self documenting technology goes a long way in alleviating the hardships.
Consider coming to work on a Monday, only to discover an API changed and as a result something broke. You now have to figure out what changed and where or how to fix it.
The data might have moved to another endpoint and you just need to find the new endpoint and use it instead. If you’re lucky, the swagger definitions were updated. If not, it’s going to be a gruesome job trying to track down the changes in git and figure out how to fix. If we’re talking about a Micro Service Architecture, then this is so much more complicated.
GraphQL as a self-documenting technology
With GraphQL, thanks to the type system, the schema and introspection, we can very easily track the API change and fix the problem.
The introspection and tooling that come with the technology, along with Query and Mutation autocomplete capabilities thanks to the Type System, go a long way in serving as API documentation and are especially helpful in a remote setting.
Let’s talk about it!
I have been working in this setting for the past 2.5 years and I have a lot of experiences, good and bad to share.
Next month, On May 5th, I’ll be talking about this as a case study in our Meetup.
I’ll go into greater detail into each of the challenges that Hybrid Remote poses, and what worked for us to achieve a successful, productive environment for such a long period of time, and how we improved the process along the way.
Plus, Uri Goldshtein, founder of TheGuild, will talk about an exciting new tech called GraphQL Mesh!
The event will be in Hebrew, you’re welcomed to join us!
<hr><p>Why We Chose GraphQL for a Hybrid Remote Setting was originally published in Everything Full Stack on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>