4 ms·

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 A

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/ 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 5y ago
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.
- AaronFriel 5y ago
  I'm confused as to what sort of service that would make sense to do.
- dolmen 5y ago
  The only use cases are the ones that fit the $5 free tier.
- dolmen 5y ago
  > 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'
xf1cf 5y ago
The lack of SLA/SLO/data sovereignty is an absolute non-starter. It's a decent idea but it lacks the necessary guarantees to get people to move off of their current provider (my $company included).
zachrose 5y ago
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.
- killingtime74 5y ago
  Firebase and Heroku would fill that niche
asim 5y ago
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 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.
- debarshri 5y ago
  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.

friendly_chap 5y ago

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.

AaronFriel 5y ago
I'm confused as to what sort of service that would make sense to do.
dolmen 5y ago
The only use cases are the ones that fit the $5 free tier.
dolmen 5y ago
> 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'

xf1cf 5y ago

The lack of SLA/SLO/data sovereignty is an absolute non-starter. It's a decent idea but it lacks the necessary guarantees to get people to move off of their current provider (my $company included).

zachrose 5y ago

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.

killingtime74 5y ago
Firebase and Heroku would fill that niche

asim 5y ago

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

debarshri 5y ago
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.