say you have a model with two attributes profile_image_url: str and profile_image: bytes
it's expensive to fetch profile_image since it will involve a http call to profile_image_url. right now, i would resolve this by using the @property decorator
this library offers an alternative method for populating profile_image by explicitly giving the user a hook for when they want to resolve this dependency. they might want to do it before access time, they might want to batch requests to this external profile_image service to reduce roundtrip latency
this pattern has potential to become more powerful if we only have user_id in context initially. we might want to fetch the product_image_url from the database then fetch the actual product_image after. this dependency graph might be simplified/optimized using this tool
the repo provides its own concrete example of this form with batch_person_age_loader
navbaker|2 years ago
thornewolf|2 years ago
it's expensive to fetch profile_image since it will involve a http call to profile_image_url. right now, i would resolve this by using the @property decorator
this library offers an alternative method for populating profile_image by explicitly giving the user a hook for when they want to resolve this dependency. they might want to do it before access time, they might want to batch requests to this external profile_image service to reduce roundtrip latency
this pattern has potential to become more powerful if we only have user_id in context initially. we might want to fetch the product_image_url from the database then fetch the actual product_image after. this dependency graph might be simplified/optimized using this tool
the repo provides its own concrete example of this form with batch_person_age_loader
yen223|2 years ago
tangkikodo|2 years ago
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...
tangkikodo|2 years ago
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~
dlahoda|2 years ago
unknown|2 years ago
[deleted]
canadiantim|2 years ago
lucky_cloud|2 years ago
This project might be helpful in fetching the actual content from a database in an efficient way.
malcolmgreaves|2 years ago
tangkikodo|2 years ago