DEV Community: Bojan Todorović

A day in life of a senior (UI) engineer

Bojan Todorović — Sun, 19 Dec 2021 21:30:05 +0000

I am a Lead Frontend Engineer in a team of 13 people at Redbox.
Redbox is a streaming service, we offer a wide variety of movies and TV shows on demand. Those of you in US might recognize the name from the red kiosks all around for renting DVDs and Blurays.

Being a streaming service we have apps covering many TV platforms, Samsung, Vizio, LG, VewD, PS4/5, Xbox, Roku, and more to come.
Our main projects are native Roku app, and web app that supports every other platform besides Roku.

But business occupies a whole spectrum, from customer facing, to internal tooling. My team has about 10 projects we maintain.

I often encounter beginners that think seniors write thousands of lines of code daily, deploy it to millions of users, and somehow it is all stable all the time by itself.
I even forget I was once a beginner that thought something similar.
But, those of us in the "trenches" know better.

So, how do engineers manage to create stable apps people use every day?
How does a day of a senior frontend engineer look like?

Step 1: check email

So, my morning starts simple enough.
I quickly check my email. It takes 5-10 minutes, I got stuff organized in folders so I can make easier and quicker sense of stuff.

Step 2: check metrics

I move onto taking a short look at Grafana charts for performance of our backend services that my (frontend) team maintains. These are small in terms of backend code, but important, as they deliver stuff like feature flags and various misc content from CMS(like Terms & Conditions texts).
We do have alerts setup for critical scenarios, but that doesn't excuse not manually checking for trends.
This is what some of these charts may look like, they're fed by Prometheus into Grafana.
We got error percentage, Redis used memory, event loop lag, and so on.

Step 3: check bug monitoring

After that, I move onto the bug monitoring.
We use Bugsnag.
Again, alerts for critical stuff are setup here too, but manual checks are desired.
There's a timeline of bug trends and view of bug events themselves, with all the good stuff like stacktraces, breadcrumbs, custom event data an app might attach, etc.
Unhandled errors are setup so they automatically open bugs in Jira, handled stuff usually not. But, just because an error is handled, does not mean it's okay for it to occur. It might, for example be a symptom of some issues at the backend, like on the data sync side.

These 2 monitoring steps are not something that all team members are required to do every day, but we encourage everyone to be comfortable with them.

Step 4: deployments

Next, if there are any deployments to be done, I like to do it now.
This is not something I alone do.
We encourage everyone to be comfortable with the process of deploying to production. As in CI/CD, deployment is something to be seen as (daily) routine, not a big deal.
After merge to master, Jenkins builds our code, and when build is done Spinnaker automatically deploys it to staging.
Test automation starts running right away on freshly built stage instance, and our manual QA folks are automatically alerted by a webhook in a chat about the new build in staging, so they can pick it up too.
Once everything is greenlighted, production is just a click away in Spinnaker.

Step 5: code reviews

After all these usually short endeavors, I move onto code reviews. Since we have many projects, that are in separate repos, we have a Gitlab CLI utility that lists open merge requests on all our projects.
This is what that looks like, it's a simple script but quite helpful.
We have a rule, code review takes priority if you're in between tasks, and having opened merge request more than a day old is considered a red alert for taking up code review.
This is because we embrace the trunk based development, with short lived branches only.
Merge request => code review => merge to master/main => test => deploy as soon as possible.

Step 6: daily team meeting

After this point, we usually have a short daily meeting.
A short status update and getting rid of various misc doubts and blockers people might have.
We encourage people to also do this by a chat at any time they have doubts about some approach and would like to get a consensus from team.

Step 7: actual coding

And finally, we got to the actual coding.
I'm not going to get into the details of coding, but just an overview of the process.
Every one of our projects has it's own Jira board, but as a rule we don't venture there for picking up a task, as that would be too chaotic.
We have a team Jira board, that pulls tickets from all Jira boards of projects our team maintains.
A master board, if you will.
As a developer, this is your taking off point.
In this board, priority is by sorted top to bottom, so developer doesn't have to go "window shopping" for a ticket. First ticket in TO DO column is yours for the taking.
We are doing Kanban with a backlog, also called Kanplan.
The spin is we embrace what is called zero bug policy. Meaning, bugs can't be in backlog, and they take priority over stories/features.
This does not mean our UIs have literally 0 bugs at all times, or at any one time for that matter, only that bugs don't get to live happily ever after in the backlog. We either fix the bug ASAP, or declare it as not relevant and close it.

