I decided to give @defer another go today consider...
# apollo-kotlin
i
I decided to give @defer another go today considering its Dec. 2024 and its been around for a while. A few issues I've noticed (if someone has come across this and can offer guidance, pls help 🙏) 1. Whilst the console shows
incremental
payload being sent, with
hasNext: true
each time, the query only sends two response when using
.toFlow
-- initial data-fetch (without the deferred items) and empty payload which I believe concludes that call. 2. In the fetch call, we're calling like so for instance:
Copy code
apolloClient.query(
                GetUserQuery(
                    id = userId,
                    skipItem = true,
                    skipOther = false,
                    skipPreference = false,
                    skipDonations = true,
                    skipCards = true,
                    skipFriends = false
                )
            )
            .toFlow()
            .collect {
              // handle error via it.hasErrors() 
              // OR
              // emit(it.response) // it stops after the first emit
            }
I thought the @defer should be abit usable now or at least with good error provision but after 5 hours, I'm going to have to drop it and manually fetch queries on a need-to-use bases. Please let me know if there's anything I'm missing! Happy New Year! 🚀
b
Hi!
the query only sends two response when using
.toFlow
-- initial data-fetch (without the deferred items) and empty payload which I believe concludes that call.
This sounds like this could be expected, but it depends on what is returned. Did you expect more emissions? Could you maybe paste your query, and the received payloads (e.g. from a curl)?
i
I've got about 5
deferred
queries e.g
Copy code
... on User @defer(label: "posts") {
            posts @skip(if: $skipOther) {
                pageInfo {
                    hasNextPage
                    endCursor
                }
                edges {
                    node {
                        ...UserPostsFragment
                    }
                }
            }
        }
        ... on User @defer(label: "followers") {
            followers @skip(if: $skipFriends) {
                user {
                    ...UserFollowersFragment
                }
            }
        }

        ...
These queries are really slow hence why we abstracted them but the payload are not being emitted when received. I could see in the console the payloads are sent
The first image shows the query being called and the 2nd shows the emitted data in console
b
It may be a bug but I can't be sure without more info. Would it be possible to copy the relevant types of your schema, the full query, and the full backend response? From that I should be able to make a test to investigate.
i
I believe its a bug. Here's a sample query we're calling
Copy code
query getUser(
    $id: Int!
    $skipPreference: Boolean!
    $skipOther: Boolean!
    $skipFriends: Boolean!
) {
    user(id: $id) {
        user_id
        ... on User @defer(label: "settings") {
            settings {
              ...UserSettingsFragment
            }
        }
        ... on User @defer(label: "subscriptions") {
            subscriptions {
                ...UserSubscriptionsFragment
            }
        }
        ... on User @defer(label: "user_preference") {
            user_preference @skip(if: $skipPreference) {
                ...UserPreferenceFragment
            }
        }

        ... on User @defer(label: "groups") {
            groups {
                ...UserGroupsFragment
            }
        }
        ... on User @defer(label: "posts") {
            posts @skip(if: $skipOther) {
                pageInfo {
                    hasNextPage
                    endCursor
                }
                edges {
                    node {
                        ...UserPostsFragment
                    }
                }
            }
        }
        ... on User @defer(label: "followers") {
            followers @skip(if: $skipFriends) {
                user {
                    ...UserFollowersFragment
                }
            }
        }

    }
}
All those other types are abstracted into fragment.
Copy code
// sample response

 GraphQL Client: {"hasNext":true,"data":{"user":{"__typename":"User", "user_id": 100101 } } }
GraphQL Client: {"hasNext":true,"incremental":[{"data":{"settings":{"__typename":"UserSettings", "user_type", "other_user_types" } }] }}
GraphQL Client: {"hasNext":true,"incremental":[{"data":{"followers":[{"user":{"__typename":"User","John Doe" } }]}}]}
b
The 2 incremental payloads are not valid JSON. Did you paste them verbatim or edit them?
i
that was an edited version redacting some data (but no gql props redacted)
b
I don't see anything wrong with that at first sight. Can you reproduce the issue with a simpler query? It would be great if we could reproduce with a simple test.
i
do we have a working example of using @defer internally? I spent too much time on this yesterday that ive had to drop it. small or big query, it just doesnt emit deferred items going by the documentation
b
We have a bunch of tests.