Please do not interpret this comment as negative in any way - I am sincerely trying to understand what this does.
Instead of setting up cronjobs on a machine I own, this allows me to set up a cronjob on jiter servers to make a callback to my server?
Who is your target user? I am happy to run cronjobs or systemd timers on servers that I or my team control. And for execution in environments like GitHub Actions or AWS Lambda, they all have functionality to trigger execution with a timer.
This introduces added complexity of maintaining a webhook receiver and having to deal with the rather complex failure modes of webhooks.
FWIW my engineering org built a service that pretty much does what Jiter offers because we need to do things like schedule messages to be sent in the future.
And for execution in environments like GitHub Actions or AWS Lambda, they all have functionality to trigger execution with a timer.
We use it for triggering things dynamically within services. For example, when someone books a flight we need to send a follow-up email X amount of time later. Building a scheduler into the service that handles booking the flight might make sense, but what happens when we need to do the same thing for someone booking a hotel or car rental? Instead we just have a service that stores all of the messages it needs to send in the future and has a tight reconciliation loop to send out those webhooks.
This introduces added complexity of maintaining a webhook receiver and having to deal with the rather complex failure modes of webhooks.
If you only need to do it once, sure. If you standardize the behavior/API then it reduces complexity a ton.
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.
Actually, I hadn't considered that signup use case at all. Good point. It could be a useful way of offloading heavy data processing to Jiter.
It would be useful to see on your website what the webhook request from Jiter.dev would look like. How does the receiver know that the webhook came from Jiter with no tampering by a middleman? Is there a signature that the user could verify? (Slack does this well on their webhooks.)
Congratulations on the launch, and I wish you the best!
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.
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!
to my understanding, it's for those who can imagine (and predict time) how to write simple additional httprequest to external URI and create simple `route` in their NodeJS app [for getting callbacks], but who's not confident on wtf is `man systemd.timer` (smells like all dead sysadmins' zombie magic) which `service unit` it should trigger and what actually to run under that service unit. How to deploy all that after all.
Indie/solo devs, if that express state of things better, who are assured their product will be never run in internal/isolated networking, for example or never need to stop some specific cron but not all of them during migration, blah blah blah.
Comments
Please do not interpret this comment as negative in any way - I am sincerely trying to understand what this does.
Instead of setting up cronjobs on a machine I own, this allows me to set up a cronjob on jiter servers to make a callback to my server?
Who is your target user? I am happy to run cronjobs or systemd timers on servers that I or my team control. And for execution in environments like GitHub Actions or AWS Lambda, they all have functionality to trigger execution with a timer.
This introduces added complexity of maintaining a webhook receiver and having to deal with the rather complex failure modes of webhooks.
FWIW my engineering org built a service that pretty much does what Jiter offers because we need to do things like schedule messages to be sent in the future.
We use it for triggering things dynamically within services. For example, when someone books a flight we need to send a follow-up email X amount of time later. Building a scheduler into the service that handles booking the flight might make sense, but what happens when we need to do the same thing for someone booking a hotel or car rental? Instead we just have a service that stores all of the messages it needs to send in the future and has a tight reconciliation loop to send out those webhooks.
If you only need to do it once, sure. If you standardize the behavior/API then it reduces complexity a ton.
Hey there! I'm another dev from the Jiter team.
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.
Actually, I hadn't considered that signup use case at all. Good point. It could be a useful way of offloading heavy data processing to Jiter.
It would be useful to see on your website what the webhook request from Jiter.dev would look like. How does the receiver know that the webhook came from Jiter with no tampering by a middleman? Is there a signature that the user could verify? (Slack does this well on their webhooks.)
Congratulations on the launch, and I wish you the best!
Yea we think it's a solid use case (mostly because we had that problem ourselves with a previous product haha)
And another great question! We use signing secrets to create a signature so you can validate that the request from us is authentic.
And thanks! This is just the beginning for us, so hopefully you give us a chance and sign up so we can notify you as we release new features!
If you are using signing secrets, consider having the client keep a secret and simply encrypt and sign the payload before handing it off to you.
When it comes back in, they can decrypt and authenticate it. You could hide all this in your api client.
Then you don’t end up with a big centralized database full of the PII of millions of your customers’ customers.
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.
Defaults matter. Make the api client encrypt everything it sends to you, so you never handle unencrypted customer data.
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!
When I say “make”, I mean in your own api client library. It should happen automatically so the user doesn’t have to think about it.
You can provide some functions for the webhooks so targeted to authenticate and decrypt the stuff posted to them.
Ah gotcha. Yea we'll 100% include that as part of our SDK. Thanks for clarifying!
What happens if the webhook fails, does it requeue?
to my understanding, it's for those who can imagine (and predict time) how to write simple additional httprequest to external URI and create simple `route` in their NodeJS app [for getting callbacks], but who's not confident on wtf is `man systemd.timer` (smells like all dead sysadmins' zombie magic) which `service unit` it should trigger and what actually to run under that service unit. How to deploy all that after all.
Indie/solo devs, if that express state of things better, who are assured their product will be never run in internal/isolated networking, for example or never need to stop some specific cron but not all of them during migration, blah blah blah.