RFC: 0.5.0 rewrite with official SurrealDB SDK v2 (alpha)

[sandros94]

Feel free to leave comments about the future of the 0.5.0 release, which is currently in alpha and based on the offical SDK v2, which is also in alpha.

you can find some of my notes in various merged PRs

• refactor!: rewrite module using official SDK #22
• feat: SurrealDB SDK v2 Alpha #23

[sandros94]

New release 0.5.0-alpha.4

With release 0.5.0-alpha.4 I've refactored the SSR-safe composables and introduced a new one called useSurrealAsyncData (which is used under the hood by all other SSR-safe composables)

As of now it requires the first argument to be a string which will be used by useAsyndData as its unique hydration key, while the second argument is a callback which exposes the underlying configured Surreal client. Please also make sure to always call .json() when returning data from the client, as currently I cannot correctly serialize automatically the incoming data before sending for hydration.

In the following example we can see that it supports reactive data

const tableRef = ref('test')
const idRef = ref('fbvohpnfii61m24uizw1')
const { data } = await useSurrealAsyncData('select:test', (client) => {
  return client
    .select(new RecordId(tableRef.value, idRef.value))
    .where(eq('payload', 'ciao'))
    .json()
}, {
  watch: [tableRef, idRef],
})

Caveats

Currently useSurrealSelect cannot accept a reactive Table, RecordId or RecordIdRange. If you do need them to be reactive plese use useSurrealAsyncData shown above. Otherwise, if you do need reactive data in the where statement or similar it works as normal:

const whereRef = ref('ciao')
const { data } = await useSurrealSelect(new Table('test'), (select) => {
  return select
    .where(eq('payload', whereRef.value))
}, {
  watch: [whereRef],
})

[Deeyuude]

What do you think about 3.0 of Surrealdb ?

[sandros94]

What do you think about 3.0 of Surrealdb ?

I've been using the alpha and beta for a few months now, mostly for performance and size optimization, along some other changes like the ability to alter tables and fields, or about data types. This major has so many changes done in so much time. What I'm really interested in is surqlize, which really looks promising

[Deeyuude]

Oh thank you so much for the info ! It was really missing feature as drizzle won't support surrealdb now we have something alike

[sandros94]

@Deeyuude surrealdb/surrealdb.js#507 got merged. I'll make sure to update this project in a few days as I'm able to work on it and publish a new release!

[Deeyuude]

Thank you for your answer and happy to see your good work 😊

[sandros94]

New release 0.5.0-rc.5

With release 0.5.0-rc.5 We are officially based on surrealdb@2.0.0 release!

I decided to do a release candidate instead of a stable release because I'm noticing that IndexedDB isn't yet working with SurrealDB 3.0.

As always feel free to leave any comments below if you find any issues 🙏

[sandros94]

Thank you for your amazing work :) Really solid ! One question if you don't mind isn't SurrealKV will replace IndexedDB ? I've seen it somewhere they said that SurrealKV was made for replacing rocksDB for sure but i think it's the case for IndexedDB too if i'm not wrong

They are planning to use OPFS with SurrealKV instead of IndexedDB, but as of now this is planned as an opt-in feature, which to my testing neither work yet with Surreal 3.0, we'll have to wait.

[Deeyuude]

Thank you so much

[Deeyuude]

It will disturbe you if you give me your advice about this : https://github.com/oskar-gmerek/surreal-better-auth/ when ever you'll have time ? And if it would work with your module ? I trust your advice

[sandros94]

It will disturbe you if you give me your advice about this : https://github.com/oskar-gmerek/surreal-better-auth/ when ever you'll have time ? And if it would work with your module ? I trust your advice

@Deeyuude yes it should work without any issue as I see it accept just a surreal client that is already connected.

If you have your surrealdb server configs properly populated in nuxt.config.ts or via env var you should be able to simply to:

// server/utils/auth.ts
import { betterAuth } from "better-auth";
import { surrealAdapter } from "surreal-better-auth";

export const auth = betterAuth({
  database: surrealAdapter(useSurreal()),
  emailAndPassword: {
    enabled: true,
  },
  socialProviders: {
    github: {
      clientId: process.env.NUXT_GITHUB_CLIENT_ID!,
      clientSecret: process.env.NUXT_GITHUB_CLIENT_SECRET!,
    },
  },
});

Tho better-auth doesn't play really well with useRuntimeConfig (called inside useSurreal), as it would lack all the Nitro context in general. But this only applies if you are trying to run their cli to generated the schema automatically (wichu you would either need to gernerate manually or create a dedicated useSurreal mock, something quite a bit more advanced...).

Tho I wouldn't personally use better-auth with surreal, as it already offers solid auth via their methods, tho it has a steeper learning curve compared to better-auth

[Deeyuude]

Thank you so much for the most great explaination really helpful 😊