.NET 5.0 about graphql-aspnet HOT 4 CLOSED

.NET 5 support was added with release 0.5.1-beta . All demo projects were updated to target .NET 5 as well.

from graphql-aspnet.

Hi Jason! It hasn't been tested with .NET 5 yet but it is a .NET standard 2.0 library, so in theory it should work, but the devil is in the details as they say.

A note of caution, to yourself and anyone else that may read this, this project is a 1 man crew right now (me) so completion of features, testing etc. is a slow process. If you are looking to use this library it in a production environment in the near term I would caution against it and steer you toward another more tested solution like graphql-dotnet. To my knowledge this library has not been used in any large scale deployments, ever. It also has yet to be put through the testing rigors necessary for a production environment of any volume. All of these things will happen of course but there isn't any realistic timeline that I could responsibly offer if you are working on something serious with your own deadlines.

To your second point, this project and graphql-dotnet are not in any way related and do not work together. They might be able to be loaded side by side into the same application (not something I'd recommend) but they do not talk to each other nor share or use any common data types between them.

Note: Leaving this issue open until a .NET 5 verification can be completed.

from graphql-aspnet.

Sure thing thank you for this info!! I can run some tests to help if need be. I like your structuring unlike graphql-dotnet due to obvious extra class creation (just to handle graphql objects). In my mind the best way of approach is yours (similar to Newtonsoft-Json). Is there any interest in having this project implemented as a feature in graphql-dotnet?

from graphql-aspnet.

I'm always open to collaboration or others that are willing to run any sort of tests, make contributions, fix bugs etc. I love working with other people. If you feel inclined to contribute in any way please do so!

As far as this library being a feature to graphql-dotnet that's a bit of a double edged sword. This library is opinionated in how it approaches type definitions and exposes queries/mutations. It trys to follow the "Microsoft way" that you would setup your controller in any web api or aspnet MVC application and makes a lot of assumptions about your graph types. Reasonable assumptions, but assumptions nonetheless. Even the pipe lining methodology for resolving a graph query very closely aligns to how the aspnet core (and older own) pipelines attempt to build and manage data requests.

graphql-dotnet however is infinitely more flexible and for good reason. It doesn't necessarily subscribe to the opinions and approaches this library enforces, opting more for a "here are the blocks, assemble your own house" approach. Could the paradigms used in this library be applied to graphql-dotnet? Maybe, but I would posit that it would be inappropriate for that library (this is just my opinion of course). Such a setup seems antithetical to how the rest of the library feels or is used by the developer to create an api/application.

This library has a great focus on attempting to translate an engineer's knowledge and conventions used in MVC controllers in aspnet into a graphql api with as little additional ramp up time as possible. graphql-dotnet doesn't subscribe to that restriction and is far more general purpose.

from graphql-aspnet.