An interview with Ashby on RPC APIs

‍In this piece, Shensi Ding (Co-founder at Merge) talks with Ashby engineer Aaron Norby about integrating with RPC APIs. Ashby is a next-generation Applicant Tracking System (ATS), with customers like VanMoof, Deel, Census and Modern Treasury. Merge’s integration with Ashby is live and available for all users.

Gil and I first met the Ashby team when one of their customers wanted us to add Ashby` to our ATS API. We immediately loved the founders, Benjamin and Abhik, and were excited to start working on adding their integration once they built out their API. When their API launched, I was intrigued— it was RPC.

RPC stands for Remote Procedure Call, and stands apart from the most common API styles— REST (Representational State Transfer), GraphQL, SOAP— because it is relatively uncommon for public-facing APIs. 

Luckily, Aaron Norby, the lead on Ashby’s API creation, agreed to sit down with me to discuss how Ashby chose their API-style, and what his team has learned since. Even after releasing our integration with Ashby, I learned a lot in this discussion, and I hope you all do as well!

{{blog-cta-100+}}

‍

Shensi Ding: Tell us the backstory about Ashby’s API.

Aaron Norby: The original impetus for building an API was that we had a customer who wanted to completely build their own website for applying, posting job boards, taking applications, and to use Ashby for analytics. We originally built it to help with that use case.

Our internal API is not REST— it’s not RPC either. We use GraphQL, and since we were outside of the REST framework anyway, we were more open to seeing what else was out there.

What were the different styles of APIs that you considered, and what were the pros and cons of each?

We knew we didn’t want GraphQL for our external API because there was a heavy lift for learning. GraphQL is getting more popular, but it’s not widely adopted yet. It’s also a very opinionated decision— not everyone who will want to use the API wants to use GraphQL or is familiar with it.

When we were considering REST, it was less about the downside and more about how easy it is to learn and understand immediately what to do to get something done. REST uses standard HTTP verbs, and there are standards about how they should be used and what they should mean. From my previous experience it’s not always that easy. Occasionally, you’ll want to do a relatively simple operation, but you’ll need to spend a lot of time thinking in circles to figure out exactly what entity you’re addressing and making decisions about. 

One example that comes to mind is our current method application.change_source. Would this fit with the application entity or is there a separate source entity? Would this be a POST or a PATCH on the source / application entity? It’s not that easy to figure out.

How did you become familiar with RPC APIs?

Right before this project, I was working on an integration with Slack. Slack’s API is RPC. When I was building that out, I encountered their API and needed to read their documentation to figure out how to do things, and it felt much easier and significantly more intuitive than trying to figure out what endpoint / method was necessary to get things done. It was very simple and felt a lot like what an engineer is used to when writing functions.

What was different during the process of building out the API?

Things would have felt more weird if we weren’t coming from GraphQL, but the main difference was that everything is a POST vs. in the REST world where you’re using a variety of HTTP verbs. It didn’t take much to get over that mental hurdle.

There was also the discussion of how to do error handling. Once you say you’re not going to use the standard REST way of doing things in terms of HTTP stuff then that either opens up or puts a burden on how you handle if somebody gets an endpoint for a single entity. The standard response is returning a 404, but here we could return a more helpful error response with information about their problem.

Were there any downsides that your team considered as you were deciding on RPC APIs?

One downside is that it’s less familiar overall. REST is much more familiar and widely used for publicly-facing integrations, and RPC is more widely used for communication between services within a system. We considered this when we were rolling out our API to customers and whether it was too much of a learning curve, but ultimately decided that it wasn’t that bad. Our first few customers also seemed very happy with it.

Any surprise benefits from using an RPC-based approach?

Documenting our API was a lot easier than we thought it would be!

What feedback have you received?

Feedback has been pretty good so far! It’s been satisfying as we’re onboarding more people onto using it.

Merge provides the tools to transform how B2B companies realize customer-facing integrations. Want to integrate with Ashby just once? Check out our solutions here.

‍