Итак urql. Если вдруг это буквосочетание прошло мимо-вас - это мощная и эффективная альтернатива apollo client в качестве graphql клиента
Когда я первый раз узрел formidable.com/open-source/ur… то-ли на Hacker News, то ли на Dev.to мой скепсис был столь же велик, как технический долг @vue/test-utils
Однако из этого выросла мощная библиотека с уникальными фичами
Более того, если бы в абстрактном GitLab я бы сейчас принимал решение - я бы взял именно urql и в этом треде попробую пояснить почему
Я конечнео мог бы просто кинуть ссылку на formidable.com/open-source/ur… но все вот эти разговоры про "быстрее, выше, сильнее" - в пользу бедных :)
Как известно, в программирование есть две проблемы, и обе из них есть в работе с graphql в Apollo
И если с именованием переменных мы ничего не можем сделать, то пуговицу... в смысле инвалидацию кеша частично же мы решить можем?
На данный момент в Apollo есть два с половиной подхода как обновить состояние системы после мутации
1. Вернуть данные в мутации. Хорошо работает с изменением данных (аве, нормализация), но плохо - когда в результате меняются какие-либо списки
2. Указать что после мутации вот такие-то query надо рефетчить - по имени
2.5 Руками обновить нужные квери в кеше после апдейта
Проблема с этими подходами очевидна - они ужасно масштабируются с ростом системы. при добавлении новой query по сути надо пройтись и указать после каких мутаций ее надо перегружать (да, здесь я немного утрирую и не рассматриваю сценарии когда нам плевать на десинхронизацию)
Добавьте туда страннейшее решение Apollo делать это в слое отображения (да, если вы вызываете мутацию несколько раз - ответственность за консистетность ваших рефетчей на вас, правда неприятно?) - и вы получите мощнейшую головную боль, а главное - потерю управляемости
Почему так и можно ли лучше? Ответ - потому что GraphQL-схема почти не несёт семантики связей между мутациями и запросами, вот никакой магии и не происходит
Почему "почти"? Потому что со значительной вероятностью если мы изменяем объект типа Х - запросы, у которых тип Х[] и подобные ему есть среди возвращаемого значения будут затронуты
Собственно это и есть киллер-фича urql которая работает на удивление хорошо - он может быть schema-aware и сделать это магически!
С таким подходом могу заявить, что мне неизвестно ни одного киллер-преимущества Apollo перед urql
При этом у urql сверхмощный механизм интеграции в любую часть работы urql - от кеширования до собственно отправки запросов (exchange), в разы мощнее link'ов apollo, которые весьма ограничены в своих возможностях
Другими словами, если у вас "на той стороне" не Apollo-server со специфичными для аполло экстеншнами, если вы не собираетесь в ближайшее время использовать @stream и @defer - посмотрите на urql. Мой инженерный опыт с ним в разы позитивнее чем с Apollo
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Во многом этот тред навеян заполнением своего Career Mapping в GitLab и обсуждением этого с многими людьми "а как у вас это происходит" :)
Начнём с самого простого - с иерархии. Если с первыми шагами у инженера всё просто - junior, middle, senior, то дальше всё нетривиальнее - часто с точки зрения _инженерных_ позиций наступает карьерный тупик
Когда я говорю о карьерном тупике инженерной работы, то имею ввиду, что часто "продолжением" этой лесенки рисуют всякое "тимлидство" - должности, направленные на управление людьми, а не кодом.
Для тех, кто не в курсе - Apollo Client это "толстый graphql-клиент". Он автоматически выполняет нормализацию кеша, пользуясь тем, что в GraphQL строго типизированные данные
О недостатках, хотя нет, хм... ОСОБЕННОСТЯХ Apollo Client можно говорить очень долго - к примеру, они КРАЙНЕ react-centric, но есть у Apollo Client важная фича - это управление local state
Фактически, вы можете из своих компонентов, продолжать писать GraphQL-запросы и мутации и ваши компоненты __почти__ не будут знать работают ли они с локальным состоянием или с состоянием сервера.
Почему почти? потому что придется писать директиву @client
Спасибо всем за дельные замечания и вопросы. Как и обещал - делюсь своим видением проблемы стейт-менеджмента
Для меня сейчас - это основная и фундаментальная проблема в рамках GitLab. Я ее формулирую так "как реализовывать хранение и управление состоянием так, чтобы не рос технический долг и не страдал скорость деливери фич"
Нюанс начинается уже с определения: я осознанно ставлю вопрос технического долга важнее скорости деливери фич. Это связано с тем, что в случае "кризиса срочно-надо-на-вчера" (а так бывает и это нормально), когда мы ставим технический долг во главе угла - мы можем им пожертвовать
Хочу в качестве утренней разминки рассказать о сне, своих экспериментах с ним и, возможно, подсказать как спать лучше
Для меня сон - это всегда ощущение потерянного времени и маленькой смерти. Мне жалко спать. Поэтому я всегда относился ко сну как к необходимому злу и пытался его оптимизировать
Когда я работал в аутсорсинговой компании, практиковал полифазный сон. Спал 3 часа ночью и 2х45 минут днём. Первые две недели нереально тяжело, потом нормально. Прекратил после 3 месяцев, когда понял что начал тупеть - работать в таком режиме можно, придумывать что-то нет