5 Changes to YesGraph’s API: Faster, Stronger and More Flexible

We’ve made a few changes to YesGraph’s API that allow for new product features and better performance in your app.

hulkbuster tight

1. Recording Seen Suggestions

We’ve added the endpoint /suggested-seen.

This helps keep track of which contacts a given user has seen. When we rank contacts, we don’t know what end users see — for example the top 5 or 10 could be featured. With this endpoint, now we do.

This matters because users can be constantly shown new suggestions.

Besides the input of seen suggestions, you can filter them out of the ranked results. This is by default on, but you can control it with a filter_suggested_seen flag on the /address-book endpoint.

2. Get Ranked Contacts Immediately

Previously, contacts were input with POST /address-book and retrieved with GET /address-book. Now we’ve optimized ranking to the point where we’ll return the ranked results immediately on POST.

This is a big deal because of the time it takes to run two requests. Previously, the client would make an API request to input contacts, wait for the response, then make a request to get the contacts out, and wait for the response again. The network time between these two requests is a big part of the waiting that will impact end users. On a slow mobile connection it might be 500ms each way. Removing network steps makes this a far better user experience.

3. Removing Landlines from Mobile Contacts

We’ve recently enhanced our ranking to find contacts which belong to businesses and landlines. This is a powerful change because landlines can’t receive an SMS. They literally can’t be invited in many cases, even if the contact is a close connection.

This kind of enhancement is exciting because it highlights that better modeling on YesGraph’s end can dramatically increase invite performance — without your needing to worry about it. We’ll continue to add new signals to drive even better performance.

4. Dramatic Speed Boosts

We’ve made our primary ranking endpoint 4X faster. We now return on average in 200ms, and frequently less than 100ms. This doesn’t count network time from making the request, which can be highly variable based on the user’s connection. With our new iOS SDK, we’ll be tracking end user performance closely.

Beyond YesGraph’s ranking performance, we can now state with confidence that we’re faster than rolling your own systems.

How did we do it?  This isn’t one change, but the result of many small changes. We added caching layers for different data processes. We moved some processing to the background. We optimized our queries and models for the data. We still want to get faster, but considering the volume of data we process, it would be a challenge to replicate these results by doing it yourself.

5. Android On Its Way

We launched our iOS SDK and now have started work on our Android SDK. This is a big deal to help apps drive consistent performance across every platform.

Android has some differences, like how users request permissions and how Facebook and Twitter native flows work. This also varies by version of Android. But you don’t need to worry about that with our SDK. We’ll take care of it, on top of managing YesGraph’s API to recommend exactly who a user should invite.

If you want to dive into these changes, join our growth community on Slack here.

To get the latest news about YesGraph, subscribe to future posts right to your inbox here.