Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Micro APIs for Everyday Use

blog.m3o.com

Post reply on HN
Print view View original

81–90 of 91 posts

Re: Micro APIs for Everyday Use

#81

Post by dolmen »

akudha wrote: post #56
Jakobeha wrote: post #16

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…

People pay 5$ for Starbucks Latte when they can make coffee (maybe better even) at home in 5 mins. It is laziness, convenience etc. Or simply, one less thing to think about (assuming m3o's service works well etc), which alone is a good enough reason to pay for it.

Any external service is not "one less thing to think about" but "one more thing to think about" (security, refilling account, check alive status...).

Re: Micro APIs for Everyday Use

#82

Post by dolmen »

musingsole wrote: post #45
Jakobeha wrote: post #16

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 maintena…

If you are ready to delegate image handling to a SaaS AND do not want bother about it, just use the best one that will allow you to grow in API coverage and volume (number of images, number of derivations, number of clients) so you'll be better covered by an expert in that domain.

A micro API might be useful for a micro project. But if your project is micro, do you really need to bother with one more SaaS dependency? Just use a full SaaS app building platform that will provide a fully integrated developer experience. (https://www.nocode.tech/ is a directory).

Re: Micro APIs for Everyday Use

#83

Post by dolmen »

shoo wrote: post #69
TheDudeMan wrote: post #61

I like this model. It's something I wanted to do a few years ago but of course didn't. I think this works best for complex and expensive computational APIs. For instance, "do an FFT on these 2^N-1 data points" or "factor this 20-digit number". Things that are fairly easy to state in words, but tricky to implement correctly. Maybe you can't find a good implementation in your language. Also, this is probably most usefu…

FFTs or integer factorisation are pure-functional tasks and seem more suitable for a simple library call and local computation, without involving the network or adding new external dependencies -- assuming you have code running somewhere with sufficient compute. i find APIs that let you interact with or observe the world far more compelling (e.g. get the latex forex rates, make a phone call, etc), especially if they…

The rule is: if you data is local, the code to handle it should be local.

APIs that provide data are useful. APIs that just transform data that you provide much less because much less efficient and also bring integration nightmares (think not just today but long term).

Re: Micro APIs for Everyday Use

#85

Post by dolmen »

detaro wrote: post #34
pbreit wrote: post #33

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 "?

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?

Why not a custom HTTP header where the value is the bare token without "Bearer" prefix?

I don't see the value of using specifically the Authorization header for machine-to-machine APIs (except to make it easier for man-in-the-middle).

Re: Micro APIs for Everyday Use

#86

Post by dolmen »

zomglings wrote: post #51
golondon wrote: post #46

is this the latest pivot? are we going to see another completely different business in 3 months?

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.

Who wants to rely on an API which will disappear in 3 months?

This is fine for a student project or an app which has a fixed planned end-of-life, but not much more.

If I learn that API and it disappears, I just wasted my time. I should have learned an API that I will be able to reuse later.

Re: Micro APIs for Everyday Use

#87

Post by dolmen »

A-Train wrote: post #71
spzb wrote: post #26

I literally just had the idea for something like this yesterday. Congratulations on beating me to it!

You should be grateful that someone else did it because it is a bad idea. Everyone of those services is easily replaceable with a library call. For example there is no language in the top 20 Tiobe index that doesn't implement all of this stuff already: image resize, key value store, id generation. And also you should not split your system into microservices like that.

What's wrong with using http://left-pad.io/ ;)

Re: Micro APIs for Everyday Use

#88

Post by dolmen »

friendly_chap wrote: post #50
AaronFriel wrote: post #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…

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.

The only use cases are the ones that fit the $5 free tier.

Re: Micro APIs for Everyday Use

#89

Post by dolmen »

friendly_chap wrote: post #50
AaronFriel wrote: post #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…

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.

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

    alias t='date +%s'
Post reply on HN