Ответ
GraphQL — это язык запросов для API и среда выполнения для этих запросов. Он позволяет клиенту точно описать, какие данные ему нужны, и получить их в одном запросе, решая проблемы избыточной или недостаточной загрузки данных, характерные для REST.
Ключевые отличия от REST:
| Характеристика | REST | GraphQL |
|---|---|---|
| Эндпоинты | Множество эндпоинтов (/users, /posts/:id) |
Обычно один эндпоинт (/graphql) |
| Структура ответа | Определяется сервером | Определяется клиентом в запросе |
| Загрузка данных | Часто приводит к over-fetching (лишние данные) или under-fetching (нужно делать доп. запросы) | Клиент получает ровно те данные, которые запросил |
| Типизация | Не встроена в стандарт (используются внешние спецификации, как OpenAPI) | Строгая система типов — основа языка. Схема API является контрактом. |
Пример запроса GraphQL:
Клиент хочет получить имя пользователя и заголовки только его постов. Он формирует запрос, точно описывающий нужную структуру:
query GetUserWithPosts {
user(id: "1") {
name
posts {
title
}
}
}Основные концепции GraphQL:
- Схема (Schema): Определяет все типы данных и операции, доступные в API.
- Запросы (Query): Операции для чтения данных.
- Мутации (Mutation): Операции для изменения данных (создание, обновление, удаление).
- Подписки (Subscription): Позволяют клиентам подписываться на события и получать обновления в реальном времени (например, через WebSockets).
В Go для создания GraphQL-серверов популярны библиотеки gqlgen и graphql-go/graphql.
Ответ 18+ 🔞
Давай разберём эту вашу GraphQL-штуку, а то как будто про космос говорят, а на деле всё проще, чем кажется.
Представь себе ресторан. REST — это как стандартное меню: вот суп, вот второе, вот компот. Хочешь только котлету из второго? Не, братан, получишь всё блюдо целиком, с пюрешкой и салатом, которые тебе нахуй не сдались. Это over-fetching, лишняя загрузка. А хочешь ещё и пирожок на десерт? Делай новый заказ, иди нахуй. Это under-fetching, недозагрузка.
А GraphQL — это как шеф-повар, который выходит к тебе и говорит: «Ну чё, пацан, накидывай, что конкретно хочешь, я соберу в одну тарелку». Хочешь только имя юзера и заголовки его постов? Без проблем, ёпта. Получаешь ровно это и ни грамма лишнего.
Чем они вообще отличаются, эти ваши технологии?
| Прикол | REST | GraphQL |
|---|---|---|
| Точки входа | Их дохуя. /users, /posts, /cats — как будто по всему офису разбросаны кнопки. |
Обычно одна, блядь. /graphql. Всё, точка. Сюда все запросы и летят. |
| Что прилетает в ответ | Что сервер захочет, то и пришлёт. Как повезёт. | То, что ты в запросе чётко прописал. Сам виноват, если не дописал. |
| Проблемы с данными | Классика: либо тебе пол-API пришлют, либо заставят бегать по эндпоинтам как угорелому. | Клиент — царь и бог. Запросил три поля — получил три поля. |
| Типы данных | Ну, там какие-то свои документы на стороне, OpenAPI, хер пойми что. | Всё строго, по-взрослому. Схема API — это святое. Там каждый тип расписан, и если запросишь несуществующее поле — получишь по рукам сразу. |
Вот смотри, как запрос выглядит, реальный пример:
Допустим, тебе от юзера нужно только имя и заголовки его постов. Никаких лишних email'ов, дат рождения и прочей хуйни. Пишешь запрос:
query GetUserWithPosts {
user(id: "1") {
name
posts {
title
}
}
}И всё, ёбта! Сервер, как послушный пёс, принесёт структуру, где будет только name и массив posts, внутри которого только title. Никакого мусора. Красота, в рот меня чих-пых!
Из чего эта магия состоит?
- Схема (Schema): Это как конституция твоего API. В ней прописано, какие вообще бывают типы данных (
User,Post) и что с ними можно делать. Без неё — пиздец и анархия. - Запросы (Query): Это когда ты просто читаешь данные. «Дай-ка мне то, дай-ка мне это».
- Мутации (Mutation): А это когда ты уже меняешь что-то. «Создай юзера», «Обнови пост», «Удали эту дичь». Операции с последствиями, блядь.
- Подписки (Subscription): Вообще охуенная штука! Это как подписаться на паблик. Хочешь получать уведомления в реальном времени, когда новый комментарий появляется? Подписался — и тебе стримом летят обновления, обычно через WebSockets. Не нужно постоянно опрашивать сервер «Ну чё там? А щас?».
А если ты на Go пилишь, то смотри в сторону библиотек gqlgen или graphql-go/graphql. Они тебе всю эту кухню с типами и схемами помогут организовать, чтобы не охуеть от количества boilerplate-кода.