slonik VS Bookshelf

And sometimes invest instead in learning a technology rather than hide it: for example slonik encourages you to write normal SQL queries by making SQL templating easier and safer. In turn, your IDE would be able to understand those queries and give you support based on the database schemas you actually have.

I'd push you to consider using postgres, slonik or similar for database queries. With these libraries, you just write SQL, but they perform input sanitization for you. So you can safely write:

You can already use postgres with Slonik.

https://github.com/gajus/slonik#user-content-slonik-how-are-...

It is not going to be the default because it is way slower.

https://github.com/gajus/slonik/actions/runs/6616647651

Test node_version:18 test_only:postgres-integration is taking 3 minutes.

Test node_version:18 test_only:pg-integration is taking 38 seconds.

For those uninitiated, Slonik is a battle-tested SQL query building and execution library for Node.js. Its primary goal is to allow you to write and compose SQL queries in a safe and convenient way. Now, let's see how it pairs with Express.js.

I am the maintainer of Slonik and I am trying to understand what portion of this sub-users are using Slonik vs other libraries, and if they are using anything else – what are their reasons for it.

It's nice that they implemented string templates essentially exactly the same way Javascript template literals and tag functions work. They even give an example of using it to create a prepared statement (e.g. DB."SELECT * FROM foo WHERE bar = \{inputParam}") which is exactly what many NodeJS libraries due, e.g. Slonik https://github.com/gajus/slonik, like sql`SELECT * FROM foo WHERE bar = ${inputParam}`;

I've found libraries like Zod useful when interacting with external data sources like a database. Slonik[1] uses Zod to define the types expected from a SQL query and then performs runtime validation on the data to ensure that the query is yielding the expected type.

I don't think it's necessary to use Zod/runtime validation everywhere, but it's a nice tool to have on hand.

[1]https://github.com/gajus/slonik

Demonstrate how easily and accidentally one can make an SQL injection with these:

https://github.com/porsager/postgres

https://github.com/gajus/slonik

Have you tried Slonik (https://github.com/gajus/slonik)? It won't generate types from queries automatically, but it encourages writing SQL vs. a query builder and allows type annotations of queries with Zod. Query results are validated at runtime to ensure the queries are typed correctly.

Bookshelf.js is an uncomplicated and lightweight ORM designed for Node.js, constructed atop the Knex.js query builder. Its primary aim is to support SQL databases, such as PostgreSQL, MySQL, and SQLite. Bookshelf.js focuses on simplicity and user-friendliness, offering a direct method for defining models and relationships through JavaScript classes and prototypal inheritance.

If you're set on JS (using only one language on a team/project can be very nice) common choices for backend often involve using Express or hapi with some ORM (like Prisma or Bookshelf).

Strapi uses Bookshelf.js library to send database queries in an ORM fashion. Bookshelf itself is powered by Knex.js, which is a SQL query builder. Knex.js supports popular SQL-based database engines like PostgreSQL, SQLite, MySQL, and MariaDB, which are also supported by Strapi. Knex.js also supports database transactions, which then makes Bookshelf also provides support for it. With a basic understanding of both libraries, we can add Database transaction support to Strapi queries.

I made the transition from LAMP to Node-based stacks 6 or 7 years ago and started out using BookshelfJS. Node is a different world though, one that lends itself to distributed services and server-less infrastructure, and it's changed how I interact with DBs.

First, we need to get all recordsets randomly sorted. To achieve this, we will need to build a query. Strapi is using Bookshelf as an ORM. So we can start by getting our Partnership model, so we can run a query on it. Inside the query, we get a knex (this is the query builder that Bookshelf uses under the hood) query builder instance. On this query builder instance, we can there ask to order recordsets randomly. Let's try this:

A few of the most important characteristics of the solution we wanted was that any documentation-related work had to be easy for developers, and it would ideally be located in proximity to the actual implementing code. Anvil's web application is written in Node, and we chose Apollo as our GraphQL framework and use a modified version of Bookshelf as our ORM.

FYI Currently I use Knex with Bookshelf. Bookshelf is an ORM written by Knex author before TypeORM, Objection... existed. It's not maintained anymore but it works fine and is much better than Sequelize when I've tried.