FreeFeed API/3

July 12, 2017

Привет,

Я не открою секрета если скажу, что текущий API фрифида не отличается изяществом. Он достался нам в наследство вместе с кодом Пепятки и мы старались не ломать его раньше времени, а учились подстраиваться.

Несмотря на то, что Пепятка изначально писалась под модель «один бэкенд + много фронтендов», API был сделан по канонам той версии Ember Data которая использовалась в единственном существовавшем на тот момент фронтенде.

С тех пор утекло много воды: Ember-фронтенд был отправлен на пенсию уступив своё место фронтенду freefeed-react-client написанному с использованием библиотек React и Redux, у нас появилось 2 альтернативных open-source клиента (раз, два), несколько закрытых (раз, два, …) и некоторое количество частных. Все разработчики разбиравшие ответы сервера приходили к нам примерно с одними и теми же вопросами (чаще всего «так это что ли подписки? а я думал подписчики!») и жалобами на тяжеловесность и избыточность API.

Отдельно были запросы разработчиков на специализированные методы эффективно решающие узкие задачи.

В свою очередь когда мы работали с кодом изнутри мы спотыкались о «магичность» и неэффективность «сериализаторов». Особенно это проявилось когда мы стали катастрофически терять производительность после смены основного СУБД с Redis на PostgreSQL и были вынуждены создать API/2 старающийся быть похожим на v1, но выполняющий сложные запросы написанные вручную и сериализующий сложные структуры данных атомарно.

В общем, комок противоречивых требований растёт, а с ним растёт и сложность кода. Всё это наводит на мысль о том, что нам нужно внешнее «решение» на которое мы могли бы сгрузить часть сложностей. Так чего же мы от этого решения хотим:

  1. Должно быть «проверено» крупными игроками. Мы не можем позволить себе вкладываться в технологию которая умрёт послезавтра [check]
  2. Должно базироваться на открытых стандартах, чтобы мы имели возможность уйти на другую реализацию и получить поддержку у сообщества других пользователей [check]
  3. Должно работать как через стандартный HTTP-интерфейс (поддержка «простых» клиентов), так и через Web Socket (минимизация накладных расходов) [check]
  4. Должно позволять нашим «клиентам» задавать произвольные вопросы серверу [check]
  5. Должно позволять нам оптимизировать типичные запросы и предоставлять инструменты отладки [check]

Посмотрев на то что предлагает рынок, выбор свёлся к одному варианту. Итак:

API/3 будет основан на наборе инструментов Apollo Data реализующих язык запросов GraphQL:

Возможно также пригодятся:

Мы собираемся начинать работу над API/3 c узких случаев (например с «нотификаций»), постепенно переводя фронтенд на работу через GraphQL полностью.

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

comments powered by Disqus