Привет! Это tech-команда СберМаркета. Сегодня кто-то празднует день влюбленных, а для нас с вами это ещё и профессиональный праздник — день компьютерщика. Если совместить два повода, получим день влюблённых в компьютеры. Кто-то любит копаться в железе, кто-то в программах. Кто-то пишет библиотеки, а кто-то их использует. Но все мы не равнодушны, иначе нас бы здесь не было. Эта статья — любовное письмо языкам, фреймворкам и библиотекам, которые крутятся у нас под капотом — Go, Ruby, React, React Native, Redux. Слова любви к ним из первых уст — от инженеров СберМаркета.

Ruby — why I love it?

Ruby — язык программирования, который был представлен в 1995 Юкихиро Мацумото, также известным под ником Matz. Наибольшую популярность язык приобрел с появлением фреймворка Ruby On Rails, и это действительно поставило Ruby на новые рельсы. Фреймворк делает создание нового приложения достаточно простым, а Ruby «под капотом» позволяет описывать именно бизнес функциональность, не тратя много времени на сложные конструкции.

Я познакомился с Ruby в далеком 2010 и он все еще мне помогает в работе! Именно с RubyOnRails создавался проект Instamart, который вырос в СберМаркет.

Несколько важных особенностей, за что можно полюбить Ruby:

  • Высокоуровневый язык, который понятен прежде всего человеку, а не только машине.

  • Динамическая типизация — это позволяет реализовать бизнес логику достаточно просто

  • Поддержка блоков (block). Возможность передавать целый блок функционала как аргумент увеличивает возможности.

  • Огромное кол-во gem’ов. Можно найти библиотеку практически под любую задачу. Ну а если не нашел, легко создать собственную.

  • Ну и конечно же Ruby on Rails. Быстро развернуть и использовать на production.

В СберМаркете мы пишем на Ruby и бекенд, и скрипты-помощники, которые используем в повседневной работе. А наша PaaS платформа позволяет создавать сервисы как на Golang, так и на Ruby.

Фраза «Ruby мёртв» давно стала мемом. Мой ответ — «Конечно жив и в отличной форме!»

Дорогой Go...

Главное, за что можно любить язык Go — это его простота и эффективность. Он позволяет писать лаконичные, но вместе с тем производительные программы. Так, например, чтобы поднять сервер, не нужно дополнительно знать какой‑либо фреймворк — всё необходимое уже есть в стандартной библиотеке. Радует и нативная поддержка GRPC, ведь многие наши сервисы используют данный протокол вместо HTTP.

И, конечно же, нельзя обойти стороной конкурентность. Как по мне, горутины, наравне с другими фишками, освобождают разработчиков от заботы о многих технических нюансах и дают возможность больше думать о продуктовой составляющей.

Конечно, простота Go несёт с собой и свои недостатки и боль. Но разве есть в мире что‑то идеальное?

Как-то при поиске работы я наткнулся на вакансию на Go, куда можно было податься без его знания, но с опытом на других языках. Получив приглашение на собеседование, я открыл туториал и к моему удивлению через 4 часа я уже мог написать простенькие алгоритмы. Тут я впервые полюбил этот язык.

На тот момент у меня за плечами был опыт разработки на C, JavaScript, Java и Python, однако разработка на Go не шла в сравнение с этими языками. Благодаря опыту работы на других языках все достоинства Go для меня особенно заметны:

  • В отличии от Java у Go был простой синтаксис и очень простая модель разработки программ.

  • При сравнении с JavaScript с его нелогичностью и кучей костылей Go выгодно отличается своей продуманностью.

  • При сравнении с Python сразу же подкупает статическая строгая типизация и быстрота. И вот при сравнении с великим C ты начинаешь понимать, что Go это язык, который вдохновлялся C и который старается быть еще лучше.

Он простой и не переусложненный, но в тоже время мощный и на нем можно писать самое разнообразное ПО. Go еще активно развивающийся язык, в который с каждым релизом добавляют кучу новых возможностей. Также у Go есть обширное сообщество, а сам язык разрабатывается Гуглом, что позволяет всегда быть уверенным в надежности как самого компилятора, так и всего тулинга, который идет вместе с Go.

Когда я оцениваю свою каждодневную работу и пытаюсь понять, почему мне нравится делать те или иные штуки, я всегда понимаю, что самое важное — это удобный инструмент. И Go является наиболее удобным в моем понимании инструментом для разработки.

React Native, что меня в тебе так зацепило?

