Expected:
Collection.all().toSteam() starts a stream
Current:
Error message is thrown can't call .toStream() because only collections and user defined indexes are streamable
Use Case:
As part of our ORM and CMS, we need continuous updates on the schema so we can support multiplayer without actively continuously fetching the schema.
Full disclosure: I’m a total beginner with Fauna.
It seems that the inability to subscribe to updates from all collections is a feature, not a bug.
While it’s not exactly the same, I do have a similar need: supporting the spinning up of separate database instances with essentially the same schema, to ensure data segregation per client or customer. In this case, collections and other schema-specific artifacts would only be created lazily, based on actual usage, to avoid resource waste.
Ultimately, I’ve decided that I should build a TypeScript wrapper around FQL for constructing queries and managing entities. This wrapper, with a predefined schema, would address your issue since the schema and collections would be predefined and codified in advance.
This approach is only applicable if your solution or product offering has control over what the customer’s schema should look like, and you’re not building a feature where customers or clients create distinct collections beyond the initial schema through their actions. Obviously TS here is a placeholder to whatever programming language you use in your project.
Hi @AndrewRedican,
great to hear that you started using Fauna and that you identified also the need of a TypeScript Wrapper! I’m already working on one for some time. If you’re interested in helping me you can check it out here: GitHub - Etesie/fauna-typed: Fully typed Javascript client for Fauna with Store included
It’s a client that creates all TS types automatically for you from your Fauna schema. It has an API that tries to be as close as possible to FQL. I achieve that by introducing a local cache with that I can interact synchronous while lazily fetching from Fauna.
Allowing me to write code like this:
import { s } from '$fauna-typed/stores';
s.Collection.byName("Car")
s.Car.definition
At the moment it’s build up on Svelte Stores, but if you’re not using Svelte, maybe we can find a way to make the store configurable to work also with e.g. React.
If you want to have a chat over it, you can reach me via Discord (Search in Fauna Discord for micha.mailaender)
Thanks for sharing, Mike.
I’ve spent some time reviewing your project and comparing it to mine. Here are my observations on how they compare and differ:
Here are my thoughts:
Client.ts
It’s great to see the newId() example here. I’ve been considering creating a wrapper around global functions, so this caught my interest.
Types.ts
I’m unclear about the mental model behind types like Event*, Consequence*, MasterChapter*, MasterQuestion*, and MasterAnswer*. Without digging too deep, it seems like these types might define general request/response models—for example, questions vs. answers, or events vs. consequences. I’m still unsure what “MasterChapter” represents though.
Stores.ts
I’m not too familiar with Svelte stores, but I understand that Svelte is primarily a client-side rendering framework. Still, the pattern here is familiar, akin to Redux, RxJS, or the Context API, where you’re essentially defining a global store. My question is: Can all the data be accessed through a single store (like Redux)? Or are the top-level nodes managed independently, more like RxJS?While I may not be fully familiar with Svelte stores, I feel like I’m on the right track. However, I’m unsure about the advantages of using Svelte stores over a custom implementation that isn’t tied specifically to either frontend or backend. I would think the FQL client typically runs on the backend as a service. Unless, of course, your goal is to create a Firebase-like experience where you query FaunaDB directly from the frontend. In that case, integrating Svelte stores makes sense if you’re aiming for a seamless frontend-backend experience, like Firebase, but using FaunaDB for Svelte projects.
Fauna.ts
This file closely aligns with what I’m working on. However, I’ve separated the logic for string construction in my project. I have several folders and files dedicated to creating the components of FQL expressions, which combine to form complete instructions.I’ve also created functions to handle common FQL operations (create, update, replace, delete) using by* selectors. My next step—which I haven’t started yet—is to build a method that accepts a fully constructed FQL instruction, uses the FQL client, and runs the command within a try/catch block. Instead of logging directly to the console, I plan to pass logs through a custom logger instance that supports info, warn, and error levels, and funnels logs to different destinations, such as a persistence layer, depending on the log level.
README.md
From what I can see, we’ve made similar progress in covering the FQL API. I’m also using Zod to define parsers and validators, and to derive the correct interfaces or types for config objects and arguments in typical FQL operations (create, update, replace, delete).In that sense, my project aims to be a core package that wraps FQL in TypeScript. All internal functions are exported to maximize composability, enabling other projects to reuse and build on them. The higher-level functions in my project are essentially composed of these lower-level ones.Eventually, I’d like to define TypeScript decorators that can enhance custom classes, allowing users to register entities or other components in a manner similar to Java’s Spring Boot framework.
Further Observations:
Your project seems deliberately aligned with Svelte, which is great. From a goals perspective, I think we’re targeting different use cases for FQL integration. Your project appears to be focused on Svelte-specific implementations, while mine avoids reliance on any particular frontend framework and aims to remain framework-agnostic. My project is not about storing data—I leave that to the projects using my TypeScript wrapper.
Where I think we could collaborate is by having you take a tour of my project and comparing notes. If it makes sense, you could potentially build your project on top of mine, which could lead to further synergy between our efforts.
Let me know your thoughts. I am based in Ireland, but I’d be down to have a sync call.
I’ve been writting this TSWrapper for 2 weeks, in a private repository, made for my own monetary goals in mind, but if this is something that could be useful to you or other people I’d be down to making it open source for sure. There is nothing particularly exclusive about this TSWrapper that would make it an issue for me to open source.
I would love to have a chat about it 
But before this feature request about “Support streaming for Collection” becomes to much off topic let’s continue the chat via discord (micha.mailaender) or mail (micha@mailaender.me) 
There we can also check the availability for a call window @AndrewRedican