Open staltz opened 3 years ago
Improved API proposal, removing pipe
:
// client side
const {and, type} = require('ssb-db2-client')
pull(
ssb.db.queryAsSource(
and(type('post'), author(me)),
live()
// no need to do toPullStream because that's done server side
// in the implementation of queryAsSource()
),
pull.drain(console.log)
)
db.query
is a bit difficult to support over a muxrpc stream, but it should be possible.ssb.db.query
"in the same thread" (thread being either another Electron renderer, or a React Native rn-bridge thread, etc) is a synchronous function that will call all those chained functions (note that internallyssb.db.query
will injectfromDB(jitdb)
at the start!) and then will return a pull stream."In another thread", there are only async muxrpc calls, so we would have to do something like
But i'm not even sure if that would work, because
toPullStream
is a function, and you can't pass functions over the muxrpc stream, I guess.There's one way to side step all of this, and that's to only use
ssb.db.query
"on the same thread" as sbot, and if you want to make queries from another thread, you'd have to create a custom muxrpc method on the "server side" such asssb.extra.getPullStreamOfAllPosts
which will do the snippet above, and that's what the client side calls.But I'm quite sure someone will eventually ask for support for
ssb.db.query
on the client side, so we could begin thinking how to do that.One way is that maybe on the client side we could have a custom
ssb.db.query
that creates objects (after all operations will be encoded as objects) and we can pass the objects from client to server, no problem. Just requires some careful thought because upon receiving such object on the server side, we have to prepend it withfromDB(jitdb)
and the waitForDrain deferred thing. Also things liketoPullStream
could be converted to an object like{type: 'RESULT', data: 'pull-stream'}
. But there's also the question of how does muxrpc know to dynamically return either"source"
or"async"
depending on our input, and I don't think it can do that. Maybe then we'd havessb.db.queryAsAsync
andssb.db.queryAsSource
which are"async"
and"source"
, respectively?Hmmm! Idea: we keep
ssb.db.query
as is (implicitly available, not declared on the manifest), then we addssb.db.queryAsAsync
andssb.db.queryAsSource
and those are declared in the manifest. And then maybe we should have another package,ssb-db2-client
that doesn't drag in all these heavy dependencies likeasync-flumelog
andjitdb
(which are certain to not be needed on the client), andssb-db2-client
basically just has operators, and it would have one special functionpipe(...args)
which bundles all the arguments and spits out one single ops object, e.g.