Нравится за счёт своего подхода к кроссплатформе, когда «под капотом» используются компоненты целевых платформ. В сложных ситуациях RN оставляет возможность реализации деталек приложения при помощи нативных технологий, что позволяет развиваться как мобильный разработчик и улучшать навыки в UX. Так же хочется отдельно упомянуть hot reload, OTA и поддержку Typescript — эти технологии сильно упрощают разработку.

Тупо лучший, ReactJS

В СберМаркете мы используем React для разработки витрины (той части сайта, которую вы видите, когда заказываете продукты) и панели администратора, но помимо этого у нас есть и другие frontend-проекты, где также используется React. Кроме того, мы используем его и при разработке внутренних библиотек.

React мы любим за:

  • Его универсальность.
 Ни одна другая JS-библиотека не работает в таком количестве окружений и на таком количестве устройств.

  • Гибкость.
 React — библиотека, а не фреймворк, это развязывает руки, по факту всё, что можно сделать в JS, можно сделать, используя React.

  • Высокую производительность (спасибо виртуальному DOM-дереву). 
Вы указываете, в каком состоянии должен находиться интерфейс, а React добивается, чтобы DOM соответствовал этому состоянию. Это абстрагирует манипуляции с атрибутами, обработку событий и ручное обновление DOM.

  • Возможность переиспользовать код.
 Чаще всего, компонент пользовательского интерфейса можно использовать в других частях приложения или даже в разных проектах. За счёт этого увеличивается скорость и разработки.

  • Огромное сообщество.
 Более 20 миллионов скачиваний за неделю, большое количество библиотек для React, форумы, конференции.

А ещё, мы используем большое количество других библиотек, Redux, Redux-thunk, Next, Typescript и многое другое. Это представляет React уже не как библиотеку, а как экосистему, вокруг которой образуется инфраструктура в виде инструментов и людей. За это мы и любим React.

От ненависти до любви к... Redux

В далеком 2016 году, ещё в начале своего программного пути, я познакомился с такой вещью как Redux. Каким же ужасным и неудобным он был. Крошечная библиотечка с абсолютно примитивной логикой, проповедующая предсказуемость поведения, в угоду которой было принесено всё остальное. Не было слежения за изменениями и на любой экшен дёргались все подписчики, вне зависимости от того, относятся ли они к изменяемой сущности или нет. Не было мемоизации и все селекторы так же вызывались на каждый экшен. Не было правил именования экшенов, про их структуру говорилось только то, что обязательно поле type, а про payload никто и не слышал. А уж работа с бэкендом превращалась вообще в ад: на каждый запрос нужно было писать middleware с сагами и по три экшена с обработчиками.

Хоть в основе Redux лежали полезные принципы, он был настолько неудобен, что через год использования, я для себя его похоронил и перешел на MobX. Поэтому, когда устраивался в СберМаркет, и мне говорили, что здесь используется Redux, я был очень скептически настроен, но к счастью мои опасения не подтвердились.

За прошедшие годы командой Redux была собрана обратная связь и проделана огромная работа по улучшению библиотеки. Так на свет появился Redux Toolkit (RTK), а вместе с ним слайсы и RTK Query:

  • Теперь не надо отдельно описывать экшены, достаточно просто указать начальное состояние и редьюсеры.

  • Не нужно следить за иммутабельностью данных, RTK делает это сам.

  • Общение с бэкендом из того ужаса превратилось в привычную работу с хуками, которые автоматически создаются по описанному API. При этом API можно генерировать из swagger схемы, сводя работу руками к минимуму.

  • Больше не нужно писать столько бойлерплейта, сколько приходилось раньше, при этом основная идея про единый стор, цепочки экшенов и предсказуемость состояний осталась.

Так я для себя открыл, что у редакса тоже есть человеческое лицо :)

Вот такая вот история про то, что от ненависти до любви тоже один шаг. А какие библиотеки контроля состояний нравятся вам?

Tech-команда СберМаркета завела соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и YouTube.

