[HN Gopher] Micro APIs for Everyday Use
___________________________________________________________________
Micro APIs for Everyday Use
Author : friendly_chap
Score : 180 points
Date : 2021-06-24 15:28 UTC (7 hours ago)
(HTM) web link (blog.m3o.com)
(TXT) w3m dump (blog.m3o.com)
| harrisonjackson wrote:
| This is neat! A similar set of APIs I've used in the past is API
| Layer - https://apilayer.com/
|
| The PDF api was really easy to hook into for cleaner receipt
| attachments in emails.
| golondon wrote:
| is this the latest pivot? are we going to see another completely
| different business in 3 months?
| zomglings wrote:
| I don't understand your intention here. It seems like you are
| shitting on the guy.
|
| He is trying to build something useful, which may take some
| pivots, and that is nothing to be ashamed of.
| IAmMaulik wrote:
| This looks great!
| blakbelt78 wrote:
| Would you consider this product a competitor to RapidAPI?
| adamhp wrote:
| 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.
| pault wrote:
| You can find a bunch of these if you search for jam stack
| resources.
| asim wrote:
| Hey there. We've got you covered. Here's our user service that
| includes user management and authentication
| https://m3o.com/user
| bsid wrote:
| 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?
| nickreese wrote:
| Really surprised this is the first I've seen of the idea for an
| API marketplace that seems to get the developer UX right. Would
| love to be an investor in this idea.
| orliesaurus wrote:
| Basically the old Blockspring platform but built for 2021 - looks
| good!
| mrtimo wrote:
| This is great. I'm a college prof, and this is perfect for
| teaching students how to use APIs.
| asim wrote:
| Thanks! Let us know if it ends up being used at your college :)
| NanoWar wrote:
| Where do I keep the Api key when I use this from a SPA?
| transitivebs wrote:
| Love the initiative; I'm sure you'll run into some of the same
| lessons that I've learned building Saasify:
| https://transitivebullsh.it/saasify-vc-feedback
|
| Happy to chat further about this space if you're interested &&
| keep up the great work building for devs
| Jakobeha wrote:
| 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 wrong, this seems like a great service and I can see
| some niche use cases. Also basic APIs for things like database
| operations and authentication which can actually get pretty
| complex, and like getting the weather which you can't do
| yourself. But I can't really see the benefit to some of these
| APIs, and a custom lambda-style service-creator seems better than
| a lot of niche APIs and "submit a form if you want your API
| here".
| asim wrote:
| Thanks for that. It really comes down to the target audience.
| We have a lot API builder like platforms. In fact this is what
| Micro was before (https://m3o.dev) but it turns out that's not
| really what a lot of people want. Those who want to build APIs
| already know how and tend to pick a cloud of choice to do it
| on. Otherwise it's really down to reusability of building block
| APIs we all tend to continually build. What GitHub did for
| source code we want to do for APIs.
| Jakobeha wrote:
| Cool, thanks for the response.
|
| Btw, I suggest adding links to https://m3o.dev from
| https://m3o.com and vice versa. Until your response I didn't
| see that the former site existed.
| musingsole wrote:
| > 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.
| TamDenholm wrote:
| Do you have a roadmap for the API's you'll be adding?
| asim wrote:
| Hey we don't yet have one to publicly share but will happily
| put one up if more people are interested with potentially user
| ranked priority so we get to the most requested ones first.
| TamDenholm wrote:
| That would be awesome. :)
| _def wrote:
| Is there something like this as open source and self hosted?
| remram wrote:
| Redis?
| AaronFriel wrote:
| 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?
| friendly_chap wrote:
| 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.
| krat0sprakhar wrote:
| Love this! I'm surprised this hasn't been done before (or it
| has?) because it sounds so good. The list of APIs cover almost
| 95% of all project ideas that I want to run on Cloud, so I'm
| really excited to try this out. The simple pricing structure is
| excellent as well.
|
| Good luck!
| asim wrote:
| Thanks for the positive feedback! What's that 5% you feel is
| missing? We'd obviously love to build it and make sure we've
| got everything covered. A couple on my list are a message queue
| and probably the ability to run apps in a container from a git
| URL.
| jamestimmins wrote:
| I love this, and can immediately see the value.
|
| Is there an opportunity for third party developers to add new
| APIs?
| asim wrote:
| Hi, yes this is the end goal and for it to be entirely self
| service. For now we're working directly with those third
| parties and doing the integration ourselves but ideally we want
| to let people do it themselves, display their own logos and
| price the APIs however they see fit. Happy to chat further
| about it and get ideas too on how we could speed this up.
| 256DEV wrote:
| I've actually just gone through the process of integrating my
| currency API [1] with Micro. I really liked the idea for this
| service and actually just emailed them asking your exact
| question! The process was smooth and I was impressed by their
| clear communication and very responsive development work.
|
| I've been a user of RapidAPI as both an API publisher &
| consumer and I think I prefer this Micro model instead - API
| curation, standardized docs etc. etc. RapidAPI can feel like a
| bit of a free for all and even though it's technically one
| entity proxying everything it's often felt to me like more of a
| list of random services than something cohesive. I can
| definitely see why Micro is describing their service as a sort
| of AWS of useful APIs.
|
| [1] https://www.exchangerate-api.com
| mana72 wrote:
| I like this. How different are you from Abstract API
| (https://www.abstractapi.com) though?
| [deleted]
| vira28 wrote:
| when trying to create an api getting "There was an error creating
| the key. Please try again later."
| flipnotic wrote:
| 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?
| asim wrote:
| 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.
| jokethrowaway wrote:
| 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?
| jokethrowaway wrote:
| 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!
| spzb wrote:
| I literally just had the idea for something like this yesterday.
| Congratulations on beating me to it!
| yNeolh wrote:
| 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 project itself.
|
| Other than that, loving it, and I will try to give it a go in the
| future, and check how the pricing affects my decisions.
| asim wrote:
| Thanks for the feedback on pricing. Yea we understand the
| initial cost on some APIs might seem high in aggregate but what
| you see is what you get. Unlike AWS who bill you in aggregate
| across storage, egress, etc, we only have one cost - the price
| per request. So some costs are baked in but we as developers
| ourselves totally get it and pricing will definitely evolve.
| Thanks again for the feedback.
| rishav_sharan wrote:
| Likely an unreasonable ask, specially considering that you
| folks are just starting out - but have you considered adding
| a free tier for hobbyists and pet projects?
|
| Most of you competitors have some form of free tier and
| cheapo devs like me would prefer to embrace some complexity
| over paying upfront for just simple projects. the $5 starting
| bit is great but is not the same as a limited free tier.
|
| Overall love the idea and wish you all the best. Love the
| minimalistic/functional UX of the site as well.
| asim wrote:
| Free tier was something we've had previously but it became
| hard to justify because of our third party integrations and
| what it costs us. It might be something we try figure out
| in the future. Thanks for the feedback.
| taberiand wrote:
| 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.
| rank0 wrote:
| This is awesome I will definitely be trying this out later! I
| have been wanting a service like this in my head for ages. I hate
| having to sign up for developer accounts for every single api I
| want to hit. There SHOULD be a general purpose one stop shop
| where I can pay by request for access to things like weather,
| stock prices, ephemeral storage...
|
| Some advice - keep it simple! Simplicity and ease of use are big
| selling points to me. It's very easy to get lost in feature
| creep.
| pbreit wrote:
| Could someone explain to me this whole movement towards "Bearer"
| authentication? I understand it in an Oauth context and using
| JWTs. I don't really understand it with simple API keys. What is
| the point of prefixing and API key with "Bearer "?
| tobyjsullivan wrote:
| A security token with the property that any party in possession
| of the token (a "bearer") can use the token in any
| way that any other party in possession of it can.
| Using a bearer token does not require a bearer to
| prove possession of cryptographic key material
| (proof-of-possession).
|
| I think most people interpret that definition as including API
| secret keys. I'd be curious to hear any alternative suggestions
| as I run into this fairly regularly.
|
| https://datatracker.ietf.org/doc/html/rfc6750#section-1.2
|
| Also relevant: https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Authentica...
| detaro wrote:
| An Authorization header value is defined to be a pair of type
| and the actual authentication/authorization information.
| "Bearer" works, so why make up something else?
| tyingq wrote:
| I suppose it's because of the "micro" focus, but it seems odd to
| me that the table name would be optional in the DB, and that the
| KV api doesn't have namespaces.
|
| The navigation and layout of the site are terrific.
| asim wrote:
| Thanks for that feedback. Optional table name just means you
| get a default table which is literally called "default". We
| left out namespace in the kv API just to keep things simple but
| I'll take that feedback onboard and think about changing it.
___________________________________________________________________
(page generated 2021-06-24 23:00 UTC)