Empowering Developers: Key lessons from designing Canva’s APIs

Kicking us off, let's take a quick look at what the Canva developer platform is.

So I'll start with a quick history of what Canva, how Canva started.

So over a decade ago, the visual communication landscape was very different from what it is today.

If any of you recall, like Design tools are very complex, fragmented, expensive, it was only really accessible to folks that could afford them, to professionals, right?

So the Canva founders had a belief that everyone, everywhere should be empowered to design.

So in 2013, Canva was launched with the goal to bring, to integrate the entire design ecosystem into one convenient place.

Where users could make great looking designs, with easy to use tools, using like massive, this massive library of really high quality stock assets, full of professional, professionally designed and curated templates.

And it's worked out.

Canva is web scale today.

Irony of this is that we do actually use MongoDB, for those of you that know.

What does web scale mean in numbers?

We have over 185 million people using Canva every month.

To put that in perspective, 1 percent of our monthly active user base is bigger than my entire home city of Auckland.

Logically, in my mind, that means people outside of Auckland might be using Canva.

Yes, so we've got folks using it across 190 different countries, we translated into a hundred different languages for them.

Your Canva is global, it's, user base is really, diverse.

So when we talk about active monthly users, we really do mean active.

These folks are making 280 designs per second.

I'm speaking a bit faster than, my, my speaker notes planned for.

I thought we'd be at two minutes here, so I could say 40, 000 new designs.

We're coming up on 40, 000 new designs since I started talking.

Needless to say, a lot of design work's going on.

In fact, we've recently hit 25 billion total designs created, since Canva was launched.

So let's look at those numbers again.

185 million monthly active users across 190 countries, 100 different languages, 25 billion designs, 280 designs per second, and, bear in mind, you can use Canva on any computer or mobile device.

Canva has a lot of untapped opportunities across its user base.

And while, we were going through this period of amazing growth, we realized that we wouldn't be able to take up, to take advantage of all these opportunities.

We realized that we needed to unleash the creativity of developers outside of Canva.

We needed to add third party extensibility to Canva.

We decided we'd do that by introducing what we call Canva apps, apologies for the very original name.

These apps run inside the Canva product itself.

They would have access to a developer platform full of like really powerful APIs, which they'd be able to compose into all kinds of new, fun functionality for our users.

But for this platform to be successful, we'd have to guarantee a few key things.

So first off, APIs must be interoperable and composable.

It's got to be super easy, super low friction for developers to mix and match APIs within a single app.

We also wanted to give developers maximum control over the app UI, encourage innovation.

But, we still wanted them to feel natural within Canva, they had to feel like part of the Canva experience.

And third, over time, we wanted to be able to expose more and more of the key user actions that you have within Canva, but via APIs.

We built the Apps SDK.

The Apps SDK is a series of tools, data kit, API clients, the developer portal, that allow app creators to get a working app up and running really quickly.

And from there, they can do anything they can imagine with the SDK's loads of, powerful, simple APIs.

You can see a bunch of them listed over there.

So let's take a moment to see how the Apps SDK actually works.

So at the highest level, we've got two things.

We've got the app, built by a developer, and we've got the Canva editor, which, contains all of our product features, obviously, and the app framework itself.

An app is really just a JavaScript bundle, but we load that inside a sandboxed iframe.

Now this is crucial.

Any security folks around here will understand why.

We cannot allow third party code that's essentially opaque to us and has network access to run directly in our product.

We've got to secure, we've got to protect our users data.

We've got to protect our product.

Sandboxing means we can control exactly what access this third party code has to user data, to product functionality.

We can restrict what it can read and execute.

The only access we do allow apps is via API clients.

As a, app developer, you'd get access to API clients by importing NPM packages, hitting a little import command, cool.

But these clients actually are very thin wrappers over objects that we inject at runtime into the iframe, this means we can push hotfixes, we can, make improvements without requiring apps to re bundle, re submit, re review, allows us to move a bit faster.

