I was never a fan of projections, very clever trick but the idea that an the path to an endpoint was controlling a filter for the http response gives me the heebie-jeebies :-)
On the other side feels like a form of graphQL From experience don’t do the feature flag, and don’t try to implement in another way. If you want to invest effort instead show an example/lib of using whisk actions as front workers for graphQL might be more useful similar to Cloudflare [1] when talking about projections and filtering responses. I like the idea of a cut off date. Do a /remind in Slack or a Whisk alarm trigger :-) [1] https://developers.cloudflare.com/workers/templates/boilerplates/graphql/ - Carlos Santana @csantanapr On Aug 30, 2019, at 9:53 AM, Rodric Rabbah <rod...@gmail.com> wrote: >> Assuming no one wants to bother with a feature flag for a deprecated > feature, let's set a concrete date on which the PR will be merged. My > suggestion is December 1, 2019. That gives ample time for downstream > operators to do their deprecation process. > > I don't want to bother with a feature flag. I think the feature as > implemented is unwieldy and kudos to those that did get it to work. Fine > with me to defer it's already been open 4 months. > > That said, I have thought that we could provide projection capabilities but > using X- headers (an argument for keeping some of the code around). I am > not sure/convinced this feature in general though is useful. > > -r
