Less than a decade ago, if you had asked me whether API speed is important, I wouldn’t have given it much thought at all. I have worked with APIs for a long time, but usually from an infrastructure perspective – when I was configuring servers or storage, a few seconds here or there wasn’t going to make a huge difference.
Fast‑forward to now and I better understand how large aspects of my life and my daily interactions with technology are API‑driven. Speed matters: it can be the difference between a good user experience and an unacceptable one. In this post, I want to walk through some of the use cases that matter the most to me and look at how a great API implementation can make all the difference to your customers.
Dinner on Demand
Wherever you are in the world, without a doubt you have access to a modern food delivery service like DoorDash or Deliveroo. Where I live in the UK, the most popular is Deliveroo and during the recent pandemic, I’ve made a lot of use of this service.
The average consumer probably doesn’t give a lot of thought to the logistics of how dinner gets delivered, but if you look under the hood you find a technological masterpiece. Hundreds, or thousands, of services all work together to give you, the user, the experience you’ve come to expect.
Many of those services are providing API endpoints for various functions throughout the stack of the application. Some of these services allow the restaurants to come online and display the estimated waiting time for your delivery. Other services allow the drivers to log on as ready to accept requests, and keep track of their location.
The delivery tracking process is where I want to focus on how the speed of the underlying APIs is important. Once you’ve made your order and the driver has been assigned, you get real‑time updates on his or her progress towards your location. You can see the driver’s name and photo, current location, method of transportation, and estimated time of arrival.
All of this data is gathered from the driver’s side of the delivery app and passes through the backend systems via an assortment of APIs before arriving as updates on your side of the app. Delays in this system, especially in the case of fast‑moving vehicles, can cause unreliable or outdated information to appear to the end user. Most of these apps predict the fastest route taken to the destination, and if the updates are delayed, the driver can appear to dance around on the screen, causing the route to adjust and the estimated arrival time to increase.
Processing time for most APIs runs in the hundreds of milliseconds, which sounds very fast. But when you add together multiple calls among the services in the application and the roundtrip time over mobile networks, the cumulative latency can make all the difference in knowing whether the driver made that easy-to-miss left turn or not.
Lights, API, Action
I am a lover of home automation – I have several Amazon Echo products, Samsung SmartThings, Philips Hue, and even some homegrown automation in Home Assistant. Getting up in the morning and asking Alexa to turn on my home office has become a normal part of my daily routine. How would that look without fast API calls?
The overall routine is fairly simple: Alexa is connected to my Hue Bridge via the existing Alexa Skills system, my Hue Bridge is connected to the internet and in turn the Hue cloud, and finally, my lights are all connected via a local network using Zigbee. My office has seven different lights I can control individually, and I have some Hue Play light bars that provide color ambiance and help with softening the all‑white walls during conference calls or filming. I also have a white ambiance bulb that I use to provide bright whites that help me concentrate.
Along with lighting, my office‑prep process involves turning on a WiFi‑enabled socket connected to my ATEM Mini Pro, and finally sending a Wake-on-LAN (WoL) packet to my main office PC. Both are controlled within the Samsung SmartThings Hub. The power sockets are a part of that ecosystem directly and I use webCoRE to invoke the WoL magic packet. Samsung SmartThings, again, has an available Alexa Skill where I can connect the Echo to my Samsung account and the SmartThings cloud.
So there are a lot of moving parts with multiple API calls among three separate systems and my home network. If latency increases by just 200 milliseconds for each API call, the overall delay can become several seconds by the time the entire routine has run and acknowledged back to my network. Standing around in the dark isn’t a lot of fun in this situation while I scramble about looking for where I left the remote for the lights.
First‑world problems, I know, but once you are used to working within your environment a certain way and to a certain set of response times, anything else feels off and damages your perception of the system.
Fun with Finance
In terms of modernization and embracing APIs to provide a better customer experience, the area that I am most impressed with is finance. The banking industry has traditionally been a very slow adopter of new technologies. Even online banking took years to achieve feature parity with the in‑branch experience.
In recent years, several challenger banks have emerged and the world of FinTech has become agile and bustling with talent. One such bank that I use is Monzo; I’ve been a user since the early Beta stages, and I have friends who have been with them even longer. Monzo’s technology platform is second to none in finance and even though many traditional banks are starting to catch up, Monzo still holds a decent lead.
When it comes to money, every second counts, and you want to know that you are in safe hands with your bank. Monzo is entirely digital – there are no branches where I can walk in and speak with an advisor, so I rely heavily on the mobile app and the information it provides me. The APIs Monzo has built are so fast that I can receive a notification on my phone of the transaction before the in‑store point-of-sale device has been updated.
Monzo also provides mechanisms to instantly block my card via the app, to prohibit the use of legacy mag‑stripe ATMs, and to block harmful transactions such as those related to gambling. On the bank’s side, ensuring that APIs run as fast as possible can save thousands. If your customer has placed a block on his or her card, you want to be sure that the payment networks know about that before the next tap or swipe.
How NGINX Helps
All the examples we’ve looked at are customer‑facing services provided over the Internet, an Internet that already runs largely on the great technology that NGINX provides. From humble beginnings as a web server, NGINX now offers application load balancing, reverse proxy, and API gateway services, among others.
Already being entrenched in the data plane means that NGINX is extremely well placed to deliver your API services. Every millisecond counts and being able to remove several hops from the traditional path through API gateways to load balancers and on the way to the application itself makes all the difference.
Most Kubernetes clusters that I’ve deployed over the last couple of years already use NGINX as the Ingress controller. Much like the physical ADCs we once used, NGINX consolidates multiple application delivery functions into a single platform (software this time). Unlike hardware ADCs, NGINX is lightweight enough to deploy in multiple locations in your infrastructure, and bringing API services closer to the code just makes sense for modern apps.
This blog is part of a series about APIs and other trends in app modernization, written especially for NetOps engineers by industry experts and published in collaboration with Gestalt IT. If you enjoyed this blog, check out the entire series.
