API series - Algolia: The ‘first’ principles in the API economy
This is a guest post for the Computer Weekly Developer Network written by Bernadette Nixon in her role as chief executive officer at Algolia – the company is known for its API-first specialisms in enterprise search technology, which is used to power website and mobile applications.
Algolia’s platform is designed to give consumers seamless access to an organisation’s product catalogue via AI-powered search, discovery and recommendations to increase online revenue.
Nixon writes as follows…
The modern cloud-centric uber-connected world of business is both expansive in its total scope, but often comparatively granular in terms of the internal mechanics and components that make it work.
We know that consumers want instant gratification and, in balance, that commercial organisations are under constant pressure to innovate new products and services that deliver on what is an instant and also ever-shifting customer fulfilment goal. This is a world where customers (both corporate & consumer) expect the organisations they spend their money with to ‘know them’ and help them reach their gratification point instantly, or sometimes faster.
The expense of experience
While it is all well and good to state this reality, this is not plug-and-play technology. Creating enduring customer experiences requires software application developers… and developers are a) expensive b) traditionally keen to always ‘build from scratch’ and c) often prone to weaving complex networked technologies together from a litany of cloud SaaS providers.
The other route here is to purchase a monolithic SaaS product – and I probably don’t need to ask you what part of ‘why customising a monolithic SaaS product to create unique differentiated user experiences is hard’ you don’t understand, right?
Faced with the option to build vs. buy, a new generation of API-first specialists (without mentioning our own brand) has grown up and we can point to firms like Twilio, Segment, Zapier, Stripe etc. These vendors provide developers with a selection of jumpstart-shortcuts in the form of API-based building blocks that can be used to create applications.
If you are questioning what is API-first, anyway? Then that’s the right reaction. We use this term to talk about platform-level enterprise software solutions designed to provide composable API-based software products.
Because there are multiple digital touchpoints into a modern application (via mobile devices, through connected machines from sensors to kiosk computers, or just through a plain old desktop web connection), delivering that application so that it can operate and scale across every channel without having to rebuild each time can seem like a big ask. That’s why APIs are special and powerful.
API-first defined in 3-factors
Algolia CEO Bernadette Nixon: An API-first mindset delivers three things: flexibility, speed & backward compatibility.
When we talk about API-first today we are thinking about three things: flexibility, speed and backward compatibility.
In our case, by flexibility, we mean to express how and why we designed an API to be able to handle a broad range of use cases, which is the opposite of what a product or platform vendor does.
In terms of speed, this means an API that can handle the velocity of intense throughput and application ‘calls’ without developers having to worry about performance tuning.
Thirdly – and in a similar backroom engineering vein – organisations that want to offer an effective API have to think about backward compatibility, this is so that developers are not stuck carrying out grunt work on maintenance tasks when they should be building frontend functionalities.
We have customers using our APIs with an app they designed some 8-years ago – and they’ve not had to make a single change to their app because of the changes we have brought to bear in our API (which have been many and various) over time.
Democracy on the dashboard
In keeping with the wider momentum across the technology industry to democratise access to elements of IT stack functionality to all users that extend wider than word processors and email clients, its important to provide a powerful API dashboard capability to any technology that aspires to be API-first.
Speaking from our own work to provide dashboard access and control to our search & recommendation products, a user does not necessarily need to be an enterprise search guru to find ways of incorporating these functions into an organisation’s applications.
Whether its market-facing customer-level or backoffice apps, we are seeing business users that would often be defined as ‘product owners’ or ‘merchandisers’ use dashboard controls to create, amend and tweak search and customer experience technologies – and none of these people are able to write a single line of code.
Your API is a product
We know that the more granular software developers on any platform will still be working at a relatively low level with APIs to finesse their syntax, create function call structure and provision their scope for scale, security and system robustness. That’s fine, we have engineers doing that too, but what we want to think about going forwards is the point where an organisations API becomes one of its products, one of its entry points and one of its branded assets.
It’s often said (by us… and by others) that publishing an API is the easy part.
The tough part is making a great API that is fit for purpose in terms of public consumption. This is so that the developers who will bridge to the services on offer through the API itself (in our case, search and discovery, but we could be talking about geolocation services, embedded finance functions and just about anything else) can know how the API works, what its functions are, how a connection to it should be maintained over time and what standards for compatibility and security might be involved.
There are some core watchwords and truisms to guide into the API-first economy on the road ahead. It’s called API-first for a reason, attempting to retrofit an API on top of an existing platform can improve a degree of automation and functionality, but it’s not a process that stems from the API-first clean slate that IT stacks should now be created from.
An ability for reusability
We know from our experience at Algolia that really effective API-first centricity and truly robust API management stems from reusability. It’s where we started in this conversation i.e. the poor souls caught between building from scratch vs. monolithic mayhem.
When an organisation insists upon an open and accessible approach to APIs, they can promote API reusability by using a clear and consistent API description language, this ‘establishes the contract’ that describes how any given API is supposed to operate and be used.
One-size-fits-all solutions no longer cut it in this competitive world as each product and service experience has to be tailored to each individual (and not a broad marketing segment). APIs enable the now neural-like interconnections on the web and the cloud to be formed with the right fit, in the right view and with the right DNA.
It’s a small, but essentially API-first, world after all.