Twitter | Search | |
Carlos Rufo
Lessons Learned Migrating APIs to πŸ“ ↳ Share yours πŸ’œ ↳ Open πŸ—£ ↳ Be πŸ€— β € 🀠 [Thread] πŸ‘‡πŸ½ πŸ‘‡πŸ½ πŸ‘‡πŸ½ πŸ‘‡ πŸ‘‡πŸ½πŸ‘‡πŸ½ πŸ‘‡ πŸ‘‡πŸ½γ€€πŸ‘‡πŸ½ γ€€πŸ‘‡πŸ½γ€€ πŸ‘‡πŸ½ γ€€ πŸ‘’ πŸ‘’
Reply Retweet Like More
Carlos Rufo Nov 26
Replying to @swcarlosrj
Create different files per each typeDefs & resolvers domain, then import and properly merge them. As you schema grows, you'll 😍 to have a modular design!
Reply Retweet Like
Carlos Rufo Nov 26
"Break your schema by concern, not by types" by . Extend your typeDefs as much you can, it'll allow you to define clearly your typeDefs & ♻️ the logic functions within their respective resolvers πŸ‘Œ
Reply Retweet Like
Hasura Nov 27
Replying to @swcarlosrj
Great thread.πŸ‘
Reply Retweet Like
Carlos Rufo Nov 27
Replying to @HasuraHQ
Looking forward to learn from your input πŸ€—
Reply Retweet Like
cory mcaboy Nov 27
I didn't even know you could extend! Good to know!
Reply Retweet Like
Carlos Rufo Nov 27
Replying to @JakeDawkins
You'd πŸ˜„ to be able to have access to certain methods inside of your resolvers right?, that's why πŸ‘‰ context πŸ‘ˆ exits. It is useful for passing things, like authentication scope, DB connections, and custom fetch functions. Thanks to for the tip πŸ€—
Reply Retweet Like
Andrey Los πŸ‡ΊπŸ‡¦πŸ‡΅πŸ‡± Nov 27
Still, don't know how to easily save a call to some resource when many field resolvers rely on the same resource that needs to be retrieved in order to get them.
Reply Retweet Like
Andrey Los πŸ‡ΊπŸ‡¦πŸ‡΅πŸ‡± Nov 27
So for example. You're getting `messages` You have `events` field on `Message` type. And `approveHistory` field that actually resolves history of approves in a nice consumable by client way using `events` resource that I retrieve by `id` of the message.
Reply Retweet Like
Andrey Los πŸ‡ΊπŸ‡¦πŸ‡΅πŸ‡± Nov 27
It enters `events` resolver and calls to DB for raw events. It enters `approveHistory` resolver and calls to DB for raw events again and then form them in a nice way. So for each message it will do two stupid calls instead of only one. Hence n+n calls instead of n.
Reply Retweet Like
Andrey Los πŸ‡ΊπŸ‡¦πŸ‡΅πŸ‡± Nov 27
How to make it nice and easy I have no idea (memoizing resolvers maybe, but it sounds like overkill). Parsing AST of `info` part of the resolver? Meh, too hard and I couldn't find online any nice package to do so in a reliable way. Any idea on how to make right and easy?
Reply Retweet Like
Carlos Rufo Nov 27
Replying to @RIP212 @JakeDawkins
Thanks for sharing your thoughts, actually is super interesting what you're saying. I'll give you back as soon as I can look into it!
Reply Retweet Like
Carlos Rufo Nov 28
Replying to @swcarlosrj
Structure your modular schema depending on your features, having only typeDefs & resolvers, you'd 😍 to structure it by feature, although if the number of features grow, do it by domain!
Reply Retweet Like
Carlos Rufo Nov 28
Replying to @swcarlosrj
On large schemas you'll notice that each domain contains tons of types, prioritize πŸ‘‰ WHAT MATTERS FIRST. Knowing that the 'extends' keyword stands for links between types, put them to the πŸ” of the file, then add the domain type and finally the field types
Reply Retweet Like
Carlos Rufo Nov 30
Replying to @swcarlosrj
Scalars, interfaces, enums, inputs… 😱, you'll have β™Ύ global typeDefs inside of your schema, don't miss the opportunity of identifying & decoupling them when you're creating your schema structure
Reply Retweet Like
Carlos Rufo Dec 1
Replying to @swcarlosrj
Use async/await to fetch data from the DB/API, array destructuring to get individual elements and object destructuring to join/remove elements. ⚠️ Don't forget handle possible errors!
Reply Retweet Like
Victor Zamfir Dec 7
Replying to @swcarlosrj
One resolver per file properly structured to be able to find them on fuzzy search - BlogCategory/posts, Query/allBlogPosts etc
Reply Retweet Like
Victor Zamfir Dec 7
Replying to @swcarlosrj
User resolver decorators to decouple validation / side effects from actual resolver's logic -
Reply Retweet Like
Carlos Rufo Dec 7
Replying to @victorzamfir
Adding a visual example would help for understanding, I'd be delighted to add them to the post πŸ˜‰
Reply Retweet Like
Victor Zamfir Dec 7
Replying to @swcarlosrj
Basically these are higher order resolvers - functions receiving a resolver and returning another one. The ones from here are pretty generic - . It's all about layers and responsibilities.
Reply Retweet Like