You have a lot of great points Peter. Let me come back to you with an article describing a nested implementation and some good practices and how to tackle the N+1 problem.. I'll say this though, you are right, you are moving the problem to somewhere else, from frontend to backend.. As always it's meant to be used in specific cases not to replace REST but coexist. I'll come back with an article in 2-3 weeks, currently on holiday
Thanks for the post! Have you had time to write a follow-up article on this? I am particularly curious about tackling the N+1 problem myself.
Also, if you have any tips about implementing a Relay-compatible GraphQL server in .NET (C# or F#), that would be really helpful!
As always it's meant to be used in specific cases not to replace REST but coexist
Yup - my approach so far has been to provide REST APIs in the .Net portion of our stack, and allow the Swift guys to implement a GraphQL aggregator if they care enough for one.
Unfortunately, our database isn't normalized nearly as much as it should be, so pulling back entire tables hurts massively, and I'm yet to find any nice Linq2Sql or similar approaches that eliminate that as an overhead when implementing GraphQL on the .Net side.
I think this is primarily due to maturity of the toolchains, as from what I've seen, the Swift guys are going through the same overhead - it's just .Net has spent decades perfecting the REST approach to the point where I can mock one up in a comment section from memory. Our Swift guys seem to go through the same overhead regardless of REST or GraphQL at the moment however.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You have a lot of great points Peter. Let me come back to you with an article describing a nested implementation and some good practices and how to tackle the N+1 problem.. I'll say this though, you are right, you are moving the problem to somewhere else, from frontend to backend.. As always it's meant to be used in specific cases not to replace REST but coexist. I'll come back with an article in 2-3 weeks, currently on holiday
Thanks for the post! Have you had time to write a follow-up article on this? I am particularly curious about tackling the N+1 problem myself.
Also, if you have any tips about implementing a Relay-compatible GraphQL server in .NET (C# or F#), that would be really helpful!
Yup - my approach so far has been to provide REST APIs in the .Net portion of our stack, and allow the Swift guys to implement a GraphQL aggregator if they care enough for one.
Unfortunately, our database isn't normalized nearly as much as it should be, so pulling back entire tables hurts massively, and I'm yet to find any nice Linq2Sql or similar approaches that eliminate that as an overhead when implementing GraphQL on the .Net side.
I think this is primarily due to maturity of the toolchains, as from what I've seen, the Swift guys are going through the same overhead - it's just .Net has spent decades perfecting the REST approach to the point where I can mock one up in a comment section from memory. Our Swift guys seem to go through the same overhead regardless of REST or GraphQL at the moment however.