In a previous post I mentioned a new NodeJs Package I am working on which is planned for release soon. Today I’m going to introduce the package, what it’s for and why I’ve built it.
The package is called SQL Mason and can be found on Github here.
Quite simply its a SQL command builder with a fluent interface heavily inspired by Laravel’s Eloquent Query Builder.
There are already plenty of SQL builders for NodeJs, why build another one?
Many existing packages don’t just provide a builder, but a model/ORM system, migrations, schema builders, and all the configuration to connect to your database. Granted these tasks are generally needed if you’re using SQL but being locked down to a packages implementation of all those things is limiting.
In true NodeJs Style I should be able to mix and match a query builder, a connection, a migrations package, and a orm.
As my experience with NodeJs is pretty low I thought it would be a good first project to create to hone my skills and provide a useful package for future developments.
SQL Mason will be the first in a line of SQL database based packages which all provide abstracted interfaces for SQL related functionality.
The package will only provide the means to convert a fluently built query into native SQL, that’s it! Future packages will handle other operations like migrations, connections, ORM, etc.
It’s still in early development right now, with aggregate and join functionality to be added. Once those are completed it will be first released as a MySQL only implementation, and a full V1 release will come after with support for other SQL based databases (SQLite, PostgreSQL, etc).
Heres a little taste of the functionality:
As you can see its heavily inspired by Laravel and Knex. But whats different is this package contains a Builder (fluent clause functions, retrieval of bindings, etc), and a Compiler (converts the builder properties into a SQL string).
Existence of the persistence layer isn’t needed or desired by the package, it converts a builder request into a string and bindings that’s it! I’m aware this wouldn’t be production ready code when its finished as it will rely on other packages to actually use whats returned, but its a start to a decoupled persistence layer.
I think this also touches on something else ive referenced recently, which is the added benefits of a Data Mapper pattern over Active Record in a NodeJs app. If we can separate the concerns between these kind of packages, we can utilize only whats needed both on the Server and in the Browser.
In a follow-up post I will be exploring this further, and publishing the package to the NPM registry.