Comments 1
Основная проблема такого подхода заключается в том, что вы в compile time должны знать все запросы, которые будете исполнять на клиенте. Т.е. по факту каждый клиент будет генерировать свои собственные запросы. На мой взгляд более перспективный подход - это генерировать полноценный клиентский DSL по GraphQL схеме, который позволит нам выполнить любой GraphQL запрос в runtime, не зная о нем заранее в compile time.
Какие преимущества даст нам такой подход? Мы можем распространять такой DSL как клиентскую библиотеку. Представьте, что вы пишете микросервис с API на GraphQL. Мы можем разделить этот микросервис на 2 модуля - API и реализацию. В модуле API мы разместим схему GraphQL, и сгенерируем по этой схеме клиентский DSL. Затем мы опубликуем сгенерированный DSL в Maven репозитории, и любой клиент нашего микросервиса сможет подключить к себе этот артефакт как зависимость. Мы не знаем заранее, какие запросы потребуются клиентам нашего микросервиса, но нам и не нужно этого знать, так как сгенерированный DSL позволит выполнить любой запрос.
Еще один неочевидный бонус такого подхода заключается в том, что если наш микросервис изменит свой API, то мы обо всех проблемах несовместимости узнаем во время компиляции, подключив новую версию клиентского DSL.
Для генерации клиентского Kotlin DSL по GraphQL схеме можно использовать Kobby Plugin:
Apollo 3.0 для работы с GraphQL в многомодульном Android приложении