Hacker News Reader

Comment by Jakobeha | Hacker News Reader

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

View on HN

> Why do I need an API to convert images?

This is actually SUPER useful because it means you can upload one master image and have the API automatically generate thumbnails, hover states, text overlays, face-detected cropping, effects, shapes, source sets, WEBP versions, etc. And then it manages all the caching, invalidations, CDNs, etc. too. It fits really well into serverless architectures where you don't want to have to maintain and scale your own backend instance of ImageMagick or similar. It turns hours of work into seconds.

But it's also a pretty mature field: Imgix and Cloudinary both do this much more powerfully and much cheaper. 10,000 cropped images (say, for thumbnails) would cost $100 on Micro but be free or nearly so on either Imgix and Cloudinary.

For the more complex APIs (like images, ironically), I would rather trust one of the bigger companies that have been doing that -- and only that -- for years, with more forgiving pricing.

For simpler APIs, I'd just build it as a serverless functions straight in Cloudflare Workers or similar. Much cheaper, probably faster and more reliable infrastructure, and scalable.

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

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

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

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.

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.

Reply on news.ycombinator.com