React Microfrontend Applications for TVs and Game Consoles

Cool. First of all, let me introduce myself. My name is Denys. I'm principal engineer at the zone. And if you want to check some code samples I'm going to refer to, you can use my GitHub account and also if you want to find any of my contacts, just follow my website.

And at the zone, we change every aspect how funds are engaging with sports, starting from their content distribution to creation of own documentaries and fully extended augmented experience with amazing feature we built, which are working in real time. But what's interesting as well is that we are available on dozens of devices, such as of course, web devices, mobile devices but also smart TVs, game consoles, set top boxes and about these three last three, we're going to talk in now in next 20, 25 minutes or so.

So before we continue, I just want to share this split we have at the zone. We have two groups of targets. One group is HTML5, or we probably can call it React targets, and another one is Bespoke. So today, we will be focusing on the first one. The other one is more for native languages and as you can see it covers so many different targets, which are Samsung, LG, PlayStation, et cetera. There are lots of them.

So now, I'd like you to take all of you to some adventure and show how our architecture journey started, how we iterated over it and what we currently have. And as you can imagine, with Samsung Hue back in 2016, when the Zone just started, it was the way application created by even third party company and we started of course, with monolith architecture because monolith is kind of obvious choice for Samsung Hue as it helps you to grow fast enough at a small scale. Yeah. And it works really well until your development team and features in your application is relatively small. And later on, we stepped into the rapid growth space where we have hundreds of engineers and of course, at this scale, one of the most important things is to give teams autonomy. It's actually where we step in as like engineering company and instead of the third party company, we have rebuilded application completely from scratch. It is a micro front-end architecture where we implemented vertical split of the vertically split of the mains. And just to give you idea of the domains, so domains is something with that time we thought so, with clear boundaries. For example, we have authorization domain which is responsible for signing-sign-up, recovery password flow. We have the catalog domain which is basically responsible for browsing of the content. We have learning page domain which is responsible for C pages and so on. And I believe you get the idea. If you're interested in this journey how we actually like iterate it from the monolith to the microfrontend, I really recommend you this talk from my friend and colleague Max Galla which he did, I believe, last year. Really interesting journey. But same time we also introduced deployment dashboard for our new microfrontends. So this domain can be released independently and that time the only one team were responsible for the entire domain. And everything was well, it was really, I mean, big step forward from what we had previously.

But we continue to grow, we reach the point where we have more than several hundreds of engineers and some of the domains become way more complex than they were initially. So, catalog itself, yeah, it's a place where you can draw the catalog, but it also has quite a lot features. For example, player. Player, quite complex, feature-rich package, adaptive bitrate, digital rights management, other things which it's aimed to support. Later on, we have key moments. You see these dots? Yeah? Right in a player. They are actually representing the interesting moments of the game. We have the thing for various sports, for football, for boxing, for motor GP, and recently we introduced it for the baseball. I highly recommend you to check it out. And we apply various techniques, including the machine learning, to detect them in real time and plot on the timeline correctly according to the video. So, you know exactly when moment happens. As I said, it works for VOD content and for live content.

We have also the panel here, which is sort of mini-app where lots of mini-things integrated, but they all are developed by various teams, such as Formation. They, again, live feature, fully in sync with video. If any transformation happens on the pitch when you're watching the game, it's going to reflect that change, yeah? And as you can imagine, we need something different to manage all of this, because Catalog no longer belongs to the one team. There are lots of teams which are now sit there. So we're getting the same problems. Multiple teams share the single deployable artifacts and we're getting the release congestion because if you're promoting the change between your test environments and probably you have staging for pre-prod and prod environment, and let's say a player tries to release their changes, but they stuck or found an issue, yeah? Any other team kind of blocked with their release because they need to wait until the issue will be resolved or someone going to take out those changes from the code, which is tricky in many cases. We have APAC release statuses even though I just demoed to you. We have a nice deployment dashboard where you can deploy the chapter, its entire chapter. You know the version of the entire chapter, but what version of the package? Well, good luck to find out. You need to either maintain something or develop custom solution for this. Yeah, quite tricky. So we iterated over it and we introduced new microfrontend architecture, which we call ALEP, which stands for Asynchronous Library Loading. So we still keep our vertically splitted domain, but it's complimentary, fulfill it with horizontal feature base split where features can be fetched on parent demand and I'm going to demo it now how exactly it works. So let's consider first from web perspective, what happens in action when you visit the zone. As the first thing, you enter in our website, we're loading your bootstrap. Bootstrap is a model which is responsible to fetch all further chapters. It's also responsible to prepare our runtime environment. It's also like checks your old status to know which chapter to load and some other stuff.

And next, as soon as bootstrap done, it fetches the chapter and let's say catalog is fetched and this is where AliB comes to stage. And to better understand how AliB works, let's consider it from two sides, developer experience and the runtime. So on that developer experience side, teams they have full autonomy developing and deploying their packages when they're ready. And there is a very special thing. In AliB, we have two steps, deployment and release. And if you have deployed something, it doesn't mean that someone will consume it. No one actually will be consuming until release happens. And teams can do the release, updating the specific metadata from the front-end deployment dashboard. Which means in the runtime, catalog fetches metadata about the package first to see what's being released and what should be consumed now in the runtime. And then initialize it on demand.

