Комментарии 7
Мне из статьи представилось, что эти сервисы работают вообще без бэкенда, а вешаются прямо на базу данных и делают запросы к ней. Получается, фронтенд должен знать, какие поля в БД как называются, чтобы сформировать свой запрос? Скажем, если в базе таблица user, а мне нужен subscriber, которые объединяет данные из user и из payments, то на какой стороне происходит это объединение данных?
Или оно не напрямую подключается к базе, а надо сперва вручную описать ту самую схему?
Hasura и Directus могут работать без бэкенда, предоставляя GraphQL API прямо поверх базы данных, автоматически генерируя схему на основе её структуры.
Фронтенду не обязательно знать названия полей в БД — у него есть схема (SDL), которую можно получить через introspection-запрос (обычно доступен по /graphql). На основе этой схемы строится GraphQL запрос, а Hasura/Directus уже преобразуют его в SQL-запрос к базе данных.
При этом, эти сервисы обладают более широкими возможностями, чем просто генерация GraphQL API на основе бд. Например, они позволяют настраивать ролевую модель доступа, создавать виртуальные связи между таблицами, добавлять кастомные резолверы и автоматизировать обработку событий.
Apollo Server — это уже инструмент для написания своего кастомного GraphQL-сервера, где схему и резолверы нужно описывать вручную.
Если схема автоматически сгенерирована на освнове базы данных, то взятие полей из схемы — это же как взятие их из БД. Это же получается некая обёртка над SQL.
По сути отчасти так и есть, но с SQL есть большая проблема - его нельзя напрямую использовать на фронте по соображениям безопасности. То есть для SQL запросов в любом случае нужно использовать бакэнд в качестве посредника, и создавать REST API эндпоинты, чтобы отдавать данные фронту, в принципе так везде и делается, в основном.
Сервисы вроде Hasura автоматизируют этот процесс, при этом закрывая 90% потребностей CRUD приложений. GraphQL в ней пресдтавлен в первую очередь потому, что это более гибкий инструмент для фронтендера, он может написать какие угодно запросы без необходимости делать изменения в бакенде, как в случае с самописным бакендом на REST API.
В приложениях, где нет никакой бизнес-логики, кроме CRUD можно вообще не писать бакенд, поднимать Hasura и сразу ставить задачи фронтендеру.
Это понятно. Я к тому, что фронтендеру придётся разбираться, как данные хранятся в базе, там же один объект со своими полями может быть разбросан по таблицам. Например, пользователь и его адрес. Для фронтенда это был бы один объект, а тут его придётся собирать по нескольким местам.
Там недолго разобраться, в той же хасуре есть удобный браузер таблиц, где можно выбирать непосредственно поля и составлять из них запрос и так же видно зависимые таблицы, можно их в том же запросе достать как вложенные. Там же можно запустить запрос, проверить, что он возвращает нужные данные.
Порог входа очень низкий для того, чтобы научиться собирать себе запросы, зато потом не надо гонять бакендера на каждое новое поле или добавленную таблицу.
GraphQL 10 лет. Пора в нем разобраться?