So if we look a bit deeper under the hood We can see that these clients are really just a bit of an RPC interface or facade over an API messaging system.

This is the thing that allows us to talk from the sandbox to the host editor.

So we've got this message channel that marshals these API calls, these API messages back and forth between the app and the Canva experience itself.

And on the other side, we've got the API controller.

This is the thing that wraps the core Canva functionality.

Now this API control is important for another pretty big reason.

Canva is not being built API first, right?

Our, product teams, optimize, our product teams, our entire architecture is optimized for quick delivery of features.

Definitely not delivery of stable, long lived APIs.

So our API controller is where we take the rapid change that goes on inside our product and transform that into a stable contract outside.

Say something trivial like when an attribute name changes, we can map it to the stable version in the API, for example.

How do we actually build APIs on this platform?

Let's take a look at the way we use Canva's unique engineering culture and values to fuel our approach.

First up, here's an overview of what we call our table stakes process for API design.

It's a process that's rooted in refining through continuous feedback.

So we will always start with user research.

We'll go to, we'll, conduct developer interviews, we'll look at data insights, these things will tell us what API features we need to build.

From there, we'll do an internal release, we'll often support these internal releases with, internal hackathons, internal feedback rounds, start refining these, API features.

When we feel they're ready there, we'll do a preview release, to public alpha and beta developers.

Get feedback from them, get any insights from them that we can.

And once that's been through the rounds, we've ironed out all the rough edges, we'll move on finally to a full public release.

So having run this program, this process for a few years now, biggest takeaway is that the dogfooding and, the internal releases and listening to our preview devs, really, influenced our product direction for the better, like feedback is absolutely king.

So with the overall process described, let's go on to the values that drive it.

So from the start, we always, we dreamt big, we started small.

We started so small that the first preview release of the app framework took a year to get out to production.

This was expensive.

We knew it would be expensive.

It took a lot more development effort overall than a Big Bang would have.

But that continuous feedback throughout that year absolutely paid dividends, like massive net gain in learnings and quality delivered by the end of it.

And we realized these gains by applying something Canva calls pragmatic excellence.

Fancy term.

Roughly means choosing the quickest, but most maintainable and robust solution that we can deliver.

At the time of the App Framework's inception, we had a lot of unique deployments, security, runtime requirements.

It didn't quite fit into Canvas architecture, it didn't quite work with our build platform.

We could have spent a lot of time tackling these differences.

We decided to keep things simple, keep things nimble.

First release of the SDK, literally just manual deployment onto some S3 buckets.

It was quick, but it did take a bunch of manual work to make secure, to make stable.

Obviously we also didn't have the advantage of our internal tools.

We didn't have all the safety nets of our CICD pipeline.

We didn't have all the productivity boosts as we normally would have had.

There was a lot of manual burden and responsibility placed on our devs.

Yeah, look, taking the seemingly dirty approach, raised eyebrows, evoked questions from, Canva engineers outside of the ecosystem group, because we weren't taking advantage of all the safety nets and productivity boosters, but they first sought to understand why we were doing this before really critiquing it.

This, approach of theirs really it allowed us to overcome a lot of critical dependencies in the project.

Collaboration like this is at the core of Canva's value to work with empathy, humility, and generosity in everything we do.

Yeah, look, all of this extra work at a price.

But it allowed us to rapidly prove the Core Apps SDK.

Getting all that early feedback through our internal hackathons, our preview releases, all of that stuff.

Once we launched our MVP, we could start adding sophistication to our product.

First improvement out the door was a gateway service.

So this meant we could start moving apps and the app runtime into the Canva infrastructure, serving it from within.

It meant we could start offloading all the…a bunch of that manual DevOps burden that, that our devs were shouldering onto Canva's pretty amazing internal tools.

