How and why did we end up using GraphQL and Apollo? The tech sphere is obsessed with the latest and greatest tools - no we haven’t got Rust in our codebase…yet!
Working in healthcare gives you a slightly different lens, you want to use reasonably well established tools balancing Boring Technology … with some experimentation in less critical infrastructure areas.
Our frontend data-fetching and state layer is a prime example of an area that we need to be robust and consistent - we also can’t afford to migrate it to the latest hotness every few months.
Why GraphQL
REST with Redux/Sagas and fetch felt like an over complication, we were essentially maintaining two different structures of our data - one in redux and one on the backend.
This complicated saving and transformations.
It was also difficult for developers to keep a mental model of the reducers, what they contained, when they needed to be refreshed, which actions refreshed them … and so on!
Relay
When we started scoping out a new project we investigated what was happening in this space, GraphQL had taken off and had stable libraries in multiple frameworks, namely Relay and Apollo. After doing some proof of concepts we decided to back Relay, the interface seemed straightforward enough to implement and it checked off the usual CRUD requirements.
The next year was frought with painful caching issues, complex constructed queries and nonsensical optimistic mutations. Luckily for the team that project ended up plateauing and moving into BAU.
Apollo
Our next project was to be longer term, we PoC’ed out Apollo with some of the learnings of pain points from Relay. Neither library seemed to handle optimistic updates that added new nodes + modifying those nodes before they have synced and received “real DB identifiers”, though we accepted that and moved forward.
Apollo has served our needs well adding and exposing new data to the frontend is easy, if it’s already on the model our frontend devs don’t have to touch backend code! We don’t have to put in additional work to sync our backend and frontend state - the data models persist throughout the stack. Most of our technical debt comes from not fragmenting out queries to the right degree and mutations that have been abstracted out to support things like dynamic autosave on fields.
Conclusion
Most people knee-jerk when they see GraphQL and want to move back to REST, I think a lot of this is inertia. GraphQL certainly doesn’t solve all problems but not having to consciously sync state and maintain reducers is a worthwhile trade off.