sandros94 / nuxt-surrealdb Goto Github PK

Currently I'm forcing a RpcResponseOk and RpcResponseError to handle types. But if someone uses a transform their types will be messed up.

(previously #1)

Integrate DevTools to incorporate incoming and outgoing data and requests, ability to send custom queries; also potentially embedding Surrealist or atleast a fraction of Surrealists features i.e. view tables, data etc.

I realized this issue when I was writing a reply for #13 and it applies to both client and server side.

Lets say a user has been authenticated to the database preset A, while the next request points to database preset B. This request could error out because SurrealDB will forcefully try to use the token since I passed it regardless of the database preset in use.

Potential solutions:

• Store the auth database preset with the token inside the cookie and only pass to the request if the presets match (this both requires a breaking change and store the db preset in plain sight)
• only use the token if the db preset matches the default auth preset (but then how do I handle if the db preset has been overwritten in the useSurrealAuth params?).
• Any suggestions?

Instead of redefining each preset's URL, WS and NS I could pick up the default one, if exists.

Useful in multitentant projects.

Roadmap

• custom fetch plugin and useFetch composable.
• Database presets
• support official SurrealDB Rest integration.
  Discarded in favor of RPC. Can still be manually used via $surrealFetch and useSurrealFetch.
• support official SurrealDB RPC integration.
• server side surrealFetch and surrealRPC utils
• catch Surreal errors
• built-in auth composable.
• custom websocket composable.
• unwrap RPC responses by default
• doublecheck types
• docs
• study Concise Binary Object Representation (waiting for reply on undio#18)
• vitests

Experiment with SurrealDB 2.0 alpha

• headers prefix
• new auth

The query and sql functions should return proper types instead of any.

This could go against the unwrapResponse if set to false, should I deprecate the possibility to unwrap it?

I can use $fetch's onResponse to do so.

How do I force types then?

Currently, like in the example below, it can happen that the use message within onConnected is sent after the live message, although it should be the other way around. It suggests a racing condition not being respected with the useBuffer.

In the following screenshot the request with id 1 is the configuration message (method: 'use'), while the request with id 0 is the live('products'). For no reason, at random, they switch order like this.

Currently the token override only accepts a string, undefined or false. I should also implement true and object.

Cases:

• token === undefined: try auth > current db > default db
• token === string: use string as token
• token === true: try current db > default db auth
• token === false: don't use any tokens
• token === object: use as basic auth

I think it's a good idea to normalize the return data of the select & query methods or at least to have a flag that we can opt into, from this:

[
	{
		"result": [
			{
				"id": "tests:z4ie6eum4qbh6j9xugzp",
				"name": "title 1",
			},
			{
				"id": "tests:fwr424wum4qbh6j9xug5",
				"name": "title 2",
			},
		],
		"status": "OK",
		"time": "3.7952ms"
	}
]

to this:

[
	{
		"id": "tests:z4ie6eum4qbh6j9xugzp",
		"name": "title 1",
	},
	{
		"id": "tests:fwr424wum4qbh6j9xug5",
		"name": "title 2",
	},
]