A JavaScript API Client Can Be a SaaS Product. Find Out How.

A product-based JavaScript API client should be able to run in the browser, with direct front-end DOM access, as well as in a node environment, to access back-end servers and services.

Additionally, a product-based API client should provide exhaustive and easy access to all features of the application it serves. And it should keep up-to-date with every new feature.

Finally, an API client should add extra value to the application, by adding such functionality as:

• Retry logic, to sidestep network or any other momentary glitch or timeout.
• Rate-limits and throttling strategies, to reduce server load and usage costs.
• Batch processing, where the API performs a set of actions to accomplish a single common task.
• And other helper functionality.
• Friendly view of underlying Rest API.

What is a Product-Based API Client?

An API (application programming interface) is not just a wrapper; it’s a separate, light-weight application that enables developers to interact with a full-featured software platform.

A product-based API is an API that a company sells as a product. Google sells the Google Maps API, Stripe sells a financial API, and we sell a Search API.

A product-based API client is an API that comes in different programming languages, frameworks, and JavaScript flavors. Our clients sit on top of different REST API endpoints.

By offering an API client in a developer’s own language, they get the benefit of:

• Faster onboarding to implement the basic and advanced features of an application.

• Simpler integration into their own codebases.

• Large amounts of code already written for them, including retries, throttling, and batching.

  
  

The best API design also tries to limit the amount of boilerplate code needed to instantiate, use, or parameterize an API method.

We can name a few other defining characteristics of a product-based API client:

• Small code size.
• Low or no dependencies.
• Flexible customization with smart parameters.
• Intuitive DX in the naming and usage of requests and responses (improvement over Rest API).
• Thorough API documentation and tutorials.
• Non-breaking versioning.
• Authentication with API keys or tokens.
• Simple and universal data exchanges with JSON.
• Keeping up to date with changes and best practices in the underlying programming languages and technologies.

How to Improve an API Product From Version to Version

First a word about the process: We have over 10,000 customers using our API clients. With that kind of usage, we are in a good position to fine-tune our APIs based on customer support tickets, chats, and usage statistics in our logs.

However, an even greater source of truth is our own engineers. Our APIs are not just used by our customers.

Our Dashboard uses our JavaScript, PHP, Ruby, and other API clients; we have inhouse use cases that implement our API clients; our client-facing tech support teams create demos, prototypes, and solutions using our API clients.

With all that API testing and internal usage, we know first-hand the pain points and positive aspects of our API clients.

With all that feedback, every release includes:

• Refactoring the interface and the code behind (non-breaking) to keep up with the changing standards and evolutions of the underlying technology. For example, our newest version of our JavaScript client supports ES6 and TypeScript.

  
  

• Improving the DX for all kinds of developers – experienced, beginners, domain experts.

  
  

• Targeting more use cases. New or existing methods to better address certain use cases, sometimes even adopting the jargon of an industry.

  
  

• Generating a common interface across all API languages. Many customers switch between different languages. Having a common interface helps with that. Using JSON also helps.

Some Upgrades We’ve Made to Our JavaScript API Client

For SaaS companies like ours, a JavaScript API client is critical, because of its ability to request services directly from our cloud servers without requiring customers to go through their own back-end servers.

Among other things, client-side API requests improve the response time of the new API and simplify the front-end code on the front end. Because of these benefits, our JavaScript API is our most used client.

With that in mind, JavaScript APIs have to manage the challenges of client-side application development, as well as the particularities of the JavaScript language and its flavors like React, Vue, and Angular.

Here are some improvements we’ve made recently:

Support for both require and import, and default and lite versions:

// For the default version
const algoliasearch = require('algoliasearch');
 
// For the default version
import algoliasearch from 'algoliasearch';
 
// For the search only version
import algoliasearch from 'algoliasearch/lite';

Parameterized Instantiation

We started with a simple instantiation – client application id and the API key:

const algoliasearch = algoliasearch('YourApplicationID', 'YourAdminAPIKey');

Then we added a third parameter, allowing the developer to customize a number of additional features:

const algoliasearch = algoliasearch(
   'YourApplicationID',
   'YourSearchOnlyAPIKey',
{
   timeouts: {
       connect: 1,
       read: 2,
       write: 30,
   },
   requester: createBrowserXhrRequester(),
   logger: createConsoleLogger(LogLevelEnum.Error),
   responsesCache: createInMemoryCache(),
   requestsCache: createInMemoryCache({ serializable: false }),
   hostsCache: createFallbackableCache({
       caches: [
           createBrowserLocalStorageCache({ key: `${version}-${appId}` }),
           createInMemoryCache(),
       ],
   }),
});

As you can see, the third parameter allows developers to define:

• Unique timeouts.

• The behavior of requesters.

• Customizations for node requests or a browser environment.

  
  

• Log callbacks:

  • Logging enables us to follow the lifecycle of a client, to record and then analyze API activity.

  • Recording API activity helps us improve the usage of an API in future versions. It also enables us to reduce pricing by removing certain common usages from the costs.

  • Also, by allowing developers to send us their own logging methods, we can store the information they think is important, thus improving the quality of our own logs.

    
    

• Response caching:

  • Developers can manage their own throttling, for example.

  • They can disable our response caching, as well.

  • They can manage local storage, preserving the state of search even after a browser refreshes.

    
    

• Request caching:

  • Allows promise sharing, for example.

Reduced Size of the JavaScript

Make the client tree shakeable:

// Tree shakable ( 1 kb, dead code elimination )
// list the methods you use and don’t include the code of any other method  
const client = createSearchClient({
   // ..
   methods: { search }
}); 

Customized Requests

Experts sometimes require a non-opinionated, open request to handle unexpected use cases. For example, developers can pass read/write requests to cover what is not in the API:

client.transporter.read ({
   path: '',
   verb: 'GET'
});

Note on logging: when we log these customized requests, we can take that information to create new methods in the future.

Reducing Dependencies to Zero

You can achieve zero-dependency simply by following JavaScript standards and using Typescript.

Batching Common, Multi-Tasked Operations

Instead of a single Save() method, we added more robust methods like replaceAllObjects(), reindex(), copyIndex().

This helps ensure best practices in such data-sensitive methods. Additionally, we’ve written all the code that manages retries and zero-downtime logic.

Typescript Support

Managing the Release Schedule

Last but not least, a product-based API client must follow the best strategies for testing and release practices.

We’ll leave testing to another blog, but here’s the overall strategy we use for our release cycle:

• Release a beta version for internal use cases, applications, and demos.
• Work with the Docs team to standardize and document the DX.
• Help upgrade products that rely on our API clients.
• Release a final beta to a handful of customers.
• Release the stable version, along with the updated Docs.
• Promote and encourage migration via Support calls, blog posts, and social media.