Show HN: M3O – Universal Public API Interface (m3o.com)

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.

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'

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.

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.

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!

    crypto/handler/crypto.go:172: 
    rsp.Date = time.Unix(0, int64(res.Timestamp)*int64(time.Millisecond)).UTC().Format("2006-01-02")

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.

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).

If you scroll down it says it under the "API request" heading. 1 credit is £1 and allows 1M API calls. There are a few APIs that are charged above the base rate so that number will be slightly lower but effectively 1 credit is £1. The reason for using credits is because a lot of our users complained of currency fluctuation and preferred not to have something dollar denominated.

Thanks for your response and questions. On the point of payments. Yes would love to do this for payments. We've abstracted away stripe in this way internally but offering it to everyone is more of a question of how to do it right. Do people want to use their own stripe account? If not do they want us to manage their payout details and customers? It's worth doing but only if we can do it right.

On currency vs Forex. The Forex service is more for those needing trading data, that's what it is. The currency service is more generally useful for providing currency conversion in your website or app or that's how I think of it.

I first seen M3O from the public-apis repo[0], while it looks fine, the LICENSE change is pretty messed up.

[0]: https://github.com/public-apis/public-apis

Thanks for your honest and critical feedback. Let me try to address your questions head on. First let's start with context. I've been working on the ideas behind and around Micro for 7 years now. The first 4 years of which were solo and bootstrapped. It started with the idea of building a "platform for microservices". I spent that initial time focused on an open source framework called Go Micro and then a companion toolkit called Micro. These were what I thought as the building blocks of a platform and my hope was to create a standard in the industry that would lead to everyone building services that could be shared and reused. It was pretty hard going, I burned my savings for a year, then a friend was gracious enough to put his name on the line and sponsor my work at his company. But I was still largely doing this solo coding 18 hours a day in my apartment. Eventually I managed to raise $2m in seed funding May 2019 after failing for the 4 years before that. That changed everything. I was able to hire a team and try to execute on the goal of building a platform for microservices. It also meant massively overhauling the open source project to support that.

The licensing change you're referring to is at a time when we were writing a v3 of the software (again major overhaul) moving from a toolkit to a PaaS like product. At that time AWS was picking up popular open source projects and running them without contributing anything back. I watched the hard work of so many people I knew personally just get lifted and profited from with nothing in return. I also saw them fightback using custom licenses. Cockroach, Mongo, Redis, Elastic, Confluent and others all relicensed to address the issue. I tried to learn from their experiences and my assumption at the time was, we need some sort of new licensing standard and that Micro should adopt something like that too so we don't run into this future problem. I saw Heather Meeker, who wrote most of those custom licenses do something called Polyform, trying to create this standard, so I started to think about adopting it. We had gone from this solo bootstrapped project to VC funded and I was trying to turn this thing into a real platform which meant the project was effectively being totally rewritten and v3 was a massive departure from everything it had done before. It was clear we'd be leaving behind those existing users and so I made the decision to relicense. I used the information I had at the time to make a decision, whether it's right or wrong in the eyes of users, it was the decision I made.

You have to understand, I'm a developer who believed in everything being free and open and doing the right thing in the open source ecosystem. But I had also spent 5+ years giving away free software with little contribution in return, I had one corporate sponsor and everyone else was just using the software filing issues, complaining on slack, etc. I was so grateful in the beginning to have people use something I wrote, but I became resentful of that fact the longer it went on without anyone contributing back. I was personally struggling, mentally, financially, but no one really cares about that side. People just care that you give them free stuff.

So the licensing change was based on a complete rewrite, move to v3 and watching the industry shift. I was in that space, I had to act accordingly. In time as our PaaS efforts failed, it became clear this wasn't going to be a thing we needed to worry about, so I switched back to Apache 2.0. That's the gist of it. People make mistakes, but we're also just trying to do our best. I have more empathy for Solomon from Docker, Shay from Elastic and others now than ever before. None of us are doing things maliciously, none of us are trying to pull a bait and switch, we're just doing the best we can. It's blood, sweat and tears. But you can only know that if you live the journey.

On your frustrations around the rebranding. Startups pivot. What can I tell you. We're quite lit...