Что такое идиоматический, эффективный способ решения связанных объектов?

Question

Как вы записываете решатели запросов в GraphQL, которые хорошо работают с реляционной базой данных?

Используя пример схемы от this tutorial, допустим, у меня простая база данных с users и stories. Пользователи могут создавать несколько историй, но в рассказах есть только один пользователь в качестве своего автора (для простоты).

При запросе для пользователя также может потребоваться список всех историй, созданных этим пользователем. Одно из возможных определений запроса GraphQL справиться с этим (украдено из приведенного выше связанного учебника):

const Query = new GraphQLObjectType({ 
    name: 'Query', 
    fields:() => ({ 
    user: { 
     type: User, 
     args: { 
     id: { 
      type: new GraphQLNonNull(GraphQLID) 
     } 
     }, 
     resolve(parent, {id}, {db}) { 
     return db.get(` 
      SELECT * FROM User WHERE id = $id 
      `, {$id: id}); 
     } 
    }, 
    }) 
}); 

const User = new GraphQLObjectType({ 
    name: 'User', 
    fields:() => ({ 
    id: { 
     type: GraphQLID 
    }, 
    name: { 
     type: GraphQLString 
    }, 
    stories: { 
     type: new GraphQLList(Story), 
     resolve(parent, args, {db}) { 
     return db.all(` 
      SELECT * FROM Story WHERE author = $user 
     `, {$user: parent.id}); 
     } 
    } 
    }) 
}); 

Это будет работать, как ожидалось; если я запрошу конкретного пользователя, я смогу также получить истории этого пользователя, если потребуется. Однако это не идеально. Это требует двух поездок в базу данных, когда одного запроса с JOIN было бы достаточно. Проблема усиливается, если я запрашиваю несколько пользователей - каждый дополнительный пользователь приведет к дополнительному запросу базы данных. Проблема ухудшается экспоненциально, чем глубже пересекаю мои объектные отношения.

Решена ли эта проблема? Есть ли способ написать запрос-преобразователь, который не приведет к генерированию неэффективных SQL-запросов?

Answer 1

Существует два подхода к решению этой проблемы.

Один из подходов, используемый Facebook, заключается в том, чтобы запрашивать запросы, совершаемые одним тиком, и объединить их перед отправкой. Таким образом, вместо того, чтобы делать запрос для каждого пользователя, вы можете сделать один запрос для получения информации о нескольких пользователях. Дэн Шафер написал good comment explaining this approach. Facebook выпустил Dataloader, что является примером реализации этой техники.

// Pass this to graphql-js context 
const storyLoader = new DataLoader((authorIds) => { 
    return db.all(
    `SELECT * FROM Story WHERE author IN (${authorIds.join(',')})` 
).then((rows) => { 
    // Order rows so they match orde of authorIds 
    const result = {}; 
    for (const row of rows) { 
     const existing = result[row.author] || []; 
     existing.push(row); 
     result[row.author] = existing; 
    } 
    const array = []; 
    for (const author of authorIds) { 
     array.push(result[author] || []); 
    } 
    return array; 
    }); 
}); 

// Then use dataloader in your type 
const User = new GraphQLObjectType({ 
    name: 'User', 
    fields:() => ({ 
    id: { 
     type: GraphQLID 
    }, 
    name: { 
     type: GraphQLString 
    }, 
    stories: { 
     type: new GraphQLList(Story), 
     resolve(parent, args, {rootValue: {storyLoader}}) { 
     return storyLoader.load(parent.id); 
     } 
    } 
    }) 
}); 

Хотя это не решает эффективной SQL, он все еще может быть достаточно для многих случаев использования и будет делать вещи работать быстрее. Это также хороший подход для нереляционных баз данных, которые не позволяют JOIN.

Другой подход заключается в использовании информации о запрошенных полях в функции разрешения для использования JOIN, когда это релевантно. В разрешающем контексте есть поле fieldASTs, которое проанализировало AST в части разрешенной в данный момент запроса. Просматривая детей этого АСТ (selectionSet), мы можем предсказать, нужно ли нам соединение. Очень упрощенный и неуклюжий пример:

const User = new GraphQLObjectType({ 
    name: 'User', 
    fields:() => ({ 
    id: { 
     type: GraphQLID 
    }, 
    name: { 
     type: GraphQLString 
    }, 
    stories: { 
     type: new GraphQLList(Story), 
     resolve(parent, args, {rootValue: {storyLoader}}) { 
     // if stories were pre-fetched use that 
     if (parent.stories) { 
      return parent.stories; 
     } else { 
      // otherwise request them normally 
      return db.all(` 
      SELECT * FROM Story WHERE author = $user 
     `, {$user: parent.id}); 
     } 
     } 
    } 
    }) 
}); 

const Query = new GraphQLObjectType({ 
    name: 'Query', 
    fields:() => ({ 
    user: { 
     type: User, 
     args: { 
     id: { 
      type: new GraphQLNonNull(GraphQLID) 
     } 
     }, 
     resolve(parent, {id}, {rootValue: {db}, fieldASTs}) { 
     // find names of all child fields 
     const childFields = fieldASTs[0].selectionSet.selections.map(
      (set) => set.name.value 
     ); 
     if (childFields.includes('stories')) { 
      // use join to optimize 
      return db.all(` 
      SELECT * FROM User INNER JOIN Story ON User.id = Story.author WHERE User.id = $id 
      `, {$id: id}).then((rows) => { 
      if (rows.length > 0) { 
       return { 
       id: rows[0].author, 
       name: rows[0].name, 
       stories: rows 
       }; 
      } else { 
       return db.get(` 
       SELECT * FROM User WHERE id = $id 
       `, {$id: id} 
      ); 
      } 
      }); 
     } else { 
      return db.get(` 
      SELECT * FROM User WHERE id = $id 
      `, {$id: id} 
     ); 
     } 
     } 
    }, 
    }) 
}); 

Обратите внимание, что это может иметь проблемы, например, с фрагментами. Однако и с ними можно справиться, это всего лишь вопрос более детального изучения набора выбора.

В настоящее время в репозитории graphql-js имеется PR, что позволит писать более сложную логику для оптимизации запросов, предоставляя «план разрешения» в контексте.