RJR
Convex Community3w ago
10 replies
RJ

Confect v1

Hi everyone! I've been working on Confect on and off for over two years now, and am thrilled to announce that I have just released, at long last, Confect v1!

If you haven’t heard of it before, Confect is a framework that deeply integrates Effect with Convex. That means Effect-native APIs wherever possible, but not only that. Confect grants you the ability to define your database table schemas and Convex functions args/returns validators using Effect’s
Schema
library, which in turn unlocks fully integrated, automatic, end-to-end rich type decoding/encoding, from the client all the way down to the database (and back).

Documentation is still a work-in-progress, but there should be enough there to get motivated folks started. Expect them to continue to improve and expand over the coming days and weeks!

If you’ve used Confect before, these are the major changes from v0.x:
- You can now invoke Convex functions from the client (just React, for now) and get automatic
Schema
decoding/encoding, without any manual wiring whatsoever. The client-side API experience is now basically identical to the native Convex experience.
- The Convex platform capabilities exposed via Convex function contexts (
ctx
) are now exposed via individual Effect services, for more expressive and cleaner helper functions/shared code between Convex functions.
- The database reader/writer APIs have been cleaned up/streamlined, based on challenges I’ve experienced myself and feedback I’ve seen from the community over the past few years (along with some inspiration from
convex-ents
). These changes include:
- Always requiring table names when querying the database.
- Removing the
.filter()
method footgun.
- Requiring explicit index specification when querying for more than one document at a time. The vast majority of the time you want to be querying (and filtering) with a user-defined index. If you’d like to use the default
_creationTime
index, that’s fine—you’ll just have to be explicit about it.
- Co-locating order specification with index specification. Ordering is determined by the index you’re using for your query. Separating them in the querying API obfuscates this fact, making this relationship harder to understand for newer users.
- Extending
get()
with the ability to specify a single document you’d like to retrieve using equality comparisons with indexed fields other than
_id
.
- Codegen! This is not a feature per se, but rather something that was necessary for providing a good DX for the actual feature of fully automated, end-to-end Effect
Schema
decoding/encoding.

If you try it out and have any feedback at all, please let me know! Feel free to open issues in the GitHub repo, reply to this thread, or send me a DM on Discord.

Thanks and happy coding!
Was this page helpful?