GraphQL and modeling domains
I’ve been a big fan of what Apollo is doing for a while, and recently they have been doing various interesting talks and interviews. In this post I want to review and share my notes about the conversation that happened on February 24th 2021 around GraphQL modeling and backend driven UI.
Yes, I know that’s now what the title of the video says. But I think there is not very much to take out from that video about federation. They mention a bit about organisation structure, but nothing that caught my attention. Instead, there are some important things to learn about modeling and designing systems.
Let me share my experience and views on the topic.
At Lifeworks we’ve been using GraphQL for over two years now. So one could say I have a bit of experience with it. During all this time there is one thing that just keeps coming back: the most important part of GraphQL is knowing how to model your domain.
Seems quite obvious, right? After all, you are defining a graph of entities for your domain. But often we get lost in other more fancy things like how nice is having a schema for your API, types, an amazing cache, subscriptions, etc. But none of that matters if your schema design is not ideal.
If you want to focus on something important, that will help you be good at GraphQL, my advice is to learn how to model domains. It’s not specific to GraphQL, but is a skill that often developers ignore. Luckily for me I had excellent teachers at University that reiterated the importance of it.
The nice thing that is discussed in the video is about understanding that the graph is something that can evolve. And I agree with that sentiment. Defining your graph is an iterative process that benefits from experimentation. You don’t have to be afraid of taking some decision that is now correct for your product and later deprecate it and evolve it in another direction. That’s a nice thing about GraphQL, it understands deprecations. This is often important if you’re trying to sell managers on GraphQL. It’s likely that it involves a migration and you can’t “stop the press” for it. So focus on delivering value and do a migration bit by bit.
This is how we did it at Lifeworks. We started our schema as a proof of concept for a new and shiny new feature. After that we started migrating the rest of features that are related to the first one (they belong to the same feature team). And nowadays we are undergoing a migration of the rest of features using Federation.
Being able to do it bit by bit and keep growing the schema is important. But this shouldn’t be used as an excuse to have a poorly design graph. Think about it properly and try to do it properly sooner rather than later. Make every step a correct step. Yes, you can deprecate things and perfect it over time, but it won’t be without friction. Know how to model and you will do yourself a favour. 😉
Backend driven UI
Another interesting topic that the video talks about is backend driven UIs. This is another thing I introduced in the product years ago. I implemented a simple backend service that returned a JSON structure for a landing page build out of components. In fact, this is where the beginning of HubKit started, a homegrown UI component framework.
Having a system like this is super cool when you want to have a dynamic screen that can adapt and change a lot. For me the goal was to improve our Perks home screen. It’s also interesting because you can slowly build up the system. You can start with a simple backend returning a hardcoded JSON. Then you can introduce dynamic elements, eventually linking it to a CMS or even some fancy AI.
But then enters GraphQL, which in people’s mind contradicts this completely since GQL is all about giving the power to the frontend. But in reality, it can totally be done. You just have to design your graph based on some component entities. The FE still benefits from being the one in control. For example, the component library can grow without breaking changes.
Some slides from the video to illustrate the point:
Yes, you need to have components and a proper design system to do this. But you should have that anyway nowadays.
Conclusion
The video is very interesting. I really recommend it if you want to see how GraphQL is used in production and how a company migrates from old technology to a modern graph.
If you need to take one thing out from all of this, it should be: learn how to model a domain. That will help you in so many aspects, not only on GQL but also in any other product development.