Skip to content
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.

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

Generic Webhooks v0 #337

Merged
merged 30 commits into from Mar 11, 2024
Merged

Generic Webhooks v0 #337

merged 30 commits into from Mar 11, 2024

Conversation

colehpage
Copy link
Contributor

@colehpage colehpage commented Mar 7, 2024

Generic Webhook Option for Alerts

DETAILS:

This PR enables the creation and use of generic webhooks alongside the existing slack webhooks. This allows users to configure arbitrary webhook consumers/destinations with custom payloads.

For now the lack of signage/security features means more complex webhooks that perform actions on alert will most likely be gated off due to their internal requirements, but this should unlock a variety of message-focused consumers alongside the existing slack implementation. Query parameter usage was built into the migration and logic, and can be enabled in a later version when security options make those more complex use cases (like caching) worthwhile. For the time being many consumers allow/mirror QP functionality in the body of the request, and otherwise building into the url manually achieves the same purpose.

This implementation assumes and is limited to POST requests only, which is the ideal sender behavior and has exceptionally large coverage, but optionality for GETs and PUTs can be added in later versions if they are desired.

Message templating is still quite limited while the more robust templating system is in development, and users should refer to their specific consumer documentation for implementation.

As a minor addition, with the added complexity beyond just single slack webhooks, optional descriptions were also added to the webhook model and displayed on the settings page.

V1+ NEXT STEPS:

  • security/signature functionality
  • user facing webhook edit functionality
  • functionality to send webhook tests during creation
  • alignment with current in-progress alert templating
  • user facing queryParam functionality (and/or url building for ease of use)

VISUALS:

TEAM SETTINGS UPDATE:
Screenshot 2024-03-07 at 3 16 11 PM

GENERIC WEBHOOK CREATION:
Screenshot 2024-03-07 at 3 17 50 PM

ALERT CREATION UPDATE:
Screenshot 2024-03-07 at 3 18 27 PM

Copy link

changeset-bot bot commented Mar 7, 2024

🦋 Changeset detected

Latest commit: b07e123

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages
Name Type
@hyperdx/api Minor
@hyperdx/app Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@colehpage colehpage marked this pull request as ready for review March 8, 2024 01:04
@colehpage colehpage requested a review from wrn14897 March 8, 2024 17:27
packages/app/package.json Outdated Show resolved Hide resolved
@colehpage colehpage requested a review from wrn14897 March 8, 2024 18:38
@colehpage
Copy link
Contributor Author

import linting....fixed....

wrn14897
wrn14897 previously approved these changes Mar 8, 2024
Copy link
Contributor

@wrn14897 wrn14897 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good stuff. Thanks for the contribution!!! 🙌

// Converts this map to a native JavaScript Map for JSON.stringify(). Set the flattenMaps option to convert this map to a POJO instead.
// doc.myMap.toJSON() instanceof Map; // true
// doc.myMap.toJSON({ flattenMaps: true }) instanceof Map; // false
toJSON: (options?: {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so we need to set flattenMaps to true to convert the document to JSON ? not very intuitive

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naw, need to set flattenMaps to true only if the input has nested Maps - in these cases it's probably not needed at all since inputting nested maps would rarely happen. the regular call to toJSON() it still preps it for use with json.stringify etc.

Copy link
Contributor Author

@colehpage colehpage Mar 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't need them for queryParams/headers I should have left those out, nobody is inputting raw maps their either, that was my mistake - these use cases don't mind if maps are flattened or not (and they shouldn't be nested anyway) we just care that they are available for JSON parsing/strings - just a call to toJSON should almost always be sufficient unless you need to work with nested js objects instead of maps for some reason or another

Copy link
Contributor Author

@colehpage colehpage Mar 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we really just want to make sure the object is valid for JSON.stringify() and the raw method does that
image

@wrn14897 basically if the input has nested maps json.stringify may return an empty object for the Map instances but I don't believe that should be an issue with how these request pieces are inputted and stored because they really shouldn't have them to begin with - it's "safer" with broader compatibility to flatten, but only needed in cases where the mongoose map could be stored with nested maps, which in this case it really should not since it's JSON in and JSON out (and that's validated on user input to begin with)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Thanks for the detailed explanation. This makes sense.

@kodiakhq kodiakhq bot merged commit 0e365bf into hyperdxio:main Mar 11, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants