Для тех, кто не в курсе - Apollo Client это "толстый graphql-клиент". Он автоматически выполняет нормализацию кеша, пользуясь тем, что в GraphQL строго типизированные данные
О недостатках, хотя нет, хм... ОСОБЕННОСТЯХ Apollo Client можно говорить очень долго - к примеру, они КРАЙНЕ react-centric, но есть у Apollo Client важная фича - это управление local state
Фактически, вы можете из своих компонентов, продолжать писать GraphQL-запросы и мутации и ваши компоненты __почти__ не будут знать работают ли они с локальным состоянием или с состоянием сервера.
Почему почти? потому что придется писать директиву @client
@client Это звучит суперкруто - фактически мы получаем возможность спрятать от компонентов все за унифицированным ТИПИЗИРОВАННЫМ интерфейсом - graphql-запросами. Хотите - используйте это для локального состояния, хотите - чтобы реализовать допустим эндпойнт, которого на сервере ещё нет
@client К сожалению, именно что "звучит". Начнем с проблем:
- фактически вы получаете примитивнейший конструкт для построения архитектуры - резолверы для полей graphql-запроса, аналогичные тем же на сервере
Хотите какую-нибудь сложную логику а-ля redux-saga - пилите сами
@client Вы можете объявлять typeDefs для локального состояния, но они используются крайне ограниченно - не ожидайте что вас будут бить по рукам за нарушение типов схемы - к сожалению полноценная "проверка на соответствие схемы" слишком тяжела, чтобы жито во фронтенд-бандле
@client Вообще сам Apollo (здесь и далее я говорю о клиенте, если не сказано обратное) местами удивительно ограничен - к примеру если вы хотите после какой-то мутации ВСЕГДА выполнять какие-то действия - придется строить в Реакт свой хук (ав о вью всё еще хуже)
@client Да, в 2021 году от вас хотят реагировать на операцию изменения состояния на сервере в слое отображения. Есть альтернативы вида github.com/afafafafafaf/a… но они работают достаточно проблемно
@client Кроме того, local resolvers объявлены deprecated в текущей версии Apollo. Это удивительно, потому что предоставленный "альтернативный" механизм - type policies является, в отличие от local resolvers, СИНХРОННЫМ, а значит бесполезен чуть менее чем полностью
@client Моё удивление умножается на два, потому что local resolvers только только (две минорные версии назад, в 2.5) были приняты "в ядро", а до этого существовали как отдельный подпроект apollo-link-state.
@client Учитывая, что GitLab интенсивно использует локальные резолверы и мы пока не хотим от них отказываться (для сценариев небольшого подмножества локального стейта) - я уже морально готовлюсь, в случае чего поддерживать этот пакет (я посмотрел - там вроде ничего военного)
@client В дополнение к этому, сама документация по управлению локальным состоянием в Аполло - гм.. по шкале 0..10 я бы оценил её на минус три. Почему так? Часть параметров упоминается только в API Reference, про то как взаимодействуют локальные резолверы и кеш почти не описано
@client Как следствие - когда я первый раз реализовывал простейшее локальное состояние - я сделал кальку с Redux по сути - так, к примеру мутации писали в кеш (который я использовал как стейт), но ничего не возвращали
@client Когда пришло прозрение (прямо посреди стрима), я переписал всю логику в более GraphQL-way и стало как минимум гибче - проявилась важная сторона локального стейта аполло - "плохой код" остается в рамках одного резолвера (так как резолверы между собой почти не взаимодействуют)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Итак urql. Если вдруг это буквосочетание прошло мимо-вас - это мощная и эффективная альтернатива apollo client в качестве graphql клиента
Когда я первый раз узрел formidable.com/open-source/ur… то-ли на Hacker News, то ли на Dev.to мой скепсис был столь же велик, как технический долг @vue/test-utils
Однако из этого выросла мощная библиотека с уникальными фичами
Более того, если бы в абстрактном GitLab я бы сейчас принимал решение - я бы взял именно urql и в этом треде попробую пояснить почему
Во многом этот тред навеян заполнением своего Career Mapping в GitLab и обсуждением этого с многими людьми "а как у вас это происходит" :)
Начнём с самого простого - с иерархии. Если с первыми шагами у инженера всё просто - junior, middle, senior, то дальше всё нетривиальнее - часто с точки зрения _инженерных_ позиций наступает карьерный тупик
Когда я говорю о карьерном тупике инженерной работы, то имею ввиду, что часто "продолжением" этой лесенки рисуют всякое "тимлидство" - должности, направленные на управление людьми, а не кодом.
Спасибо всем за дельные замечания и вопросы. Как и обещал - делюсь своим видением проблемы стейт-менеджмента
Для меня сейчас - это основная и фундаментальная проблема в рамках GitLab. Я ее формулирую так "как реализовывать хранение и управление состоянием так, чтобы не рос технический долг и не страдал скорость деливери фич"
Нюанс начинается уже с определения: я осознанно ставлю вопрос технического долга важнее скорости деливери фич. Это связано с тем, что в случае "кризиса срочно-надо-на-вчера" (а так бывает и это нормально), когда мы ставим технический долг во главе угла - мы можем им пожертвовать
Хочу в качестве утренней разминки рассказать о сне, своих экспериментах с ним и, возможно, подсказать как спать лучше
Для меня сон - это всегда ощущение потерянного времени и маленькой смерти. Мне жалко спать. Поэтому я всегда относился ко сну как к необходимому злу и пытался его оптимизировать
Когда я работал в аутсорсинговой компании, практиковал полифазный сон. Спал 3 часа ночью и 2х45 минут днём. Первые две недели нереально тяжело, потом нормально. Прекратил после 3 месяцев, когда понял что начал тупеть - работать в таком режиме можно, придумывать что-то нет