Micro APIs for Everyday Use(blog.m3o.com)
blog.m3o.com
Micro APIs for Everyday Use
https://blog.m3o.com/2021/06/24/micro-apis-for-everyday-use.html
90 comments
Thanks for the questioning. I'll do my best to answer.
1. How do you trust any startup is going to be around in the future? You can't know for sure, but something about the product calls out to you. Luckily all our services are "source available" here https://github.com/micro. Meaning if the company ever went under, you could go ahead and reuse these. We'd obviously change the licensing as required. Otherwise, we're also happy to license this technology to anyone who wants to run it themselves. Its just not "open source" by the traditional measure.
2. Maybe you wouldn't, or maybe you would depending on what kind of IDs you want to generate and how inconvenient it is for you to do otherwise. Snowflake IDs aren't the easiest to create, they require backend clustered coordination and uniqueness. But alas pricing is an art so all of this will likely change over time and be made much cheaper as we get more feedback like this.
3. If someone is looking for full SQL, they should go spin up a managed SQL database, this isn't that. We see this as a super simple and convenient persistent data storage layer that might work really well for frontend or people who were otherwise big fans of mongodb for that simplicity. It's just our first shot at some sort of CRUD layer.
4. You're right, we should do better on this. Firstly we're not selling your data and we only store whats needed purely from a customer perspective. We offload a lot of credit card and transaction processing to stripe so don't store that directly either. The product is in beta, so no SLAs just yet. Everything else, we're just learning and evolving so hopefully with helpful prodding like this we can do better.
1. How do you trust any startup is going to be around in the future? You can't know for sure, but something about the product calls out to you. Luckily all our services are "source available" here https://github.com/micro. Meaning if the company ever went under, you could go ahead and reuse these. We'd obviously change the licensing as required. Otherwise, we're also happy to license this technology to anyone who wants to run it themselves. Its just not "open source" by the traditional measure.
2. Maybe you wouldn't, or maybe you would depending on what kind of IDs you want to generate and how inconvenient it is for you to do otherwise. Snowflake IDs aren't the easiest to create, they require backend clustered coordination and uniqueness. But alas pricing is an art so all of this will likely change over time and be made much cheaper as we get more feedback like this.
3. If someone is looking for full SQL, they should go spin up a managed SQL database, this isn't that. We see this as a super simple and convenient persistent data storage layer that might work really well for frontend or people who were otherwise big fans of mongodb for that simplicity. It's just our first shot at some sort of CRUD layer.
4. You're right, we should do better on this. Firstly we're not selling your data and we only store whats needed purely from a customer perspective. We offload a lot of credit card and transaction processing to stripe so don't store that directly either. The product is in beta, so no SLAs just yet. Everything else, we're just learning and evolving so hopefully with helpful prodding like this we can do better.
I can give you an argument from end user perspective. It is quite some hassle to setup an AWS instances or services, you always have a feeling you are doing something wrong. With your service, it suits my needs as an individual dev.
But I see that as a challenge too, your target market is very limited. It is really cool product from dev or engineer perspective but I am not sure how you will go beyond individual developers. I think by posting your service here you might get a bias opinion, what would be really cool is if you target people who are learning to code and couple this service with that, it adds lot of value. Joy of getting an API working as a junior dev acts like a positive stimuli and your APIs are built for that. I dont think it is built for serious apps and services because the liability is high and it is very competitive too.
But I see that as a challenge too, your target market is very limited. It is really cool product from dev or engineer perspective but I am not sure how you will go beyond individual developers. I think by posting your service here you might get a bias opinion, what would be really cool is if you target people who are learning to code and couple this service with that, it adds lot of value. Joy of getting an API working as a junior dev acts like a positive stimuli and your APIs are built for that. I dont think it is built for serious apps and services because the liability is high and it is very competitive too.
> what would be really cool is if you target people who are learning to code
I think those people would get more value/experience from more integrated solutions/platforms of the "no code" family.
https://www.nocode.tech/
I think those people would get more value/experience from more integrated solutions/platforms of the "no code" family.
https://www.nocode.tech/
Because not everything is a reliable business? Sometimes it’s nice to make something for fun or practical.
I teach front end web development to a total beginner who is only just becoming aware that programming a web app with persistent state shared amongst users requires separate technologies than HTML/CSS/JS. The table API could be ideal for her. The alternatives: shared hosting with PHP/MySQL, anything AWS, or even Google Sheets/Airtable are all much bigger cans of worms that just slow down her cycle of getting things out there and learning the whole of the SLDC.
I teach front end web development to a total beginner who is only just becoming aware that programming a web app with persistent state shared amongst users requires separate technologies than HTML/CSS/JS. The table API could be ideal for her. The alternatives: shared hosting with PHP/MySQL, anything AWS, or even Google Sheets/Airtable are all much bigger cans of worms that just slow down her cycle of getting things out there and learning the whole of the SLDC.
Firebase and Heroku would fill that niche
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.
If you want an example $X_FORMAT id, paying 1/100 cent for it is no big deal.
I'm confused as to what sort of service that would make sense to do.
> 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'The only use cases are the ones that fit the $5 free tier.
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.
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.
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.
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.
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.
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.
That's reasonable—glad to know you considered it. Two alternatives to the free tier for single or small-batch uses so that you don't need to deal with payment information and reduce sign-up friction:
User completes a human-level task (for another API even) somewhere between CAPTCHA and MTurk to earn a few API calls.
Do something with ads near or even on the result to earn a few API calls. (Prototyping dev eyeballs are valuable.)
User completes a human-level task (for another API even) somewhere between CAPTCHA and MTurk to earn a few API calls.
Do something with ads near or even on the result to earn a few API calls. (Prototyping dev eyeballs are valuable.)
A free tier that didn't allow third party integrations might work if that's really your sticking point.
But honestly nothing wrong with charging money for a service.
But honestly nothing wrong with charging money for a service.
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.
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?
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.
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.
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?
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?
Why not have an API that publishes your API to all of them?
It’s APIs all the way down.
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.
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.
Hey there. We've got you covered. Here's our user service that includes user management and authentication https://m3o.com/user
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?
You hate your users and love watching them shake a fist at the hardest captchas.
You can find a bunch of these if you search for jam stack resources.
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.
The PDF api was really easy to hook into for cleaner receipt attachments in emails.
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
Happy to chat further about this space if you're interested && keep up the great work building for devs
that's so cool, I was just looking at your pull request on notion-api-worker a moment ago... funny to "run into" other devs across different sites!
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".
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".
> 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.
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.
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).
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.
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.
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.
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.
Best of luck!
I had a similar idea and never followed it up.
The way I see it is this: there are always a bunch of devs learning their trade.
At one point I would have great ideas but be missing two or three key components that I couldn't build.
I searched for out of the box solution for one time tokens and for a way to store date in transit for automation - nothing existed that I could use so I built it - but I've 20 years experience now and wanted to share my solutions.
Yes, you can do all of this in AWS yourself, but sometime you just want to solve it and move on.
Sometime you want to tell a client it is 0.0001 per record and that their business needs $5 per month to automate/integrate/remove something that costs them a lot more.
And charge them a decent rate for the solution, not the tools.
The way I see it is this: there are always a bunch of devs learning their trade.
At one point I would have great ideas but be missing two or three key components that I couldn't build.
I searched for out of the box solution for one time tokens and for a way to store date in transit for automation - nothing existed that I could use so I built it - but I've 20 years experience now and wanted to share my solutions.
Yes, you can do all of this in AWS yourself, but sometime you just want to solve it and move on.
Sometime you want to tell a client it is 0.0001 per record and that their business needs $5 per month to automate/integrate/remove something that costs them a lot more.
And charge them a decent rate for the solution, not the tools.
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!
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!
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 useful for prototyping scenarios. In production, you want something faster and cheaper.
Also, this is probably most useful for prototyping scenarios. In production, you want something faster and cheaper.
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 put a nice stable interface in front of a lot of complex or evolving details you'd rather not have to care about.
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 put a nice stable interface in front of a lot of complex or evolving details you'd rather not have to care about.
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).
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).
I love this, and can immediately see the value.
Is there an opportunity for third party developers to add new APIs?
Is there an opportunity for third party developers to add new APIs?
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
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
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.
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.
I like this.
How different are you from Abstract API (https://www.abstractapi.com) though?
[deleted]
I've never use another product like this again after my experience with Parse.
Tell us more about that experience.
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.
The navigation and layout of the site are terrific.
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.
Where do I keep the Api key when I use this from a SPA?
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!
Good luck!
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.
How do I create an API to offer on the site? I don't have one right now, but I know from experience the kind of API's that people need but don't want to deal with creating from scratch themselves.
Is there an API for creating, or at least registering, APIs?
(Maybe save that for 2022-04-01.)
(Maybe save that for 2022-04-01.)
Basically the old Blockspring platform but built for 2021 - looks good!
Do you have a roadmap for the API's you'll be adding?
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.
Hey, submitted the google form about an API I believe you might be interested in using!
That would be awesome. :)
For how long will it stay micro?
If it is guaranteed to stay micro, what are the migration paths to go to something less micro? Will Micro Services, Inc help me in that path?
If it is guaranteed to stay micro, what are the migration paths to go to something less micro? Will Micro Services, Inc help me in that path?
Would you consider this product a competitor to RapidAPI?
Man, I could just connect these with Retool and prototype some massive apps pretty instantly. Definitely will be keeping this service in mind!
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 "?
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).
https://datatracker.ietf.org/doc/html/rfc6750#section-1.2
Also relevant: https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentica...
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).
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).
This looks great!
when trying to create an api getting "There was an error creating the key. Please try again later."
is this the latest pivot? are we going to see another completely different business in 3 months?
You may have been saying this tongue in cheek but it's an important thing to consider when choosing a platform.
I got very burnt once (in terms of time wasted anyway) by a startup that couldn't decide what it wanted to do.
They had an amazing BaaS product that probably was making good coin already that I am sure would have got them a buy out eventually but they decided to pivot to work on a DB abstraction layer and shut the whole thing down.
If they had just pursued the original vision they would be minted by now instead of trying to convince people their commercial layer is better than the umpteen other free ones.
I got very burnt once (in terms of time wasted anyway) by a startup that couldn't decide what it wanted to do.
They had an amazing BaaS product that probably was making good coin already that I am sure would have got them a buy out eventually but they decided to pivot to work on a DB abstraction layer and shut the whole thing down.
If they had just pursued the original vision they would be minted by now instead of trying to convince people their commercial layer is better than the umpteen other free ones.
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.
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.
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.
I agree with you in that I would not use this service.
The only issue I had was with shaming the developer for building something he thought people would want and soliciting feedback. If that wasn't the intention of my parent comment, I apologize and retract my statement.
The only issue I had was with shaming the developer for building something he thought people would want and soliciting feedback. If that wasn't the intention of my parent comment, I apologize and retract my statement.
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/ ;)
Looks interesting, what's the difference between this and IFTTT?
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?