That done meant we could start introducing more and more bold automation, so we'd get all of our pre release safety checks, we'd get automated rollbacks, we'd get audit logs, we'd get to sleep at night.

Wonderful.

And then lastly, now that we were on our CICD pipeline, we could use Canva's internal, message, API message evolution tools.

It's a bunch of stuff that does type checks and backwards compatibility checks and has processes for, version migrations.

A whole bunch of automated safety that proved absolutely invaluable because now we were able to add change and iterate on our APIs confidently, knowing that we weren't going to break anything.

We'd be able to safely manage deprecation periods, that sort of thing.

So we chose these three technical improvements initially because they were the ones that would create the largest net positive impact on our end users.

Combination makes development safe and pluggable.

It means our teams could deploy new versions of APIs confidently, knowing they wouldn't make breaking changes.

Which means existing apps keep on working, new apps keep on getting better, our users keep on getting happier.

If this is how it helps our users, it's been really great from within Canva like watching how all of these, all of these values came together in the success story we feel we've had, with the Apps SDK and the developer platform.

We're all really proud of how we've applied our pragmatic excellence, to prove our products early.

So next up, we'll focus on the strategies we employed, not just to deliver, but to guarantee outstanding APIs.

Loads of opportunities.

How do we pick which ones to tackle?

How do we prioritize APIs?

So coming out of a lot of preview releases, we got really strong signals on the types of apps that people use, that people want to build, and these are the Insights helped us focus on three archetypes of apps that we'd enable.

First one being creation apps.

So these are things that allow users to create new content to put into designs.

Second are content apps.

These allow users to import existing content into designs like images, text, media elements, that sort of thing.

Third one is data driven apps that allow users to bring data from sources outside of Canva, into enter Canva for visualization, automation, that sort of thing.

Yeah, so we set our goals on enabling these archetypes and making more and more sophisticated versions of them.

This helped us identify, prioritize the potential future APIs we'd work on.

For example, we iterated on our archetypes, first including importing images and media.

Then moving, I think I've skipped forward a bit, then moving on, adding the ability to drag and drop images and media from an app onto a design.

Then being able to edit in place images that were already on a design.

Then being able to create compound shapes to put on a design.

And connecting data to design.

Just going on and on always pushing out the boundaries of what was possible within these particular archetypes.

Archetypes were a massive breakthrough for us.

They enabled us to ruthlessly prioritize what we worked on, decrease our time to market overall.

They established the core features of our MVP.

But it also meant that we did end up de prioritizing and sidelining a bunch of APIs we'd invested quite a lot in, APIs we really loved.

For example, the entire data app archetype, we replaced it with generative AI.

If you look at Canva's app marketplace today, you can see it really paid dividends.

We've got a lot of very popular Gen AI apps there.

And look, ultimately, this just meant that we could get, we could, all of this meant that our beta developers could build better apps sooner.

Phew, I've got a note here telling me to breathe.

I think I need to.

We knew which APIs we needed, but how do we make sure that they are outstanding?

The reality is, building outstanding APIs is expensive.

They're expensive to design, they're expensive to maintain, they're expensive to evolve.

Because once they're out in the public, once you've got thousands of developers using them, once you have production code consuming them, it is very difficult to make any kind of breaking change, to do any kind of deprecation.

And on top of that, a poorly designed API can really slow down your internal, feature teams.

If an API doesn't I think we've done a bad job of abstracting internal functionality, and that functionality changes.

If we can't translate that functionality in our API controller layer, the feature team has to wait for a deprecation, a deprecation cycle before they can release their new feature.

And we can't afford to slow our feature teams down.

We realized that, the key to building outstanding APIs is understanding that they are a commitment, a long term commitment to our developers.

As long as we honor that commitment, developers are encouraged to invest in our APIs, to build long lived apps that our users love.

So how do we actually do that?

We introduced a set of overarching principles we follow that boil down to four essential qualities.

