Pass in dependencies to `ssb-conn`

[pietgeursen]

Hey @staltz :wave:

Would you be open to merging a PR that allows the caller to pass in ConnHub, ConnDb, ConnStaging and ConnQuery instances to the CONN constructor?

I was thinking of something like:

• Define interfaces for the dependencies (I'll prefix them with I in my examples)

• Change ssb-conn construction to be something like:

  constructor(ssb: any, cfg: any, connHub?: IConnHub, connDb?: IConnDb, ... ) {
  this.ssb = ssb;
  this.config = cfg;
  this._db = connDb ?? new ConnDB({path: this.config.path, writeTimeout: 1e3});
  this._hub = connHub ?? new ConnHub(this.ssb);
  ...
  
  this.initialize();
  }

  I'm tryingg to build up some microservices with a combination of rust and js modules. I'd like to use ssb-conn and friends but I'd need to be able substitute ssb-conn-hub for some rust code I have.

I'm happy to do the work btw, just checking if you're on board with the general idea.

[staltz]

Hey @pietgeursen that's super interesting that you're about to make a connHub in Rust. Keen to see what you come up with!

About the suggestion, how do you intend to call the CONN constructor? It is a secret-stack plugin, so it has the arguments (ssb, config, permissions, manifest), but in this case we're not using the 3rd and 4th arguments. See https://github.com/ssb-js/secret-stack/blob/6c7b8b2d73c7b1c2e298a270e99b5cfbc6a907dc/src/api.ts#L31-L37 . So I'm afraid we can't just use the 3rd and 4th arguments for ConnHub and ConnDB.

(Note that the interfaces should be defined already in the types folder, e.g. https://github.com/staltz/ssb-conn/blob/7ffe4e8ccdb4f7d42f88c00eaf4aafb8bd43691b/src/types/db.ts )

[pietgeursen]

So I'm afraid we can't just use the 3rd and 4th arguments for ConnHub and ConnDB

Ooof, good point. Well in that case, arguments 5,6,7 and 8? It's disgusting, I know. But we can declare multiple constructors and document them for clarity.

Would you be up for that?

Note that the interfaces should be defined already in the types folder

:tada:

[staltz]

Could I first know what's your thoughts on this question?

how do you intend to call the CONN constructor?

[pietgeursen]

It depends if you're talking about my code or "you" more generally.

If you mean me specifically: I'm calling the constructor directly and passing in config and a mocked / customised sbot object (and hopefully the ssb-conn-db etc too).

More generally: Using it as a secret stack plugin should not change at all.

[pietgeursen]

Note that the interfaces should be defined already in the types folder

I went looking for these but I'm not seeing them in the source. I'm sure I must be missing something. If I look in the db types file there isn't a type / interface describing the ConnDb type. Is it generated automagically somewhere? I'm not a ts expert at all so sorry if this is a stupid question.

[staltz]

I see, thanks. I'm concerned that adding these constructor parameters is going to come back and bite us when using CONN as a secret-stack plugin (the main use case). (It's easy to just add a new use case, it's hard to maintain that use case and all other use cases in the long-term future). Since we're in disgusting territory, can we consider other (maybe equally disgusting) options? CONN (as a class) is just a light wrapper around DB,Hub,Staging,Scheduler and as a wrapper it's intended as a secret-stack plugin. Since you want something that is not secret-stack plugin, how about you just copy-paste conn.ts and modify it for your purposes?

I went looking for these but I'm not seeing them in the source. I'm sure I must be missing something. If I look in the db types file there isn't a type / interface describing the ConnDb type. Is it generated automagically somewhere? I'm not a ts expert at all so sorry if this is a stupid question.

It's this and in TypeScript you can use (I guess) typeof ConnDB to use it as an interface as opposed to an actual class.

[pietgeursen]

how about you just copy-paste conn.ts and modify it for your purposes?

Yeah. Obviously I was hoping to avoid duplicating modules. But I can make a fork and change the constructor, that's ok too. Thanks!