Как я и говорил в Apollo 3 добавится гарбэдж коллектор и они будут кричать, что новый релиз супер пупер. Хотя у Релея этот гарбедж коллектор уже как пару лет есть.

Но они не только догнали релей с гарбедж коллектором, они начали наконец-то двигаться в сторону собственных крутых фишек. И они действительно очень-очень крутые:
- суперские typePolicies 👍
- офигенно простая в реализации и в это же время безумно полезная доработка - это отключение нормализации для объектов без ключей. Это реально 💣 которой нет в релее.
- добавили possibleTypes для Union’ов, раньше было жутко неудобно
- иммутабельность кэша, но она уже с 2.6 доступна

Вобщем детали по ссылке. Скорее всего зарелизят 3 версию 30-31 октября на GraphQL Summit c помпой и кучей Amazing как у Apple.

Все еще ждем нормальных фрагментов от них, которые скорее всего появятся уже только в аполло 4. А пока приветствуем аполло 3 🎉

https://blog.apollographql.com/previewing-the-apollo-client-3-cache-565fadd6a01e

Ага, читал. Норм фичи. Ждем релиза суспенса полноценного, чтобы уже они и пр. начали его реализовывать по полной программе :)

хелп, fastify-gql пробую пример с ридмихи, не отдает статику с не плейграндом не графиклом (((

localhost:3000/graphql?

localhost:3000/playground?

так заработало. оч странно, у них статика на уроверь выше лижит от текущего файла. было так как на скрине закоменчено.

видел ишака, пробовал — не работало

всем привет.

query {
  getPost(id: 5){
    title
    comments {
      title
      author {
        name # this will be the same as the name above
      }
    }
  }
}

вот для такого примера, если имеется 5 коментов, то resolver свойства author породит 5 запросов за данными каждого автора? Если их будет 100, то будет 100 запросов?
Общий вопрос - как в графкл разруливать получение данных по комплексным свойствам типа Author, данные которых запрашиваются отдельно и порождают n запросов по числу элементов массива?

query {
  getPost(id: 5){
    title
    comments {
      title
      author {
        name # this will be the same as the name above
      }
    }
  }
}

Не обязательно, у меня в apollo сервер прописан подзапрос на все подсущности:

answers:  async (obj, args, ctx, info) => {
      return await ctx.db.quiz_page_answer.find({page_id: new ObjectId(obj._id)});
    },

answers:  async (obj, args, ctx, info) => {
      return await ctx.db.quiz_page_answer.find({page_id: new ObjectId(obj._id)});
    },

то есть подзапрос прописан уже на уровне массива?

Да.

  QuizPage : {
    answers:  async (obj, args, ctx, info) => {
      return await ctx.db.quiz_page_answer.find({page_id: new ObjectId(obj._id)});
    },
                    }

Так что есть запрашивать типа

page {
answers {_id title}
}

То отработает answers, где можно запросить сразу массив данных.

а если данные ответов лежат в одном апи (+ ид автора ответа), а данные самих авторов нужно по ид тащить из другого апи?

Не понял.

GraphQL автоматически подтягивает подзапросы если это поле указанного типа.

ну как пример. По пользователю получаю массив его заказов с датой, количеством, офисом, ид товара. Эти данные лежат а апи одного микросервиса. По ид товара для каждого элемента нужно получить название, описание и тд. Данные товаров лежат в другом апи

да но тогда каждый подзапрос генерит обращение к апи за данными дочернего свойства "Товара"

и допустим у пользователя было 5 заказов - будет 6 запросов - один за заказами и 5 за каждым товаром