Shane Krueger
Shane Krueger
> I think at least some consumers (within the millions of downloads of QRCoder) might appreciate or care for a design that includes a usage pattern that is close to...
Here’s a structured **summary of the discussion, consensus, differing opinions, progress to date, and open items** for the QRCoder v2 abstraction design thread. --- ## 🧭 Summary of Discussion The...
Based on the above, I'd like to proceed planning the v2 design, with these goals: - Brand new fully-fluent API design - Aim for 95%+ backwards compatibility for v2, achieved...
Yeah it’s supposed to be independent. Why don’t you try the authorization library included in GraphQL.Server.Transports.AspNetCore instead? It uses policies defined by ASP.Net Core and has a fuller feature set...
Sounds good. Check the docs at https://github.com/graphql-dotnet/server?tab=readme-ov-file#authorization-configuration for details on: - configuration - transport-level rules - schema/type/field-level rules - websocket auth - auth schemes - different auth for get vs...
I'm in favor. Perhaps we could release an appendix stating the specification for legacy compatibility. It would be out of the main spec, an optional feature. We could recommend compliance...
> the current version is essentially approved pending the security work Can we simply finish the pending security work and release it as-is without any changes in regards to the...
Agree! Also, in-house/private APIs may have long term benefits from any spec advances by requiring less custom implementations and being able to rely more on well-tested public implementations, thus requiring...
> it would make changing a field from a non-list type to a list type a non-breaking change I hadn't thought of that, but that's potentially an even more important...