From the integration to the React, it looks very like on this slide. Basically, there is a hook which is use AliB package. You are specifying the package you are interested in, you are specifying some options, including the major version up to which you are interested, to ensure that all the integrated changes will be non-breaking for your current state. And by that we ensure that packages have a completely independent lifecycle. Teams have full ownership over their minor and patch releases. For the major releases, they need integrational changes, they're going to need to update the catalogue, and it's enforced on the code level. And it fully supports the idea of autonomy and you build it your own statement, which we truly believe in.

Surprise, surprise, we have completely the same micro frontend architecture on TV devices. What we have on TV is different compared to that. We have our runner, or apk, or call it whatever you like, which we're trying to keep as tiny as possible. In best cases it's just URL, in good cases it's just manifest, in some cases it also includes native models because if you need native models they should be integrated there. But later on, bootstrap loaded, and then chapters, and then again packages as you can see on the screenshot. But compared to web on TV and game consoles all targets are different. And they were more different than just different browser engines, because there is a different browser engine, there is different lifecycle events, there are different UI events and different runtime. And something what's available on one target can be just not even possible on other targets. That's why we delegate some extra responsibility on TV to the bootstrap player, compared to web one in addition to the normal functionality. It also supports various transformation such as configuration of various things including key mapping, because left, up, right, down events are all different across different targets. It's also different on Xbox and completely different on PlayStation. Also important, each target has fully independent infrastructure. It's crucial, as you remember. They're all different. So we maintain all our infrastructure with code, and if you're interested how to basically build broad-ready infrastructure for your front end with TypeScript and Terraform, I was doing the talk last React advanced and there is a link for the sample to the similar infra we have. And, yeah, there is a recording as well. So you can check it out.

Similar to the previous one, teams should have autonomy to release to those targets where it's been tested, right? Because they're all different. So, it's possible to promote changes completely independently, so you don't need to go immediately to all targets. You can just release where you've already been tested. But what about development process on TV? Development process from the very beginning always starts in your browser, yeah? So you can use Chrome, Firefox, your choice. For most of the packages we have storybooks, for some we have own sandboxes. It's up to the team to decide what they like for their development needs.

We also have state and UI code mostly shared between targets. We even have cases where code shared between web and TV targets, even though that UI-wise it looks completely different. But state-wise, it can be very similar and you may want to leverage your abilities there. And in order to share, we use different techniques.

One of these is Create React Contexts, basically very powerful and straightforward. The idea here is that on the common code base, you're using components which are available in your context. So in this case, on the target level, you can define which components to pass in and your common code becomes just agnostic to whatever you're going to pass in and it can enforce the interface of those components with the TypeScript.

With the feature flags, with assigned audiences, other popular and very powerful technique because basically with the feature flags you can toggle on or off your component, straightforward. But with the audience complementary to this, you can gradually define on which conditions you want to toggle it on or off. And let's say if you have incident for something, for let's say you haven't tested that there is a memory leak in your fancy new feature on certain targets, you can specify even the versions for which targets you want to toggle it off. For sure, we have target-specific models. As a legacy we also have model swapping. I'm not a big fan of this approach but model swapping, yeah, with us for a while and it's still there but the main downside of this that you need to provide model with a completely same interface without any help of TypeScript or anything else.

And I just want to remind you, on TVs, all the targets are different so we have lots of code shared but it doesn't mean that it's guaranteed that this shared code is going to work out of the box so we need to test something. Well, utilizing cinema room like on this slide kind of cool but requires lots of space at your home and at least you will need good iron cone over summertime. And to be fair with you, we started with this approach where we had sort of cinema rooms. So we have still have those in our office but we come up with something better for the remote working. And on this slide you see very simplified high level version of the architecture of our remote virtual lab where you can see there are two entry points. One is a web app and the other is one end to end tests. So with the web app, you can, yeah, it's really useful for, like, exploratory testing and manual testing when end to end tests can still access our remote devices through the API. API layer is responsible for authorization, cuing, and proxying request to the Raspberry Pi service. Now, on the Raspberry Pi, we have this shared responsibility to control camera in front of TV to make the recording of it and to control TV itself to toggle it on, off, restart, and control the remote. And let me show you how the interface looks like. So we start on the page, we can occupy the device now, device books for us. So when I'm testing, no one else will be using this device. And as you can see, I can use just the web interface, I can use this fancy remote to control it. For some of the targets, we even implemented debugger. And for those who were working with Cardova many years ago before Chrome introduced remote debugger, this plugin can be familiar, but it's been duplicated for a while and we are supporting their own version of it. I also want to bring your attention to the fact, it's not loaded, here we go, that devices, those devices, they are located in different locations. So some of them are located in Poland, others in the UK, and definitely not in your home.

