Pull to refresh

Comments 22

Пожелание по подпискам — если подписка называется productAdded, пусть вернет product, а не cart
На клиенте будете разбираться куда он добавился, что добавился.
Просто если список будет большим, это будет нехорошо после добавления product-а каждый раз весь список тащить.
JPA используется для персистенции в БД

Что будет, если в сущности у меня 10 полей, а запросил я только 3 из них. На уровне БД все равно прокачаются все 10 полей? Если нет, то интересно как это реализовано.
на уровне БД будет так, как ты запрограммируешь обработку запросов и их трансляцию в запросы в БД =)
Спасибо, Капитан) Я имел ввиду конкретную реализацию в статье (как я понял на Spring Data), которая скрыта и там не все так очевидно.
А не получится так, что при создании API на основе GraphQL мы невольно начнем привязывать представление данных и элементы запроса к структуре БД (или моделям) на сервере?

Такая проблема может встать при проектировании апи на основе любой парадигмы. Это общий вопрос.

Вам не кажется, что это все уже гдето было? В SQL например.
UFO just landed and posted this here
Лучше выглядит, читается и пишется.
UFO just landed and posted this here
Для Явы например совсем с инструментарием для oData не замечательно… и все попытки найти для чего-то кроме МС успехом тоже не увенчались.
UFO just landed and posted this here
Для OData все хорошо пока стек Микрософта. Создал модели данных, пара кликов, и вот у тебя уже и база, и контроллеры OData и можно сложные запросы к базе писать по http. Особенно радовала поддержка построения запросов прямо из Excel, можно за несколько минут репорты сложные нагенерить прямо из него без доп инвестиций в разработку и интеграцию. Хотел бы я посмотреть как GraphQL с подобным справится…

https://jeffhandley.com/2018-09-13/graphql-is-not-odata
Годная статья с описанием преимуществ и недостатков. Но что самое важное, ясное и основное на опыте понимание архитектуры и методов использования обеих технологий.

По моему это все переброс с больной головы на здоровую.
Т.е. когда у нас простое API, разработчик на серверсайде сам видит и оптимизирует запросы.
Когда некий GraphQL, то такой разработчик вообще ничего не знает о том что и как запрашивается, и спрашивается как это все оптимизировать?
Вместо предоставления кучи простых решений в виде кучи простых API, мы имеем одну большую головную боль о том, что вообще не знаем какие данные запрашивает клиент.

И да чем это отличается от прямого SQL? формой запроса только? еще одним уровнем абстракции? а зачем?
Ещё один уровень абстракции в любом случае будет нужен. Если мы будем просто бездумно пробрасывать GraphQL запросы в базу или в ORM, то получим поля, которые нам не хотелось бы видеть на клиентсайде: приватные данные, хэши паролей и т.д. Плюс в GraphQL проще будет прокидывать на сервер тяжёлые запросы, которые могут этот сервер уронить.

Да, это именно что переброс с больной головы на здоровую (вот вам спецификация, а вы уж на бэкэнде сами разбирайтесь как вам её выдавать), но оно действительно решает кучу проблем с API. В статье это хорошо описано. Тут мы и решаем проблему того, что выдавать по API, а что не выдавать, и решаем проблему с тем, что для получения вложенных данных частенько приходится тягать API много раз и т.д. Здесь всё просто и стандартизировано.

Другое дело, что и на клиентсайде происходит усложнение: при стандартном API например, если оказывается что нужны данные с ещё одного поля — мы просто меняем вьюху, а здесь нужно менять и вью и GraphQL-запрос.

На криентсайде хорошей практикой между вьюхой и риквестом будет иметь слой, который билдит структуру запроса. Это позволяет иметь довольно простой меппинг между полем и его местом в запросе.


Т. е. при описании поля в довольно простой форме описываем путь его получения. Билдер запроса всё остальное сделаем сам.

Одно из преимуществ GraphQL, то что он позволит вам делать дополнительную обработку перед отправкой запроса в БД, или же вообще не отправлять запрос в БД.
«Когда Фейсбук столкнулась...», блин да 99% проектов ни фига не Фейсбук. И для 99% нужна понятность и простота.
Ваш подход конечно же имеет место быть...,
проблема в том что очень много новичков тянут все хайповое в проекты и на выходе мы имеем монстра в плане архитектуры и производительности и сопровождения.
проблема в том что очень много новичков тянут все хайповое в проекты


Справедливости ради: если у новичков есть полномочия тащить в проект все, что они хотят, то в проекте есть более глубокие проблемы, чем наличие хайповых технологий.
Да, это основная проблема. Многие компании создают проекты и тулзы для своих задач и оптимизируют их для себя. Выкладывают в Open Source по разным причинам, и не обязательно для того чтобы все бездумно применяли у себя. GraphQL явно слишком массивен для большинства компаний.
Sign up to leave a comment.