Skip to content

Various fixes #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

Various fixes #3

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
31c4a7b
Various fixes
rust-jvm-go Jan 19, 2024
340ec4c
Merge branch 'webhookdb:main' into feature/updates-from-20240119
rust-jvm-go Jan 19, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions .gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,3 +13,6 @@ _site/
# Ignore folders generated by Bundler
.bundle/
vendor/

# For JetBrains IDEs
.idea/
11 changes: 9 additions & 2 deletions Gemfile.lock
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,7 @@ GEM
forwardable-extended (2.6.0)
google-protobuf (3.24.3-aarch64-linux)
google-protobuf (3.24.3-arm64-darwin)
google-protobuf (3.24.3-x64-mingw-ucrt)
google-protobuf (3.24.3-x86_64-linux)
http_parser.rb (0.8.0)
i18n (1.14.1)
Expand Down Expand Up @@ -65,9 +66,14 @@ GEM
rexml (3.2.6)
rouge (4.1.3)
safe_yaml (1.0.5)
sass-embedded (1.67.0)
sass-embedded (1.67.0-aarch64-linux-gnu)
google-protobuf (~> 3.23)
sass-embedded (1.67.0-arm64-darwin)
google-protobuf (~> 3.23)
sass-embedded (1.67.0-x64-mingw-ucrt)
google-protobuf (~> 3.23)
sass-embedded (1.67.0-x86_64-linux-gnu)
google-protobuf (~> 3.23)
rake (>= 13.0.0)
terminal-table (3.0.2)
unicode-display_width (>= 1.1.1, < 3)
unicode-display_width (2.4.2)
Expand All @@ -77,6 +83,7 @@ PLATFORMS
aarch64-linux
arm64-darwin-21
arm64-darwin-23
x64-mingw-ucrt
x86_64-linux

DEPENDENCIES
Expand Down
6 changes: 3 additions & 3 deletions docs/integrating/httpsync.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,10 +18,10 @@ The standard pattern for webhooks is:
1. Something happens in an external system.
2. The external system sends you an event (usually they send an HTTP POST).
3. Your backend validates the event is authentic.
4. Your backend enques the event for further processing, and returns a successful response.
4. Your backend enqueues the event for further processing, and returns a successful response.
5. Your backend processes the event further, like synchronizing data from the external service, or updating your own data based on the external event.

The big challenge here is that the order events happen in the external system (first step), and the order your backend processes events (last step), can happen in any order. Both because events from the external system may reach your application in any order, and because your backend may not process them in serial.
The big challenge here is that the order events happen in the external system (first step), and the order your backend processes events (last step), can happen in any order. Because both events from the external system may reach your application in any order, and because your backend may not process them in serial.

So you could have, for example, have a user's name in an external system that changes from 'Kyle' to 'Taylor'; when you process these events, you either need to know which of them to throw out (this is tricky to build, and not always possible), or you need to re-query the external system for the latest data (which is potentially slow).

Expand Down Expand Up @@ -52,7 +52,7 @@ Here's how it works:

It's important to note that *you will not need to handle concurrent HTTP Sync webhooks.*

Instead, all processing happens within your API endpoint. Your endpoint can take up to a minute (or more, when [self-hosting](/docs/self-hosting))
Instead, all processing happens within your API endpoint. Your endpoint can take up to a minute (or more, when [self-hosting]({% link docs/operating-webhookdb/self-hosting.md %}))
to respond, to make sure you have time to do what you need to with the changed data. The page size can also be modified to send fewer rows.

When your endpoint returns successfully, we assume that page has been processed, so can POST the next page, until there are no new changes. If your endpoint returns an error, we retry the POST until it succeeds.
Expand Down