And we need to have flexibility to test our changes. We can't just reinstall every time because it's going to take ages every time we make a change in a new APK. So for non-prod environments, we implemented a really interesting overlay, which you can just open with a specific combination, and it allows you to just type GitHub run ID for your specific push, and in this case, Alip, will respect this run ID for the package and will fetch the exact version of this package. And it's possible because on the Alip side, we have extra thing for non-prod environments. Before Alip does a fetch of the version json to ensure which package should be downloaded, it checks if there's any local storage override. And if there are, then it will respect it. So teams are responsible in this case to integrate a specific GitHub run ID to their push pipeline, which uploads their package to Dev Infra and then Alip is responsible to respect those overrides and fetch them on demand.

As you can see, there are a lot of things teams need to remember, and you may worry how to start a new project with such complex setup. And for this, we are, of course, leveraging the power of teamplates projects. So we have generators created specifically for it, which spin up your project with a set-up pipelines and the best techniques, which we share.

When developing something for smart TVs, there is one special thing about them, right? It's like input control. You don't have mouse or touch, you probably have pointer, but it's a different story. And typically, focus is changed on the reaction on some of your key events. Up, down, left, right. And for this, we have the in-house solution, which is not yet open-sourced, but I just want to share with you an idea how it's possible to address focus management challenges and some open-sourced projects which you can use if you're interested in this topic. So one of the most straightforward approach is probably manually maintain focus map. It doesn't scale at all, but it's very suitable for small apps. And the idea here is that you just create an object which is linked list and you're iterating really in imperative way, switching the active node. The other approach which Netflix utilizes, it's distance-based and priority-based solution where you're just computing closest nodes based on the priorities, left to right, right to left and others, what should be focused next. And the other thing which we're utilizing is a more declarative one where you specify a higher order components like vertical list, horizontal list, and grid. And you make your node focusable by just adding the hook, like use focus in our case. And it tells you it is focus, is it selected, that's all. All those solutions can be combined together so you can check it out and try to implement your own. For some TVs, like LG, there is also another input method which is pointer one, is a magic remote and pointer navigation should be familiar for most of you as it's quite similar to mouse. But with the pointer navigation, we have slightly different behavior on TV because users can move their pointer and scroll at the same time and we need to support it as well.

And you make your node focusable by just adding the hook, like use focus in our case. And it tells you it is focus, is it selected, that's all. All those solutions can be combined together so you can check it out and try to implement your own.

For some TVs, like LG, there is also another input method which is pointer one, is a magic remote and pointer navigation should be familiar for most of you as it's quite similar to mouse. But with the pointer navigation, we have slightly different behavior on TV because users can move their pointer and scroll at the same time and we need to support it as well. And another thing in cases if you want to support horizontal scrolling with the pointer, you need to think about even different UI so you need to ask your designers to not forget about it as you can see on the slide. So, it's quite tricky.

Performance wise, yeah, just I had a full talk about performance separately but this is just general advice because on devices such as smart TVs we're really low in memory and CPU in most cases so we really need to think of rendering and startup performance. Rendering performances happen during user interaction when you have front up, yeah, and here of course one of the like most obvious advices is to avoid paint and layouting when you can. Avoid that. It sounds easy but not so easy in many cases. Render only what is really needed. Nadia Makharevich was doing the talk right before me so I think you all saw it. Avoid useless and heavy renders, yeah. About startup one of course optimize your resource delivery, introduce CDN, be closer to your customers, introduce priority caching, do asset optimization and load only what you need. Oh I also forget about like virtualizing, yeah. Like really, virtualization is very powerful so render only what you need on your screen at the moment. And thank you so much, I hope you enjoyed it. Yeah, if you have any questions.

Thank you so much Denis, that was amazing. So much content. I know we had a little discussion about some of your things and even as I was listening I was like I'm definitely going to go and watch some of the other talks you referenced because it sounded like so much amazing content. Why don't we jump in, this is one that I was questioning as well because you kind of talked a little bit about. There was some functionality you showed on Dazon which was the sort of moments inside the map. Yes, key moments. E-moments. So how do you detect those? Do you use a library or is something else doing that? You talked about machine learning or AI? Exactly, so it depends on which type of sport we're talking because we leverage different techniques. For example, for the football part everything's more straightforward and actually it was the first sport for which we introduced key moments. On the football side we just need to find the exact moment where the game started because we need zero position and all the streams are different because we have different broadcasters, different partnerships, even though the game is the same. And then we're utilizing the data provider which gives us the data and we can plot it.

It's more or less straightforward. With the baseball, for example, we do the detection ourselves with the machine learning to identify the moments and do the synchronization plotting them correctly. That's amazing. That also sounds like such a complex person's problem to figure out. Boxing, for example, is really interesting because when you're trying to detect, we do detection of every round starts, but we also do detection of fighter names because fighter cards are not always revealed prior to the fight, I mean for the entire night, and it's quite interesting. That's impressive. I'll remember that the next time I watch a boxing match. Thank you.