Folding two callbacks into one Observable - mongodb

Question

The snippet of code below is functional (in the sense that it's working ;-)), but seems lame at best and well...
Can anyone suggest a way to make this more composable or at least less ugly?
The code is based on the examples on this page:
Wrap an Existing API with RxJS
function connect() {
return rx.Observable.create(function (observer) {
mongo.connect('mongodb://127.0.1:27017/things', function(err, db) {
if(err) observer.onError(err);
observer.onNext(db);
});
}).publish().refCount();
}
function getThings(db) {
return rx.Observable.create(function (observer) {
db.collection('things').find().toArray(function(err, results) {
if(err) observer.onError(err);
observer.onNext(results);
observer.onCompleted();
});
return function () {
db.close();
};
}).publish().refCount();
}
connect().subscribe(
function (db) {
getThings(db).subscribe(console.log);
}, function (err) {
console.log(err);
}
);

Answer 1

In this specific example, assuming that getThings() is supposed to happen only once after connect() happens, I would change the implementation of getThings() as such:
function getThings() {
return connect()
.flatMap(function(db) {
return rx.Observable.create(function (observer) {
db.collection('things').find().toArray(function(err, results) {
if(err) observer.onError(err);
observer.onNext(results);
observer.onCompleted();
});
return function () {
db.close();
};
});
});
}
Then you can just subscribe to the getThings() stream:
getThings().subscribe(console.log);
We used flatMap to hide the the connection step inside the whole getThings(). FlatMap's documentation sounds complicated, but it isn't that complicated. It just substitutes an event from the source Observable with another future event. Explained in diagrams, it substitutes each x event with a future y event.
---x----------x------->
flatMap( x => --y--> )
------y----------y---->
In our case, x event is "connected successfully", and y is "got 'things' from database".
That said, there are a couple of different ways of doing this, depending on how the app is supposed to work. It is better to think of RxJS as "Event Bus on steroids" rather than a replacement for chainable Promises, because it really is not the latter.
Developing on RxJS is best if you model "everything that happens in the app" as streams of events. If done properly, you shouldn't see these chainable "do this, then do that, then do that", because ultimately that's an imperative paradigm, and RxJS is capable of more than that. Ideally it should be more about telling what the events are, in a declarative fashion. See this tutorial for more explanations, specially the discourse in the "Wrapping up" section. Also this gist might help.