С появлением любой новой парадигмы программирования появляются возможности по-новому подойти к старым проблемам. Хорошо зарекомендовавшие себя передовые методы можно улучшить с помощью новых инструментов и дополнительной информации, доступной вовлеченному разработчику.

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

Недавно я разрабатывал свой первый GraphQL API с использованием NodeJS, и, несмотря на множество дискуссий о методах аутентификации, я изо всех сил пытался найти какое-либо подробное рассмотрение того, что делать после аутентификации пользователя. На мой взгляд, в этом пространстве есть несколько удивительных новых возможностей, которые только и ждут, чтобы их использовали.

Когда я начал понимать высокоуровневую структуру сервера GraphQL, мне стало интересно, как избежать создания отдельного запроса к базе данных для каждого поля в схеме. Я был не одинок в этом. Я наткнулся на блестящую библиотеку dataloader из Facebook, и путь вперед стал ясен. Гениальность загрузчика данных заключается в том, как он использует структуру функций преобразователя. Он обеспечивает повышенную производительность за счет пакетной обработки и кэширования запросов к базе данных практически без дополнительных затрат на абстракцию.

Я знаю, что в 2017 году люди не будут в восторге от кэширования запросов к базе данных, но это намекает на важный момент. Изменения в устоявшейся парадигме могут привести к новым инновациям неожиданным образом. Очевидно, что GraphQL — это огромное дело для самодокументирования, разделения клиент/сервер и безопасности типов, но это только начало. Существуют огромные изменения в эвристике запросов, возможности предварительного анализа запроса перед принятием решения о стратегии оптимизации и многие другие важные изменения для среднего сервера API.

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

Если вы извините за бесстыдный плагин (вы знали, что он будет), моя новая библиотека authorizr пытается включить некоторые из этих оптимизаций. Он используется в новом проекте GraphQL, над которым я работаю, и стал откровением в плане абстрагирования от мельчайших деталей таблиц разрешений и т. д. и предоставления простого API. Это, в свою очередь, упрощает рассмотрение функций преобразователя. Есть некоторое сходство с философией загрузчика данных, и по этой причине две библиотеки хорошо работают вместе. Но, как и в случае любой новой разработки, всегда будут возникать новые проблемы, требующие решения.

До сих пор самым большим убийцей мечты о бесшовной оптимизации была потребность в свежих данных. Как и в случае с загрузчиком данных, которому требуется метод loader.clear для удаления устаревших данных из кэша, авторизация должна иметь возможность реагировать на изменения в разрешениях и данных. Лучший подход для этого менее ясен для механизма авторизации без ограничений на структуру данных приложения, чем для механизма кэширования. Мне еще предстоит найти чистый способ сделать это, но, возможно, у кого-то умнее меня появится идея, меняющая правила игры, и он представит для нее PR (подсказка, подсказка).

Помимо нерешенных проблем, в пространстве серверов GraphQL есть чему порадоваться! Спасибо за чтение и, пожалуйста, не стесняйтесь оставлять комментарии.