FSharp.Data.GraphQL
FSharp.Data.GraphQL copied to clipboard
fsprojects
Comparison with GraphQL.NET
Currently checking out if GraphQL is a good fit for us. Have no prior experience.
Using F#, so of course FSharp.Data.GraphQL gets bonus points for being focused on F#. But I also see that GraphQL.NET seems more popular (not surprising since it's C#), more feature-rich (e.g. has built-in support for sandboxes like GraphiQL), in some ways more convenient (supports other useful scalar types out of the box), and due to its popularity generally seems like a "safer" choice.
Do you (or anyone else) have any experience with both FSharp.Data.GraphQL and GraphQL.NET and can point to some important differences?
One thing I'm concerned about is performance. If FSharp.Data.GraphQL uses async for all fields etc. internally, performance could be significantly worse. (I had that problem with Felicity, and got an order-of-magnitude improvement after i changed to Hopac internally).
@cmeeren I am not answering the exact question but I would add HotChocolate to the equation, especially if performance is important. It's a very powerful tool with both server and client support, plus browser IDE (Banana Cake Pop, comes out of the box with server). Feature rich, actively developed and supported.
They are not focused on F# but they start talking about improving support/design for F#, too. Yet development in F# is possible indeed. Some server sample project (not theirs) -- https://github.com/adelarsq/hotchocolate_fsharp_sample
All in all, having evaluated GraphQL.NET and HotChocolate, we went with HotChocolate and we are happy. I personally value FSharp.Data.GraphQL for ad-hoc client scripting, with F# unique data provider features.
Hey guys, I find myself in the same situation now as @cmeeren when he opened his issue. About half a year later, maybe any of you can share any lessons learned so far? I'd love to choose the best option here among the three options HotChocolate/FSharp.Data.GraphQL/graphql-dotnet. Thanks in advance.
As I understand HotChocolate has quite good support and evolved well. However, it is completely object-oriented. So that if you look at the functional approach it is not for you.
Banana Cake Pop should be language agnostic on .NET. But I have not tried yet.
In general, I have a standard project template that I use. I've already incorporated #332 and I created #324. I hope that with @nikhedonia and @mickhansen we will merge that stuff soon and prepare solution templates for ASP.NET Core and Azure Functions that will also contain Banana Cake Pop
They are not focused on F# but they start talking about improving support/design for F#, too. Yet development in F# is possible indeed. Some server sample project (not theirs) -- https://github.com/adelarsq/hotchocolate_fsharp_sample
I've reviewed it but comparing to this implementation it not so good for F# developers.
One thing I'm concerned about is performance. If FSharp.Data.GraphQL uses
asyncfor all fields etc. internally, performance could be significantly worse. (I had that problem with Felicity, and got an order-of-magnitude improvement after i changed to Hopac internally).
I think we need to rethink this approach. At least to use asyncResult
@cmeeren v2 was released with a lot of cool features. The sample includes the use of Banana Cake Pop
Congratulations! Happy to hear it. F# needs a solid GraphQL library.
As for me, I'm now using HotChocolate, which seems sufficiently far ahead of FSharp.Data.GraphQL in terms of functionality and active development that I would rather use that and put up with its friction with F#. YMMV, of course.
The blessing and curse of F# - you get to choose between an FP library with a small community or an OOP library with a large community!
FSharp.Data.GraphQL is better, though 🙂. I chose it over HotChocolate because I was so much faster getting a GraphQL service up and running with it than with HotChocolate. With the latter, I had to go through an extensive documentation which shows how to do X, Y and Z in a hundred different ways with hundred different defaults and this and that... Less (meaning straightforward) is often more.
I can take another look. If FSharp:Data.GraphQL could support SSE (Server-Sent Events), I'd be one step closer to choosing it. And #460 would help, too!
In any case, this API is intended to live for decades, so a big and active community/userbase is a big plus for us. Getting up and running quickly is not a primary concern.