Я полностью убежден, что GraphQL - следующая большая вещь в архитектуре API. Приятно видеть технологию, которая решает целый ряд проблем, присущих REST, и которую так приятно использовать. Ключевые преимущества GraphQL хорошо известны, но есть одно недооцененное преимущество, о котором люди мало говорят: мы наконец можем перестать спорить об URL!
Вы когда-нибудь тратили время и умственную энергию на споры о том, как структурировать URL-адреса REST? Например, если я хочу получить всех наставников, принадлежащих определенной компании, из моего API, каким должен быть URL-адрес GET?
/companies/:id/mentors
/mentors?companyId=:id
/mentors?filters="companyId = :id"
Что должна вернуть эта конечная точка? Должен ли это быть список объектов, структурированный точно так же, как объект, возвращенный из /mentors/:id? Должен ли он также содержать информацию о компании? Каковы могут быть затраты, если мы вернем только ту информацию, которая необходима для конкретного варианта использования? Это нетривиальные вопросы, и я никогда не работал в организации, которая не тратила время на их обсуждение. Именование и структурирование сложных отношений с URL-адресами - это непростая задача!
GraphQL решает эту проблему, предоставляя разработчикам единую конечную точку, которая передает контроль над тем, какие данные возвращаются, включая связанные данные и встроенную фильтрацию! Вы называете корневые запросы так же, как и функции. В GraphQL ваш запрос может выглядеть примерно так:
query {
company(id: "abc123") {
id
name
mentors {
id
name
}
}
}
Это самое большое преимущество GraphQL? Конечно, нет. Это всего лишь один из тех действительно побочных эффектов, которые мне нравятся как опытному разработчику REST API.
Спасибо за чтение и удачного кодирования! 🤙
Подписывайтесь на меня!
Если вам понравился этот пост, подписывайтесь на меня! Или, по крайней мере, брось мне пару-тройку хлопков. Вы можете сэкономить один жалкий хлопок, не так ли?
Веб-сайт: https://sreisner.github.io
Средний: @ shawn.webdev
Twitter : @ReisnerShawn
