Live data from Hacker News

Micro APIs for Everyday Use

blog.m3o.com

41–50 of 91 posts

Re: Micro APIs for Everyday Use

#41
Devs tend to like freedom and customisation.

You're selling something for budding entrepreneurs who can't afford a developer and marketing it to developers.

The sooner you realise this, the earlier you'll be able to pivot (like mashape did).

Best of luck!

Re: Micro APIs for Everyday Use

#42
post #11

I love the Idea but pricing seems a little... premium for something is "beta". For example, Cache, a Get is 0.0001$ per request, so, with the initial 5$ you would have 50k Gets that, given the nature of a Cache seems extremely expensive. I guess your highest costs are storing up to 1mb and egress traffic (If you are in a cloud provider) but, even for a side project I could destroy the 5$ by myself developing the proj…

I think $5 (or even $50) over the life of a hobby development project is not at all unreasonable. If the service can be integrated in less time than what is required to set up a free solution, then you only have to save an hour or so for it to pay for itself.

Re: Micro APIs for Everyday Use

#43

Question regarding "Sell your APIs on Micro." If a developer makes an API and it becomes popular on Micro, what prevents Micro from cloning that API and cutting the dev out of the proceeds?

Why do support, q/a, maintenance, performance improvement for hundreds API with thousands of quirks when you can sell shovels as if they were made of gold?

In a similar vein, how much visibility does micro API bring to my API compared to established platforms? Even assuming it's a lot, why not just publish my API on all of them?

Re: Micro APIs for Everyday Use

#44

Question regarding "Sell your APIs on Micro." If a developer makes an API and it becomes popular on Micro, what prevents Micro from cloning that API and cutting the dev out of the proceeds?

Because we don't want to do the hard work. We tried it already. We initially started by managing all our own infrastructure, building our own APIs from the ground up and it turns out that's really hard. If anything we can never match the depth and experience of someone who's already doing it. So it just makes more sense to partner. We can probably provide some nice features on top for caching and whatever else to protect the third party API but otherwise the goal is to bring together a fragmented market.

Looking at it another way. I worked on open source for many years. Seeing what AWS has done to open source projects, it's a really dishonourable thing and while I get they're running a business I think there were better ways to go about it than just lifting a project and running it themselves. So for us it's really about building a trustworthy business that empowers individual devs and small teams. And you can't do that if you try to cut out the people who got you to where you wanna go.

Re: Micro APIs for Everyday Use

#45

I'm probably missing something - some of these APIs I get, but some just seem useless. Why do I need an API to convert images? Find emojis? Convert "John" to "Hello John"? (ok the helloworld service is just a demo.) I can do that on the client using Javascript. Moreover, why this instead of something like AWS Lambda, where you code your own service? Instead of prebuilt APIs, why not make it more general? Don't get me…

> Why do I need an API to convert images? Find emojis? Convert "John" to "Hello John"? (ok the helloworld service is just a demo.) I can do that on the client using Javascript.

Twofold: First, it's similar to why they wouldn't just clone a developer's API on the network. The system that can do image conversion requires maintenance. A system that is calling an API providing that image conversion offloads that maintenance elsewhere (presumably to something that can manage the maintenance more efficiently than someone who just incidentally needs the feature).

Second, APIs will become the primitives everything else is built out of in time. Custom code in clients just become more and more of a shim over time.

Re: Micro APIs for Everyday Use

#48
1. Why would I trust that this will stick around if I make a business on this?

2. Why would I pay someone to "generate IDs" at $1/10k requests?

3. If the DB API was performant and supported full SQL, it looks like it would cost $business I know of two orders of magnitude more than current cloud spend to switch to it. (They would not, because of compliance.) For whom is this the right pricing model for?

I compared the pricing here to Amazon Aurora Serverless (https://aws.amazon.com/rds/aurora/pricing/) with their example of 110 operations/second. Their cost: $186/month, yours: $28,512/month.

4. No SLAs, SLOs, SLIs, metrics, no data sovereignty or retention/deletion policy, no privacy policy, no compliance policy, no mention of encryption or details on how tokens are generated, rotated, revoked. No mention of password security in the user identity API. Why should I trust that you're not selling my data or storing it on an SD card somewhere that anyone could just grab and walk away with?

Re: Micro APIs for Everyday Use

#49
post #7

Would be cool to have a really lightweight auth service for registering and logging in. Could still be ephemeral on the order of hours. This seems like it would be easy to monetize (if that were desired) by just increasing quotas / limits, or adding certain features to any particular API that made QOL better.

I'm working on a product in the auth space, would love to know a bit more about your use case... also, why would you want ephemeral auth?

Re: Micro APIs for Everyday Use

#50

1. Why would I trust that this will stick around if I make a business on this? 2. Why would I pay someone to "generate IDs" at $1/10k requests? 3. If the DB API was performant and supported full SQL, it looks like it would cost $business I know of two orders of magnitude more than current cloud spend to switch to it. (They would not, because of compliance.) For whom is this the right pricing model for? I compared the…

Some of these services are proof of concepts/placeholders while the others are coming out of the pipeline. So their price is not necessarily final either.

Admittedly the "library as a service" ones are more for niche use cases, like how I go to a website sometimes to get the current Unix timestamp.

If you want an example $X_FORMAT id, paying 1/100 cent for it is no big deal.

Post reply on HN