Canva’s App UI Kit: Empowering Developers With Modern Web Technologies

Thank you. Welcome to the Canva Tech talk. This is a different version of the talk. We've done a bit of work to extend and enhance the Canva experience.

In this talk, I'm going to quickly run through the Canva tech stack, how we structure our React components and how we got our UI kit into the hands of developers. If you're not familiar with Canva, it's a design platform with a visual suite, including tools such as presentations, whiteboards, documents, print products and websites.

So, anyway, let's start diving into the Canva tech stack and how we got to where we are today. At Canva we have what we call blessed languages, which we consider to be acceptable languages for developing products, features and tooling when working in those respective domains. By limiting the number of languages we consider to be blessed, we gain focus for internal tooling while building up specialized expertise across the organization and the product. So, back-end services are generally written in Java. Tooling is written in Go, Bash, TypeScript or Python. Python is the go-to for ML models. And finally, TypeScript and React is the language of the front-end.

But we didn't always use React and TypeScript. In the initial MVP for Canva back in 2013 was effectively framework-free. There was this constant rush early on to keep building new features and any architectural changes to the product would have to be made alongside aggressive feature development. The original code base could easily accommodate five or so engineers working simultaneously, productively. But we were growing very rapidly as a company. And just for comparison, in 2013, we only had 14 employees. But by 2017, we had over, like, well, nearly 250 employees.

So, when we started thinking of this refactor in 2017, the primary goal was to enable hundreds of developers to work on the code base productively. So, by 2017, when we started investigating, we found that the JS landscape had changed pretty dramatically in those years, like, consider for the fact that React launched in 2013, and that was the same time we actually, you know, developed our initial MVP. So you can start to understand how the landscape had changed. And so we had to find which libraries worked with the design patterns that we had developed and honed internally, and eventually we decided on TypeScript, MobX, and React. React, of course, because it was unopinionated, it was component-based, and it allowed for modular development for empowering our teams. Similarly, MobX enabled us to distribute the state across the code base with better management, more on that in a bit. And finally, TypeScript was selected for its flexible type system, which has only proved to be more and more valuable over time. At Canva we use a modified MVP pattern, which we call the store presented component pattern. This pattern is comprised of four main parts, the stores that hold state and don't have access to anything. Presenters operate on those stores, stateless components that aren't aware of those stores, and factories that do all the wiring together. Unlike MVP, the presenter doesn't manipulate the component directly and doesn't have access to anything, and the presenter just changes the store, which in turn leads to a re-rendering of the component. The React components are a view layer, they're responsible for rendering UI based on the input props and for triggering events. Store classes hold state and are used by presenters or components. Presenters contain the logic for the components, they mutate data, trigger side effects such as analytics, service calls, that sort of thing. Presenters enable us to separate the UI from the business logic, and this makes it a lot easier to test and segment everything when you get to a company as large as ours. And finally the factory function just wires everything together. Ideally the factories don't have any side effects or other logic than wiring, they shouldn't be really a reason to test to these factories, just like wiring everything together. So MobX and React enabled us to create this massively composable pattern across the code. And this has really enabled us to scale out.

Anyway, back to what I've been doing at Canva, so over the past three years I've been personally working on the apps SDK, a set of APIs that enables developers to build unique experiences in the Canva editor. Apps are distinct user experiences. Here we have the Canva editor, and on the left side we have a third-party app, and everything customizable by the developer. The thing is, though, with great freedom to design apps, there comes great UX responsibility. So we wanted to provide developers with a UI library that would make building their apps a breeze, whilst meeting Canva's strict UX design constraints.

We could create an entirely new set of UI components that mimics Canva's UI, but wasn't on the same components that Canva engineers would use internally to build the main product. This would allow us to explore options such as CSS style sheets, but it would become a bit of a maintenance headache, however, as we would forever be updating components to be consistent with Canva's style and we would lose out on any of the localization and accessibility improvements that come part of Canva's internal component library, which is a huge focus for the company.

The other option was to try and explore Canva's internal component library or fork it in some way. This would involve partially releasing the library under some modified license, and as you can understand, there's a lot of proprietary code and stuff like that that we don't really want to be pushing into the public domain. But it would mean consumers of the UI library would have to be React consumers. We decided on the latter option. So with a semi-open source license whereby the library can only be used for apps built for the platform. This ended up being the fastest way for us to deliver the UI library, and it does mean that any improvements made internally will be bundled and released to the community. And over time, we want to move to a more relaxed license. So the UI library becomes much more feature complete and, like, more generally available to the wider community as a whole.

Over the last year or so, the developer community has added loads of apps integrations, both in our apps marketplace or otherwise incorporated into our platform. And they're now accessible to Canva's 150 million monthly active users. So what's everyone going to build? Thank you.