In our latest podcast episode, we spoke with Jon Parise, a lead architect at Pinterest. At Pinterest, Jon provides company-wide technical leadership across several strategic initiatives and leads Pinterest’s open-source program. We sat down with Jon to learn more about how the API program at Pinterest works, some keys to their success, and where they plan to go from here.
APIs and Pinterest, a Perfect Match with Endless Use Cases
“The largest source of our API surface area is ourselves because everything we do is internally API first and API oriented. So everything you would do on the Pinterest website or iOS or Android apps is powered by a really thick API layer that all developers at Pinterest can contribute to, which is awesome.” —Jon Parise
Like many organizations, the largest use case for APIs at Pinterest starts internally first, according to Jon. However, Pinterest also sees many advertising partners seeking analytics, spend metrics, and integrated data through their external APIs. Pinterest operates with a single complex API layer that underlines a lot of their work and the public layer that customers see looks rather different. In Jon’s role, he owns the technology from their first-party clients all the way through the APIs to their back-end product logic.
“When I talk about our first-party use cases, that’s the majority of what we’re serving and how we’re thinking about how we build our product logic and how we design our data models. The third-party audiences tend to be a subset of that,” shares Jon. “So, for instance, I mentioned earlier that we talk about how we manage Advertiser data, and we ourselves are a first-party consumer of that with our own business-focused management interfaces. Similarly, if we were talking about the simplest thing such as creating and reading pins on the site, that’s a relatively straightforward, CRUD-style API interaction.”
Jon emphasizes that their first parties do a lot more with that than one would ever expect a developer to be able to do. A lot of prosperous functionality has evolved over the last few years for the Pinterest developer team. But, Jon reinforces that they can’t expect a third-party developer or a partner to react to their changes the same way internal developers would react or evolve their team’s APIs in terms of stability and long-term support.
Constant Iteration and Innovation
“One of the things that are challenging for our team is looking at how do we continue to support the variety of devices on iOS and Android? I would say the way we think about it is that for better or worse, mostly better, those devices are constantly evolving.” – Jon Parise
Being a software that constantly has to be updated to stay fresh with the latest IOS and Android upgrades means that Jon’s team consistently has to iterate and innovate their APIs and the platform itself to remain compatible. For example, with the recent rollout of iOS 15, the development team has to figure out how to add new exciting features to the Pinterest platform while maintaining compatibility with five or six-year-old devices. In turn, everything API-related that the team created five or six years ago still needs to work when newer technologies emerge.
“Basically, it means that our API surface area goes back at least two to three years at all times. And then if you multiply that because it’s a matrix of all the features we support, it becomes a lot that our development team needs to scale and keep track of on the regular,” shares Jon.
For instance, Pinterest as a platform is doing a ton of work with video these days, whereas if you looked at the product eight years ago, it was primarily an image-focused site. The addition of audio, video, streaming, immersive screens, distribution, and podcasting comes with challenges to the Pinterest platform that the development team continuously has to innovate through.
Managing a Giant API Program at Scale
“We have thousands of APIs, which is a lot. So they don’t all follow the same rule set in one dimension. We think about ownership. So when you have that many APIs, and we just celebrated our 1024th engineer, you can tell why. It’s a big engineering team, and many of them are able to make API endpoints themselve.” —Jon Parise
For their engineers who want to work in the API space, they’re given access and agency to contribute, which Jon views as team-level ownership. Many of their API endpoints and various engineering projects overlap, so a significant amount of cross-collaboration needs to occur across Pinterest’s technology teams.
What helps to ease that cross-collaboration is having a portfolio that embodies all of the product features and the inventory of API endpoints behind the features that are powering them. In addition, Pinterest keeps track of all the subteams that are evolving those endpoints and why and how they interact.
Furthermore, Jon’s team spends a lot of time looking at overlapping time windows to maximize efficiency wherever possible on their large developer team. For example, one team might be doing some work the first half of this year, and then another group might be doing work the second half of this year, and there might have been a team doing work all year long, so it’s essential to ensure these teams and project timelines are lined up. Especially since Pinterest conducts continuous releases multiple times a day all the way through that entire calendar year, having an organized understanding of all projects, APIs, launches, and initiatives is the only way to keep the program running efficiently at scale.
“A lot is going on for sure when you’re thinking about fast product services, multiple teams, and what product we put in front of people on iOS, Android, and Web today versus what we were still supporting a year ago. It can be hard to juggle, but it’s important to have a 360-degree view to keep up with the pace of innovation,” shares Jon.
A Design-First Approach
“We’re going in the design-first spectrum and development direction there, which is really exciting, and we’re embracing OpenAPI as well. These three new pieces [below] work together really well to deliver what we think are perfect audience-specific API renderings for how we see the world.” – Jon Parise
As for what’s next for Pinterest’s developer and technology teams, they’ve taken the design-first path. Pinterest has been running a RESTful API for the last almost nine or so years, and that’s been their single sort of hammer for all API-related customers. But, now that the team is thinking about how they want to do an even better job in the future, they’re doubling down on a design-first approach to their API strategy and focusing on partners.
The internal Pinterest developers are developing a GraphQL API, and their focus is entirely on that use case. Internally, their developers are also focused on Thrift. As for Pinterest partners, they will be shipping Restful Open API-based schemas with substantial versioning requirements and excellent documentation in the future. Those will be in high demand and come with some excellent open-source tools. The need to double down on partner work is a big focus for the Pinterest team moving forward in the coming years. The demand for partner integrations will only continue to grow as Pinterest technology transforms and the end-users utilizing Pinterest evolve their use cases for the app.
If you would like to hear more API innovation stories, tips and tricks for your own API program, or industry trends, please visit our podcast page to learn more and listen to the full episode.
