Viewing profile — tangkikodo

different tool for different aspect. using OPENAPI, rpc, GQL types in client, etc to share typing (schema) information between client/server resolver/dataloader in GQL, eager join …

I would like to recommend pydantic-resolve, it can enjoy benefits from botn rest/rpc and gql. the triky part of gql is we need to build a Query system for all business requirement …

We just need a tool to let every REST/rpc endpoint gain the ability of 'resolve' and 'dataloader' from GQL, to provide rich detailed view data to frontend (in just single call) So …

Things will be very interesting if we treat each single rest endpoint as a GQL query. With static typing definition and OPENAPI, we can declare the response type first, and then bo…

this sounds pretty like what dataloader do used in graphql.

1. use declaretive way to define schema of view data like graphql, easy to maintain and develop 2. use main query and loader query to break down complex queries, and better reuse 3…

not really, it only traversal (with resolving descendants at the same time) once from top to bottom and then back.

my fault lol. here is a step by step tutorial, building various kinds of views data you need, and keep service layer simple and clear at the same time. https://github.com/allmonday…

inspired by graphql (define schema in declaretive way) however gql itself only walks from top to bottom, which lack the ability to change data after it's descdenants are resolved. …

A powerful tool to build nested view data. based on pydantic, pydantic-resolve uses declaretive way to define and resolve (fetch) data from top to bottom and provides post-process …

The current popular approach is to use GraphQL, but the introduction cost of the entire solution is not low for the backend. Additionally, the frontend needs to manually write quer…