15 minutes ago, Pichkaari said:

How do yoy refactor the existing resources man? I still need to watch the tutorials but just curious..

Lets say I have an RESTful /employee resource and it has 3 end points.. /info ../payroll ../timesheets .. In current world UI/client makes 3 diff requests to fetch employee data.

But in GraphQL world, how do you refactor this pattern to add GraphQL layer on top of this? Client directly calls just /employee resource with some request object and GraphQL consolidates the  responses from all three endpoints and return as requested?

@Pichkaari  yeah, may be if you go deeper into the implementation, u will get the idea how that works.

Graphql ki backbone is the schema definition and resolvers.

so in the above example,

UI will make a query to fetch data from Graphql API.

Graphql APi will check the schema, and invoke the resolvers needed to fetch that data and stitch it and respond.

suppose neeku  info response lo only certain data kavali, payroll mottam kavali and timesheets lo only latest kavali anuko...

u cannot seggregate that even if u make individual calls, but Graphql can do that for u...

 

4 minutes ago, Pichkaari said:

Why? Is it because, it has to pull the information from the data sources for all 3 end points at once? 

I'm concerned about this approach, obviously I have to dig in more kaani.. lets say if we have a greedy client and it wants to fetch data from 7 endpoints at once, dont you think this results in a timeout if one of the endpoint takes more time to fetch data from its data source?  Sorry I'm just thinking through the edge cases.

I am not sure but i think because we will try not to re fetch data when data is still fresh.  I could be wrong though.  I have a feeling it depends on the requirement. 

26 minutes ago, Pichkaari said:

@Spartan Why caching is important here? what are the bottlenecks if we don't use caching particularly for GraphQL..

 I mean caching depends on our use case kada, but why GraphQL ki caching mandatory?

caching is mandatory kaadu...but if u want to enable it, then caching plays a critical role in your API performance.

memu caching resolvers ki delegate chesam....rather than using that on the Graphql Endpoint.

it is working fine so far, response time is below 1s .

currently 7 resolvers unnai , out of which 2 are external and 2 are ours, and 3 vere team vi....

need to fetch data from all those sources and stich accordingly for UI and other stuff.

3 minutes ago, Pichkaari said:

Why? Is it because, it has to pull the information from the data sources for all 3 end points at once? 

I'm concerned about this approach, obviously I have to dig in more kaani.. lets say if we have a greedy client and it wants to fetch data from 7 endpoints at once, dont you think this results in a timeout if one of the endpoint takes more time to fetch data from its data source?  Sorry I'm just thinking through the edge cases.

That’s why as @Spartansaid you should first research if GraphQL is really needed for your use case. In my opinion you should not just add GraphQL on top of an existing API, the design should cover end to end from client request to database table columns and I don’t think you should include heavy payloads which takes long time to process a request. 

Caching is always a good thing to implement in general not just for GraphQL. I believe it is much more need in GraphQL approach. 

below is sample application using Appsync (AWS graphql service)

https://aws.amazon.com/blogs/architecture/things-to-consider-when-you-build-a-graphql-api-with-aws-appsync/

 a example lo, u can see there are 6 sources, from which data is fetched and stitched using resolvers and schema...

in case neeku http endpoint nunchi koncham data and dynamodb nunchi koncham data kavali ante,

only those 2 resolvers will be invoked, migitavatini touch cheyavu resolvers.

 

Just now, JAMBALHOT_RAJA said:

That’s why as @Spartansaid you should first research if GraphQL is really needed for your use case. In my opinion you should not just add GraphQL on top of an existing API, the design should cover end to end from client request to database table columns and I don’t think you should include heavy payloads which takes long time to process a request. 

Caching is always a good thing to implement in general not just for GraphQL. I believe it is much more need in GraphQL approach. 

+1, already unna rest api meeda graphql implement chesaru ante..

markulu kotteddam ani sketch tappa...techincal gain emi undadu ani anukovali..blind ga.

because when ur REST APi and Graphql give u same repsonse, why do u want to spend time on adding Graphql layer.

2 hours ago, Spartan said:

backend GraphQL API design use chestunnadu...

currently working on similar project, for our company.

Facebook came up with this and heavily use in their API architecture....open source chesadu.

cc: @k2s and other engineers.

 

Nice

Just now, Spartan said:

+1, already unna rest api meeda graphql implement chesaru ante..

markulu kotteddam ani sketch tappa...techincal gain emi undadu ani anukovali..blind ga.

because when ur REST APi and Graphql give u same repsonse, why do u want to spend time on adding Graphql layer.

Managers are not technical konta mandi chamchas edi chepte organization lo tech initivates antu implement chestaru ala chesevallaki em cheptam. Vellu director ki poyi showoff chestaru we got this new thing into org ani when it is waste of money and man hours. 

It is not automatic right and we have to create which makes all in one call right?

Bs we have to create denornalized table and get all in one call. They called new name as graphql all fking bs

8 minutes ago, naughty15 said:

It is not automatic right and we have to create which makes all in one call right?

 

2 minutes ago, naughty15 said:

Bs we have to create denornalized table and get all in one call. They called new name as graphql all fking bs

anthy bro , antha BS

5 hours ago, ShruteSastry said:

anyone tried, its surprising how much presence i have on the internet.

Miru inka cheppaledu how to use it ani

24 minutes ago, naughty15 said:

It is not automatic right and we have to create which makes all in one call right?

 

18 minutes ago, naughty15 said:

Bs we have to create denornalized table and get all in one call. They called new name as graphql all fking bs

 

15 minutes ago, sri_india said:

 

anthy bro , antha BS

Anthey antaara.. ok.. I'm taking this GraphQL off my 2021 bucket list.... 

Just now, r2d2 said:

 

 

Anthey antaara.. ok.. I'm taking this GraphQL off my 2021 bucket list.... 

 large companies going to adopt this more and more in near future .... it is a must if you are web developer

1 minute ago, sri_india said:

 large companies going to adopt this more and more in near future.... it is a must if you are web developer

 I'm the, if ain't broke don't fix it guy.. but it doesn't hurt digging and knowing more about it..