Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
My obsession with this problem goes back to working as an SRE at Google in 2011, seeing how the internal platform and APIs were being used by teams. I then worked at a ride hailing startup called Hailo where we got to build something similar, and experience the velocity of development in shipping products on top of simple, easily discovered APIs. I spent the next few years bootstrapping an open source project called Micro, trying to get people to standardize their API development to reach this goal.
Ultimately it took raising funding to take a real shot at it. After seeing the productivity Google unlocked and what Hailo could have done with their platform, it was clear it could and should be a product: a single way to consume APIs with one platform, one account and one framework.
Our goal is to build an API catalog that can act as the building blocks for most use cases, and then double down on services that have a lot of demand so we can improve the features and reliability.
In the wild, every API looks different, the docs are different, you have to figure out if there's client libraries or not. We unify all that, so everything looks and feels the same. All our docs are generated based on OpenAPI specs, and we code generate examples/client libraries for JS, Go, Dart and the CLI. It means you only ever need one client to access all these APIs.
Unifying API development and consumption requires a lot of resources to do at scale, hence its only happening inside fast growing startups and large tech cos. There are a lot of barriers to entry. Getting started isn't easy. Our approach has been to first nail API development for ourselves and then focus on API consumption by end users— ultimately we want to let anyone offer APIs on our platform. That requires enough large scale distribution and inbound traffic to make an attractive proposition to developers.
We've spent a year building the product with a lot of feedback on what worked and what didn't. We’ve signed up 8000 people, served 5M API requests and have 60+ APIs on the platform.
On billing: we're still figuring it out and would like feedback. It started as a free product, then moved into per request pricing. Unfortunately that's hard to scale without a lot of volume and it felt like people were more used to subscriptions for SaaS products so that's the route we've gone.
Anyway that's us, hope you like the idea and try it out: https://m3o.com.
Cheers
I believe it's a shortening of Micro -> m3o with the 3 representing the number of removed letters. In the style of Kubernetes -> k8s, accessibility -> a11y, etc.
You can find out more about Micro at https://micro.dev and https://github.com/micro (I am not affiliated).
