open-feature / flagd-schemas Goto Github PK

With the new release of better named protos here, we should update the buf.md file.

• reference new names/locations
• mention migration from old
  • flagd will support both for some time
  • generate sources based on new protos

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update actions/setup-node action to v4.0.2
• chore(deps): update actions/checkout action to v4
• chore(deps): update actions/setup-go action to v5
• chore(deps): update google-github-actions/release-please-action action to v4
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

If the discussion here is implemented, I think we want to change ResolveObjectResponse from:

message ResolveObjectResponse {
    google.protobuf.Struct value = 1;
    string reason = 2;
    string variant = 3;
}

to:

message ResolveObjectResponse {
    google.protobuf.Value value = 1;
    string reason = 2;
    string variant = 3;
}

This allows us to return arrays (as well as other protobuf values) as the top level object in the object resolver.

Is there any objections or challenges to doing this? I've POC'd it in the flagd-java provider. Would it be reasonable in flagd?

@james-milligan @skyerus @beeme1mr

Currently, we define a JSON-schema definition for flagd. This schema is adequate, but doesn't support:

• validation of JSON logic rules
  • all native JSON logic operations
  • custom operations (fractional, semver, string)
• validation of custom injected properties (might not be possible)
• validation that defaultVariant is actually one of the variant keys (might not be possible)

We should implement a JSON schema that includes as many of the above validations as possible. Once we have this, we could host it at flagd.dev, and when users edit a JSON file in vscode or other editors, they could get built-in validation if the schema is referenced in their doc ("$schema": "https://flagd.dev/flagdefition").

Remove the OpenAPI folder and associated workflows. We're now using Buf and gRPC.

In the schema we are currently only providing the java and go package name options, these options will be required for any languages we expect to produce a provider for.

This would also be a good opportunity to review the existing package names.

Update the buf gen configs to generate client stubs for the grpc apis.

Currently buf.gen.yaml is configured to generate grpc-gateway and go-grpc code, however, stubs will need to be generated in all languages we intend to produce a client for.

(Java, Typescript, Go etc ...)

This is a possible solution to the problem here.

Instead of throwing for DISABLED flags, (which according to the OpenFeature spec is not an error) we need a way to comunicate that the caller should use their code-provided default.

Consider an additional field to the Resolution responses, which adds additional information, indicating if the default should be used.

Schema Store is a collection of JSON schemas that are automatically loaded in supported IDEs. This would make editing flagD configurations easier because it would automatically perform basic validation and autocomplete functionality.

Split the ResolveNumber rpc into 2 separate rpcs.

ResolveInt handling int64
ResolveFloat handling float64

The current flagd flag configuration schema lacks some reasonable defaults that can easily be derived assumed:

• Boolean flags don't really need variants explicitly defined - they essentially should always be true/false. We can make these variants "implied".
• Flags states are generally ENABLED. We should implicitly assume they are ENABLED if the state is not defined.

Things that need to be done to accomplish this:

• Relax JSON schema to support this.
• Leverage relaxed schema in flagd and make required updates to state management to support this
• Leverage relaxed schema in OFO

Requirements

• Add a readme to root of the schemas folder so it's included in the Buf schema registry
• Version the schema releases (see #27)
• Document properties on the schema so they're visualized in Buf
• Include a link to the Buf schema registry on the readme

In order to support synchronous evaluation (something particularly important for client use cases), we need a bulk evaluation rpc. The endpoint would accept a context and evaluate all configured flags with that context. The returned result should be a map of flagKey: resolutionDetails.

Relates to: open-feature/flagd#234

Requirements

• Create a GitHub release automatically based on a git tag
• The git tag should match v*.. and follow semver guidelines.
• Breaking changes should be represented in PRs and Release notes
• Breaking changes should NOT bump major version numbers until a 1.0 release
• Push releases to the Buf Schema Registry

When we renamed https://github.com/open-feature/schemas to https://github.com/open-feature/flagd-schemas, we never changed the go module name, and the package isn't being indexed properly at https://pkg.go.dev/github.com/open-feature/flagd-schemas, so we're forced to rely on a specific sha instead of a proper release here.

Originally posted by @toddbaert in open-feature/flagd#1146 (comment)

tasks:

• rename module
• update https://pkg.go.dev/github.com/open-feature/flagd-schemas

Buf can be used to validate PRs. It should run:

• buf lint
• buf breaking change detection
• buf format