Step 8: afternoon meetings

In the afternoon, as a lead I usually attend some meetings.
This is usually for various planning/grooming purposes with product people.
We all know how fun this is, so we try to spare other team members from it as much as possible.

Step 9: misc

Some other things that can pop up here and there.

Triage, which I sometimes do by myself, but also bring in other team members when needed. We have no strong rules here, we do it when and if it is needed when bringing tickets from backlog into TO DO world.

Retrospective once a month to review our team practices and processes, and try to improve.

Feature flags are setup for most of major features, with optional A/B testing. As soon as work on a major feature is started, feature flag for it is set up. In this way, doing parts of a new feature and opening small merge requests is doable, because unless feature flag is turned on, partially done feature won't be visible to users. It goes hand in hand with trunk based development, since everything is on master/main and in production all the time, but we have control over what users see.

Step 10: And that's pretty much it. Now you know (almost) everything

Thank you for your attention and take this inspirational quote to go.
”What one programmer can do in one month, two programmers can do in two months.”

Frederick P. Brooks

ReacTV

Bojan Todorović — Sun, 19 Dec 2021 12:02:58 +0000

Vizio, LG, Samsung, PS4, PS5, Xbox, VewD.
What do all these platforms have in common?
Yup, that's right, React!
All of these devices support web apps, and React is the web king.
At Redbox, a streaming service you might not have heard of, we run React on all of these platforms, from a single codebase.

Now you might think "oh, so it's just a regular web app, okay".
And you would be correct, up to a point.
But let's go beyond that point.

Challenges

There are a couple of challenges when developing TV web app that you don't generally encounter doing "normal" web apps.

Ancient browsers
Spatial navigation
So many platforms
Performance

Some of these are TV specific, but some can be applied to improve any web app.
So, don't worry if you're not starting a TV web app project tomorrow, might still find something for you below.

Ancient ones

Browsers on TVs can be old.
Old like Chrome v38(latest is v94), Opera v36(latest is v80), old non-Chromium Edge, Safari 6, etc.
And most of them are not vanilla browsers, but platforms built on top of these browsers.
Meaning there's always some custom code in there too, potentially making compatibility even more painful.
We come well prepared in the web world to deal with this, however. Most of the time browserslist will take care of it.

Still, two main issues can arise here:

CSS - it can be a pain anywhere, but we all know old browsers are especially volatile.
Transpilation - it is generally the practice to exclude node_modules from transpilation, as it decreases build time significantly. However, you may find for TVs that many modules over time drop support for browsers you simply have to continue supporting. You can include the whole node_modules in transpilation, but we've found including only a handful of modules with the issues works well. Ie:

include: [
    path.resolve(__dirname, 'src'),
    {
        include: path.resolve(__dirname, 'node_modules'),
        or: [/wonka/, /vtt-to-json/, /serialize-error/, /joi-browser/, /whatwg-fetch/],
    },
],

Alternatively, there are tools like are-you-es5 that you can try out.

Spatial navigation

Besides your regular mouse and keyboard, TVs work with remotes.
There are modern "magic remotes" that function almost the same as the mouse.
But the classic remote requires navigating by arrow keys around your UX, or as commonly referred to, "spatial navigation".

There is nowadays this library for React react-spatial-navigation
However, one safe and secure way is to build your own React wrapper around the tried and tested Mozilla's open source spatial navigation.
And we have done just that.

So many platforms

Supporting all the browsers on the web from a single codebase is a pain, but much less pain then doing it with all of TVs.
For regular web apps, besides a browserslist, you might need an if to apply different styling or similar here and there, but that's about it.
TVs, on the other hand, are platforms built on top of browsers, and this is where the difficulty lies.
All of these platforms will have different ways to handle remote keys, TV specific events, to get device info, playback, etc.

