5 sats \ 2 replies \ @ek 6 Mar freebie \ on: Moderation, automation...automoderation meta
@jeff mentioned webhooks in the past, too and I never mentioned that I am not a fan of webhooks. The place I worked before did exactly this (allow customers to configure the product to their needs). It worked but it was definitely not great. A lot of support tickets where the customer complained about something not working and in most cases, it's because the endpoint they configured did not respond fast enough, in the wrong format or not at all. We basically had to debug their webhooks.
I know that only 20% will make 80% of the problems so it would probably work fine for the majority of cases but I would like to avoid the 80% of problems, too. I think just giving better API access is the better way. No webhooks or any code we run for you (huge security nightmare) but you just query the data whenever you want and then do API calls whenever you want.
Yes, having an API on the SN side may be a less of a reach. As a compromise between hooks and a server API, there could be an empty-payload "something changed, do stuff if you want" style of notification like Signal uses. Without a change notification, the remote side needs to poll.
reply
there could be an empty-payload "something changed, do stuff if you want" style of notification like Signal uses. Without a change notification, the remote side needs to poll.
That makes sense, very good point! We will consider it. Maybe we will do something like long polling just because I liked working with it when I used the TG API.
I'm definitely a fan of not having to poll for stuff (even though it's more complex and can be more demanding of resources) and want things to be as real time as possible and reasonable.
reply