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

feat: Apply schema validation to all topics in local development #2013

Merged
merged 10 commits into from
Apr 14, 2023
246 changes: 240 additions & 6 deletions Cargo.lock

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 2 additions & 0 deletions relay-kafka/Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,8 @@ rmp-serde = { version = "1.1.1", optional = true }
serde = { version = "1.0.114", features = ["derive"] }
serde_json = { version = "1.0.55", optional = true }
thiserror = "1.0.38"
sentry-kafka-schemas = "0.0.25"
jsonschema = "0.17.0"
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if it would make sense to hide the jsonschema dependency in sentry-kafka-schemas. That is, if we removed this dependency here, and sentry-kafka-schemas exposed a validate(topic, message) function.

That way, the library client (Relay) would not have to deal with compiling schemas, and the way that sentry-kafka-schemas validates would be completely encapsulated (i.e. you could change the library or even the format it uses for schema definition and validation).

Copy link
Member Author

Choose a reason for hiding this comment

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

See my reply to the local cache comment. For now I would like to avoid that. There's still many unsolved questions around how the workflow in Relay will look like, what performance requirements we have on the entire system, etc.

Copy link
Member

Choose a reason for hiding this comment

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

OK! Definitely not a blocker.

As such it doesn't have many dependencies. This is a good thing if you're only using the generated types in your service.

Makes sense, though this could be solved with cargo features. I.e. there could be a codegen feature and a validation feature, and clients use either-or. My gut feeling is that 90% of clients that want to perform validation will not care about what schema definition language or validation library is used under the hood, hence the idea to hide it inside the library.

Copy link
Member Author

@untitaker untitaker Apr 7, 2023

Choose a reason for hiding this comment

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

i'm reconsidering my response now. one of the reasons i was hesitant to change this was because python currently also works the same (it just exposes the raw schema, doesn't prescribe a schema validation library)

but at the same time it would be good to have a vetted recommended library that everybody ought to use (for both python and rust)


[dev-dependencies]
serde_yaml = "0.9.17"
Expand Down
Loading