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 in ORM is to handler internal data composition

presenter layer should not care about data composition, so that writing Query at presenter is an anti-pattern.

presenter should fetch schema info & data passively, like what https://github.com/hey-api/openapi-ts did, the job of implementation belongs to backend.

In fact what rest/rpc really need is the resolver and dataloader, to help backend easily extend or composing data together, and immediately transferring the schema & data to clients.

pydantic-resolve is the python binding for this idea.

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 be issued by client.

this is anti-pattern because presenter layer should not care about how data is composed.

It would be much easy if we treat each rest/rpc endpoint as a GQL entry, use resolver and dataloader to quickly & easily build complicated view data, everything is still under the control of backend.

here is a demo. https://github.com/allmonday/pydantic-resolve/blob/master/ex...

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 stack from REST/rpc 2. we gain the ability of quick composition from resolver / dataloader 3. with iteration, we can replace/ refactor endpoint without breaking anything.

for fastapi user, the lib 'pydantic-resolve' can help.

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 construct the response we want.

Using resolver and dataloader can iterate as fast as GQL, and after the requirement is stable, we can refactor each single endpoint on demand.

for FastAPI user, pydantic-resolve is developed for this purpose.

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. provide various of tools to precisely construct view data, no overhead

4. changing view data has never been so easy

5. with OpenAPI and typescript, developers can use the type definitions at client side

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/composition-oriented-developmen...

code is ready, documents of english version is still wip.

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't need to introduce a big framework to build a nested view data, all you need to do is just:

- simpilify your query of root data (no complex sql any more, then you can reuse it)

- define the related data you wanted, and then let resolver to fetch it.

that's all~

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 & calculation)

it also provides visibility control over all fields.

concept diagram: https://raw.githubusercontent.com/allmonday/pydantic-resolve...

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 directly using RPC-like requests.

The combination-oriented development model is to solve this problem. By using pydantic2-resolve , the router layer is responsible for building the schema to encapsulate changes, thereby avoiding changes to service and client.