много понадобилось вручную прогать на сервере для обработки запросов?

ну достаточно, особенно для jsonb полей схемы рисовать. Но в принципе при хорошем проектировании БД absinthe + ecto делают многие вещи на автомате.  Большая часть разработки была связана с проверкой прав доступа и т.п.

ага, понял

т.е. у тебя graphql + postgres силами эликсировской экосистемы, так?

Тоже ипользовал это. Довольно легко все прошло, кода не много. Интеграция с бд удобная - надо graphql поля так же называть, как поля в базе, тогда вообще почти ничего писать не придется. Когда интегрировал, мутации самому имплементить пришлось, не было их готовых в либе. Сейчас наверное уже есть из коробки.

да

там удобные штуки встроены, типа оптимизации резолверов через батчинг, для избежания n+1 запросов

у меня коллега хочет это к нам попробовать посмотреть.

У нас не база, а всякие ets-ки, да прочая муть

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

Какие возможные проблемы с graphql?

т.е. есть ли проблемы которые отличаются от проблем с обычным REST API

одно время интересовался им, попутно почитал опыт других. из того, что запоминилось, самая боль случилась в разных местах -
самое первое, с чем придется разбираться - error handling. не знаю как сейчас, еще была боль с мультипарт реквестами. по производительности проседания (это, конечно сильно зависит от природы данных и работы с ними).
Все нюансы уже навскидку не вспомню, можно покопаться и найти те видео и статьи, что смотрел-читал. Думаю при должном интересе сами сможете легко найти.
Для себя решил - не обазательно жрать кактус, чтобы узнать его пищевые ценности ). Ценность graphql для меня осталась больше академическая.

проблема обычного рестапи - невозможность внятно мультиплексировать. в общем-то эту проблему и решал фейсбук придумывая graphql.

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

мне понравилось использовать graphql в качестве внутреннего апи мобильного приложения + веб клиента. Из плюсов всегда есть четко заданный формат запросов и входных и выходных данных. т.е. ненужно дополнительно описывать API это все приходит вместе с GraphQL. Для себя я пока вижу так что если нагрузка небольшая и нужно быстро сделать API для фронтенд команды, то можно довольно просто его сделать с помощью GraphQL

Типа валидация из коробки?

И схема, которая и для фронта, и для бека?

да, плюс документация

о входящих параметрах и их форматах

+ что все апи в итоге выглядит однородно даже после того как его писало множество людей