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:

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:

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:

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:

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:

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: