Daniel Hochman
Daniel Hochman
**Description** After scaffolding is generated, hash the dep files and cache them to speed things up. Complexity [S/M/L]: S
**Description** Give a quick overview of Clutch's core features in a video via a couple of sample workflows. Also show auditing capabilities, resolver, creating a new workflow, etc. Complexity [S/M/L]:...
**Description** The oauth2 flow is already implemented, will just need some tweaks to support GitHub as the current authn implementation is only set-up for OIDC flows (e.g. Okta). InfluxDB's Chronograf...
**Description** Currently we don't render histograms or timers into the stats output of the Envoy remote admin endpoint. Either we'll need to flatten these into normal key/value pairs (not preferable)...
**Description** After 3-6 months of initial open-source availability, we will want to offer versioned builds. Guessing we will use semver but we'll need details on what constitutes major/minor version upgrades,...
**Description** Error handling is kind of a free-for-all at the moment. For the backend, I think we want to use `google.golang.org/grpc/status` pretty much all the way down to the service...
**Description** Audit that Clutch-specific annotations in https://github.com/lyft/clutch-preview/blob/master/api/api/v1/annotations.proto are always present on endpoint definitions. Complexity [S/M/L]: M
**Description** There need to be two gRPC listeners. One for grpc-gateway to proxy JSON requests to, always running in insecure mode and only bound to localhost, and a second that...
**Description** Our repeatable build tooling is mostly bash scripts at the moment, managing protoc, yarn etc. Bazel would be ideal for this kind of project, i.e. a multi-language monorepo. IIRC,...
**Description** Allow systems to call into Clutch rather than only users. Would be nice to manage tokens and applications via an Admin UI, see #29 (stateful sessions) for more work...