Release v2.0.0-alpha.15

Changes since the previous version

• Changed the .query() method to collect results by default, without requiring .collect()
  • The collect function is still required to collect specific results by index
• Added a chainable .responses() method to .query() to receive v1-style response objects
• Added improved value inspecting on NodeJS (#503)
• Strongly type RecordIds (#500)

Full changelog

📦 Welcome @surrealdb/wasm and @surrealdb/node!

The existing WebAssembly and Node.js SDK's have been rewritten, updated to support the 2.0 JavaScript SDK, and have been moved into the JavaScript SDK repository.

Going forward, the JS SDK, WASM SDK, and Node.js SDK will be published together, meaning embedded versions of SurrealDB will be kept up-to-date. Both the WASM and Node.js SDK versions will sync their major and minor components with SurrealDB, while the patch is still kept separate. This means a version such as 2.3.5 will use at least SurrealDB 2.3.0.

As an additional bonus, the WASM SDK now also supports running within a Web Worker. This allows you to offload computationally intensive database operations away from the main thread, while keeping your interface responsive.

Wasm

import { Surreal, createRemoteEngines } from "surrealdb";
import { createWasmEngines } from "@surrealdb/wasm";

const db = new Surreal({
    engines: {
        ...createRemoteEngines(),
        ...createWasmEngines(),
        // or for Web Worker based engines
        ...createWasmWorkerEngines()
    },
});

Node.js (+ Bun.js & Deno)

import { Surreal, createRemoteEngines } from "surrealdb";
import { createNodeEngines } from "@surrealdb/node";

const db = new Surreal({
    engines: {
        ...createRemoteEngines(),
        ...createNodeEngines(),
    },
});

✉️ Official event listeners

The original SDK allowed for the listening of events through the leaked internal surreal.emitter field. Instead, the updated SDK provides a type-safe surreal.subscribe() function allowing you to listen to events. Invoking .subscribe() now also returns a cleanup function, which unsubscribes the listener when called.

Example

// Subscribe to events
const unsub = surreal.subscribe("connected", () => {
    ...
});

// Unsubscribe
unsub();

🏹 Access internal state

Additional getters have been added to retrieve internal state from the Surreal instance, such as

• surreal.namespace and surreal.database to obtain the selected NS and DB
• surreal.params to obtain defined connection params
• surreal.accesToken and surreal.refreshToken to obtain authentication tokens

Example

await surreal.use({ namespace: surreal.namespace, database: "other-db" });

🔄 Automatic token refreshing

The SDK will now automatically restore or renew authentication when your access token expires or the connection reconnects. When refresh tokens are available, these will be used and exchanged for a fresh token pair, otherwise the SDK falls back to re-using the provided authentication details, or firing an auth event for custom handling. (read more)

In situations where authentication may be provided asynchronously you can now pass a callable function to the authentication property.

Example

const surreal = new Surreal();

await surreal.connect("http://example.com", {
    namespace: "test",
    database: "test",
    renewAccess: true, // default true
    authentication: () => ({
        username: "foo",
        password: "bar",
    })
});

🔑 Multi-session support

You can now create multiple isolated sessions within a single connection, each with their own namespace, database, variables, and authentication state. The SDK allows you to construct entirely new sessions at any time, or fork an existing session and reuse its state.

Simple example

// Create a new session
const session = await surreal.newSession();

// Use the session
session.signin(...);

// Dispose the session
await session.closeSession();

Forking sessions

const freshSession = await surreal.newSession();

// Clone a session including namespace, database, variables, and auth state
const forkedSession = await freshSession.forkSession();

Await using

await using session = await surreal.newSession();

// JavaScript will automatically close the session at the end of the current scope

📣 Redesigned live query API

The live query functions provided by the Surreal class have been redesigned to feel more intuitive and natural to use. Additionally, live select queries can now be automatically restarted once the driver reconnects.

The record ID will now also be provided as third argument to your handlers, allowing you to determine the record when listening to patch updates.

Example

// Construct a new live subscription
const live = await surreal.live(new Table("users"));

// Listen to changes
live.subscribe((action, result, record) => {
     ...
});

// Alternatively, iterate messages
for await (const { action, value } of live) {
    ...
}

// Kill the query and stop listening
live.kill();

// Create an unmanaged query from an existing id
const [id] = await surreal.query("LIVE SELECT * FROM users");
const live = await surreal.liveOf(id);

❗ Improved parameter explicitness

Query functions now no longer accept strings as table names. Instead, you must explicitly use the Table class to represent tables. This avoids situations where record ids may be accidentally passed as table names, resulting in confusing results.

Example

// tables.ts
const usersTable = new Table("users");
const productsTable = new Table("products");
...

// main.ts
await surreal.select(usersTable);

🔧 Query builder pattern

In order to provide a more transparent and ergonomic way to configure individual RPC calls, a new builder pattern has been introduced allowing the optional chaining of functions on RPC calls. All existing query functions have received chainable functions to accomplish common tasks such as filtering, limiting, and fetching.

As a side affect, both update and upsert no longer take contents as second argument, instead, you can choose whether you want to .content(), .merge(), .replace(), or .patch() your record(s).

Example

// Select
const record = await db.select(id)
    .fields("age", "firstname", "lastname")
    .fetch("foo");

// Update
await db.update(record).merge({
    hello: "world"
});

🗼 Query method overhaul

The .query() function has been overhauled to support a wider set of functionality, including the ability to pick response indexes, automatically jsonify results, and stream responses.

Example

// Execute a query and return results
const [user] = await db.query<[User]>("SELECT * FROM user:foo");

// Collect specific results
const [foo, bar] = await db.query("LET $foo = ...; LET $bar = ...; SELECT * FROM $foo; SELECT * FROM $bar")
    .collect<[User, Product]>(2, 3);

// Jsonify responses
const [products] = await db.query<[Product[]]>("SELECT * FROM product").json();

// Response objects
const responses = await db.query<[Product[]]>("SELECT * FROM product").responses(); 

// Stream responses
const stream = surreal.query(`SELECT * FROM foo`).stream();

for await (const frame of stream) {
    if (frame.isValue<Foo>()) {
        //  Process a single value with frame.value typed Foo
    } else if (frame.isDone()) {
        // Handle completion and access stats with frame.stats
    } else if (frame.isError()) {
        // Handle error frame.error
    }
}

Note

SurrealDB currently does not yet support the streaming of individual records, however this API will provide the base for streamed responses in a future update. It is fully backwards compatible with the existing versions of SurrealDB and is now the only way to obtain query stats.

🎨 Expressions API

In order to facilitate working with the .where() function found on multiple query methods, we introduced a new Expressions API to ease the process of composing dynamic expressions. This new API integrates seamlessly with the surql template tag, allowing you to insert param-safe expressions anywhere.

Example

const checkActive = true;

// Query method
await db.select(userTable).where(eq("active", checkActive));

// Custom query
await db.query(surql`SELECT * FROM user WHERE ${eq("active", checkActive)}`);

// Expressions even allow raw insertion
await db.query(surql`SELECT * FROM user ${raw("WHERE active = true")}`);

You can also parse expressions into a string manually using the expr() function

const result: BoundQuery = expr(
    or(
        eq("foo", "bar"),
        false && eq("hello", "world"),
        eq("alpha", "beta"),
        and(
            inside("hello", ["hello"]),
            between("number", 1, 10)
        )
    )
);

🔭 Value encode/decode visitor API

To support advanced use cases and situations where additional processing must be done on SurrealDB value classes, you can now specify a value encode or decode visitor callback in the Surreal constructor. These functions will be invoked for each value received or sent to the engine, and allow you to modify or wrap values before they are collected in responses.

Example

const surreal = new Surreal({
	codecOptions: {
		valueDecodeVisitor(value) {
			if (value instanceof RecordId) {
				return new RecordId("foo", "bar");
			}

			return value;
		},
	},
});

...

const [result] = await surreal.query(`RETURN hello:world`).collect<[RecordId]>();

console.log(result); // foo:bar

👀 Diagnostics API

The Diagnostics API allows you to wrap engines and intercept protocol level communication. This is useful for debugging queries, analysing SDK behaviour, measuring event timings, and other advanced use cases.

Since this API is implemented in the form of a wrapper engine, no further overhead is added to the SDK unless used. We do however discourage use of this API in production as it may affect performance negatively and the events are considered unstable, meaning they might change between versions.

Example

new Surreal({
	driverOptions: {
		engines: applyDiagnostics(createRemoteEngines(), (event) => {
			console.log(event);
		}),
	},
});

Events contain various bits of information describing the start or completion of operations

• Each event consists of at least a type, key, and phase property
• The type property determines the type of operation being sent
• The key property is a stable id consistent throughout connected phases
• The phase property determines when an operation starts, progresses, or completes
• The query diagnostic exposes the internal chunk stream, so you are responsible for stitching queries and batches together.
• The after phase contains duration, successandresult` properties

The previous example may produce the following output:

{"type":"open","key":"1560a0e1-402f-46f9-bf47-796ff626f776","phase":"before"}
{"type":"open","key":"1560a0e1-402f-46f9-bf47-796ff626f776","phase":"after","success":true,"duration":"535us875ns"}
{"type":"version","key":"5c9bda29-3a86-4501-aee4-d95443ae663c","phase":"before"}
{"type":"version","key":"5c9bda29-3a86-4501-aee4-d95443ae663c","phase":"after","success":true,"duration":"964us416ns","result":{"version":"surrealdb-3.0.0-alpha.10"}}
{"type":"use","key":"4fba2fe5-5dfd-48c7-8aaa-f690915a8472","phase":"before"}
{"type":"use","key":"4fba2fe5-5dfd-48c7-8aaa-f690915a8472","phase":"after","success":true,"duration":"387us","result":{"requested":{"namespace":"test","database":"test"},"corrected":{"namespace":"test","database":"test"}}}
{"type":"signin","key":"d61ab7cf-dcc6-4095-ac02-ce3021e3634e","phase":"before"}
{"type":"signin","key":"d61ab7cf-dcc6-4095-ac02-ce3021e3634e","phase":"after","success":true,"duration":"14ms709us583ns","result":{"variant":"system_user"}}
{"type":"query","key":"6763817d-74e9-41af-95f6-da36112a7add","phase":"before"}
{"type":"query","key":"6763817d-74e9-41af-95f6-da36112a7add","phase":"progress","result":{"query":"CREATE ONLY $bind__4 CONTENT $bind__5","params":{"bind__4":"person:1","bind__5":{"firstname":"John","lastname":"Doe"}},"chunk":{"query":0,"batch":0,"kind":"single","stats":{"bytesReceived":-1,"bytesScanned":-1,"recordsReceived":-1,"recordsScanned":-1,"duration":"548us"},"result":[{"firstname":"John","id":"person:1","lastname":"Doe"}]}}}
{"type":"query","key":"6763817d-74e9-41af-95f6-da36112a7add","phase":"after","success":true,"duration":"1ms680us250ns","result":{"query":"CREATE ONLY $bind__4 CONTENT $bind__5","params":{"bind__4":"person:1","bind__5":{"firstname":"John","lastname":"Doe"}}}}
{"type":"reset","key":"dc2be49c-b184-4048-be73-d57d7b26578d","phase":"before"}
{"type":"reset","key":"dc2be49c-b184-4048-be73-d57d7b26578d","phase":"after","success":true,"duration":"584us458ns"}

⚙️ Separation of concerns

The SDK has been rebuilt in a way which allows for optimal code-reuse while still allowing flexibility for future RPC protocol iterations. This is done by dividing the internal SDK logic into three distinct layers.

Engines

Much like in in the original SDK, engines allow you to connect to a specific datastore, whether it be over HTTP or WS, or embedded through @surrealdb/wasm. However, this has now been streamlined further so that engines are only exclusively responsible for communicating and delivering RPC messages to a specific datastore, while implementing the new SurrealDB Protocol pattern.

Controller

The connection controller is responsible for tracking the local connection state and synchronising it with the SurrealDB instance through the instantiated engine implementation. This includes tracking the selected namespace and database, handling authentication, and performing version checks.

Surreal / SurrealSession

Much like in the original SDK the Surreal class represents the public API and exposes all necessary public functionality, while wrapping the underlying connection controller.

📚 Updated documentation

TypeScript signatures and documentations have been fixed and updated to correctly describe different arguments and overloads.