Why APIs change everything
Ant Stanley talked about everything being an HTTPS interface in his post recently
Everything is an HTTPS interface
In the Linux world everything is file, in the Serverless world everything is an HTTPS interface.
and connected the idea of how you do serverless to the philosophy behind Unix. It made a lot of sense:
“Good Serverless design is the Unix Philosophy reimagined for a new world of building applications on top of clouds.”
It also got me thinking.
My question is simply “Why did I start building everything as an API?”
A bit of background might help here.
I started developing backends for websites in the 1990s. That makes me pretty ancient in terms of web technologies. My first programming language was perl which is a bit crazy as a language, but I liked it and I grew in my skillset.
I then moved to building web solutions with (among many other things) ColdFusion (urgh), C#, Java (various things), and even PHP (even more urgh). Always building on a base where a “single server” was the deployment for each of these solutions (ignoring load balancers for now).
Basically, I was always building monoliths.
Monoliths are great for keeping code all in one place.
But not that good for scalability.
Along with all of this came various services. First off were tools like SOAP and WSDL which were horrible. But we figured out how to avoid the mess pretty quickly and built services based upon APIs.
The first time I remember having a web API to play around with was Flickr. We could upload and download photos and build interfaces on top of their service. It was a really interesting thing to do, and a lot of fun.
It proliferated open source SDKs on top of flickr, and then other social tools started opening up APIs and creating SDKs, and that meant that we had many and varied ways of using tools.
It also meant that new sites starting up put API access at the heart of some of their solutions, and meant that some of the frameworks built in things like REST interfaces and the ability to provide different content based upon the requested type of content.
These services became really popular.
The owners of the services didn’t overtly control the visual interface any more.
But they did control the data interface.
Then along came mobile, and we had to deal with lower bandwidth interfaces again, just like we had before the wide rollout of broadband in the early 2000s.
And this move meant that the monolith had to change. Most solutions were built for the web, and the interface was HTML, with server side processing.
Mobile‘s rise meant that we started to build APIs as a matter of course, specifically for mobile. These APIs were primarily based on some form of routing based monolithic app and utilised JSON, allowing both a website and an app to use the same API.
And that was the key.
The web and mobile could use the same API.
Looking back, I realise that because I’ve been involved in mobile technology in one form or another since before the iPod Touch came out (I started to develop around things like the Palm Pilot back in the day), I am now very much service driven in my thinking.
The idea of services and APIs has been driven by Amazon Web Services as well. I’ve been a user pretty much since AWS only had 1 or 2 EC2 instance types.
Their approach has been key to popularising the service based approach with techies and has been vital in providing the infrastructure for us techies to build solutions upon.
Although I would say one thing: they don’t always get it right first time. They do their best, but they have built and removed services over time, because they didn’t fit or built better solutions in their place.
Why I do services
So I do services because they are the simplest way to build scalable solutions on cloud that work for multiple client types.
It’s that simple.
For some solutions, a monolith or script sitting on your laptop is absolutely all that’s needed.
But for most solutions that are B2B or B2C in this world, the right way to at least start will probably be service based.
Which is why serverless is interesting.
It allows you to build services without having to know a lot about how to construct a service.
With API Gateway and Lambda, you can rapidly prototype a solution that breaks all the “rules” of how to build a service, but still works and is scalable as a prototype.
APIs separate out concerns
One of the biggest reasons I like APIs as a concept is that it separates out concerns and produces an easy way to separate a client from a server.
Most APIs up until recently were built into the server solution, usually by some form of “routing” solution.
Now, if you go towards serverless, you can ignore the routing part altogether and allow something like an API Gateway to handle the routing for you.
It separates the problem of the client and the server being tightly coupled. You can easily change both the client and the server, because the API Gateway is the contract that both sides have to agree too.
Types of service
A quick comment about microservices and REST and other things. It’s all fine if you want to go down that route, but please bear in mind they are only tools. They are not religious scripture that must be followed verbatim or you’re going to end up in a fiery technical hell.
That being said, it does help to have a common code/infrastructure philosophy when in a big team.
I’ve never liked it when people say “Is it RESTful?” or “It’s not a microservices architecture unless…”. Why? Because it often comes from either a person who’s never had to understand how to build these things from scratch, or from a person who only has worked in a scenario where these things are imposed.
I do Serverless because I am very comfortable with building prototype APIs and building from there.
I love APIs because it separates and decouples the responsibilities of teams and developers.
APIs begin to make monoliths more complex as it begins to help decouple internally as well as client <-> server.
I do APIs because it’s a natural forward progression of the way we do stuff on the internet.
Our solutions are becoming more distributed, using more third party services (APIs) and with more ways of interfacing with them than ever before. This is not going to change.
Get used to building your own APIs.
It’s not the future.