@jbulava EventSub still has a lot of outstanding issues, that I hope can be fixed switftly.
For example, there are a lot of instances in the docs of mismatched types between example and type. One instance is EventSub Subscription Types | Twitch Developers where the example shows duration_seconds as a string, but the event payload docs list it (correctly) as an integer. There are many instances of this.
Secondly, there are event missing crucial data, like EventSub Reference | Twitch Developers not including information about the gift recipient. This causes us to have to create a lot of hacky workarounds that are not fool-proof, and cause a lot of turbulence for both our developers and our users.
I hope these issues can be addressed very soon, the state of EventSub is concerning for business that depend on it like Tangia.
It’s also irritating that situations like resubbing after a sub expires sends both a new sub event, and a resub event. Again, this results in more hacky deduplication implementations for our Alerts. It’s exacerbated by the fact that Twitch sends the new sub immediately, but the resub only after they finsh typing the message.
The user stops being a sub for whatever reason, so a unsubscribe is sent
Then they realise and restart payment leading then to business event from a non sub to a sub.
Leading to a sub start event
And if its a resub an optional extra message sent with the message they left.
Sub/Unsub are business logic events rather than a representation of status.
So channel.subscribe potentially needs a is_resub flag.
But then you get a possiblity that the user will resub and never send a message.
Which generally doesn’t happen with prime resubs but can with regular. Leaving a message is optional and there can be a days between a sub and a resub message inb theory
It is debatebable if this topic is incomplete or not.
Yes additional hydration would be nice, but for feature parity with PubSub then you need chat notification as that is what parities with the PubSub topic it replaces
channel-subscribe-events-v1.<channel_id> is migrate to channel.chat.notification
Edit: Full migation paths in my opinion are: [source]
IIUC there is also no way to distinguish a prime sub in EventSub, that’s another pain. We never used PubSub, because that model doesn’t work as well for server-side managed reactivity to events.
IDK if I’d consider it debatable, it’s clearly missing critical information required for the standard functionality all streamers expect from integrations, and has so for a long time.
The recent introduction of the chat event also makes EventSub more confusing. It’s more intuitive to use the direct event rather than parse out chat events, but those direct events are not well coordinated, have incorrect examples, and lack critical information.
There is on channel.chat.notification which is why I’m saying thats the migration path.
channel.chat.notification is USERNOTICE as a topic so has Prime
I’ve been using PubSub for server side events for 10 years. Since I started doing overlays so I’ll disagree there.
Hence the debatable, for PubSub/EventSub feature parity it’s not needed as the data you refer to is on another topic.
For my use case when I migrate I’ll be migrating from channel-subscribe-events-v1.<channel_id> to channel.chat.notification
Which will give me who is prime-ing and whom gifted what subs.
Since it’s a flat migration of IRC USERNOTICE as a type which also replaces a PubSub topic
And since it’s a chat type I can connect to a handful of live channels and wait for samples, if I don’t already have those samples on file from my testing.
It’s not confusing to me.
It’s just IRC USERNOTICE as a Topic.
99% of the time I connect up and get examples from the live API rather than relying on documentation, I do this for any API I use.
Would more fuller and complete examples for documentation on any service (not just Twitch) be great yes, will we get them probably not.
Thats why Google/YouTube has a live API Tester right on the documentation, live data, beats documentation any day.
Documentation can be fixed and improved over time, but isn’t part of “feature parity” per sae.
I’ve been using PubSub for server side events for 10 years. Since I started doing overlays so I’ll disagree there.
When you scale out to multiple servers, coordination becomes a massive PITA.
I think if you have to rely on live events rather than documentation (which we also do when we can, but not as easy for things like resubs and prime subs), that says a lot about the accuracy and trust developers have in the docs.
Regardless, I just wanted to provide some feedback so they could focus some efforts in useful places. We operate at a pretty significant scale and these problems have only become more painful over time. If their goal is to help more developers expand their usage then they should probably address the issues that cause us pain, as they are certainly unnecessary obstacles.
If the new chat events truly solve everything, they should plan to remove the others. That will probably break a lot of unmaintained integrations though (which I’m sure PubSub deprecation will too)
Different topics have different use cases, so it doesn’t make sense to retire a topic. Sure those topics that are dry on data just need to be enhanced, I would assume that the underlying service powering the topic in question, doesn’t have the data you have requested which is why it’s missing and we uservoice as such requesting hydration. Where as the service powering USERTNOTICE as a topic does so can raise that information.
For Example: If someone just needs a raw gift count like I do in one of my use cases, I don’t care about who sent or whom received just the number of gifts during that stream, then I would and do use the gift specific topic(s).
Correct topic selection is part of building your application in order to ensure it does what you need it to do.
Now that we have feature parity with documented pubsub most projects can move over from pubsub (or even chat over IRC socket) to eventsub relatively easily.
