tangkikodo

4 ms·

1.
by tangkikodo 2y ago
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 in ORM is to handler internal data composition pre
2.
by tangkikodo 2y ago
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 in single entry, and we can not predict what query will
3.
by tangkikodo 2y ago
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 that: 1. we enjoy the current tech
4.
by tangkikodo 2y ago
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 borrow the concepts of resolver and dataloder to easily constr
5.
by tangkikodo 2y ago
this sounds pretty like what dataloader do used in graphql.
6.
Building your data step by step, everything is under control(allmonday.github.io)
1 points by tangkikodo 3y ago|0 comments
7.
Yet another data construction solution in BFF layer: pydantic-resolve(github.com)
2 points by tangkikodo 3y ago|1 comments
8.
by tangkikodo 3y ago
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. provide various of tools to precisely construct view data,
9.
by tangkikodo 3y ago
not really, it only traversal (with resolving descendants at the same time) once from top to bottom and then back.
10.
by tangkikodo 3y ago
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/composition-oriented-developmen... co
11.
by tangkikodo 3y ago
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. pydantic-resolve is progressive, this means you don&#x2
12.
Pydantic-resolve, a hierarchical solution for data fetching and processing(github.com)
58 points by tangkikodo 3y ago|14 comments
13.
by tangkikodo 3y ago
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 hooks from bottom to top (friendly for aggregation & cal
14.
by tangkikodo 3y ago
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 queries to describe fields, which lacks the smooth experience of
15.
Composition-oriented pattern for API development(github.com)
1 points by tangkikodo 3y ago|1 comments
16.
Pydantic-resolve: a small yet powerful tool to extend your pydantic schema(github.com)
2 points by tangkikodo 3y ago|0 comments