There are a lot of ways to elegantly handle this platform specificity in a codebase and make it less painful.
Here's one:
Let's say you want to exit the application when exit button is pressed on the remote.
So you do this:

import { exitApplication } from '../../utils/device/device';

// .... call exitApplication in some event handler

But, the trick is, every platform has it's own way of handling application exiting.
So, we make a device folder with the structure:

/device
    |- device.lg.js
    |- device.tizen.js
    |- device.xbox.js
    |- device.vizio.js

And we make a little webpack magic.
Note that we have separate build script for every platform, so application is aware where it's being run by build script passing env.platform variable.

function platformizeExtensions(platform, extensions) {
    return [...extensions.map(extension => `.${platform}${extension}`), ...extensions];

And in your webpack.config.js

resolve: {
        extensions: platformizeExtensions(env.platform, [
            '.mjs',
            '.js',
            '.jsx',
            '.scss',
        ]),
},

For LG, this will make extensions look like this:

['.lg.mjs', '.lg.js', '.lg.jsx', '.lg.scss', '.mjs', '.js', '.jsx', '.scss'];

This way, doing import { exitApplication } from '../../Utils/device/device'; will import from device file for the platform, ie on LG it will import from device.lg.js.
Problem solved.
Naturally, one caveat of this is that every device.*.js will have to export methods with the same name, otherwise you might encounter an error trying to import something that doesn't exist on some platforms.
Ie all of our device files have the same signature:

export const getDeviceId = () => {};
export const getOSVersion = () => {};
export const exitApplication = () => {};
export const isTTSEnabled = () => {};
export const isLowEndDevice = () => {};

And we do the same with eg. keyCodes, since most platforms have keys on the remote dispatch onKeyDown event with their own custom set of keyCodes.
But, this little trick can have more use cases than just TV web app development.
One advantage of this approach over classical if or switch is that code in modules for other platforms is never imported, and therefore shaken off by webpack at bundling time, reducing bundle size.

Performance

You might have heard of "you need to watch for performance, mobile devices are low powered".
That is certainly true, until you encounter a new beast, a TV device.
Premium TV devices will probably be on par with mid range phones, which is great.
But budget TVs are more on par with a calculator.
I'm talking couple of hundred MHz processing power and 1GB or less RAM, shared with the operating system too.
Even a powerful platform like PlayStation, only allocates a small amount of resources to a web app, so in practice is also very low powered.

So, it's clear, you need to watch for performance, and not just like an afterthought.
That, however, involves multiple layers, not just React.
Let's go over some of the stuff you can do to preserve optimal experience on low end devices.

Measuring

A good starting point is always to continually run your app through well established performance measuring tools.
No single tool that I know of has everything regarding exposing performance flaws in your code, but a combination should do.
These tools are great for pointing out weak spots in terms of performance, and even suggesting improvements.

I'd mention:

Lighthouse, Webpagetest, etc These ones do it from a simulated user perspective, what might be called "end to end", on a web app level. This is what you always want to have. But, they don't precisely point out flaws in your React code, so there's still a gap for another tool.
React profiler Great for measuring and pointing out where you have performance bottlenecks in your React code. An absolute must.

Ideally, you'd want one of these tool in CI/CD pipeline.
But, we found that manual checks will always be required.

Assets

Fonts - trying not to load huge file sizes for fonts is always sensible. For optimization, try preloading fonts with <link rel="preload" as="font"> and avoiding flash of invisible text while fonts are loading by using font-display API, ie font-display: swap;
Images - ideally use webp format, and keep images as small as possible by loading in only what you need in terms of resolution. Ie, if user is on mobile, and image is displayed in ie 320x160, don't load huge image for desktop and resize it in-browser. This can be achieved by tools like Thumbor.
Compression - gzip your data sent over network, that goes for API data and for JS/CSS files(which should be minimized too)

Preconnecting to relevant domains

Any app nowadays is bound to fetch a lot of stuff from other domains.
Things like data from your APIs, images from image server, etc.
Preconnecting to these domains or doing DNS prefetch might improve load time somewhat.
Learn the differences between these two and have them in mind as tools at your disposal
<link rel="preconnect" href="https://example.com">
<link rel="dns-prefetch" href="https://example.com">

Prefetch/preload, async/defer

Another set of tools that might come in handy is preload and prefetch.
Also, script async and defer.
Again, learn the differencies between these, so you're aware if and when to use them.
<link rel="prefetch" href="/bundle.js">
<link rel="preload" href="/something.chunk.js">
<script defer src="./script.js"></script>
<script async src="./script.js"></script>

Reflow vs Repaint

While this is somewhat advanced and you might not need it on a daily basis, learning the concept of browser repaint and reflow cycles might further expand your horizons when pondering performance.
And for general web performance overview, MDN is always a good starting point.

Code splitting

Code splitting with React and bundlers like webpack is extremely easy to setup, and you should almost always use it.
The most sensible way to start with is usually splitting your routes and maybe some parts of the application that are not accessed very frequently by users.

const Library = React.lazy(() =>
    import(
        /* webpackChunkName: "library" */ /* webpackPrefetch: true */ './Components/Library/Library'
    )
);

Watch out for async/await

We all know async/await is great, right?
But one thing I noticed it has lead to, is the pitfall of sequential code where none is needed.
It's not once that I've seen in the wild code that awaits something, while there's code below hanging in there, even though it does not have to.
Ie

async componentDidMount() {
    const genres = await fetchGenres();
    this.setState({ genres });

    const isPlatformReady = await platformReady();

    if (isPlatformReady) {
        this.setState({ isPlatformReady: true });
    }
}

In the case above, there's no reason for anything below line 3 to wait for genres to fetch.
Beware of sequential code, folks.

React components

Performance wise, React is great.
But, there are still stuff to watch out for.
Here's some:

React.memo There are two "schools of thought" here. First is use it all the time, second one is use it sparingly. If you decide to use it all the time, you might end up slightly improving performance for some components, having little to no impact on others, and having negative impact on edge cases. If you decide to evaluate and use it sparingly only where it makes sense, you'll be safer, but it does consume more time(which is one of the main arguments for "use it all the time" I've seen). It sounds great in theory, but in practice it can easily prove "more trouble than it's worth". Eg. if a component has large number of props, might be the same or even faster to just let it re-render instead of making a costly check against all those props. Personally, I'm leaning towards checking in the profiler whether you're getting something out of it.
Context is always somewhat costly to use. Make sure it's not overused. Prop drilldown isn't ideal, but it might save you some performance hits of having every component ever connected to global state management. One problem we encountered was with styled-components a couple of years ago, when we started the project. Not sure about now, but back then it used context for every single styled component. Needless to say, we noticed performance hits, and quickly switched to good old sass.
useMemo and useCallback are generally worth it, with some exceptions. useMemo is great for your stuff that is derived from props/state and useCallback for your functions in components. Main thing to watch out for here is using these if their dependencies change too often. Ie, if you're memoizing function reference with useCallback, but it's dependency is ie inputValue which changes on every key press. In that case, useCallback just slows you down, as function reference will change anyway because of constantly changing dependency, you're just introducing memoization on top of recreating the function.

Virtualization

There are many great open source libraries for React which handle virtualization and lazy loading of components in lists.
Most notable being react-virtualized.
These are generally easy to setup and use, and solve almost all your problems of slow rendering in long lists of components.

However, because of spatial navigation, none of them satisfy our needs on TVs.
So, we built our own virtualization that works well for us, although we can't say we're too happy about having to allocate time for that.
Fortunately, if you're not running your web app on a TV, this is a problem you won't encounter.

Conclusion

And that about covers the main stuff.
Sure, there's also stuff like video playback, which is an epic narrative on it's own.
The accessibility, TV vendors usually have mandatory requirement for TTS accessibility in apps.
That's where we learned the hard way that WAI-ARIA standard is not much of a standard and that imperative TTS is much more maintainable.
And don't get me started on development experience TV vendors provide, or we might be here all day.
But, these are stories for another time.