Привет! Давно ничего не писал в этот канал. Прошло уже 8 месяцев с тех пор, как я работаю в Reality Labs (Meta) и занимаюсь разработкой Quest Store — это место, где люди покупают приложения для устройств Quest. За это время я успел пережить один лэйофф и получить высокую оценку EE (Exceeds Expectations, «выше ожиданий») за 2024 год.
В основном я занимался производительностью и надежностью (Reliability) — тем, чем, собственно, и занимался последние 10 лет. И в этих аспектах особенно заметно, чем большие компании отличаются от остального мира. Например, в Т-Банке и Booking использовались общепринятые стандарты производительности и подходы SRE от Google. Google активно вкладывался в развитие/продвижение своих идей.
Meta же пошла во многом своим путем. Она появилась давно и, как и Google, параллельно развивала внутренние подходы, затачивая их под свои нужды. За годы требования к метрикам и инструментам росли, и в итоге базовый уровень здесь значительно выше, чем, например, в Booking.com или Тинькофф и подкреплено отличным инструментарием.
Для меня тоже многое изменилось в подходе к улучшению производительности. В Тинькофф я много работал над оптимизацией фреймворка Tramvai: как загружаются JS/CSS на клиенте, как происходит инициализация приложения и так далее. Это были довольно низкоуровневые оптимизации.
В Meta же я работаю в продуктовой команде, которая отвечает за оптимизацию самих приложений. Мой фокус сместился с низкого уровня на уровень приложений — как сделать так, чтобы они выглядели и загружались быстро для пользователей.
Это сильно изменило мои приоритеты. Вот несколько ключевых моментов:
-
- Meta создала GraphQL, чтобы решить проблему избыточной загрузки данных (оверфетчинга) на клиенте. На бумаге это работает: клиенты могут выбирать, какие данные загружать. Но на практике компоненты обрастают множеством сценариев, становятся монолитными, и в итоге оверфетчинг всё равно возникает. С этим приходится бороться через рефакторинг.
- Близость к командам, разрабатывающим React, React Native и Relay. Это похоже на то, как в Тинькофф я мог бы обсуждать задачи с разработчиками Tramvai и просить у них помощи. Здесь то же самое. При этом внести улучшения довольно просто. Например, мои правки для производительности React Native: https://github.com/facebook/react-native/pull/46103/files и https://github.com/facebook/react-native/pull/47965.
В итоге за 8 месяцев в Meta я как минимум посмотрел на тему производительности с другой стороны — с продвинутым инструментарием и подходами, где не пришлось строить этот процесс с нуля, как это было, например, в Тинькофф. И увидел изнутри огромную компанию с десятками тысяч инженеров и гигантским офисом MPK 22, 21, 12, где можно идти пешком с одного конца до другого 30 минут, а между концами офисов ходят шаттлы.
В основном я занимался производительностью и надежностью (Reliability) — тем, чем, собственно, и занимался последние 10 лет. И в этих аспектах особенно заметно, чем большие компании отличаются от остального мира. Например, в Т-Банке и Booking использовались общепринятые стандарты производительности и подходы SRE от Google. Google активно вкладывался в развитие/продвижение своих идей.
Meta же пошла во многом своим путем. Она появилась давно и, как и Google, параллельно развивала внутренние подходы, затачивая их под свои нужды. За годы требования к метрикам и инструментам росли, и в итоге базовый уровень здесь значительно выше, чем, например, в Booking.com или Тинькофф и подкреплено отличным инструментарием.
Для меня тоже многое изменилось в подходе к улучшению производительности. В Тинькофф я много работал над оптимизацией фреймворка Tramvai: как загружаются JS/CSS на клиенте, как происходит инициализация приложения и так далее. Это были довольно низкоуровневые оптимизации.
В Meta же я работаю в продуктовой команде, которая отвечает за оптимизацию самих приложений. Мой фокус сместился с низкого уровня на уровень приложений — как сделать так, чтобы они выглядели и загружались быстро для пользователей.
Это сильно изменило мои приоритеты. Вот несколько ключевых моментов:
-
@defer и @stream. В статье https://engineering.fb.com/2020/05/08/web/facebook-redesign/ хорошо описаны подходы к загрузке данных. Например, при загрузке ленты постов бэкенд может отдавать данные как поток: по мере готовности посты отправляются клиенту. В итоге первые два поста загружаются максимально быстро и сразу показываются пользователю, а остальное подгружается в фоне в том же запросе. @defer работает похоже: приоритет отдается данным для экрана, который пользователь видит первым, а остальное загружается в фоне. Эти продвинутые подходы значительно ускоряют визуальную производительность приложения.- Meta создала GraphQL, чтобы решить проблему избыточной загрузки данных (оверфетчинга) на клиенте. На бумаге это работает: клиенты могут выбирать, какие данные загружать. Но на практике компоненты обрастают множеством сценариев, становятся монолитными, и в итоге оверфетчинг всё равно возникает. С этим приходится бороться через рефакторинг.
- Близость к командам, разрабатывающим React, React Native и Relay. Это похоже на то, как в Тинькофф я мог бы обсуждать задачи с разработчиками Tramvai и просить у них помощи. Здесь то же самое. При этом внести улучшения довольно просто. Например, мои правки для производительности React Native: https://github.com/facebook/react-native/pull/46103/files и https://github.com/facebook/react-native/pull/47965.
В итоге за 8 месяцев в Meta я как минимум посмотрел на тему производительности с другой стороны — с продвинутым инструментарием и подходами, где не пришлось строить этот процесс с нуля, как это было, например, в Тинькофф. И увидел изнутри огромную компанию с десятками тысяч инженеров и гигантским офисом MPK 22, 21, 12, где можно идти пешком с одного конца до другого 30 минут, а между концами офисов ходят шаттлы.
