The Bridge API is an alternative to building `Criteria` objects for
running operations on the database.
**Why do we need/want this?** The Bridge API will have the same
interface in Appsmith MongoDB, and in Appsmith Postgres. This means when
we write a function that uses the Bridge API to run a query, we enjoy
the guarantee that the function will work with both MongoDB and
Postgres.
**Why is that important?** As new features are being developed, and
changes made, the Postgres branch is having to play catch-up in porting
the queries to Postgres. But with this, that won't be necessary.
Besides, the diff between MongoDB and Postgres versions of Appsmith
would be significantly smaller with this.
**What conditions will be supported?** The Bridge API is intentionally
non-exhaustive. It is intended to replace the most commonly used
criteria definitions. For the rest, falling back to the way we used to
build Criteria is just fine. We're only changing the ladder used to get
to the ceiling. The hammers to break the ceiling to go further, is still
there.
**Can I start using it?** Yes please. I'm only adding one condition
here, but I have changes for ~4 more (`in`, `isNull`, etc.) that I'll be
pushing as PRs next up. I'm also only using it in one place in this PR.
I'll start moving more direct uses of Criteria API to the Bridge API in
future PRs.
**Why does Bridge have `.equal()` instead of `.where().is()`?** Two
reasons. One, an API like `.equal` is easier to implement, and since the
Bridge API is code that we will have to maintain, I voted for
simplicity. Two, once we move to Postgres, we'll be using the
`CriteriaBuilder` API, which uses the `.equal()` style, so might as well
get used it. 🙂
1cb53c4e8e