At some point, I had a job where they wouldn't allow us to use any thing other than MySQL to store our data. For the best of me, I could not convince management that the right thing to do was to move to a NoSQL solution like Mongo. At that point, my quest started to find a way to create a NoSQL solution on top of a SQL database.
https://github.com/ua1-labs/firesql
FireSQL is what came of it. This project started almost 2 years ago. I'm just starting to get around to documenting it now. Please has a look at let me know what you think.
If you are one of those that are not allowed to us anything other than MySQL, this might be the right solution for you if you are interested in a NoSQL solution built on MySQL.
Top comments (6)
But.. why? How does this perform compared to Mongo or using plain SQL? The repository pattern is the correct solution for this by placing an abstraction above the database implementation. In that why you can switch over to another /use fake implementation for testing rather than forcing a NoSQL conform API over MySQL. This stuff indeed sounds interesting, but I really hope you don't plan production usage of it.
There are definitely use cases for using this implementation. Why is it okay for Doctrine to exist and that’s perfectly acceptable for a production application, but a library like this is poo pooed on?
Seems to me like just because you might not find a production application for a library like this doesn’t mean someone else might find it useful for their application. And the opinion you shared certainly doesn’t invalidate FireSQL as a valid solution.
What is the use case for this implementation? I don't like SQL/I don't know how to write effective SQL queries but I have to use it anyways, therefore I will use a NoSQL like API with whatever under the hood because it looks nicer to me?
Doctrine and all the ORMs will also fail when you have really complex queries and causes unnecessary headaches/overhead.
As I said this project is still interesting and I am curious about the implementation but also about the performance. Create a real life project to prove its worthiness. Do some performance tests compared to a native SQL or Doctrine project. Before that I feel dangerous to say it's a valid solution.
What if a newbie comes in from the Mongo/JS world, and says "finally, I hate SQL, let's use this", and when he ends up in a SQL heavy company, he will suck because they won't let him to use a solution like this or maybe he will start using it and it turns out that this stuff is damn too slow.
We need to be very careful about what do we show to the junior colleagues because any bad practice, misused tool might ruin their days, weeks or even their career.
I think I failed to mention that FireSQL comes with a demo and a library called FireBug. Firebug makes it possible to track all queries being made to the database, how long it took for each query to run and gives you the ability to peer into what's going on behind the scenes.
I could demo this if anyone wants to jump on a Google Hangout some time.
What was the reason to use Mongo over SQL? What kind of project was it?
So the project for me was the inability to convince management to use anything other than straight SQL queries. A lot of the time, we were demanded to be fast at implementing our updates. As it turns out, things got chaotic with over 20 developers checking in changes to database schemas. The director of Software Engineering didn't want to implement new architecture. So a new Database type was completely out of the question. So, I invented a stop gap solution for inserting and querying for objects. Eventually, the FireSQL project was created shortly after leaving that company. I realized that many other companies are using solutions like Wordpress. So this could be a quick bolt on solution to wordpress without having to interrupt the schemas they have in place.
I had a client come to me who wanted me to add a registry to their Woocommerce powered website. He only wanted to spend $1200. I put this solution in place and was able to finish all of the work to create his registry in less than 10 hours worth of work.
I had another client want to build out an entire backend to manage data, but they wanted to do it for less than 10k. Again, I used this solution, built out an interface for managing their collections/objects and delivered what they asked for and I averaged $120/hour.
Both solutions are still running today. And the solutions are doing good. I'm not saying that this is for enterprise level companies, but the average small to medium sized business could absolutely use this.