FAQ

On Tuesday, 10 May 2016 15:14:35 UTC+3, GoNutter wrote:
Thanks Egon,

Here is the link to the library on github.
https://github.com/jetbasrawi/goes

So the names of the methods have been chosen as they follow the names of
the official clients for GetEventStore and so they follow the conventions
surrounding the product rather than Go naming conventions.
I would suspect that, if one of the maintainers wrote Go and did an
official client, they would use Go conventions. The library should work
nicely with the language, not necessarily with other implementations. Every
language imposes limits what you can write and what you cannot write, using
the same limits as in another language doesn't make sense. The usual ES API
look like that because, they were initially written in C# and Java, not
necessarily because that's how they wanted to write it.

This also means that you can simplify your code, e.g.

e.g. https://github.com/jetbasrawi/goes/blob/master/stream.go#L23: here you
could use type

type StreamVersion int

const (
// The write should never conflict with anything and should always succeed
Ignore = StreamVersion(-2)
// The stream should not exist at the time of writing. This write will
create it.
Create = StreamVersion(-1)
// The stream should exist but it should be empty
Empty = StreamVersion(0)
)

And then you can get rid of the pointers to *StreamVersion*.

Similarly the Take type shouldn't exist make multiple funcs instead.

tl;dr; Make sure that the library is nice to use from Go... otherwise
accidental complexity will start to collect to the users of the library.

I will have a look at the library that you have suggested.
On Monday, May 9, 2016 at 1:19:08 PM UTC+1, GoNutter wrote:

Hi All,

I have developed a http client for an GetEventStore

On the client there are several methods. I wanted to use interfaces to
describe the API and I think I have done it in line with good practice. the
interfaces are small as shown below.

type StreamAppender interface {
AppendToStream(string, *StreamVersion, ...*Event) (*Response, error)
}


type MetaDataUpdater interface {
UpdateStreamMetaData(string, interface{}) (*Response, error)
}


type MetaDataReader interface {
GetStreamMetaData(string) (*EventResponse, *Response, error)
}


type StreamReader interface {
ReadStreamForward(string, *StreamVersion, *Take) ([]*EventResponse, *
Response, error)
ReadStreamBackward(string, *StreamVersion, *Take) ([]*EventResponse, *
Response, error)
}


type StreamReaderAsync interface {
ReadStreamForwardAsync(string, *StreamVersion, *Take) <-chan struct {
*EventResponse
*Response
error
}
ReadStreamBackwardAsync(string, *StreamVersion, *Take) <-chan struct {
*EventResponse
*Response
error
}
}


type EventBuilder interface {
ToEventData(string, string, interface{}, interface{}) *Event
}


type EventReader interface {
GetEvent(string) (*EventResponse, *Response, error)
GetEvents([]string) ([]*EventResponse, *Response, error)
}

Now this helps becasue I can now inject fakes of the client into my
client code which uses the eventstore client. The constructor on the client
code now looks like this...

type GetEventStore struct {
eventBus EventBus
eventFactory EventFactory
appender goes.StreamAppender
builder goes.EventBuilder
reader goes.StreamReader
}


func NewGetEventStore(
eventBus EventBus,
appender goes.StreamAppender,
builder goes.EventBuilder,
reader goes.StreamReader) *GetEventStore {

s := &GetEventStore{
eventBus: eventBus,
appender: appender,
builder: builder,
reader: reader,
}

return s
}


So far so good, however the wierdness comes with the code injecting the
eventstore into this constructor... it looks like this..

client := goes.NewClient(nil, eventStoreURL)
eventStore := ycq.NewGetEventStore(eventBus, client, client, client)


It feels weird to be passing the same object three times to the
constructor. Does this feel weird to anyone else or is this something I
should just get over because in every other respect it feels like the right
thing to do.

Many thanks
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 12 of 12 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 9, '16 at 12:06p
activeMay 10, '16 at 12:48p
posts12
users3
websitegolang.org

3 users in discussion

GoNutter: 7 posts Egon: 4 posts Jan Mercl: 1 post

People

Translate

site design / logo © 2021 Grokbase