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:
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:
First a word about 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:
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 though 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:
// 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';
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:
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 } });
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.
You can achieve zero-dependency simply by following JavaScript standards and using Typescript.
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.
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:
Peter Villani
Sr. Tech & Business Writer