But it won't be more reliable use in such applications where we want full controller over what details we are providing... For that Rest will be more suitable.

Your explanation is lot better than this IBM guy

Your explanation is much clearer. Thanks

You forgot about costs graphql is expensive to maintain

if you want to REST api same as GraphQL fetch, you have to create a request with data sql in it. ofcourse, it is not safe but you have to filter the sql. drop, delete, update, insert and etc are not allowed.. only select will allowed.

Until you start with existing rest tooling and enormous support in almost every stack, graphql seems like a dream that doesn't come true when it comes to practical solutions. For starters, FB, where it originated, took more than 5 years to transition and few more until it became mature. But then they always have mutating endpoints effectively against fixed schema philosophy. No framework is perfect!

And he is also a beer expert!

I thought I recognised him 😂

Oh man, hello Cambodia friend from Vietnam, your video you sing Final Masquerade is awesome 👍

I had that implementation in my project. We have created wrapper over rest using graphql

Honestly I doubt that this makes sense. To hide REST under GraphQL leaves all possible disadvantages of REST in the given solution. GraphQL is not and never was a _replacement_ or _successor_ of REST. As said, the GraphQL layer would have to deal with possible disadvantages and could not play its strengths. If used as integration layer over some/many REST APIs, over-fetching issues and lack of filtering and other stuff cannot be vanished and therefore remain. What you want to "wrap" is your data model or data source - even though I wouldn't exactly call it "wrap", but "access".

When using AWS as a backend, Appsync would be the API service for graphQL.

Exactly this is what Im thinking of right now. Im just getting started with graphql, created a REST api server and implemented a layer of graphql on top of it. I think so, there may be some more features or so associated with graphql🤔🤷🏻, as companies like netflix, facebook, etc., are using graphql. Just I wish somebody could get me up with the leverage of using graphql

No, they just mirror the video

I've worked at companies that do this and I got paid *A LOT* to optimize their application. "Oh, you're retrieving 50+ columns because the UI needs these 4 columns? STOP DOING THAT!" I learned quite a bit from that company and their methodology, though, so that was great skill builder for me. Now that I'm elsewhere and we're planning on integrating multiple business units into an uniform GUI, I'm definitely interested in pursuing this. There were countless times where over 1 gig of data was being retrieved just to pare it down to maybe 20 or 30 MB for the result set on the UI.

GraphQL uses websockets under the hood for subscriptions. GraphQL dis not invent anything, websockets is just http

WebSocketUpgrade

camera -> glass -> presenter Presenter writes normally on the glass, so on the footage the writing is mirrored. Then during editing, we can mirror the footage again so the viewers can read it

Probably not exactly. It tried to cope with some shortcomings of REST, while also seeming to sacrifice some REST foundations, right?

My guess would be scalability and also the fact, that you can get data from multiple places and merge them together. Rest would require multiple requests. He does mention this

It solve the peoblem of overfetching, if you fetch from a movies api for example you don't need the production company the date of release, you need just the name and actors.

@@chaybislam This can be solved by rest api too

These are just two different ways of querying and updating information, neither gives you more functionality. As with any form of schema or framework they make certain things easier and other things harder. In graphql for example it is extremely difficult to debug and optimise the performance of a complex query, whereas in REST it is harder to do complex queries like optionally fetching related data, batching requests or providing computed properties. You need to decide what you care about. I HIGHLY value simplicity and in my opinion anything that adds another interface to communication needs to have enormous benefits to compensate. Personally I am not a fan of graphql because I dont think it has many benefits and most of the problems it solves (like overfetching) were not high on my list of concerns to start with.

the "multiple requests" comment is nonsense. you can manually make an endpoint that combines data across multiple sources and still call it restful. graphql is for frontend engineers who want to pretend that they are fullstack engineers.

That seems to be an under-complex view of the problem. If one's working with rather simpler models and clients where over-fetching is not a problem for whatever reasons, REST maybe fine. However, if it comes to complex data structures and manifold requests over the schema, GraphQL comes to rescue. Besides traversing the schema, already simple operations like client side sorting, filtering, paging are not natively supported and honestly pain in the ass problems with REST to solve, while leading "out of" REST. HATEOAS can give hints for traversing a schema, but the other problems remain and HATEOAS not only increases client comfort, but also the amount of response data. Btw, never was the question to rate one over the other as they serve (almost completely) different purposes and goals.

See ibm.biz/write-backwards

See ibm.biz/write-backwards

Timo responded in another comment, the video is likely mirrored before uploading so everything looks right to us.

it depends. I m trying the hasura graphql to get rid of maintenance actually and simplify(almost get rid of) the cross department communication. We have a need in general data access api for the gold layer of deltalake architecture. And sql endpoints to databricks are crazy money, writing apis is hell (cos no reqs, no people, no time) and its almost perfect If money for non direct costs (infra maintenance, dev efforts, lack adequate product and fe reqs, tons of stakeholders that do not want to talk, rapid dev needed) are much larger then cost of pure scaling of solution - it may be a wise option I liked the hasura concept, because you have cruds autogenerated, you have explain for each request and things like filters, sorts and pagination are done ad hoc. Thing that were previously weeks of wait are now minutes. If you have smth more complex - just write sql and back it up with gql endpoint. You need expose rest instead of gql - 2 click here you go. New db - here you have an api in a min. Need smth fully customized - fApp and proxy through hasura. No crazy estimates for things that can be done in a minutes. We got quite a nice result with hasura+cosmos for pgsql(hyperscale azure or citus). But price is not for startups.

Amen to that! With restful ODATA, you can pretty much get the data you want filtered the way you want.

Latest iteration of the schema spec do include interfaces that you can also apply in the federation mode, thus the repetition can be contained IF the backend under is composable.

agree, graphql also just ignore anything about REST (PUT, POST, GET) in favour of just using POST, and it's only return http status code 200

@@simonsimonian8306 ODATA isn't REST anymore.

GraphQL will only require more effort to debugging if the application is highly complex or the team is not experienced in the technology. What do you mean by it expending more resources in the server? 🤔 And what you mean about the clients sitting idle? How’s that different from REST? Imo you should use graphQL when you have complex queries and/or multiple data sources, it’s also good for mobile applications where bandwidth is a concern. You do lose on HTTP cache tho, so you need to test if the bandwidth gain is worth it or not.

@Niresh Maharaj: As explained earlier, this explanation is completely wrong and expresses a fundamental lack of understanding, what GraphQL is, what the conceptional differences to REST are and where and when either of these have their advantages. Never was either of these meant as replacement or successor of the other and therefore treating them a just interchangeable, as the comment implies, is plain wrong. Btw, also the assumptions drawn considering "efficiency" in different aspects are "pseudo-clever", seem overly generalized, weird and misleading. - Think yourself: Facebook only introduced and still uses GraphQL to heat up their server farms?! Others do so too... Sorry to be so straight, but the comment is in almost ever aspect nonsense!

See ibm.biz/write-backwards

I agree.

Thanks! But search on "lightboard videos" for more.

That's why it is only used in mobile environments, he!? :head_bang: