Agreed on it being brittle. However, that's hopefully where retries come into play. And if the original request is handled but an error is thrown before the new event could be created, I'd hope there would be some form of logging in place to report that and hopefully it'd be a simple API call to restore the flow. But I definitely agree that it's messy...
All that being said, we definitely want to support true cron expressions at some point in the near future, I was mostly just throwing that out there as an option that would work today.
Oh for sure, I just haven't thought of a way to enforce that the payload be encrypted because there are so many different methods to do that and most of them still result in a string...
Do you have any advice or suggestions for how to enforce that?
I'll definitely add some docs to encourage it though; thanks for the suggestion!
So are you suggesting that we update docs to encourage users to do that? We use signing secrets to sign the payload so users know the request from us is authentic, but other than that I can't think of how we'd control what users send us aside from just rejecting anything that "looks" like an object ;)
I do like the idea of including a little chunk in our SDK (Coming soon!) to allow them to easily encrypt/decrypt their payload, but that'd be entirely on them to follow that practice.
We just made some changes to our DNS which SHOULD have fixed the original issue. Can you try again?
Worst case scenario (if you're still willing to give us a shot), join our Discord and we can work with you to figure out what's going on: https://discord.gg/NPC6GBDBXp
In addition to what Jose posted above, we also want to encourage users to use the existing functionality as a trigger for setting up recurring handlers.
For example, if you receive an event to your webhook and you want that webhook to fire again at the same time tomorrow, make a new call to Jiter and create a new event when you receive the first event and you can chain them together. Hopefully by end of day today we'll be able to include the original scheduledTime in the webhook body so you can use that as the base for the new event (e.g., createNewEvent(body.scheduledTime + twentyFourHours)
And as Jose said, we definitely plan to make recurring events possible in the immediate future too!
Awesome feedback and thanks for taking the time to challenge us! Sorry in advance for the wall of text, but you asked some great questions.
It sounds like you’re probably a bit outside our target market because you sound comfortable building a scalable solution of your own. However, our target user is either unwilling to build their own or they don’t have the skillset to efficiently build and maintain a separate cron app/server.
As for other execution environments, those definitely have options for scheduling things and setting up recurring events, but you have limited flexibility and things like Type Safety can be quite the burden because they're disparate from your core app. (And while I totally agree GitHub Actions is an option, that doesn't sound fun at all haha). However, what they don't have is flexibility around the "when"...
For example, let's say you want to check to see if a user has performed XYZ action within their first 72 hours after signup. You could setup a cron job to fire once daily to simply poll ALL new users, lock those rows, and join with other tables to see if they're relevant for a follow-up email OR you could setup a Jiter event to target that specific user at exactly 72 hours after their signup. The result is distributed, small queries delivered just in time. The payload contains exactly the information you need to handle that one action and you spread your DB queries out over time to minimize larger impact to a decent chunk of your table.
I agree about the complexity of maintaining the webhook, but hopefully that logic is super focused and ideally you'd use different routes/handlers for different events so each is small and maintainable.
Great feedback all around and I'm curious to see if you have a follow up on any of that!
TL;DR - We're not for everyone, but we think we offer a convenient solution for those looking for flexibility and for those without the skillset to roll their own.
All that being said, we definitely want to support true cron expressions at some point in the near future, I was mostly just throwing that out there as an option that would work today.