Comments 10
Очень привлекательный подход. Граф очень универсальная структура, которая дает много возможностей при решении разнообразных задач.
А вот про проблемы хотелось бы услышать подробнее. В частности, для графов предложено много универсальных алгоритмов, однако в зависимости от типа графа алгоритмы часто видоизменяют. Даже представления графов на практике бывают различными — см., например.
В таких архитектурах как GraphQL есть собственные проблемы.
А вот про проблемы хотелось бы услышать подробнее. В частности, для графов предложено много универсальных алгоритмов, однако в зависимости от типа графа алгоритмы часто видоизменяют. Даже представления графов на практике бывают различными — см., например.
А чем плохи граф ориентированные базы данных? Использую JanusGraph, очень доволен.
Мне кажется, что классический REST отлично жил бы с протоколом HTTP/2 (https://habrahabr.ru/post/308846/). Новый протокол бы решил главную проблему REST — большое число запросов, т.к. позволил бы посылать их в одном TCP- соединение. Но так как HTTP/2 задерживается, то и начали появляться Odata, GraphQL и прочее. Это всё Отличные инструменты, но новый протокол бы был очень кстати. Все-так HTTP1.1 уже скоро 20 лет будет.
Этого недостаточно. Как минимум, при REST появляются запросы зависязие от результата предыдущего запроса (например, для вложенности третьего уровня).
И самое важное: при graphql у вас гибче сервер, что упрощает разработку клиента.
А почему тогда сразу не указывать все запрашиваемые поля объекта? Например, /users//?fields=id,name,groups.name,groups.founder.name. Получить также список групп и у каждой группы имя фаундера. Подобный обработчик для DjangoRestFramework я написал года 4 назад и с тех пор ни разу не заглядывал в это место, т.к. не было необходимости.
Другое дело если мы запрашиваем несвязанные объекты. Тут увы, концепция REST никак не ложится.
Другое дело если мы запрашиваем несвязанные объекты. Тут увы, концепция REST никак не ложится.
У этого решения тоже есть свои недостатки:
— трудности с переносом в другой проект;
— на мелких проектах на любые велосипеды не хватит времени;
— не очень широкие возможности по фильтрации (а если вам нужны только группы удовлетворяющие определенному условию?);
— никто не сказал, что у вас хватит времени на корректную имплементацию этого добра (например, так чтобы вы загружали только запрошенные данные, но при этом еще и работал бекендский кеш)
Но как бы можно, да.
— трудности с переносом в другой проект;
— на мелких проектах на любые велосипеды не хватит времени;
— не очень широкие возможности по фильтрации (а если вам нужны только группы удовлетворяющие определенному условию?);
— никто не сказал, что у вас хватит времени на корректную имплементацию этого добра (например, так чтобы вы загружали только запрошенные данные, но при этом еще и работал бекендский кеш)
Но как бы можно, да.
Это-то да. Но вам придется переписывать API под graphQL. А если бы появился HTTP/2, то вам вообще ничего не надо делать. Запросы как летели так и будут лететь, а там пусть за них сервер отвечает. Для legacy очень хорошо. А таких проектов как всегда очень много
А можно полслова про реализацию?
GraphQL выглядит волшебно! Мне frontend мне уши про него прожужжал. Но, как его реализовывать на backend? Или, по сути, это всего лишь batch mode для чего-то вроде REST?
На сколько это усложняет жизнь backend разработчиков?
GraphQL выглядит волшебно! Мне frontend мне уши про него прожужжал. Но, как его реализовывать на backend? Или, по сути, это всего лишь batch mode для чего-то вроде REST?
На сколько это усложняет жизнь backend разработчиков?
Sign up to leave a comment.
Знакомство с графовыми API