3 reasons why your API should be a snoozefest  

Innovation can be a wonderful thing. It can raise our standard of living, it can save lives, it can take us further and faster than we dare to dream… right?

Yes, absolutely. But innovation just for innovation’s sake isn’t always the right path. Can we let you in on a little secret? Here at Tyk, we’re rather fond of boring. Boring means reliability. Boring means affordability. And, when it’s done right, boring means success. 

Ok, so we’re only a few sentences in and I’ve already revealed my three reasons why your API should be a snoozefest. Bear with me just a minute or two longer though and I’ll show you why that is. Or, if you’ve got 20 minutes to spare, you can watch me tell you in detail


Let’s look at programming languages as an example. Everyone (well, Google Trends, GitHub and software quality company TIOBE) agrees that Java is the most popular programming language in the world. Why? Because it’s reliable. It’s not exciting, it’s not thrilling. In fact, in many ways, Java is the ultimate snooze-a-thon. And that’s why the light is burning brightly for the masses. Java delivers the reliability that only a truly boring programming language can and, as such, is popular around the globe (sorry, all you Java programmers out there!). 

And what’s so great about reliability? Well, it comes hand-in-hand with established best practice. A programming language that is popular worldwide has, of necessity, a large community of developers who all have to adhere to the same established principles. No rogue developers with wild ideas and the potential to destroy your systems – just simple, acknowledged best practices that reinforce reliability every step of the way. 


When you opt for a popular, boring product (we’re looking at you, Java), you’ve got access to a huge talent pool. Building a team is quick and easy as a result. You can find the developers you need at the right levels of seniority and end up with an affordable team with a sensible structure. 

An example. When I first founded Tyk, with the vision of creating a truly innovative  open source API management platform, I decided to write the entire thing in Go, as a reflection of the scale of my exciting global vision! However, I quickly found myself competing for the attention of a fairly small list of Go developers. My competitors? Google and Facebook. My decision to use Go turned rapidly into a lesson on the value of boring when it comes to building an affordable team. It’s a lesson I’ve learned well! 


There’s certainly a time and a place for innovation, but when it comes to APIs, boring is King. We need only look at three current trends – serverless, frameworks and microservices – to see why. 


Serverless allows you to deploy your functions to a third-party cloud and run them only when needed, with a view to writing once and deploying anywhere. At least, that’s what it says on the tin. In reality, you deploy to AWS or Google Cloud Functions or the Azure Service. And this sets the scene perfectly for you to become locked in. 

If you’re writing to deploy to AWS, before you know it you’re buying AWS Dynamo DB to fulfil your database needs, Amazon SQS to allow your microservices to talk to each other, Amazon ElastiCache as your cache for all your web-facing stuff and API Gateway to allow traffic to get to the services… Suddenly, you’ve bought more servers with serverless than you would have done without it – the only difference is that you don’t control them anymore! 

That’s not to say that there’s not a time and place for serverless – it’s pretty cool for throwaway prototypes, repeated reporting tasks and nano-services with zero dependencies. There are certainly instances where the Tyk team and I use it. Just don’t rely on it for your core functionality. 


Frameworks also claim you can write once and deploy anywhere. It’s an idea that used to work for mobile development – developers (myself included) used Cordova, Xamarin, PhoneGap, Titanium and MoSync to build for iOS, Android, Windows Mobile and BlackBerry OS. However, the world has moved on since then – in more ways than just the demise of Windows Mobile and BlackBerryOS. Frameworks went out of the window as developers just didn’t need them anymore. Instead, we wrote directly for iOS and Android. So why reintroduce them now?


Let’s talk about microservices. There are a whole host of good reasons to use them: 

  • High availability
  • Localised complexity
  • Failure isolation
  • Faster service iteration
  • Innovation
  • Independent scalability
  • Focused and productive teams 
  • Future proofing your software. 

But using microservices where necessary is very different from taking a microservices-first approach just for the sake of doing something new and exciting. Do that and you’re suddenly increasing the complexity of your application and runtime environment by an order of magnitude.

Do you have a huge amount of scale? If so, best practice says don’t go microservices first – just split off the stuff that’s breaking. After all, do you have the resources to dedicate an entire team to each microservice? And have you already got people on board who’ve implemented the relevant microservices before? If not, you’re looking at diving in head-first with no idea of what’s lurking beneath the surface. 

Microservices are perfect for the right uses, but you need to have a damn good use case in order to justify a microservices-first approach. That approach can triple your go to market and leave you with more headaches than you can bear. The result? Either complete abandonment of the project or a return to your original monolith.  

As I’ve mentioned monoliths, let’s just clarify something. ‘Monolith’ is not a dirty word. Monoliths are strong, stable, reliable… boring, even. And it is this boring approach that can be key to your success. 

Why you need a boring API strategy

Good, solid application design can yield good API design. It’s all about forethought, not pursuing trends purely for the sake of showing how innovative you are or just shoving an SQL layer on top of everything in the hope that it’s some sort of magic fix.

Stay sane. Stick with best practice and with monoliths. Stick with boring and snooze your way to success.

Just getting started with your API Programme? Why not download our exclusive guide from James Higginbotham: Approaching your API Strategy. It’s packed full of practical tips and guidance for creating your very own.