We installed graphql on our c# webapi and holy crap, it's such an improvement over using rest for our angular development. We use it mainly for querying data and still have our rest apis living alongside it for put, post, patch and delete operations. Having the ability to declare which properties to return in the payload without having to update the endpoints is the killer feature for me. This minimized the response payloads significantly. We also avoid having to run additional deployments on the backend
Well explained! thanks!! This video helped me build my first hot chocolate graphql service in no time (1 -> 2 hours). Looking forward to build my first graphql client
I am going to follow this presentation through to see what benefits graphql has, because I restrict columns in rest and have options to show embedded objects and collections, especially if you obtain data through a post, rather than a get and define your filters and columns in the body. I am certainly not calling one endpoint for a user and then calling another for other related data, when that data can already be embedded. Or is it just me with this?
There is a lot of hand waving here when he talks about connecting to RDBMS and/or existing REST services. Making random queries perform well is not trivial and involves a lot of design work. I'm not disparaging graphql but someone taking this on should dig deeper into how they will retrieve data efficiently.
I agree. I'm not experienced in graphQL, but watching this makes me think you would just build a huge database query. You'd be pulling all columns for all related tables even if I only wanted two columns from one table. Yes, there's less data being sent from the web host to the client, but there's more data sent from DB to the web host. The database gets git harder than needed too. I was expecting there to be work conditionally grabbing what was requested. Instead it's just a library that filtered out unwanted properties before sending a response back to the client. I'd only want to do this on some very light queries. It's kind of cool, but it's not as cool everyone makes it sound.
GraphQL does not use Rest, "You don't know what you''re talking about.." - only a reflection on your comment. That's like saying Soap is not dead because Rest uses Soap. They all use the HTTP Protocol that has a method POST, or GET, or Put etc.. HTTP protocol uses TCP/IP protocol, and GraphQL, Rest, Soap are protocols themselves on the HTTP protocol.
@@o0Zuel0o Kind of funny, guess for him there was no "edit" function. Haven't watched everything cause I was familiar with GraphQL but this really creates false definitions and misconceptions in the community - so I'm glad you pointed out that mistake.
We installed graphql on our c# webapi and holy crap, it's such an improvement over using rest for our angular development. We use it mainly for querying data and still have our rest apis living alongside it for put, post, patch and delete operations.
Having the ability to declare which properties to return in the payload without having to update the endpoints is the killer feature for me. This minimized the response payloads significantly. We also avoid having to run additional deployments on the backend
Well explained! thanks!! This video helped me build my first hot chocolate graphql service in no time (1 -> 2 hours). Looking forward to build my first graphql client
Tried this today and the long loading screen for the localhost/graphql was just a bug in the presentation, it loads up in a second by me.
I am going to follow this presentation through to see what benefits graphql has, because I restrict columns in rest and have options to show embedded objects and collections, especially if you obtain data through a post, rather than a get and define your filters and columns in the body. I am certainly not calling one endpoint for a user and then calling another for other related data, when that data can already be embedded. Or is it just me with this?
Please provide the link for slides in the description
There is a lot of hand waving here when he talks about connecting to RDBMS and/or existing REST services. Making random queries perform well is not trivial and involves a lot of design work. I'm not disparaging graphql but someone taking this on should dig deeper into how they will retrieve data efficiently.
I agree.
I'm not experienced in graphQL, but watching this makes me think you would just build a huge database query. You'd be pulling all columns for all related tables even if I only wanted two columns from one table. Yes, there's less data being sent from the web host to the client, but there's more data sent from DB to the web host. The database gets git harder than needed too.
I was expecting there to be work conditionally grabbing what was requested. Instead it's just a library that filtered out unwanted properties before sending a response back to the client.
I'd only want to do this on some very light queries. It's kind of cool, but it's not as cool everyone makes it sound.
GraphQL does not use Rest, "You don't know what you''re talking about.." - only a reflection on your comment. That's like saying Soap is not dead because Rest uses Soap. They all use the HTTP Protocol that has a method POST, or GET, or Put etc.. HTTP protocol uses TCP/IP protocol, and GraphQL, Rest, Soap are protocols themselves on the HTTP protocol.
I think you meant to say "HTTP protocol", not HTML.
@@diegoronkkomaki6858 you are totally right, and I am a total idiot. lol
@@o0Zuel0o Kind of funny, guess for him there was no "edit" function. Haven't watched everything cause I was familiar with GraphQL but this really creates false definitions and misconceptions in the community - so I'm glad you pointed out that mistake.
Rest and graphql are not protocols
POST is HTTP thing not REST "thing". LOL. Good content otherwise.
I almost shut it down when he said that but the rest of the presentation is decent
ODATA is pretty nice and already does these things, doesn't it?
OData is more REST with query ability. GraphQL is one Endpoint and query whatever you want.