Комментарии (9)


  1. markelov69
    00.00.0000 00:00

    За прошедшие годы командой Redux была собрана обратная связь и проделана огромная работа по улучшению библиотеки. Так на свет появился Redux Toolkit (RTK), а вместе с ним слайсы и RTK Query:

    И что? Это всё равно все то же иммутабильное и примитивное убожество, чутка под другим соусом и всё так же с лишним кодом, хоть его стало чутка по меньше. До MobX ему как раком до Китая.


    1. Geosins
      00.00.0000 00:00

      Ну почему же. В большинстве случаев менеджер состояний используется для хранения данных с бэкенда. Если использовать RTK Query, то просто в коде пишешь что-то типа:

      const { data: citiesData, isLoading: isCitiesLoading } = useGetCitiesQuery()

      И всё, одна строчка кода и ты получаешь список городов, состояние запроса, кэширование по типу Apollo GraphQL, где не нужно задумываться о том, пришли у тебя данные с бэкенда или из стора.

      Реально, одна строчка кода, никого бойлерплейта, а вся редаксовская дичь происходит где-то под капотом. При этом сама API генерируется автоматически из swagger схемы, то есть ничего не надо делать руками, всегда актуальные типы и нет несогласованности бэка с фронтом. Так что для общения с бэком очень удобно.

      Да, если писать классические модели данных, записывать туда бизнес логику, то естественно MobX. Но это разные цели. И для большинства проектов за глаза хватит того общения с бэкендом, которое я описал выше


      1. markelov69
        00.00.0000 00:00

        Вы описали проект по типо сайта визитки, где просто в тупую именно из реактовских компонентов достаточно дергать запросы без какой либо логики.

        Но мы живем в реальном мире и в нормальных проектах всегда это логика есть, более того, запросу нужно дергать из любых мест, а не только из реактовских компонентов и быть полностью к ним прибитым гвоздями, а просто в тупую голые JSON'ы не гоняются. Поэтому вы изначально проект превращается в утопическую помойку когда используете redux, потом вы понимаете что всё, вы упали в бездну и начинается самая боль по выпиливанию этого недоразумения и замены его на MobX. Так вот, нафига все эти лишние телодвижения если можно сразу не канфилоть мозг ни себе, ни окружающим, ни проекту и сразу взять MobX.

        Да и вообще всё остальное управление состоянием проекта вы как себе представляете? Использовать для этого средства реакта? - Это максимально нелепо и не разумно. Использовать для этого redux? - Точно так же, максимально нелепо и не разумно. MobX просто идеально для этого подходит, предназначение реакта одно, это тупо View слой, всё что он может это рисовать HTML в зависимости от состояния(которым конечно же не он должен управлять).

        Реально, одна строчка кода, никого бойлерплейта

        Ага, разве что в розовом мире и в розовых проектах без валидацией, без всевозможных условий формирования запросов, без цепочек запросов, без логики и т.д. и т.п.
        Так что "аргумент" мягко говоря абсурдный


        1. Geosins
          00.00.0000 00:00

          Вы описали проект по типо сайта визитки, где просто в тупую именно из реактовских компонентов достаточно дергать запросы без какой либо логики.

          Да и вообще всё остальное управление состоянием проекта вы как себе представляете?

          Этого более чем достаточно для написания всевозможных лендингов и админок, которые составляют немаленький процент от общего числа сайтов. Для всяких корпоративных порталов с формами и списками, где все остальное управление состоянием состоит из работы с данными форм.

          в розовых проектах без валидацией, без всевозможных условий формирования запросов, без цепочек запросов

          Для хранения данных форм и валидаций мы используем Formik, вполне устраивает, а условия формирования запросов и завязывать один запрос на другой RTK Query умеет.

          Для вас MobX - золотой молоток, но тем не менее он нужен далеко не всегда


          1. markelov69
            00.00.0000 00:00
            +2

            Для хранения данных форм и валидаций мы используем Formik

            Мда, теперь всё встало на свои места, вам просто абсолютно всё равно на то, какой код вы пишете, поэтому просто берете первую попавшуюся поделку которая "решает" задачу и в путь.

            Про то, что можно эти задачи решить гораздо лучше и удобнее че те "инструменты" которые вы используете вы даже не думаете, потому что это удел настоящих инженеров, которые много лет назад уже сами написали для себя инструменты для работы с такими тривиальными вещами как формы и их валидации, запросы к апи и т.п.


            1. DmitryKazakov8
              00.00.0000 00:00
              +1

              Это рекламная статья "для галочки", что "популяризируют Сбер на Хабре", только тег реклама не указали. Тут не с кем обсуждать архитектуру.


    1. popuguytheparrot
      00.00.0000 00:00

      Mobx до Effector ему как раком до Китая


      1. markelov69
        00.00.0000 00:00

        Mobx до Effector ему как раком до Китая

        :D:D Смешно, ага


  1. Lewigh
    00.00.0000 00:00
    +2

    Вы извините конечно, но какой смысл всей этой статьи? Взять постфактум технологии которые вы используете и сказать что они хорошие потому что не плохие, при этом приводя в качестве аргументов оксюмороны вроде "Он простой и не переусложненный, но в тоже время мощный".
    Мне бы, как читателю, было бы интересно прочесть - какие боли есть у технологий, которые вы используете, и почему, ни смотря на эти боли, вы любите и используете именно эти технологии.
    Конечно все понимаю, но вроде бы какой никой IT блог а не флудилка.