Компании переходят с GQL на Рест в простых сервисах? Может, они его изначально для простых систем не берут?
Ограничение сложности запроса - это буквально первое, что стоит сделать с GQL сервисом. Для этого уже есть куча готовых инструментов, где нужно просто поиграться с одним параметром.
Что касается оптимизации - тут все точно так же, как с РЕСТом - начинаем с эффективных запросов в базу, дальше обмазываем кешом и т.д.
Статья больше похожа на субъективное мнение автора, который не погружался достаточно в обсуждаемые темы.
А в чем сложность? На сервере под каждый объект генерируется резолвер. Перед тем, как вернуть объект из резолвера, можно взять данные авторизации и проверить, можно ли пользователю показать объект. В противном случае вернуть 403. Что тут сложного?
В терминах GraphQL, мутация - это изменение данных, что может быть созданием, обновлением и удалением данных. Query - это исключительно получение данных. При чем тут аналогия с get и post - не понятно.
Спасибо за доклад! Скажите, пожалуйста, рассматривали ли вы для себя пакет go pg? По большей части — это пакет, заточенный именно под Postgres. В нем есть очень приятная фича — это внутренний пакет ORM, который дает вам общий для транзакций и обычных соединений интерфейс, за счет которого можно абстрагировать бизнес логику от инфраструктурного слоя.
Я в свое время составил список вопросов по каждой интересующей меня категории, например: Менеджмент (процесс разработки, методология, как ставятся сроки и т.д.), Рабочее место: Что ждать от рабочего места, на каком устройстве работать (мне кажется, комфорт довольно важная составляющая рабочего процесса). Обязательно узнать про проект. Я часто спрашиваю, как оценивают качество кода разработчики, чтобы не было иллюзий. Проводится ли код ревью, как часто проводится. Выделяется ли время на рефакторинг, какие технологии используются. Разумеется, вопросы про соц. пакет. Тут тоже важно все выяснить детально, чтобы потом не было неожиданностей (к примеру, когда ДМС окажется без стоматологии).
В большинстве случаев, соискатели будут приятно удивлены таким интересом к своей вакансии и компании, а так же ответственностью подхода к поиску работы. На моей памяти, была всего одна компания, где данную информацию приходилось буквально клещами выдирать из собеседующих.
Выводы тоже странные.
Компании переходят с GQL на Рест в простых сервисах? Может, они его изначально для простых систем не берут?
Ограничение сложности запроса - это буквально первое, что стоит сделать с GQL сервисом. Для этого уже есть куча готовых инструментов, где нужно просто поиграться с одним параметром.
Что касается оптимизации - тут все точно так же, как с РЕСТом - начинаем с эффективных запросов в базу, дальше обмазываем кешом и т.д.
Статья больше похожа на субъективное мнение автора, который не погружался достаточно в обсуждаемые темы.
А можно узнать, какие именно компании переходят с GQL на Rest? А то такой яркий заголовок без конкретных примеров.
А в чем сложность? На сервере под каждый объект генерируется резолвер. Перед тем, как вернуть объект из резолвера, можно взять данные авторизации и проверить, можно ли пользователю показать объект. В противном случае вернуть 403. Что тут сложного?
В терминах GraphQL, мутация - это изменение данных, что может быть созданием, обновлением и удалением данных. Query - это исключительно получение данных. При чем тут аналогия с get и post - не понятно.
В большинстве случаев, соискатели будут приятно удивлены таким интересом к своей вакансии и компании, а так же ответственностью подхода к поиску работы. На моей памяти, была всего одна компания, где данную информацию приходилось буквально клещами выдирать из собеседующих.