Now you are probably wondering why did you have duplicate infra?

Well, yeah… It makes no sense and the answer could be as simple as Homer Simpson's: It was like that when I got here.

Just kidding. Although that is true, it does not really answer the question. The reason why we had duplicate infra is because the teams did not work together. They were different teams with different processes and goals. Only after some time we realized that they should work together and, as soon as we consolidated them as one team, we started to see the benefits in doing so.

GraphQL as the API Gateway

I remember the day I spent some hours staring at the window thinking about all the functional requirements we had. To nobody’s surprise, the more I reviewed everything we needed to support, the more GraphQL started to make sense.

I mean, it fits like a glove on some of our requirements:

While TVs need a big program poster, mobiles need a small one.

We need to show exactly the same video duration among all clients.

Video duration should be formatted following the same pattern / template in all interfaces.

TVs should provide detailed information about each program, but iOS and android could show only a poster + program title.

Of course the requirements were not exactly these, but you got the idea.

If we had decided to go with a backend for each frontend, we would easily end up with four backends — and we are not even considering that we have multiple types of TVs (which need different kind of support), game consoles, TV boxes, etc...

Also, can you imagine how big would be the payload if we decided to go with a single Rest API supporting all these clients?

At that time, I was very excited about GraphQL!

Given the scenario we had, we were indeed very excited about what GraphQL could give us in terms of being an API Gateway to help us to consolidate our infra, providing the flexibility so the clients could access different variations of the same data and, last but not least, it would be the living document of the schema we were going to provide to clients.

It was all good if we did not have some small but uncomfortable concerns: performance and caching.

Of course we had more concerns (dozens, to be honest), but those two were the major ones. In order to try to address those concerns we decided to start a proof of concept about GraphQL called Jarvis.