Really good information and rarely perfect presentation! Explained the usually missing links for a novice with such an ease creating a full picture of why&how. Really grateful! Thank you! :)
Thank you so much, Mr. Robert Zhu! While this is not exactly a full-fledged tutorial on writing GraphQL queries, it is a good overview of it, and due to his articulate words, I feel as if a book has been lifted off of my head!
Great presentation. I just started learning graphQL and I'm a lead full stack developer so that last part where he explains the design payoff line when using GraphQL is very helpful because I want to delivery visible progress as soon as possible.
at 07:40 I was just about to say, well, instead of calling 20 REST calls, why not make a custom API that returns all the characters in all films for the input character provided in the path variable? I then realized the power of GraphQL: It universalizes the above like an engine, without having to write custom APIs for custom requirements.
This lecture while good, is misleading. The only reason why the REST example was actually slower was because the GraphQL one was being served by in-memory json files! The performance you get is purely from how well you define your resolvers.
yes in the playground if you leave out a field like title for a book it will auto add it so I recommend trying your queries there before using them in code
any decent application makes a call to like 50 endpoints. graphql cleans this up. never mind the 100 requests... the 100 endpoints is objectively annoying nd tedious
Authorisation explanation was very weird ?! Made no sense. Practically you said we are not doing in GraphQL (API level) which is the source of truth for data of your product but instead we are moving it in BL (business logic) because we are trying to avoid duplicating the code for checking whether or not that resource/node is accessible. Okay, by saying business logic, is he referring to front-end or back-end layer ? We can have BL in both layers. - If we are doing at front-end layer as I'm kinda inclined to believe he was suggesting then his point is not valid, we will also have to duplicate business logic in each app that fetches the data using the GraphQL API. - If we are doing at GraphQL API layer then that would avoid duplicating the code and it would solve our problem. It would mean that the API would be sufficient to check whether or not a user is authorised to access that resource/graph data. Regarding how it should be accomplished well that should be another story on which we did not get the answer.
i get how popular typescript is but im so fucking sick of seeing tutorials nd talk shows with typescript everywhere.... some of us don't know typescript yet.
This is possibly the most well spoken and clear explanation/ of GraphQL I have ever heard.
Very well done Mr. Zhu !
i really love it too
great talk and demo!
Totally agree 👍
Really good information and rarely perfect presentation! Explained the usually missing links for a novice with such an ease creating a full picture of why&how. Really grateful! Thank you! :)
Thank you so much, Mr. Robert Zhu! While this is not exactly a full-fledged tutorial on writing GraphQL queries, it is a good overview of it, and due to his articulate words, I feel as if a book has been lifted off of my head!
Great presentation. I just started learning graphQL and I'm a lead full stack developer so that last part where he explains the design payoff line when using GraphQL is very helpful because I want to delivery visible progress as soon as possible.
Brilliant presentation. The presenter covered so much material in so little time without compromising clarity.
Hands down one of the best explanation videos of any technology I have come across!
at 07:40 I was just about to say, well, instead of calling 20 REST calls, why not make a custom API that returns all the characters in all films for the input character provided in the path variable?
I then realized the power of GraphQL: It universalizes the above like an engine, without having to write custom APIs for custom requirements.
Oh there was an audience! I only realized when they clapped. This was probably the most interesting thing I've actually seen on GraphQL.
Great talk with concise explanation. Well, I enjoyed watching and understood the big picture of GraphQL. Thank you very much.
Awesome job! I can't believe how dead the audience is...
it's a presentation not a Metallica concert
Excellent Presentation, Good first step to start with GraphQL. Very Profesional your comparison about Rest vs GraphQL.
Thank you very much !
Wonderful presentation.
Loved the talk. Thank you.
Perfect GraphQL starter 👌
Perfect presentation!
This lecture while good, is misleading. The only reason why the REST example was actually slower was because the GraphQL one was being served by in-memory json files! The performance you get is purely from how well you define your resolvers.
That's a good point. Ignoring the times quoted, it's still just one network call.
Great presentation. Though the code was not very legible when viewed on a laptop.
really good presentation, very helpful to get the basic concept... gg!
Thank you.
Is the code available for Graph QL server on Github for this lecture?
39 minutes of knowledge and BOOM there goes the plug... "use our managed service, you dont need to know anything, we ll do it for you" .
great explanantion !! cleared y doubts thnx
Does Graphql replace or supercede Thrift? seems FB made both
Rob says the query must terminate with scalar fields but what if I want to fetch all fields in an entity? Do I need to specify all fields explicitly?
yes in the playground if you leave out a field like title for a book it will auto add it so I recommend trying your queries there before using them in code
Very well done. Thank you.
Thank you robert !
Great talk, thanks!
Got me interested in graphQl
Why would you write a rest api that grabs 100s of resources individually? why not use get query url to grab 100 in 1 request?
it never ends up that simple man. you know that
any decent application makes a call to like 50 endpoints. graphql cleans this up. never mind the 100 requests... the 100 endpoints is objectively annoying nd tedious
Great talk
Awesome !
underrated
Authorisation explanation was very weird ?! Made no sense. Practically you said we are not doing in GraphQL (API level) which is the source of truth for data of your product but instead we are moving it in BL (business logic) because we are trying to avoid duplicating the code for checking whether or not that resource/node is accessible. Okay, by saying business logic, is he referring to front-end or back-end layer ? We can have BL in both layers.
- If we are doing at front-end layer as I'm kinda inclined to believe he was suggesting then his point is not valid, we will also have to duplicate business logic in each app that fetches the data using the GraphQL API.
- If we are doing at GraphQL API layer then that would avoid duplicating the code and it would solve our problem. It would mean that the API would be sufficient to check whether or not a user is authorised to access that resource/graph data. Regarding how it should be accomplished well that should be another story on which we did not get the answer.
i get how popular typescript is but im so fucking sick of seeing tutorials nd talk shows with typescript everywhere.... some of us don't know typescript yet.