High Level API

[Pliner]

Hi!

1. I looked through and found that there are too much action to wireup publisher and consumer. What do you think about creating simple utility class to wire up all components with fluent configuration?
   Here is an example from EasyNetQ -- https://github.com/mikehadlow/EasyNetQ/blob/master/Source/EasyNetQ/ComponentRegistration.cs and nearest classes :)

2. Imho, there is no simple API just for simple publish/subscribe. As it is done in EasyNetQ with simple IBus interface, which hides all magic inside.

Are you interested in pull requests with these features?

PS Sorry for bad English :)

[Jroland]

Yes I am interested in any and all pull requests. I can't promise they will make it in to the main lib, but fire away. If you have a big change, then you can also just send me a message to have a look at a certain fork and I can see what we can bring in.

I do like the easynetq project which I also use a lot myself and it could be a good model for this library.

Here are my thoughts on this:

I wanted the base lib to have 0 dependency requirements and allow all references to be able to be plugged in. So for example there is just an IKafkaLog interface which defaults to the trace logger. I didn't want a dependency on log4net or some other framework.

What I was thinking of having was other nuget packages that implemented say, log4net logging or Json.net serialization.

If you can put together a good way to keep the references down but make the wiring up simpler, I would like to see that. Another good example of easy plugin architecture is the Nancy web project. So have a look at both and see what you can put together.

[Pliner]

Thanks for answer!

I'll investigate nancy plugin architecture and I hope to make changes as soon as possible :)

[Pliner]

Hi @Jroland!

Sorry for long delay, here is the attempt to the first and second point.

1. Created IBus interface just for aggregation of all functionality.
2. Created BusFactory with simple Ioc container
3. An attempt to inject IBrokerRouter, IPartitionSelector, IKafkaLog, IKafkaConnectionFactory by constuctor, not by KafkaOptions.
   Also it seems these four abstactions should be singleton.

Several thoughts about high level API:
I found that configuration by attributes looks great:

[CompressionMode(CompressionMode.Zip)]
[AckMode(AckMode.All)]
[Timeout(TimeSpan.FromSeconds(30))]
public class Message {
[Key]
public string Key {get;set;}
}
It's just an example, but it shows the idea.

What do you think about that?

PS I focused on idea, something could not work :)

[Jroland]

Thank for putting that together @Pliner, I'll have a look at what you have put together. Give me a little while, I've been taking quite a bit of time off to enjoy this window of nice weather.

[Jroland]

Oh man @Pliner the injection is so much cleaner I love it. I have only just given it a quick read through but its pretty close to what I was thinking. I'll pull it into a branch and test it out.

[Pliner]

@Jroland, thanks!

Could you not to merge this branch into the master? :) There are a lot of things to do: no tests for injection, it was just a fast prototype :)

What do you think about spliting the API to simple and advanced (as EasyNetQ does) ?
I mean:

1. To have a simple Publish and Subscribe methods where T is the message class. It'is an option to configure all behavior with attribute or smth different.
2. To have advanced Publish and Subscribe methods which work with the Message and have a lot of option to configure(IBus now has simular interface).

PS I am still in the search... Do you know about ready virtual box image with already installed and configured Zookeper and Kafka? :) It's really pain in ass))

[profporridge]

One year later, any update on this?

[chester89]

+1