feat!: Updated service to use connect

[james-milligan]

Connect is a family of libraries for building browser and gRPC-compatible HTTP APIs. It is backwards compatible with gRPC and allows for all currently listed service providers and their 'variations' (gRPC, http(s), unix / tcp) to be managed by a single service provider with a single set of handlers.

Using connect introduces the connect protocol, directly compatible with the connect-go andf connect-web client libraries. This provides the benefit avoiding the use of heavy libraries such as grpc-web in the front end applications. It is also fully compatible with gRPC meaning that any existing clients that match the interface will still work, thus, providers can still be writen for other languages using pure grpc clients, without requiring a language specifc conenct library.

Breaking changes:

The http routes are changed, there is currently no support for providing 'custom' routes. A request which previously will have looked like this:

$ curl -X POST "localhost:8013/flags/headerColor/resolve/string" -d '{"email": "foo@bar.com"}'
{"value":"#0000FF","reason":"TARGETING_MATCH","variant":"blue"}

will not look like this:

$ curl -X POST "localhost:8013/schema.v1.Service/ResolveString" -d ''{"flagKey":"headerColor","context":{"email": "foo@bar.com"}}'' -H "Content-Type: application/json"
{"value":"#0000FF","reason":"TARGETING_MATCH","variant":"blue"}

This may not be an issue going forwards as these URLs are internal, and will only requre an update to the provider.
route prefixes can be added to allow for /api/ to be appended to the front of each route.

There is no longer a --service-provider option, this is because all variations of this flagkey are now available through the single connect service. (there may be argument for keeping this flag and setting the default to 'connect')

[toddbaert]

I'll look at this first thing tomorrow. I'd like to get this in.

Although the benchmark does seem to be hanging for some reason, and there's errors in it's logs.

[AlexsJones]

Nice reduction in code, happy times

[james-milligan]

Although the benchmark does seem to be hanging for some reason, and there's errors in it's logs.

I have resolved the error log on the benchmarks, the hanging seems to be on writing to the gh-pages branch so i will look into this

[skyerus]

Nice work :)

[toddbaert]

I tested this locally with the current js flagd provider, behavior looks the same as before (which is good!). Happy paths all work as expected.

The only issue I'm having (which existed before this change) is that it's a bit messy to map the RPCErrors to our error codes. See the screenshot below for an example RPC error for a not-found flag:

As you can see the code is a standard RPC error code NOT_FOUND, which makes sense. The message is a string with that code appended to our SDK error code FLAG_NOT_FOUND. I think it would be great if we could have the message contain only our error code, so flagd providers could easily set the appropriate SDK error code without manipulating this string.

What do you think? Is that possible?

UPDATE: we think this might be a parsing issue in the clients. Either way, this isn't a blocker for this PR since it's not new behavior.

[toddbaert]

@james-milligan You've missed updating a couple old REST examples in the readme.

[AlexsJones]

What does the feat! mean @toddbaert is this not ready for merge?

[toddbaert]

@AlexsJones

What does the feat! mean

feat! is just a semantic convention for git commits.

! means breaking, and can be applied to any commit prefix, but only feat and fix are user-facing and will appear in the changelog automatically. I don't consider this a "refactor" because it makes user-visible changes (REST endpoints, etc) so it's not a refactor.

@toddbaert is this not ready for merge?

I'll leave that to @james-milligan . It looks good to me!