GraphQL представляет из себя язык запросов и манипулирования данными для API, а также среду для выполнения этих запросов с существующими данными. Он позволяет различным клиентам использовать API и запрашивать только те данные, которые им нужны, а также он помогает решить проблемы, которые есть у некоторых REST-сервисов, такие как избыток и недостаток данных. В этой статье я расскажу о мутациях в GraphQL. Для доступа и хранения данных буду использовать Entity Framework.

Читать далее

https://habr.com/ru/post/714600/?utm_source=habrahabr&utm_medium=rss&utm_campaign=714600

Для передачи данных по сети есть хорошо зарекомендовавшие себя стандарты - например, SOAP, gRPC, AMQP, REST, GraphQL.

При создании вебсайтов малой, средней и большой сложности с потоками данных к бэкенду и обратно в JSON формате обычно используются последние два с их вариантами. Верней, только варианты, потому что REST и GraphQL - ресурсо-ориентированные протоколы. Это как бы просто перенос элементарной работы с базой данных на клиента (хотя под "ресурсом" может пониматься и абстракция). Обычно таких запросов не больше трети от всего бэкенд API.

Попытка сделать весь API максимально RESTful страшно раздувает код и грузит сеть. Потому что остальные две трети запросов - в форме команд на бэкенд проделать какие-то действия, слабо отображающиеся на CRUD над некими ресурсами. И вариантов послать такие запросы достаточно много. Даже, чересчур.

Читать далее

https://habr.com/ru/post/709362/?utm_source=habrahabr&utm_medium=rss&utm_campaign=709362

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

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

Читать далее

https://habr.com/ru/post/707650/?utm_source=habrahabr&utm_medium=rss&utm_campaign=707650

Речь в статье пойдет о специальных инструментах для работы с GraphQL на Python в качестве клиента. Если вы используете GraphQL в своих сервисах на Python, то, скорее всего, сталкивались с необходимостью писать и хранить строки, содержащие GraphQL запросы, а так же писать Python классы для хранения результатов этих запросов. Вероятнее всего, вам было неудобно: не хотелось дублировать схожие запросы, постоянно править классы при частом изменении схемы и т.п. Вот и мне тоже. Поэтому, решая описанные проблемы, появились на свет два пакета: graphql-query и graphql2python.

Читать далее

https://habr.com/ru/post/707374/?utm_source=habrahabr&utm_medium=rss&utm_campaign=707374

В предыдущей статье мы поговорили о том, что такое graphQL, почему решили на него переходить, какие у него есть достоинства и недостатки. Но что делать дальше, если вы всё-таки решились внедрить graphQL в java-проект? Какие на данный момент есть фреймворки, чем они отличаются и какой вообще выбрать? Именно с этими проблемами мы и столкнулись почти год назад и не нашли адекватного ответа в одном источнике. Собрав по крупицам инфу из разных ресурсов (статьи, документации, доклады) и потыкав палочкой несколько фреймворков, мы сформировали общую базу знаний о них, которой и захотелось поделиться.

Если вам интересно, какие есть современные graphql-фреймворки на java, как выбрать подходящий и посмотреть, как он может выглядеть в продакшне — эта статья для вас.

Всем привет! Меня зовут Артем, я бэкенд-разработчик в hh.ru. Сегодня мы поговорим о современных решениях в GraphQL-мире на Java.

Статья также доступна в видео-формате.

Читать далее

https://habr.com/ru/post/681910/?utm_source=habrahabr&utm_medium=rss&utm_campaign=681910

https://habr.com/ru/post/680376/?utm_source=habrahabr&utm_medium=rss&utm_campaign=680376

Меня все сильнее раздражает, сколько людей готовы записывать в REST API любой интерфейс на основе HTTP. Сегодня приведу в качестве примера SocialSite REST API. Это же вызовы удаленных процедур (RPC). Он просто выкрикивает RPC. Связность между элементами на экране настолько сильная, что это творение заслуживает рейтинга X.

Читать далее

https://habr.com/ru/post/679788/?utm_source=habrahabr&utm_medium=rss&utm_campaign=679788

Аутентификация и авторизация — неисчерпаемые бесконечные темы. И как раз именно про них всегда забывают на старте разработки. У нас MVP и обойдемся без всех этих сложностей. Именно на этом умирает огромное количество хороших начинаний в крупных компаниях, поскольку масштабирование от лабораторного проекта до промышленной среды - самая сложная часть в любом проекте. Под катом история нашей эволюции от «авторизовался в ДБО — доверяем!» до «а у вас нет доступа к данным при этом значении атрибута», расширения GraphQL и прочая магия в популярном изложении.

Читать далее нашу историю

https://habr.com/ru/post/668992/?utm_source=habrahabr&utm_medium=rss&utm_campaign=668992

N1Loader разработан для легкого избежания N+1 проблемы
любого типа. К счатью, гем очень легко интегрировать в GraphQL
API. Без дальнейших отлагательств, давайте рассмотрим простой, но самодостаточный пример.

Читать далее

https://habr.com/ru/post/663834/?utm_source=habrahabr&utm_medium=rss&utm_campaign=663834

Введение:

Все чаще слышу об использовании GraphQL, но так как последнее время все рабочее время уходило на Xamarin + GRPC + ASP.NET Core, технология казалась для меня загадочно манящей и очень не известной, потому решил опробовать ее на нескольких языках, чтобы увидеть какие плюсы и минусы в разных подходах. Начать решил с родного и любимого C# + Hot Chocolate, но планирую так же попробовать Typescript + Prisma, Kotlin + graphql-kotlin, и возможно что-то другое.
Поехали

https://habr.com/ru/post/662958/?utm_source=habrahabr&utm_medium=rss&utm_campaign=662958

В данной статье я хочу рассказать про процесс создания концепта API Gateway для обеспечения взаимодействия фронтенда, использующего GraphQL, и бэкенда, использующего gRPC, на Java с использованием фреймворка Quarkus.

Читать далее

https://habr.com/ru/post/662594/?utm_source=habrahabr&utm_medium=rss&utm_campaign=662594