HTTP Persistent Subscription - can the subscriber get notified of new events?

EventStoreDB
#1

I am guessing the answer will be no to this, but will as any.

If we were using the HTTP API for persistent subscription, from what I can gather, the subscriber would have to poll the event store for new messages.

Is there a way we could make event store post to a URL to let subscribers know that there is a new event on the stream?

Steven

#2

Not as of now (I have discussed implementing this in the past … if you are interested contact me off list). You could also implement this fairly easily outside of eventstore using a regular TCP subscription and building the http post yourself.

#3

Greg,

We have a TCP service which we built for managing this, but to be honest, it’s a bit clunky (my fault, not the API’s) which is why I started having a look at the HTTP API.

Do you think a subscriber should ever initiate a connection themselves, or should it always be driven from the system publishing the events?

#4

So if doing pushes I would make eventstore itself do the posts over to the consumer group members. It’s not a ton of work just a bit of a tricky area of code and likely needs quite a bit of testing!

#5

Yeah, I think this would be a great feature to have on Event Store.
When we create a new persistent subscription on the UI, having a field for a url to post to.

I am guessing most people who use Event Store have to go and build some kinda delivery mechanism for their events (our own took a while, and it’s probably trying to do too much now)

#6

Yeah, I think this would be a great feature to have on Event Store.
When we create a new persistent subscription on the UI, having a field for a url to post to.

It would probably be multiple no? :smiley:

#7

I was thinking 1 per Group.
How would you track events delivered to multiple URL’s on a single group?

#8

We already do it with tcp connections :slight_smile:

#9

Didn’t realise that!

#10

to be fair if implemented the way I see it you could even have mixed tcp/http “subscribers” :open_mouth:

#11

if not clear the whole point of persistent subscriptions is they get acked/nacked etc, can have retries etc configured, and can be to many consumers …

This could be done with http posts as well as over tcp :slight_smile:

#12

Sounds very good.