Skip to content

Refactor: Decouple web-features processing from raw schema#1827

Merged
jcscottiii merged 1 commit intomainfrom
jcscottiii/decouple-schema
Sep 17, 2025
Merged

Refactor: Decouple web-features processing from raw schema#1827
jcscottiii merged 1 commit intomainfrom
jcscottiii/decouple-schema

Conversation

@jcscottiii
Copy link
Collaborator

Background: v3.0 schema is stable now. And introducing it directly was a headache. So I refactored the structs.

This commit refactors the web feature ingestion process to decouple it from the raw, auto-generated JSON schema types from the web-platform-dx/web-features repository. This change adds support for the new v3 schema format while maintaining backward compatibility with the old format.

Previously, the application directly used structs generated from the JSON schema. This created a tight coupling, making the system brittle and difficult to adapt to schema changes.

To address this, the following changes were made:

  • A new set of internal, stable structs has been introduced in lib/webdxfeaturetypes/types.go. These structs define the canonical, application-specific representation of web feature data, independent of any specific schema version.

  • The data parser in workflows/steps/services/web_feature_consumer/pkg/data/parser.go has been updated. It now includes logic to process both the old schema and the new v3 schema, transforming the raw, version-specific data into the new stable webdxfeaturetypes structs.

  • All consumers of web feature data throughout the codebase (including Spanner adapters, Datastore adapters, and workflows) have been updated to use the new stable webdxfeaturetypes instead of the auto-generated types.

  • The StringOrStringArray type from the source data is now consistently normalized into a []string in the new intermediate representation, simplifying downstream logic.

This decoupling provides a robust abstraction layer that isolates the core application from upstream schema changes, making it significantly easier to support future versions of the web-features data format with minimal impact on the rest of the system.

@jcscottiii jcscottiii requested a review from jrobbins September 16, 2025 16:16
@jcscottiii jcscottiii linked an issue Sep 16, 2025 that may be closed by this pull request
Background: v3.0 schema is stable now. And introducing it directly was a headache. So I refactored the structs.

This commit refactors the web feature ingestion process to decouple it from the raw, auto-generated JSON schema types from the `web-platform-dx/web-features` repository. This change adds support for the new v3 schema format while maintaining backward compatibility with the old format.

Previously, the application directly used structs generated from the JSON schema. This created a tight coupling, making the system brittle and difficult to adapt to schema changes.

To address this, the following changes were made:

- A new set of internal, stable structs has been introduced in `lib/webdxfeaturetypes/types.go`. These structs define the canonical, application-specific representation of web feature data, independent of any specific schema version.

- The data parser in `workflows/steps/services/web_feature_consumer/pkg/data/parser.go` has been updated. It now includes logic to process both the old schema and the new v3 schema, transforming the raw, version-specific data into the new stable `webdxfeaturetypes` structs.

- All consumers of web feature data throughout the codebase (including Spanner adapters, Datastore adapters, and workflows) have been updated to use the new stable `webdxfeaturetypes` instead of the auto-generated types.

- The `StringOrStringArray` type from the source data is now consistently normalized into a `[]string` in the new intermediate representation, simplifying downstream logic.

This decoupling provides a robust abstraction layer that isolates the core application from upstream schema changes, making it significantly easier to support future versions of the `web-features` data format with minimal impact on the rest of the system.
@jcscottiii jcscottiii force-pushed the jcscottiii/decouple-schema branch from 8cc946d to b00643a Compare September 16, 2025 16:39
@jrobbins
Copy link
Collaborator

I'll try to review this by this evening.

@jcscottiii
Copy link
Collaborator Author

Many thanks @jrobbins

Copy link
Collaborator

@jrobbins jrobbins left a comment

Choose a reason for hiding this comment

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

The number of files touched scared me off, but the change itself seems reasonable.

@jcscottiii jcscottiii added this pull request to the merge queue Sep 17, 2025
Merged via the queue into main with commit 62b49c3 Sep 17, 2025
8 of 9 checks passed
@jcscottiii jcscottiii deleted the jcscottiii/decouple-schema branch September 17, 2025 13:19
@jcscottiii jcscottiii mentioned this pull request Sep 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[ENHANCEMENT] Upgrade to v3 when parsing

2 participants