Add Observable variant `Single` about rxgo HOT 9 CLOSED

@bangarharshit in Go speak, Single seems like a good candidate for an interface type that with Observable and Observer mixins:

// Imaginary unicorn
type Single interface {
        rx.Observable  
        rx.Observer
}

Most foreseeable goal is to make base interfaces like rx.Observable (not yet existing) which is implemented by observable.Observable (a "variant" struct of rx.Observable). This will mean more extensibility for developers (anyone can whip up an observable based on anything from slice to channel) while keeping the core library lean.

Maybe a Slack or Gitter for RxGo is in order. I'll open a separate issue about this.

from rxgo.

Can you give a hypothetical use case in code? I'm trying to understand what you're explaining.

from rxgo.

@jochasinga the use-case I am envisioning is when a go client needs to talk to multiple micro-service backends to fulfill a user-request. The psuedo-code would be something like:

 func processUserRequest(obj interface{}) {
   observer = {OnSuccess: func() {
    // Make a REST call to another micro-service
}, OnError: func() {
   // Return a 5xx error to caller.
}};
  //Create Single of `obj`
  single.Start(func() {
    //Create a Single of `obj`
}).Subscribe(observer)
}

Basically the single pattern will allow us make the whole request process in a micro-services architecture asynchronous while maintaining the readability of the code.

from rxgo.

afaik Single type implements both Observer and Observable which means it can both emit values or act like an observer. In your case, it seems you are using it as an observable with a single item waiting to emit. Would this suffice?

observable.Start(func() interface{} {
        res, err := http.Get("somewhere")
        if err != nil {
                return err
        }
        return res
}).Subscribe(observer.Observer{
	NextHandler:  func(item interface{}) {
		fmt.Printf("Processing: %v\n", item)
                res, ok := item.(*http.Response); ok {
                        if res.statusCode == 200 {
                                // Make a call to another service
                        }
                }
	},
	ErrHandler: func(err error) {
		fmt.Printf("Encountered error: %v\n", err)
                // Return a 5xx error to caller
	},
})

I've tried playing with Single type, but with Go I haven't found a need for it yet because Go's rather "raw" type system makes it unnecessary to come up with so many abstract types. Maybe this can be included in the next milestone.

I'd love to know if it works for you.

from rxgo.

@jochasinga yeah that's the idiom I currently plan to use. Was just thinking that the Single might make this a lot more explicit.

from rxgo.

Things like network calls can be single (with single, a large number of Observable related stuff can be migrated to it since it is terminated after an event). It should neither be a subclass of Observable and Observer. It is more of a variant of Observable.

BTW, there are other variants of Observable in RxJava for specific purposes (which may not be relevant for RxGo). Would love to learn and contribute. Do you have a slack or any IRC channel where we can ask questions?

1. Maybe 
2. Flowable  - Supports backpressure
3. Completable -  Just the case if it succeeded or not.
4. ParallelFlowable

from rxgo.

@bangarharshit very good point. A Single would be really useful in developing an actor programming model that is pretty prevalent in distributed systems.

from rxgo.

+1 for the Single interface.
Meanwhile, I tried to propose something regarding the migration of Observer, Observable and Connectable to interfaces: #90

from rxgo.

implemented on RxGo 2 (in development) #95

from rxgo.