Привет,
Я не открою секрета если скажу, что текущий API фрифида не отличается изяществом. Он достался нам в наследство вместе с кодом Пепятки и мы старались не ломать его раньше времени, а учились подстраиваться.
Несмотря на то, что Пепятка изначально писалась под модель «один бэкенд + много фронтендов», API был сделан по канонам той версии Ember Data которая использовалась в единственном существовавшем на тот момент фронтенде .
С тех пор утекло много воды: Ember-фронтенд был отправлен на пенсию уступив своё место фронтенду freefeed-react-client написанному с использованием библиотек React и Redux , у нас появилось 2 альтернативных open-source клиента ( раз, два ), несколько закрытых ( раз , два , …) и некоторое количество частных. Все разработчики разбиравшие ответы сервера приходили к нам примерно с одними и теми же вопросами (чаще всего «так это что ли подписки? а я думал подписчики!») и жалобами на тяжеловесность и избыточность API.
Отдельно были запросы разработчиков на специализированные методы эффективно решающие узкие задачи.
В свою очередь когда мы работали с кодом изнутри мы спотыкались о «магичность» и неэффективность «сериализаторов». Особенно это проявилось когда мы стали катастрофически терять производительность после смены основного СУБД с Redis на PostgreSQL и были вынуждены создать API/2 старающийся быть похожим на v1, но выполняющий сложные запросы написанные вручную и сериализующий сложные структуры данных атомарно.
В общем, комок противоречивых требований растёт, а с ним растёт и сложность кода. Всё это наводит на мысль о том, что нам нужно внешнее «решение» на которое мы могли бы сгрузить часть сложностей. Так чего же мы от этого решения хотим:
- Должно быть «проверено» крупными игроками. Мы не можем позволить себе вкладываться в технологию которая умрёт послезавтра [ check ]
- Должно базироваться на открытых стандартах, чтобы мы имели возможность уйти на другую реализацию и получить поддержку у сообщества других пользователей [ check ]
- Должно работать как через стандартный HTTP-интерфейс (поддержка «простых» клиентов), так и через Web Socket (минимизация накладных расходов) [ check ]
- Должно позволять нашим «клиентам» задавать произвольные вопросы серверу [check]
- Должно позволять нам оптимизировать типичные запросы и предоставлять инструменты отладки [ check ]
Посмотрев на то что предлагает рынок, выбор свёлся к одному варианту. Итак:
API/3 будет основан на наборе инструментов Apollo Data реализующих язык запросов GraphQL :
- Apollo Client http://dev.apollodata.com/react/
- graphql-tools http://dev.apollodata.com/tools/graphql-tools
- graphql-server http://dev.apollodata.com/tools/graphql-server
- graphql-subscriptions https://github.com/apollostack/graphql-subscriptions
- subscriptions-transport-ws https://github.com/apollostack/subscriptions-transport-ws
Возможно также пригодятся:
- https://join-monster.readthedocs.io/en/latest/
- https://github.com/acarl005/join-monster-graphql-tools-adapter
Мы собираемся начинать работу над API/3 c узких случаев (например с «нотификаций»), постепенно переводя фронтенд на работу через GraphQL полностью.
Я верю, что такой подход даст нам и скорость работы, и скорость разработки и полноценную гибкость для разработчиков фронтендов. Но, в любом случае, переход не будет быстрым процессом, т.к. наши ресурсы (в первую очередь человеческие) по прежнему очень ограничены.