Introducing MagicByte.io, a cloud functions library for developers.

Deciding to build an API

Something that's been on my nerd bucket list is building an API for public use. For non-techies (hi Mom!), API is short for application programming interface and is essentially the backchannel that lets software applications talk to each other.

I've used plenty from companies like Stripe, Quickbooks, and Shopify, and even bootstrapped some internal APIs, but there's another level of design that goes into making an API for others.

Here are a few ways in which public APIs are harder:

• Authentication - you have to dynamically generate and validate user keys
• Rate Limiting - you need to check usage against per user limits
• Documentation - you should provide polished explanations of inputs, outputs, and examples (and make it SEO-friendly!)
• Demo - you have to quickly demonstrate value to potential customers
• Extra-Thoughtful Design - you want to make life more predictable by including a versioning system for backwards-compatible updates, consistently structuring JSON responses, and following HTTP response code conventions

This project took these challenges on, plus the whole SaaS signup and billing process.

Introducing Microservices as a Service

Microservices are popular in software design since they help decouple parts of the application.

For example, if your company was building a fraud detection product, you could have one team develop the fraud detection algorithm and offer it through an API to other teams, so that your desktop software team and mobile app team can each leverage the algorithm without having to copy or maintain it in their code.

Microservices as a Service would be bundling a bunch of small, useful functions that typically appear inside a code base, but providing them to external applications through a subscription service.

The MagicByte.io product

The product vision is to build out a library of hosted microservices, delivered through an API, that developers would find useful and be willing to pay for.

A developer could theoretically move all sorts of software functions into the cloud ("Need to add two numbers? Use the number adding API!").

But there are tradeoffs of course. Using an API for trivial tasks is much slower than incorporating it in the codebase. Plus why would anyone pay for cloud functions that can be found for free on the internet and easily copy/pasted into your own code - like calculating the distance between two coordinates?

Here are some types of functions that could make sense as cloud microservices:

• Dynamic content - such as weather and stock data
• Real-world knowledge - like country capitals and company ticker symbols, that may require large databases
• Tasks requiring lots of complexity or computing power - like web scraping and optical character recognition

For the MagicByte.io minimum viable project, I've added functions for U.S. geography and IP addresses that I've needed in prior projects. These were simple in concept, but unruly to build at the time.

Going forward

With the first phase of this project complete, there could be a number of directions to take MagicByte.io.

From most to least likely:

• A living template, ready to be repurposed for a future SaaS product
• A growing collection of functions, which I contribute to and dog-food for my own projects
• A proper startup, relentlessly focused on expanding and selling the microservices that developers need

I personally think there could be some killer microservices around social media lookups. For example, if a user provides their Facebook link in a web form, can you grab their user ID and picture? Or knowing a person's Facebook ID, could you return their Instagram ID?

But those are projects for another day...