That's the first quality is simplicity, so inspired by our company's mission to make design as simple and accessible as possible, we want to make APIs as simple and accessible as possible, without making them less powerful.

Next, safety.

Like I said at the beginning, 185 million users are trusting Canvas.

Every month, our APIs cannot compromise their trust at all.

We can't compromise their data.

We can't compromise their experience.

These folks have created 25 billion designs.

Every single one of those designs still renders in the product today.

One's made from day one, right to one's made, gosh, the 280 in the last second.

Our APIs can't change that guarantee.

We cannot, through careless API design, even allow the possibility of corrupting design data.

Third, evolvability.

As stated, changing published APIs is very expensive and difficult, and we don't want to couple our internal feature engineers to deprecation cycles.

So we've got to design our API in such a way that we can gradually add more functionality for developers without introducing breaking change.

It's all about stable, incremental improvement.

And the last, finally, we think consistency is the last piece that gives our developers the sort of productive and delightful experience, development experience that we want.

Features of a consistent API just compose absolutely effortlessly.

Things just work together.

They fit together.

Patterns you learn in one area of the API just flow perfectly into another area.

Everything feels the same.

Your developers like start to build this natural intuition for how your API works.

They just get more and more productive.

They have more fun.

They make amazing things.

Here's a selection of actual principles in our internal handbook that we've got.

To give you an idea of how we use them to guide our real designs, let's take a look at how they changed one of our APIs in practice.

I'm going to talk about the Selection API.

This is an API that lets apps read and manipulate elements that a user has selected.

It comprises a few things.

First, there's the scope.

That's the type of thing that we're looking to select, so images, text, video, etc.

And you've got the listener, should be familiar to any front end devs.

Listener is what we call when the user selects something within the scope.

Then we've got the event, again, should be fairly familiar.

This is the event that represents the selection.

Then we've got the draft.

You've got your selection event, You can read the selection event and that gives you a draft copy of the elements that have been selected.

That draft copy is editable.

Edit it, save the draft, your changes are persisted back to the design.

So now you understand the concepts.

Let's see what the actual API looks like.

I was a bit worried that This text would be small, but I think it might be, I can probably read that, yeah?

Here's what it looks like today in a little toy React app.

Apologies to anybody who was expecting jQuery.

First highlighted area, we are registering a listener for the text scope.

The listener is just saving a reference to the, selection event.

Second highlighted area down here, we're reading that event, we're getting our draft back, we're iterating through the contents of the draft, and we're appending a little hello world to each text fragment and then saving it back.

Pretty simple API, principles that this demonstrates.

First up.

Always work backwards from code feel.

So we always start off designing APIs by putting it in real code to see how folks will actually use it.

We want it to feel good and work backwards from there to come up with the final contract.

Second one is protecting user data, in this case by letting developers fall into the pit of success.

Collaborative text editing is complicated.

It is full of foot guns.

It is easy to get wrong.

We're intentionally restricting what apps can edit and when in this API to make sure that they only ever perform safe operations and user data never gets corrupted.

And then last, plan for change and expose stable features.

This one's pretty straightforward.

Not all elements in Canva designs are stable from an API point of view.

We only want to expose the stable ones, so the scope parameter allows us to do that.

Text is pretty stable, we've exposed that.

As future things become more stable, we'll be able to add to scope without introducing, breaking change.

So underpinning all these principles, like We understand that perfection is difficult, it is often impossible, there are often going to be times where we can't get an API to adhere to all of our guidelines and qualities.

So we have a fast rule, a very hard and fast rule, in an ecosystem that we rather postpone a new feature to a future release rather than release it now if it hasn't met our standards.

We were a bit worried when our, Eng lead originally wrote this a few years ago, but it's proven to be the right call.

We've consistently made the right call, delaying APIs that just weren't ready in hindsight.

And the final thing we'll touch on in building outstanding APIs is internal alignment.

Without internal alignment, you cannot have external consistency.

