Writing one component is easy. Conditionally rendering two different ones is still not hard. But what if you face an "n" number of permutations. "n" number of different UI elements and scattered business logic? Switch statements all over the place. Might not sound scary when we write the code. What about your future self? Cognitive load fires off the roof. Maintaining your code? Onboarding new devs? Good luck. Sounds all too familiar? Let's see a possible solution how to tame complexity. How to tackle a large number (possibly infinite) of branches in a frontend codebase without losing our sanity.

We currently worked with an API that had to scale to serve multiple regions and millions of users. Introducing caching for such numbers is a common and battle-tested way to reduce costs. With services like Stellate, this is no longer impossible even when using GraphQL.

That is great news, however, also poses some challenges. We need to pay attention to how structure our types so we can fully utilize caching.

How to rethink some GraphQL schema designs so we can have the best of the data-driven paradigm of GQL and have amazing caching capabilities at the same time?