I understand that GraphQL is less chatty with the server because we can update a resource without first sending a get request but what about optimistic concurrency? shouldn't we get the token before applying changes to the resource?
Could anyone provide link to any working examples subscribing to GraphQL or AppSync using Xamarin? This video is great but I wish it covered subscriptions? A Xamarin video on how to work with AppSync (subscriptions and changes resolutions) would be fantastic.
Why not first educate the concept of GraphQL on the server side: a) Do we create a stand alone GraphQL server as a Class library or do we put it inside a Web API? b) Do we interact with DB through existing APIs or do we talk directly to DB via EF? If MSFT is offering a session on GraphQL, make it a full session than just a 13 min appetizer. I think Jeremy can find a more mature and experienced person at MSFT to go deep into GraphQL.
Just because it doesn't satisfy your desire for a deep dive doesn't mean it's not valuable to some. I see you're looking at OData vs GraphQL at the moment. They solve some similar problems but GraphQL has definitely gained way more traction and is the way fwd IMO, esp with JS clients. Be prepared for a learning curve though; it can get very complicated when it comes to perf, security, and so on. I'd take a good look at HotChocolate's docs (which are great) to start diving deeper, and even the GraphQL spec. Just remember GraphQL as a concept it just a layer between requests and resolvers, it's up to you how you hook that to your internals, like a DB/EF, though certainly some fx try to make that easier, like HotChocolate's filtering, paging and sorting stuff to IQueryable. FYI, certainly you can have the graph implementation as a class library and then expose that out via a web API, console app, etc. I'm looking to do that on my team so we can execute the class library as a console app to get schema info out for our front-end team who use Relay and the Relay compiler, without having to run the web app that we use to expose it on Prod. Good luck!
In terms of existing APIs vs EF, well, it depends! If you have existing systems, you can certainly jam GraphQL in between them and clients and gain a lot of the benefits of graphql. It can be a great aggregator of data and relations. On the flip side, in graph execution, your resolvers can get a list of just what the client wants, so although graph will remove stuff you've over-fetched as it returns the result, there's also opportunity to optimise the data retrieval, so just wrapping old services may mean you're over-fetching to your DB etc. So it really depends on what your dealing with. You can do a mix even of other APIs, 3rd party APIs, code-in-project.
@@BenMcCallums Nice name BTW... I was lucky I had another browser tab open that it grabbed ALL your both posts and I was able to read them fully. :-) I think you should have left your posts uncut as they were the real value here. Everything you said in both posts, I understood and agreed. This was the type of discussion & information I was expecting from these sessions, than just some intern trying to sell me GraphQL. I'm building a brand new application, that is made up of Blazor Server for system Admin, Blazor client for public facing consumers, Web API that both use to get/set data. The Web API will use three types of repositories, one uses EF for dynamic operations & queries and the other uses Dapper mainly for large batch processing using Store Procs. And the third one will use gRPC to talk to Hangfire Server to perform background Processing. As of now, the only part that I'm not happy is between Blazor Client and Web API's performance. So we could implement OData or GraphQL to solve the performance on the client side. But the biggest vacuum in my head is to see what is the best way to put GraphQL in place in server side. Just like you said, it's another layer between request & response. Dapper & SP, do a much better job on the server side to get/set data than EF, if you have good SPs written. Perhaps, I could put GraphQL right above Dapper repository and forget about EF and creating a bunch of APIs on the server side. I want the server side to be as efficient in data flow as possible and not to be the bottleneck of the application. I truly appreciate your reply Ben, as it confirmed I'm on the right path. Thanks!
Cool, Sounds like you're making progress! We've had success using SqlKata for our querying, essentially to unlock cursor-based paging for Relay connections which is quite tricky, but you may not need that. We're on graphql-dotnet but I think HotChocolate could be a better choice these days. But yea we use SqlKata for querying to grab the page of entity IDs we need, then make an EF Core query for the full entities by IDs, passing through the fields requested by the client into the magic of AutoMapper's ProjectTo extension to have it build out an optimised sql query. We re-use these data resolvers even for queries for a single record as you'll see that the dataloader pattern is crucial for perf. This part certainly isn't easy though. I explored the GraphQL.Dapper project a while back, maybe if you're into Dapper it could provide inspiration. In the end there's no one size fits all here. All the best!
Why not use a Mac? The fact that someone has to comment "a Mac?? whaaaa???" in every video is exactly why they're using a Mac. .NET isn't just for windows anymore and they want everyone to be aware
This video didn't teach me how to create a GraphQL backend. You already had the backend setup and just lightly explained some things.
It’s a 10min video - what did you expect.
I would like to see a sample showing how to limit a user from a particular field.
I understand that GraphQL is less chatty with the server because we can update a resource without first sending a get request but what about optimistic concurrency? shouldn't we get the token before applying changes to the resource?
Could anyone provide link to any working examples subscribing to GraphQL or AppSync using Xamarin? This video is great but I wish it covered subscriptions? A Xamarin video on how to work with AppSync (subscriptions and changes resolutions) would be fantastic.
Hmm why dotnet graphql when a few months ago there was a demo with hotchocolate graphql for c#?
1:35
Arghhhh! Light theme! 😂
I'm a beginner, and I watch it with no hope.....
Very interesting. Ideal to query third parties API, but it seems difficult to use in web application for API CRUD operations.
The introduction video was great, but this video has a misleading title, it should be just part of the introduction.
Why not first educate the concept of GraphQL on the server side:
a) Do we create a stand alone GraphQL server as a Class library or do we put it inside a Web API?
b) Do we interact with DB through existing APIs or do we talk directly to DB via EF?
If MSFT is offering a session on GraphQL, make it a full session than just a 13 min appetizer. I think Jeremy can find a more mature and experienced person at MSFT to go deep into GraphQL.
Just because it doesn't satisfy your desire for a deep dive doesn't mean it's not valuable to some.
I see you're looking at OData vs GraphQL at the moment. They solve some similar problems but GraphQL has definitely gained way more traction and is the way fwd IMO, esp with JS clients.
Be prepared for a learning curve though; it can get very complicated when it comes to perf, security, and so on.
I'd take a good look at HotChocolate's docs (which are great) to start diving deeper, and even the GraphQL spec. Just remember GraphQL as a concept it just a layer between requests and resolvers, it's up to you how you hook that to your internals, like a DB/EF, though certainly some fx try to make that easier, like HotChocolate's filtering, paging and sorting stuff to IQueryable.
FYI, certainly you can have the graph implementation as a class library and then expose that out via a web API, console app, etc. I'm looking to do that on my team so we can execute the class library as a console app to get schema info out for our front-end team who use Relay and the Relay compiler, without having to run the web app that we use to expose it on Prod.
Good luck!
In terms of existing APIs vs EF, well, it depends!
If you have existing systems, you can certainly jam GraphQL in between them and clients and gain a lot of the benefits of graphql. It can be a great aggregator of data and relations.
On the flip side, in graph execution, your resolvers can get a list of just what the client wants, so although graph will remove stuff you've over-fetched as it returns the result, there's also opportunity to optimise the data retrieval, so just wrapping old services may mean you're over-fetching to your DB etc.
So it really depends on what your dealing with. You can do a mix even of other APIs, 3rd party APIs, code-in-project.
@@BenMcCallums
Nice name BTW...
I was lucky I had another browser tab open that it grabbed ALL your both posts and I was able to read them fully. :-) I think you should have left your posts uncut as they were the real value here.
Everything you said in both posts, I understood and agreed. This was the type of discussion & information I was expecting from these sessions, than just some intern trying to sell me GraphQL.
I'm building a brand new application, that is made up of Blazor Server for system Admin, Blazor client for public facing consumers, Web API that both use to get/set data. The Web API will use three types of repositories, one uses EF for dynamic operations & queries and the other uses Dapper mainly for large batch processing using Store Procs. And the third one will use gRPC to talk to Hangfire Server to perform background Processing.
As of now, the only part that I'm not happy is between Blazor Client and Web API's performance. So we could implement OData or GraphQL to solve the performance on the client side. But the biggest vacuum in my head is to see what is the best way to put GraphQL in place in server side. Just like you said, it's another layer between request & response.
Dapper & SP, do a much better job on the server side to get/set data than EF, if you have good SPs written. Perhaps, I could put GraphQL right above Dapper repository and forget about EF and creating a bunch of APIs on the server side. I want the server side to be as efficient in data flow as possible and not to be the bottleneck of the application.
I truly appreciate your reply Ben, as it confirmed I'm on the right path.
Thanks!
I believe they are going to get deeper so stay tuned. Im willing to chat at chaz.m.gatian@gmail.com for any questions
Cool, Sounds like you're making progress!
We've had success using SqlKata for our querying, essentially to unlock cursor-based paging for Relay connections which is quite tricky, but you may not need that. We're on graphql-dotnet but I think HotChocolate could be a better choice these days.
But yea we use SqlKata for querying to grab the page of entity IDs we need, then make an EF Core query for the full entities by IDs, passing through the fields requested by the client into the magic of AutoMapper's ProjectTo extension to have it build out an optimised sql query. We re-use these data resolvers even for queries for a single record as you'll see that the dataloader pattern is crucial for perf.
This part certainly isn't easy though. I explored the GraphQL.Dapper project a while back, maybe if you're into Dapper it could provide inspiration.
In the end there's no one size fits all here.
All the best!
Why the smilingly-face guy was using a Mac? Good content though
Why not use a Mac? The fact that someone has to comment "a Mac?? whaaaa???" in every video is exactly why they're using a Mac.
.NET isn't just for windows anymore and they want everyone to be aware
Anyone here manage to get (GraphQL Net) works with NET CORE 3.1?? hmmm...
Help me.
Thank you
Great 👍🏼 thanks for sharing.
Great