Сообщение Как правильно применять graphql? от 20.06.2023 0:42
Изменено 20.06.2023 0:43 vsb
Как правильно применять graphql?
Изучаю graphql и в частности программу hasura. Её основная задача это предоставление graphql-интерфейса для СУБД вроде postgres. Также она позволяет настраивать гибкую авторизацию, использовать не БД, а другие сервисы и тд.
Читал про истории успеха, когда этой программой по сути заменяют бэкэнд или существенную его часть. По сути это возвращение к старым подходам с двухзвенной системой: проектируется БД, часть логики реализуется на триггерах, возможно даже с хранимыми процедурами, с помощью view. Потом эта БД частично выставляется через graphql. graphql позволяет делать произвольные запросы, т.е. в каком-то смысле это аналог SQL. Соответственно фронтэнд имеет максимальную гибкость в плане доступа к данным. Не нужно писать эндпоинты, не нужно обдумывать и согласовывать API, просто пишет строчку и у тебя любые данные с любыми джойнами.
Про принципиальные проблемы этого подхода я понимаю (можно легко положить БД плохими запросами; если не ограничивать в проде запросы фиксированным списком, то "хакер" может вытянуть всю видимую ему БД одним запросом; нужно внимательно относиться к авторизации, чтобы юзер не видел чего не положено).
Вообще интересно, получалось ли у кого-то так делать? Также интересен опыт и/или мысли по применению graphql для взаимодействия между сервисами, в том числе для замены очередей сообщений. Тут у меня в голове вообще картинки чёткой нет, но есть ощущение, что это может быть полезно.
Читал про истории успеха, когда этой программой по сути заменяют бэкэнд или существенную его часть. По сути это возвращение к старым подходам с двухзвенной системой: проектируется БД, часть логики реализуется на триггерах, возможно даже с хранимыми процедурами, с помощью view. Потом эта БД частично выставляется через graphql. graphql позволяет делать произвольные запросы, т.е. в каком-то смысле это аналог SQL. Соответственно фронтэнд имеет максимальную гибкость в плане доступа к данным. Не нужно писать эндпоинты, не нужно обдумывать и согласовывать API, просто пишет строчку и у тебя любые данные с любыми джойнами.
Про принципиальные проблемы этого подхода я понимаю (можно легко положить БД плохими запросами; если не ограничивать в проде запросы фиксированным списком, то "хакер" может вытянуть всю видимую ему БД одним запросом; нужно внимательно относиться к авторизации, чтобы юзер не видел чего не положено).
Вообще интересно, получалось ли у кого-то так делать? Также интересен опыт и/или мысли по применению graphql для взаимодействия между сервисами, в том числе для замены очередей сообщений. Тут у меня в голове вообще картинки чёткой нет, но есть ощущение, что это может быть полезно.
Как правильно применять graphql?
Изучаю graphql и в частности программу hasura. Её основная задача это предоставление graphql-интерфейса для СУБД вроде postgres. Также она позволяет настраивать гибкую авторизацию, использовать не БД, а другие сервисы и тд.
Читал про истории успеха, когда этой программой по сути заменяют бэкэнд или существенную его часть. По сути это возвращение к старым подходам с двухзвенной системой: проектируется БД, часть логики реализуется на триггерах, возможно даже с хранимыми процедурами, с помощью view. Потом эта БД частично выставляется через graphql. graphql позволяет делать произвольные запросы, т.е. в каком-то смысле это аналог SQL. Соответственно фронтэнд имеет максимальную гибкость в плане доступа к данным. Не нужно писать эндпоинты, не нужно обдумывать и согласовывать API, просто пишет строчку и у тебя любые данные с любыми джойнами.
Про принципиальные проблемы этого подхода я понимаю (можно легко положить БД плохими запросами; если не ограничивать в проде запросы фиксированным списком, то "хакер" может вытянуть всю видимую ему БД одним запросом; нужно внимательно относиться к авторизации, чтобы юзер не видел чего не положено).
Вообще интересно, получалось ли у кого-то так делать? Также интересен опыт и/или мысли по применению graphql для взаимодействия между сервисами, в том числе для замены очередей сообщений. Тут у меня в голове вообще картинки чёткой нет, но есть ощущение, что это может быть полезно.
Ещё вижу неочевидное применение этого подхода в замене ORM. В каждом языке какие-то свои выдумки, кто-то вообще без ORM руками лопатит. А тут сразу всё в объектах связанных как надо. Вообще если бы я ORM сам делал, как-то так оно бы и выглядело в моём представлении, а тут уже всё сделано.
Читал про истории успеха, когда этой программой по сути заменяют бэкэнд или существенную его часть. По сути это возвращение к старым подходам с двухзвенной системой: проектируется БД, часть логики реализуется на триггерах, возможно даже с хранимыми процедурами, с помощью view. Потом эта БД частично выставляется через graphql. graphql позволяет делать произвольные запросы, т.е. в каком-то смысле это аналог SQL. Соответственно фронтэнд имеет максимальную гибкость в плане доступа к данным. Не нужно писать эндпоинты, не нужно обдумывать и согласовывать API, просто пишет строчку и у тебя любые данные с любыми джойнами.
Про принципиальные проблемы этого подхода я понимаю (можно легко положить БД плохими запросами; если не ограничивать в проде запросы фиксированным списком, то "хакер" может вытянуть всю видимую ему БД одним запросом; нужно внимательно относиться к авторизации, чтобы юзер не видел чего не положено).
Вообще интересно, получалось ли у кого-то так делать? Также интересен опыт и/или мысли по применению graphql для взаимодействия между сервисами, в том числе для замены очередей сообщений. Тут у меня в голове вообще картинки чёткой нет, но есть ощущение, что это может быть полезно.
Ещё вижу неочевидное применение этого подхода в замене ORM. В каждом языке какие-то свои выдумки, кто-то вообще без ORM руками лопатит. А тут сразу всё в объектах связанных как надо. Вообще если бы я ORM сам делал, как-то так оно бы и выглядело в моём представлении, а тут уже всё сделано.