[HN Gopher] Show HN: M3O - Universal Public API Interface
___________________________________________________________________
Show HN: M3O - Universal Public API Interface
Hey all, I'm Asim, the founder of M3O, a curated catalog of APIs
that provides simple abstractions for the most common API use
cases. The idea is to create a single place to explore, discover
and consume public APIs as higher level building blocks. Most of
the time I don't use all the features of an API and I assume most
devs don't either, so picking and choosing the common patterns,
abstracting it away and surfacing a new building block is useful.
For example, Twilio has a lot of APIs but I only care about SMS.
Even then I just want a quick way to send it. So stripping it all
away results in something that's one endpoint and 3 fields (from,
to and message). Another example is something like email. There
are services like sendgrid that provide a really feature rich
experience for email but I'm just looking for something simple that
will let me send plain text or html. There are a number of API
marketplaces out there, but we're doing something different--our
goal is to improve productivity. For example, RapidAPI has
thousands of APIs, but there's a lot of duplication. It's
overwhelming for developers. Choice is the enemy of productivity.
AWS, on the other hand, offers a curated catalog of services where
each focuses on a specific problem. We feel the same: from an API
perspective you only need one of each building block. You only need
one SMS, Email or Geocoding service. I've been obsessed with this
problem since 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 to me 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 it's
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 try it out (https://m3o.com), and would love to hear your
thoughts in the comments!
Author : asim
Score : 68 points
Date : 2022-04-25 10:09 UTC (1 days ago)
(HTM) web link (m3o.com)
(TXT) w3m dump (m3o.com)
| erikig wrote:
| Out of sheer curiosity - why name it M3O?
| jacobwg wrote:
| 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).
| ttul wrote:
| When your email endpoint starts getting jammed up with spam and
| phishing, drop me a line.
| mfrye0 wrote:
| This looks great. I've had a similar idea, as we've had to build
| many of these utility tools internally for our team (address
| parsing / geocoding, Google search, proxies, etc). I wished there
| was just an easier, off the shelf, affordable option we could
| have reached for instead.
|
| I'm the founder of BigPicture.io. We have APIs for looking up
| company data via domain, name, or IP address. I'm not sure if our
| APIs are potentially too "high level" for your platform, but I'm
| open to chat if you're interested in collaborating or just doing
| general user research.
| ducktective wrote:
| 1- Please don't promote discord by enticing users to join a
| server to earn "extra credits". At least add in Matrix or IRC.
|
| 2- How does this differ from RapidAPI?
|
| Thanks for your post and hope you success!
| asim wrote:
| 1. Appreciate your perspective on this. We're really giving
| people credits to write services. A number of people have
| already done so. I'm trying to get more and more people to help
| us build. Always looking for better ways to introduce that to
| people.
|
| 2. Paragraph above mentions. Rapidapi has thousands of APIs.
| Often duplication across many of them. We're very much focused
| on curation and one of each building block. Hopefully less
| choice means more productivity since you don't have to spend so
| much time figuring out which API to use. We also define our own
| APIs and client libraries whereas rapidapi is more of a proxy.
| lloydatkinson wrote:
| Is there a reason for using non-standard language features for
| module imports?
|
| > const m3o = require("m3o")(process.env.M3O_API_TOKEN);
|
| Should be using ES modules, and then allowing the creation of the
| m3o object with the supplied API token. This future proofs the
| code, because ES modules are part of the language spec.
| CommonJS/RequireJS was only ever a hack.
|
| > import { m3o } from 'm3o';
| asim wrote:
| I'm not sure why we did it that way. Will get one of the guys
| on the team to respond. I think it was about simplifying that
| initialisation but I sort of understand what you're saying. We
| still allow per API intialisation in the way you've mentioned.
|
| > import { AddressService } from 'm3o/address'
| martinm3o wrote:
| At the time of writing the examples for the site we decided to
| use require as we had a lot of new Node.js developers and
| wanted to make sure they could just get going without having to
| know how to compile their code.
|
| We will potentially move to import in the future, but people
| asked for require when the examples previously used imports.
|
| With the package you can user import as an ES Module version is
| available:
|
| > import M3O from 'm3o'; > const m3o =
| M3O(process.env.M3O_API_TOKEN);
|
| Note: As long as the M3O_API_TOKEN environment variable is
| provided via a .env file then this is not required to be
| passed.
| krono wrote:
| This is very well put together! The API feels very natural and
| has an obvious flow to it, easy to work with.
|
| The vast majority of Firebase projects should have their needs
| more than covered by these endpoints/services. I doubt Google
| would mind if you were to take some of those lower-end customers
| off their hands ;)
|
| In order to make this comment look less like a paid endorsement:
| I couldn't find the upstream sources or info on your pre-
| processing of the data endpoints (news, stocks, etc.). Sadly
| without this information they are quite useless.
|
| I can see this going places.
| asim wrote:
| Thanks for the comments. Yea so we used to say "Powered By X"
| to indicate what the APIs were backed by but it was a little
| hacky. We'll try to reintroduce something back into specify the
| "source". You can otherwise see all the source code for the
| services in a monorepo on GitHub
| https://github.com/micro/services. Would be interested to get
| feedback on a better way to make it available.
| krono wrote:
| Woah, open source too, that is awesome! I'm currently
| learning Go, will try to get a PR in later this week.
|
| Considering this public availability of your data source
| implementation details, a basic provider name listing
| somewhere in the docs would be good enough for me!
| asim wrote:
| I really want to try make it all programmatic but yea in
| the docs is probably the easiest to start. Thanks for the
| feedback.
|
| You can see the rest of the source for the site and client
| libs in https://github.com/m3o. I'm separating Dev UX from
| the actual underlying platform and services in the hopes
| that others might also build things around them.
| asar wrote:
| I really like the product and the direction this is going!
| Especially for things like Authentication, DB, PubSub the value
| proposition, compared to tying a bunch of 3rd party services
| together or reading a lot of AWS docs (both options will be much
| more expensive), seems great. So I will definitely try out your
| service!
|
| I do have some question for a bunch of the other APIs, and maybe
| this points to an issue I'm having in general with the service
| right now, it's missing transparency in the specs.
|
| - Are things hosted on some other cloud provider, if so where?
| What region?
|
| - What about uptime? If I end up building an application with all
| of these APIs, I do need a bit more confidence that things will
| be stable.
|
| Some more specific questions
|
| - the crypto endpoint looks interesting, but for me, it would be
| quite crucial to know where the data is from? How often is it
| updated?
|
| - For the "Google" endpoint, I'm missing the option to select
| mobile or desktop results, and also what's the default region? Is
| this done via a headless chrome instance running somewhere, or
| just curling results? Do I have to worry that your IPs will be
| blacklisted by Google if there are too many queries?
|
| - And a random idea for the "Comments" API it would be great to
| combine it with the "Spam" endpoint that's available for emails.
|
| Really excited to see where this is going though! And I'm
| definitely going to follow you guys for new features and API
| additions, joined the discord a while ago, actually.
| asim wrote:
| Thanks for the comments and questions. I'll do my best to
| answer them.
|
| > Are things hosted on some other cloud provider, if so where?
| What region?
|
| Our core platform is currently hosted on DigitalOcean in the
| London region. That will expand to multiple regions and
| multiple providers over time. We did start that way many years
| ago but with a small team it's hard to manage.
|
| > What about uptime? If I end up building an application with
| all of these APIs, I do need a bit more confidence that things
| will be stable.
|
| We want to be able to provide uptime guarantees in the near
| future. Right now I'll say based on our experience running it
| in the past 9-12 months it's feeling like four 9s verging on 5
| but I don't want to jinx us. We are dependent on our providers
| but we're also people who have managed platforms for many
| years.
|
| > the crypto endpoint looks interesting, but for me, it would
| be quite crucial to know where the data is from? How often is
| it updated?
|
| Our crypto APIs are currently powered Finage.co.uk. We do some
| level of caching on our side but only for 5-10 mins. I'll try
| add some details around that in the overview. You can see the
| source at https://github.com/micro/services
|
| > For the "Google" endpoint, I'm missing the option to select
| mobile or desktop results, and also what's the default region?
| Is this done via a headless chrome instance running somewhere,
| or just curling results? Do I have to worry that your IPs will
| be blacklisted by Google if there are too many queries?
|
| This is using Google's custom JSON query API. It's pretty
| limited but we also started with a very simple usecase. You're
| the first to ask for anything more advanced and that's how we'd
| look into it. So happy to dig in more and see if we can work on
| it.
|
| > And a random idea for the "Comments" API it would be great to
| combine it with the "Spam" endpoint that's available for
| emails.
|
| Thanks will look into it!
| jagger27 wrote:
| > Our crypto APIs are currently powered Finage.co.uk. We do
| some level of caching on our side but only for 5-10 mins.
|
| This seems very much at odds with the description of "up to
| the second cryptocurrency prices, quotes, previous close
| information, and news."
|
| I wouldn't want to act on stale information, especially when
| the timestamp is truncated so much.
| crypto/handler/crypto.go:172: rsp.Date =
| time.Unix(0, int64(res.Timestamp)*int64(time.Millisecond)).UT
| C().Format("2006-01-02")
|
| I understand the need for caching, of course.
| asim wrote:
| I think you'll find most providers are doing some form of
| caching but I understand your point. We shouldn't miss sell
| it. Thanks for the feedback. I'd like to try provide up to
| the second relevant data but it would have to come from an
| exchange like binance or something else.
| gabereiser wrote:
| What about utilizing your own pubsub to enable a
| websocket subscription to price pushes? You could still
| cache historic, folks can subscribe to events, charged
| for receipt? I don't know how you have your backends but
| I wrote a trading platform once and this was how we did
| it. Don't become a trading platform. Just provide a way
| to get the true latest quote if someone needs it.
| RedShift1 wrote:
| Nice idea. Any plans on supporting GraphQL? I've moved all my
| API's over to that standard.
| asim wrote:
| Yes we'd love to support graphql in the long term. I guess the
| question is the best approach. Everything in the backend is a
| microservice written using grpc. So we wondered whether we'd
| need to stitch the relationship between them all together first
| or just offer a straight up graphql API per service. Would love
| some thoughts on the best approach here.
| RedShift1 wrote:
| My first instinct is definitely together, but perhaps
| namespaced, which will lead to some redundant naming but
| makes sure there are no conflicts. As a consumer you don't
| want to run to different endpoints all the time to get
| different things done, you want one endpoint and change the
| operation through the GraphQL query/mutation/subscription.
| asim wrote:
| I thought this might be the case. Hence needing to do
| something federated. But initially we might be able to
| group all the schemas into one giant graphql server. I
| don't have enough experience with graphql personally so
| will probably need some help with this.
| ricopags wrote:
| You might consider checking out www.onegraph.com and
| www.stepzen.com if you do go the GraphQL route [OneGraph
| as competition, StepZen as perhaps a solution]
| tough wrote:
| You don't need to choose. You can do both. As graphQL let's
| you build extending other graphql api's, you could do one for
| each service, and a general one, this should work nicely with
| you current setup I think.
|
| Thegraph is mainly this for web3 stuff no?
| asim wrote:
| Ok interesting. Then I'll try to figure something out. I
| think we can probably find a way to handle all the graphql
| requests through a single endpoint. Thanks for the info.
| tough wrote:
| https://www.graphql-mesh.com/ https://www.the-guild.dev/
|
| https://www.apollographql.com/docs/federation/
___________________________________________________________________
(page generated 2022-04-26 23:01 UTC)