So at Canva, we work in these sort of small, highly cohesive, but loosely coupled teams, each empowered to hit their own crazy big goals.

This approach optimizes for speed, but yes, it naturally biases teams towards the individual goals, right?

It's very easy to risk sight, risk losing sight of a bigger unified vision.

We're very sensitive to Conway's law in Canva.

We don't want that to manifest in the APIs that we publish.

So to strike a balance between the alignment and empowerment of our teams, we created an API design working group, which consists of engineers from all of our teams.

And they are tasked with ensuring that APIs align with our, with our principles, with our guidelines, with our overall vision.

We're very careful not to position these folks as, some kind of higher authority that approves designs from ivory towers.

They're not there to block bad APIs.

They're there to follow our values of working with generosity, empathy, and humility to support and empower engineers in building great APIs.

Key to this empowerment was to codify all the learnings and design philosophy we discovered over the years into Canva's internal engineering handbook.

Canva is big on encouraging a culture of continuous learning.

So as our API engineers build out our public API surface, they draw from all their knowledge and guidance in the handbook and they constantly enrich it with new learnings and new, new learnings gain.

One significant article the working group added to the, added to the handbook was what we call API Runsheet.

So this is a living document, that guides engineers through our table stakes process.

They use it to track all the essential stages of an API's life cycle.

So it empowers them to self govern through the critically important stages of building an API like rapid risk assessments, so they can identify the must do and the should do security activities, designing engagement models with our internal feature teams, the teams whose functionality they're wrapping, guidance on validating that they've actually built the correct API, that it was built right.

There's also some great templates for design docs, observability, analytics, public announcements in there.

Speaking of design docs.

Canva has an engineering culture of thinking through problems by writing them down.

Design Docs are at the core of this.

We write Design Docs to figure out and align on the solutions we're building today, and to record those solutions and, critically, their context, for our future selves.

These docs go through rigorous peer review and they are often referenced many, times over in follow up work.

This is an example of a design doc published earlier this year for one piece of our app runtime.

And these docs, these docs have been really powerful at teasing out the primary considerations of our software designs.

They've boosted the success of our product immensely.

What have app creators actually done with these APIs?

Let's take a quick look at one of the apps you can use in the App Store today.

So this is ColorMix by a group called Photomosh.

What you are seeing here is ColorMix using our Overlay API, first to detect when I've selected an image, and then to launch an overlay surface on top of that image.

Colormix has got complete render control over this new surface.

In this case, they're using it to render a preview of their rainbow filter.

So then they're using our PubSub messaging API to up, send updates to that overlay surface, based on my interactions with the controls over here.

And finally, when I hit save, they're using the upload API to upload the new edited image to my private media, and then the selection API to replace the original image with this sort of psychedelic result.

This is a great example of how a lot of simple individual APIs work together to do something, pretty cool.

And it all feels snappy and native within Canva itself.

In summary, let's take a look at the lessons learned.

First off, dogfooding with internal releases and releasing to preview developers early and often is a great way to learn what does and doesn't work.

Focusing on the essential product while still applying pragmatic excellence is a really good way of getting your product out early.

Archetypes have helped us focus on essential user needs, but it also meant that we deprioritized some APIs we love.

Deploying problematic, deploying a problematic API is much worse than missing a deadline.

Design docs help gain clarity through writing things down.

Strong engineering values can be very effective at scale.

And lastly, most importantly, always consider how does this help our users.

We really hope that this last value shines through in the care and thought we've put into the Canva Apps SDK.

Not just the APIs themselves, but also the tooling and docs behind it.

That's it for me.

There are many rabbit holes in this talk that I could easily spend another, not just 30 minutes, but 30 days talking about.

It's my email if you want to chat to me.

I'm not active on social media much at all, but apparently I've got a Twitter account lurking there.

If I check it and you talk to me, you'll probably have to block me to get me to stop talking back.

Otherwise, yeah, any questions?