(As an aside, it seems that it would work most of the time in most of environments that I'd try, but for some reason, it rarely worked in one). So I needed to find a new solution.
'Instead of debugging the one environment, I'll just reimplement the entire service!'
Ah, thanks. The fold looked like a complete page to me!
Regardless, I still find the potential lock-in costs and issues incurred with a proprietary datastore like FireBase to be a total and complete deal breaker.
For truly production-grade systems, relinquishing control over your data stores does not seem like a viable path to better reliability or control for any business with significantly large swaths of data.
If there were a compatible open-source equivalent with easy import functionality for a FireBase dump, I'd be singing a different tune.
Am I missing or overlooking something here? I get the use case for a small project or app, but for mission-critical production, it doesn't seem like a good idea.
It seems to be a personal project. Since there aren't any meaningful consequences for writing a bug-ridden, unsupported app, it's way more valuable to reinvent the wheel than to become an expert in someone else's work.
I know, I'm not saying he's a bad person, I'm just poking a little fun at the mentality that leads to wheel-reinvention as the first and only conclusion.
Comments
'Instead of debugging the one environment, I'll just reimplement the entire service!'
Obviously. :-)
Well, it might also have something to do with money or control, as Firebase is SaaS, and this solution is open source software.
https://www.firebase.com/pricing.html
As an aside, what happens with FireBase when you need more than 30GB of storage in a single app?
You switch to the Inferno plan (scroll down! :P) and then on to Enterprise plans (or just pay overages, though I'm not sure if they apply to disk?)
Ah, thanks. The fold looked like a complete page to me!
Regardless, I still find the potential lock-in costs and issues incurred with a proprietary datastore like FireBase to be a total and complete deal breaker.
For truly production-grade systems, relinquishing control over your data stores does not seem like a viable path to better reliability or control for any business with significantly large swaths of data.
If there were a compatible open-source equivalent with easy import functionality for a FireBase dump, I'd be singing a different tune.
Am I missing or overlooking something here? I get the use case for a small project or app, but for mission-critical production, it doesn't seem like a good idea.
It seems to be a personal project. Since there aren't any meaningful consequences for writing a bug-ridden, unsupported app, it's way more valuable to reinvent the wheel than to become an expert in someone else's work.
I know, I'm not saying he's a bad person, I'm just poking a little fun at the mentality that leads to wheel-reinvention as the first and only conclusion.
I still think it's a cool project.
I'm not sure if this is wheel reinvention, so much as wheel subset reimplementation. The latter of which is a very legitimate practice, quite frankly.
You're right. I forgot to put my pedantry hat on before typing that comment.