Изучаю graphql и в частности программу hasura. Её основная задача это предоставление graphql-интерфейса для СУБД вроде postgres. Также она позволяет настраивать гибкую авторизацию, использовать не БД, а другие сервисы и тд.

Читал про истории успеха, когда этой программой по сути заменяют бэкэнд или существенную его часть. По сути это возвращение к старым подходам с двухзвенной системой: проектируется БД, часть логики реализуется на триггерах, возможно даже с хранимыми процедурами, с помощью view. Потом эта БД частично выставляется через graphql. graphql позволяет делать произвольные запросы, т.е. в каком-то смысле это аналог SQL. Соответственно фронтэнд имеет максимальную гибкость в плане доступа к данным. Не нужно писать эндпоинты, не нужно обдумывать и согласовывать API, просто пишет строчку и у тебя любые данные с любыми джойнами.

Про принципиальные проблемы этого подхода я понимаю (можно легко положить БД плохими запросами; если не ограничивать в проде запросы фиксированным списком, то "хакер" может вытянуть всю видимую ему БД одним запросом; нужно внимательно относиться к авторизации, чтобы юзер не видел чего не положено).

Вообще интересно, получалось ли у кого-то так делать? Также интересен опыт и/или мысли по применению graphql для взаимодействия между сервисами, в том числе для замены очередей сообщений. Тут у меня в голове вообще картинки чёткой нет, но есть ощущение, что это может быть полезно.

Ещё вижу неочевидное применение этого подхода в замене ORM. В каждом языке какие-то свои выдумки, кто-то вообще без ORM руками лопатит. А тут сразу всё в объектах связанных как надо. Вообще если бы я ORM сам делал, как-то так оно бы и выглядело в моём представлении, а тут уже всё сделано.