Необходим ли тип идентификатора graphql, если я установил уникальный идентификатор с помощью dataIdFromObject в Apollo Client
Я использую graphql + mysql + react-apollo, и вот один из типов graphql для таблицы User:
type User {
id: ID!
name: String!
}
Моя проблема с ID scalar type в graphql заключается в том, что он возвращается в виде строки, когда первичными ключами являются int в mysql, и это создает некоторые конфликты типов во внешнем интерфейсе с машинописным текстом.
Могу я просто вообще не использовать скалярный тип ID, учитывая, что я уже установил уникальный идентификатор с dataIdFromObject для каждого объекта в Apollo Client:
import {InMemoryCache} from 'apollo-cache-inmemory';
const apolloMemoryCache = new InMemoryCache(
{
dataIdFromObject: ({id,__typename}) => {
return __typename+id
}
}
);
const client = new ApolloClient({
link: ApolloLink.from([authLink, httpLink]),
cache: apolloMemoryCache,
});
Вы бы сохранили тип удостоверения личности или просто отказались от него?
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 3
попробуйте это вместо
type User {
id: Int!
name: String!
}
Вы должны определить собственный скаляр для своего преобразователя.
В свой преобразователь вы должны добавить один для ID, где вы ожидаете int, или вы можете выполнить преобразование между int и string в своем преобразователе.
import { GraphQLScalarType } from 'graphql';
const resolverMap = {
ID: new GraphQLScalarType({
name: 'ID',
description: 'Numeric custom scalar type',
parseValue(value) {
let result;
// Implement your own behavior here by setting the 'result' variable
return result;
},
serialize(value) {
let result;
// Implement your own behavior here by setting the 'result' variable
return result;
},
parseLiteral(ast) {
switch (ast.kind) {
// Implement your own behavior here by returning what suits your needs
// depending on ast.kind
}
}
}),
};
Ты спросил
would you keep the ID type or just ditch it
Обычно я рекомендую сохранить тип идентификатора и НЕ показывать клиенту целое число, которое вы используете. Если это новый набор данных, вам, вероятно, даже будет лучше использовать uuids в качестве PK от смещения. Это будет «безопаснее» и «надежнее», так как у вас меньше шансов случайно дать кому-то доступ к чужим материалам.
В любом случае, я бы рекомендовал сделать идентификаторы «непрозрачными» в соответствии со спецификацией Relay, чтобы у вас была возможность изменить их позже, если вы измените свое хранилище данных, не затрагивая ваших клиентов. Приложения часто проводят собственную проверку типов, поэтому вы должны быть уверены, что ваши вещи никогда не изменятся в этом отношении, когда это возможно.
Я не рассматривал uuids, и, возможно, уже слишком поздно, чтобы первичные ключи не были открыты для публики. Большинство идентификаторов предназначены только для данных о продуктах, сообщений на форумах и т. д. Ничего конфиденциального.
В чем проблема безопасности ПК?
Да, я об этом думаю. Есть ли пользователи mysql + graphql + apollo, которые вообще не определяют первичные ключи как скалярный тип идентификатора?