Да, и вправду в случае с профилями можно было бы использовать интерфейсы. Насколько я понимаю, главное отличие от UNION здесь заключается в слове __typename, которого нет в случае интерфейсов. Конкретно в нашей системе от этого __typename довольно много зависит (логика отображения в приложении). Если бы надо было только отображать/не отображать какие-то поля или блоки на странице, то можно было бы обойтись интерфейсом, а нам надо иногда знать тип.
При этом я понимаю, что можно было бы просто использовать отдельное поле type, но в этом случае нет уже совсем никакого отличия между union и interface
Ну тут основная проблема в том, что перед открытием профиля мы знаем только его ID, но ещё не знаем его тип. В зависимости от типа у него может быть разный набор полей. Таким образом, при помощи UNION мы в запросе можем указать нужные данные для каждого из типов в одном запросе. Нет необходимости сначала узнавать тип профиля, а потом понимать, какие дополнительные поля по нему надо дозапросить (хотя фрагменты и упростят этот процесс).
Вполне возможно, что я вообще не очень понял вашу идею. Если так, то буду рад более подробным объяснением того, как это может работать через интерфейсы и фрагменты.
Нет нет нет, GraphQL совсем не предполагает отказ от разработки бэкенда. Под GraphQL может вообще не быть базы данных. Слой PHP (или любого другого языка) не исчезает.
Какие-то поля могут подтягиваться из базы (это надо прописывать кодом), какие-то поля могут быть получены по API из других систем (это тожно надо прописывать кодом), а какие-то поля могут быть рассчитаны прям в коде (очевидно, тут тоже код)
То есть GraphQL – это такое же API, которое надо разрабатывать. И логику для каждого объекта/поля можно (и нужно) отдельно программировать
Можно спроектировать API так, чтобы даже у хакеров не было возможности получить чужие пользовательские данные (такие, как email). Если не украсть чужой пользовательский токен, никакие чужие данные даже хакер получить не сможет. Если уж хакер украл токен, то защититься в любом случае будет сложно, GraphQL тут не при чём.
Fail2ban, непрогнозируемая нагрузка и тд можно решать (и мы это делаем) на уровне nginx, который стоит перед нашим бэкендом. То есть GraphQL имеет непрямое отношение к этому. Все необходимые меры безопасности надо предпринимать не только на уровне кода, но и на уровне инфраструктуры (имею в виду nginx и тд)
С одной стороны, надо развивать культуру разработки в компании (как минимум бэкенд должен общаться с фронтом). У нас все разработчики клиентских приложений знают об этих уязвимостях GraphQL, так что мы стараемся все вместе продумывать, чтобы их запросы были адекватны по нагрузке для бэкенда. А с другой стороны, и в GraphQL есть механизмы защиты от таких запросов. Можно, например, использовать систему весов. Для этого на каждое поле в схеме навешивается определённый вес. Итоговый вес приходящего запроса превышает максимальный – такой запрос не обрабатывается.
Лично я считаю, что GraphQL правда не очень подходит для сильно конфиденциальной информации, для важных пользовательских данных (поэтому GraphQL не слишком широко используется банками и тд). Однако и на уровне GraphQL сервисов у нас есть проверка токенов пользователя, так что никому ничего лишнего мы не отдадим.
Я упомянул, что с GraphQL имеются проблемы именно с использованием стандартного HTTP кэширования. Если мы при этом хотим отдать что-то очень быстро, нам это не мешает использовать Redis, чтобы не идти за данными в БД, а быстро получить их из памяти.
Если вам надо разработать простой сервис с небольшим количеством страниц, объектов и их взаимосвязей, то GraphQL может быть излишне сложным и медленным. Но если именно сложность системы и связи между различными объектами в ней значительно замедляют вашу разработку. GraphQL – классный вариант решения этой проблемы)
На самом деле, это скорее концептуальная архитектура на диаграмме. Вы очень правильно заметили, что в таком случае на федерацию ложится слишком много работы, для которой она не приспособлена.
В частности, для авторизации запросов перед федерацией ещё стоит nginx, который и проверяет токены пользователей)
Может быть, будет полезно: в GraphQL запросах клиенты могут использовать Fragments для повторяющихся объектов с одним набором данных. Почитать можно здесь – https://graphql.org/learn/queries/#fragments
Да, и вправду в случае с профилями можно было бы использовать интерфейсы. Насколько я понимаю, главное отличие от UNION здесь заключается в слове __typename, которого нет в случае интерфейсов. Конкретно в нашей системе от этого __typename довольно много зависит (логика отображения в приложении). Если бы надо было только отображать/не отображать какие-то поля или блоки на странице, то можно было бы обойтись интерфейсом, а нам надо иногда знать тип.
При этом я понимаю, что можно было бы просто использовать отдельное поле type, но в этом случае нет уже совсем никакого отличия между union и interface
Ну тут основная проблема в том, что перед открытием профиля мы знаем только его ID, но ещё не знаем его тип. В зависимости от типа у него может быть разный набор полей. Таким образом, при помощи UNION мы в запросе можем указать нужные данные для каждого из типов в одном запросе. Нет необходимости сначала узнавать тип профиля, а потом понимать, какие дополнительные поля по нему надо дозапросить (хотя фрагменты и упростят этот процесс).
Вполне возможно, что я вообще не очень понял вашу идею. Если так, то буду рад более подробным объяснением того, как это может работать через интерфейсы и фрагменты.
И вообще, спасибо за хороший вопрос)
Нет нет нет, GraphQL совсем не предполагает отказ от разработки бэкенда. Под GraphQL может вообще не быть базы данных. Слой PHP (или любого другого языка) не исчезает.
Какие-то поля могут подтягиваться из базы (это надо прописывать кодом), какие-то поля могут быть получены по API из других систем (это тожно надо прописывать кодом), а какие-то поля могут быть рассчитаны прям в коде (очевидно, тут тоже код)
То есть GraphQL – это такое же API, которое надо разрабатывать. И логику для каждого объекта/поля можно (и нужно) отдельно программировать
Можно спроектировать API так, чтобы даже у хакеров не было возможности получить чужие пользовательские данные (такие, как email). Если не украсть чужой пользовательский токен, никакие чужие данные даже хакер получить не сможет. Если уж хакер украл токен, то защититься в любом случае будет сложно, GraphQL тут не при чём.
Fail2ban, непрогнозируемая нагрузка и тд можно решать (и мы это делаем) на уровне nginx, который стоит перед нашим бэкендом. То есть GraphQL имеет непрямое отношение к этому. Все необходимые меры безопасности надо предпринимать не только на уровне кода, но и на уровне инфраструктуры (имею в виду nginx и тд)
С одной стороны, надо развивать культуру разработки в компании (как минимум бэкенд должен общаться с фронтом). У нас все разработчики клиентских приложений знают об этих уязвимостях GraphQL, так что мы стараемся все вместе продумывать, чтобы их запросы были адекватны по нагрузке для бэкенда. А с другой стороны, и в GraphQL есть механизмы защиты от таких запросов. Можно, например, использовать систему весов. Для этого на каждое поле в схеме навешивается определённый вес. Итоговый вес приходящего запроса превышает максимальный – такой запрос не обрабатывается.
Лично я считаю, что GraphQL правда не очень подходит для сильно конфиденциальной информации, для важных пользовательских данных (поэтому GraphQL не слишком широко используется банками и тд). Однако и на уровне GraphQL сервисов у нас есть проверка токенов пользователя, так что никому ничего лишнего мы не отдадим.
Я упомянул, что с GraphQL имеются проблемы именно с использованием стандартного HTTP кэширования. Если мы при этом хотим отдать что-то очень быстро, нам это не мешает использовать Redis, чтобы не идти за данными в БД, а быстро получить их из памяти.
Если вам надо разработать простой сервис с небольшим количеством страниц, объектов и их взаимосвязей, то GraphQL может быть излишне сложным и медленным. Но если именно сложность системы и связи между различными объектами в ней значительно замедляют вашу разработку. GraphQL – классный вариант решения этой проблемы)
Спасибо за вопрос)
На самом деле, это скорее концептуальная архитектура на диаграмме. Вы очень правильно заметили, что в таком случае на федерацию ложится слишком много работы, для которой она не приспособлена.
В частности, для авторизации запросов перед федерацией ещё стоит nginx, который и проверяет токены пользователей)
Спасибо за хороший вопрос))
Да, так и есть. Спасибо за ответ)
Может быть, будет полезно: в GraphQL запросах клиенты могут использовать Fragments для повторяющихся объектов с одним набором данных. Почитать можно здесь – https://graphql.org/learn/queries/#fragments