А что с переиспользованием кода в омниканальности? Ну, т.е.написали логическую часть сразу трех фронтов на каком-нибудь Свифт или Котлин и на трех платформах сразу запустили — выигрыша в производительности кода нет (да и нафиг он нужен на том коде, что есть на клиентах, как Вы правильно отметили!?), но вот выигрыш в производительности разработчиков может быть кратным (или не может?). Останется только верстальщиков-стажеров старших курсов универа держать на 3 платформы (или даже ИИ, куда ж без него). А единственный сеньор будет логику фронтов сразу на 3 платформы писать… Этакий горизонтальный фулл-стек…
Вопрос от Вашего коллеги по департаменту. Если что, вопрос не праздный — действительно предлагаю покопать в эту сторону — чем черт не шутит, вдруг в наших конкретных условиях это нехило стрельнет 🤷♂️
А вы хорошо понимаете сферу применимости рефакторинга?
Применять его кругом ведь тоже жутко вредно. У него очень узко обозначенная сфера применения – только тот код, который часто меняется. Как ниже отметили, вредно рефакторить код, который не меняется. Зачем? Главная цель рефакторинга – сделать код более легким для понимания. Так или не так?
Но если этот код не меняется, а значит, потребность в понимании совсем отсутствует, то цель рефакторинга тоже отсутствует. А если цель для применения инструмента отсутствует, то зачем махать инструментом? Чтоб повысить вероятность причинить себе им нечаянный ущерб? Вам все верно выше отметили...
Ну, а следующий этап – это понимание концепции изоляции. Необходимостью внесения изменений можно управлять, уменьшая и без того низкую необходимость изменений. В итоге, 80% вашего кода пишутся 1 раз и больше никогда в жизни не меняются. Да, рабочая концепция. Да, мы её применяем у себя.
Интересно, почему не довели концепцию модуляризации на iOS до состояния, как на Андроид? Почему так же не попили монолитную часть приложения на app-связку, собирающую независимые фичи? Не ожидаете, что iOS из-за этого сильно раньше своего лимита расширения достигнет? Вы ж не завершили задачу на iOS.
Писало вас трое на 2 платформы, или были еще участники? Как долго? Сколько экранов суммарно в приложении? До сотни? Тысячи? Сколько? Или в строчках кода, например... Сколько времени все заняло?
В остальном – молодцы. Low coupling/High сohesion и/или коннасценция – основа любого проекта. Еще в 70-е (90-е, если говорим про более проработанную концепцию коннасценции) годы это доказано было :)
Во всех этих дискуссиях о х10-продуктивности почему-то всегда рассматриваются только конкретные ездовые кони личности с конкретными навыками. При этом обходятся стороной реальные вопросы, влияющие на продуктивность и эффективность. Например:
Синергия или эмерджентность – система легко может быть сильно производительнее или эффективнее, чем сумма результатов или эффективностей отдельных её частей. В случае с программистами это означает, что 10 хорошо сплоченных и организованных разработчиков могут перформить сильно больше и эффективнее, чем сумма их результатов по отдельности. Я лично наблюдаю этот эффект.
В общем, нужно х10 искать не у отдельного программиста по сравнению с коллегой за соседним столом, а у целых коллективов по сравнению с аналогичными коллективами в конкурирующих подразделениях. В таком случае картинка становится прям явной, отчетливой и не вызывающей сомнений.
Второй момент: производительность и эффективность – 2 разные вещи. Высокую производительность получить просто, а вот высокую эффективность, которая потом будет синергично с положительной обратной связью повышать производительность - сильно сложнее. А сделать это еще и в долгосрочную перспективу – вообще задача со звездочкой даже для очень опытного менеджера. А это снова уже про организацию и процессы, а не про конкретные навыки конкретного индивида.
Самый интересный вывод из этого всего примерно такой: х10 работают не в вакууме, а у хороших руководителей, которые понимают, как строить эффективные и продуктивные системы не только в краткосрок, но и в долгосрок. Хотите стать х10 и понять, как это? – ищите высокоэффективные системы и их руководителей, но вряд ли Вам там будут много платить, но это уже совершенно другой вопрос – на целый цикл статей, а то и на курс в университете :)
Беглый гуглинг показывает, что этот инструмент не поддерживает следующие языки, которые у нас в ТЗ перечислены: скрипты Shell, Ruby -- и файлы конфигураций Yaml. Собственно об этом и было в начале статьи отмечено.
А так, конечно, инструмент, который бы уже умел стандартные комментарии тащить из всех используемых у нас файлов был бы существенно круче. Но мы такого не нашли. Зоопарк из разных инструментов тоже решили не устраивать... хотя что я буду повторять автора и его статью, там все уже написано :)
А можете подсказать затраты не в абсолютном времени, а в абстрактных человекогодиках? Сколько сотрудников у вас занимались этим переписыванием на протяжении указанных 2,5-3 лет?
Ну, по-хорошему именно так. Авторизация и не должна идти в бизнес-логику, соглашусь. Она должна через отдельный сервис определить, какая страница какому клиенту доступна, а какая — нет.
Вопрос не менее дискуссионный, чем те, что мы обсуждали выше и ниже :) но HTTP присылает код 403 в этом случае вроде? Почему-то HTTP решил, что это транспортный уровень – видимо, были причины. Возможно потому, что проверка осуществляется все же еще ДО входа в слой бизнес логики.
Проверки авторизации, кажется, реализуются, как и аутентификация по шаблону проектирования "Прокси", т.е.еще до передачи управления в бизнес-логику осуществляют все необходимые проверки, возможно с запросом бизнес-логики, но точно без передачи ей управления... Прокси – это как раз доп.слой перед уровнем логики. В чистом виде.
Ну, вот я (да и вроде сообщество) не относят аутентификацию и авторизацию к бизнес-логике. Это логика уровня безопасности или управления доступами. Об этом я и говорю, что конкретно эта часть должна быть отделена от бизнес-логики и обрабатываться отдельно. В HTTP оно как раз в уровне транспорта и осуществляется. Как и прочие редиректы, кеширование и другие свистопляски...
Это место будет одно, да. Но оно в HTTP уже реализовано, зачем мне его повторять? Чтоб показать, какой я крутой? Мой бизнес и так это знает и лишний раз за это платить не хочет :) Так что я лично предпочитаю так за чужой счет не самоутверждаться.
Если этого же функционала для WebSocket нет, то придется его реализовать. Но опять же, не стоит смешивать это с бизнес-логикой. Это другой уровень...
Ну, и отлично. Реализуйте на WebSocket'ах ту часть, что реализована на HTTP. Кеширование, редиректы, аутентификации, авторизации и проч. (Если оно, конечно, нужно, хотя сама идея выглядит почему-то сомнительно и стоит тут откатиться назад и подумать зачем же дублировать REST на WebSocket и нельзя ли эту же задачу решить как-то по другому, без этого "характерного запаха").
Логическую-часть оставьте отдельно и независимо. Она будет одна на оба транспорта.
Какой смысл объединять логическую часть с той частью HTTP, которая не реализована в WebSocket? Только потому что Вы её вынуждены реализовывать? Ну, ок. А стоит это сколько? Вы точно сможете HTTP-часть без ошибок и полностью повторить? А зачем повторять, если она уже есть? Используйте готовую реализацию там, где она есть - проблем хотя бы на этом транспорте не будет. Будете с ней сравнивать свою реализацию для WebSocket, как с эталоном. Еще и пошарите в OpenSource, когда закончите. Реализация будет не завязана на детали внутренней логики именно Вашего приложения и просто будет дублировать стандарт HTTP (хоть это и сомнительно само по себе), поэтому её сможет переиспользовать любой.
Так вышло, что REST – не протокол, не стандарт, это лишь архитектура, если верить Википедии. А если это архитектура, то она может быть составлена из разных слоев (транспортного и логического). Так вышло, что стандартные реализации есть для HTTP (на всех слоях), но их нет для WebSocket (или есть? JSON-RPC разве, как раз, не оно?) – ну, реализуйте сами. Но по архитектуре, а не все на логическом уровне. Реализация только на логическом уровне не будет REST, если верить Википедии и такому её пониманию. Но я не претендую на истинность этого понимания. Просто высказываю свою точку зрения.
Применительно к вашему джейсону все, что в representation будет обрабатываться логическим уровнем, все остальное (что выше) – транспортным. Разделяй и властвуй. Я лишь об этом...
Что думаете по этому поводу? Только давайте без очередных отсылок на WebSocket или неконсистентные коды ошибок. Вроде это мы уже слышали. Раскрывайте свои мысли, пожалуйста.
У меня нет "каких-то обработчиков ошибок бизнес-логики". У меня, допустим, есть один конкретный обработчик описанной Вами ситуации со страницей в одном единственном месте, в одном единственном сервисе, предоставляющем страницы книги.
Во всех остальных 99 местах у меня даже обработчика нет, я пользуюсь доступным из коробки, из системы, от HTTP.
Вы мне предлагаете этот единственный конкретный обработчик бизнес-логики сервиса страницы сделать общим для всех моих 9 сервисов и впихнуть его, например, в сервис аккаунта пользователя. Верно я Вас понял? Зачем сервису аккаунта пользователя знать что-то про ошибку бизнес-логики сервиса страниц? И вообще детали того, как обрабатываются конкретные ошибки бизнес-логики в соседнем сервисе? А если коды ошибок бизнес-логики совпадут в разных сервисах?
А еще мы не рассмотрели варианты, когда транспортные коды приводят к перезапросам, переавторизациям, обновлениям токенов, маршрутизации или покупке подписок. Не надо мух с котлетами – в одну сковородку...
Повторю ответ на Ваш вопрос. Меня заставляет разделять ошибки транспорта и логики – экономия и эффективность. Имхо, этот путь дешевле.
Вот тут об этом же. Но если есть цифры, какой из путей дешевле и проще, буду рад с ними ознакомиться.
HTTP-коды? Они ж уже реализованы и доступны из коробки на любой платформе. Остается только научиться ими пользоваться. И тогда, да, реализовывать дубль обработки кодов на соседнем уровне не придется.
Только в конкретных узких случаях, что сильно дешевле, чем продублировать всю систему, связать её независимые сервисы в один клубок, и обязать все связанное теперь обрабатывать ошибки настолько детально, насколько это необходимо одному единственному сервису. А Вы предлагает вот так действовать и считаете, что это будет дешевле и проще?
Это 2 разных уровня обработки с разной детализацией. Они не взаимоисключающие. Наоборот...
Реализация на основе HTTP-кодов может быть одна универсальная на все приложение. Да, будут проблемы с точностью описания ошибки. Зато дешево и сердито.
Если нужно дорого и детально прорабатывать, то пожалуйста - можно подниматься на уровень выше (или спускаться на уровень ниже, смотря как располагать уровни) и детализировать.
В этом смысл уровней. Есть один универсальный обработчик, если он не устраивает, дописываете конкретные обработчики на более высоких (низких уровнях) уровнях. За доп.деньги. При этом универсальный код все так же продолжает работать, если вдруг Вы забыли написать более конкретные вещи…
Поэтому заменять обработку HTTP-кодов джейсоном всегда – в корне неверно. Вы заранее обрекаете себя всегда на излишние затраты. Наоборот, правильно делать общие обработчики и потом их дополнять деталями, если это кому-то будет нужно и кто-то это оплатит...
А вот если использовать свою систему ошибок, не полагаясь на протокол, то единый интерфейс вполне себе возможен. Просто в WebSocket будет небольшой оверхед на id запроса и глагол (действие). А вся остальная часть будет той же самой.
Как-будто и используя систему ошибок HTTP тоже можно...
Вы ж просто расширите WebSocket транспортными ошибками, нет? Их можно придумать свои, а можно взять готовые из HTTP – в чем разница-то?
Как-будто это и есть рабочая, правильная и рекомендованная схема. Ошибки получаются разделенными на 2 уровня - транспортные и логические. При этом они могут быть использованы с любым транспортом (при расширении транспорта, не поддерживающего эти ошибки). Сами ошибки в такой схеме тоже генерируются и обрабатываются на двух разных уровнях и друг с другом не смешиваются, что хорошо.
Как-будто Вы с автором статьи говорите ровно об одном и том же, но разными словами.
Позволю себе добавить в миф про кеширование. На мобилах очень популярны библиотеки кеширования – огромное множество библиотек, которые слоем выше HTTP на клиенте полностью дублируют функционал, который уже имеется в HTTP из коробки. Например, SDWebImage для кеширования картинок на iOS. Для меня, например, такие библиотеки – сигнал, что команда (серверные и клиентские разработчики и аналитик) совершенно не проработала свой функционал. Соответственно, библиотеки эти из мобил надо выпиливать нещадно, а команду обучать лучшим практикам кеширования, встроенным в любую систему и сам протокол HTTP.
Вы же развернете детальнее свою мысль и предоставите подтверждающие факты, или это так и останется пустым оскорблением? :)
С производительностью все понятно, спасибо.
А что с переиспользованием кода в омниканальности? Ну, т.е.написали логическую часть сразу трех фронтов на каком-нибудь Свифт или Котлин и на трех платформах сразу запустили — выигрыша в производительности кода нет (да и нафиг он нужен на том коде, что есть на клиентах, как Вы правильно отметили!?), но вот выигрыш в производительности разработчиков может быть кратным (или не может?). Останется только верстальщиков-стажеров старших курсов универа держать на 3 платформы (или даже ИИ, куда ж без него). А единственный сеньор будет логику фронтов сразу на 3 платформы писать… Этакий горизонтальный фулл-стек…
Вопрос от Вашего коллеги по департаменту. Если что, вопрос не праздный — действительно предлагаю покопать в эту сторону — чем черт не шутит, вдруг в наших конкретных условиях это нехило стрельнет 🤷♂️
А вы хорошо понимаете сферу применимости рефакторинга?
Применять его кругом ведь тоже жутко вредно. У него очень узко обозначенная сфера применения – только тот код, который часто меняется. Как ниже отметили, вредно рефакторить код, который не меняется. Зачем? Главная цель рефакторинга – сделать код более легким для понимания. Так или не так?
Но если этот код не меняется, а значит, потребность в понимании совсем отсутствует, то цель рефакторинга тоже отсутствует. А если цель для применения инструмента отсутствует, то зачем махать инструментом? Чтоб повысить вероятность причинить себе им нечаянный ущерб? Вам все верно выше отметили...
Ну, а следующий этап – это понимание концепции изоляции. Необходимостью внесения изменений можно управлять, уменьшая и без того низкую необходимость изменений. В итоге, 80% вашего кода пишутся 1 раз и больше никогда в жизни не меняются. Да, рабочая концепция. Да, мы её применяем у себя.
Интересно, почему не довели концепцию модуляризации на iOS до состояния, как на Андроид? Почему так же не попили монолитную часть приложения на app-связку, собирающую независимые фичи? Не ожидаете, что iOS из-за этого сильно раньше своего лимита расширения достигнет? Вы ж не завершили задачу на iOS.
Присоединяюсь к вопросу.
Писало вас трое на 2 платформы, или были еще участники? Как долго? Сколько экранов суммарно в приложении? До сотни? Тысячи? Сколько? Или в строчках кода, например... Сколько времени все заняло?
В остальном – молодцы. Low coupling/High сohesion и/или коннасценция – основа любого проекта. Еще в 70-е (90-е, если говорим про более проработанную концепцию коннасценции) годы это доказано было :)
Во всех этих дискуссиях о х10-продуктивности почему-то всегда рассматриваются только конкретные
ездовые кониличности с конкретными навыками. При этом обходятся стороной реальные вопросы, влияющие на продуктивность и эффективность. Например:Синергия или эмерджентность – система легко может быть сильно производительнее или эффективнее, чем сумма результатов или эффективностей отдельных её частей. В случае с программистами это означает, что 10 хорошо сплоченных и организованных разработчиков могут перформить сильно больше и эффективнее, чем сумма их результатов по отдельности. Я лично наблюдаю этот эффект.
В общем, нужно х10 искать не у отдельного программиста по сравнению с коллегой за соседним столом, а у целых коллективов по сравнению с аналогичными коллективами в конкурирующих подразделениях. В таком случае картинка становится прям явной, отчетливой и не вызывающей сомнений.
Второй момент: производительность и эффективность – 2 разные вещи. Высокую производительность получить просто, а вот высокую эффективность, которая потом будет синергично с положительной обратной связью повышать производительность - сильно сложнее. А сделать это еще и в долгосрочную перспективу – вообще задача со звездочкой даже для очень опытного менеджера. А это снова уже про организацию и процессы, а не про конкретные навыки конкретного индивида.
Самый интересный вывод из этого всего примерно такой: х10 работают не в вакууме, а у хороших руководителей, которые понимают, как строить эффективные и продуктивные системы не только в краткосрок, но и в долгосрок. Хотите стать х10 и понять, как это? – ищите высокоэффективные системы и их руководителей, но вряд ли Вам там будут много платить, но это уже совершенно другой вопрос – на целый цикл статей, а то и на курс в университете :)
Беглый гуглинг показывает, что этот инструмент не поддерживает следующие языки, которые у нас в ТЗ перечислены: скрипты Shell, Ruby -- и файлы конфигураций Yaml. Собственно об этом и было в начале статьи отмечено.
А так, конечно, инструмент, который бы уже умел стандартные комментарии тащить из всех используемых у нас файлов был бы существенно круче. Но мы такого не нашли. Зоопарк из разных инструментов тоже решили не устраивать... хотя что я буду повторять автора и его статью, там все уже написано :)
А можете подсказать затраты не в абсолютном времени, а в абстрактных человекогодиках? Сколько сотрудников у вас занимались этим переписыванием на протяжении указанных 2,5-3 лет?
Ну, по-хорошему именно так. Авторизация и не должна идти в бизнес-логику, соглашусь. Она должна через отдельный сервис определить, какая страница какому клиенту доступна, а какая — нет.
Вопрос не менее дискуссионный, чем те, что мы обсуждали выше и ниже :) но HTTP присылает код 403 в этом случае вроде? Почему-то HTTP решил, что это транспортный уровень – видимо, были причины. Возможно потому, что проверка осуществляется все же еще ДО входа в слой бизнес логики.
Проверки авторизации, кажется, реализуются, как и аутентификация по шаблону проектирования "Прокси", т.е.еще до передачи управления в бизнес-логику осуществляют все необходимые проверки, возможно с запросом бизнес-логики, но точно без передачи ей управления... Прокси – это как раз доп.слой перед уровнем логики. В чистом виде.
Ну, вот я (да и вроде сообщество) не относят аутентификацию и авторизацию к бизнес-логике. Это логика уровня безопасности или управления доступами. Об этом я и говорю, что конкретно эта часть должна быть отделена от бизнес-логики и обрабатываться отдельно. В HTTP оно как раз в уровне транспорта и осуществляется. Как и прочие редиректы, кеширование и другие свистопляски...
Это место будет одно, да. Но оно в HTTP уже реализовано, зачем мне его повторять? Чтоб показать, какой я крутой? Мой бизнес и так это знает и лишний раз за это платить не хочет :) Так что я лично предпочитаю так за чужой счет не самоутверждаться.
Если этого же функционала для WebSocket нет, то придется его реализовать. Но опять же, не стоит смешивать это с бизнес-логикой. Это другой уровень...
Так понятнее?
Ну, и отлично. Реализуйте на WebSocket'ах ту часть, что реализована на HTTP. Кеширование, редиректы, аутентификации, авторизации и проч. (Если оно, конечно, нужно, хотя сама идея выглядит почему-то сомнительно и стоит тут откатиться назад и подумать зачем же дублировать REST на WebSocket и нельзя ли эту же задачу решить как-то по другому, без этого "характерного запаха").
Логическую-часть оставьте отдельно и независимо. Она будет одна на оба транспорта.
Какой смысл объединять логическую часть с той частью HTTP, которая не реализована в WebSocket? Только потому что Вы её вынуждены реализовывать? Ну, ок. А стоит это сколько? Вы точно сможете HTTP-часть без ошибок и полностью повторить? А зачем повторять, если она уже есть? Используйте готовую реализацию там, где она есть - проблем хотя бы на этом транспорте не будет. Будете с ней сравнивать свою реализацию для WebSocket, как с эталоном. Еще и пошарите в OpenSource, когда закончите. Реализация будет не завязана на детали внутренней логики именно Вашего приложения и просто будет дублировать стандарт HTTP (хоть это и сомнительно само по себе), поэтому её сможет переиспользовать любой.
Так вышло, что REST – не протокол, не стандарт, это лишь архитектура, если верить Википедии. А если это архитектура, то она может быть составлена из разных слоев (транспортного и логического). Так вышло, что стандартные реализации есть для HTTP (на всех слоях), но их нет для WebSocket (или есть? JSON-RPC разве, как раз, не оно?) – ну, реализуйте сами. Но по архитектуре, а не все на логическом уровне. Реализация только на логическом уровне не будет REST, если верить Википедии и такому её пониманию. Но я не претендую на истинность этого понимания. Просто высказываю свою точку зрения.
Применительно к вашему джейсону все, что в representation будет обрабатываться логическим уровнем, все остальное (что выше) – транспортным. Разделяй и властвуй. Я лишь об этом...
Что думаете по этому поводу? Только давайте без очередных отсылок на WebSocket или неконсистентные коды ошибок. Вроде это мы уже слышали. Раскрывайте свои мысли, пожалуйста.
Именно! И если не использовать HTTP-статусы, то всю эту логику придется ручками повторять в приложении. А её там немало...
У меня нет "каких-то обработчиков ошибок бизнес-логики". У меня, допустим, есть один конкретный обработчик описанной Вами ситуации со страницей в одном единственном месте, в одном единственном сервисе, предоставляющем страницы книги.
Во всех остальных 99 местах у меня даже обработчика нет, я пользуюсь доступным из коробки, из системы, от HTTP.
Вы мне предлагаете этот единственный конкретный обработчик бизнес-логики сервиса страницы сделать общим для всех моих 9 сервисов и впихнуть его, например, в сервис аккаунта пользователя. Верно я Вас понял? Зачем сервису аккаунта пользователя знать что-то про ошибку бизнес-логики сервиса страниц? И вообще детали того, как обрабатываются конкретные ошибки бизнес-логики в соседнем сервисе? А если коды ошибок бизнес-логики совпадут в разных сервисах?
А еще мы не рассмотрели варианты, когда транспортные коды приводят к перезапросам, переавторизациям, обновлениям токенов, маршрутизации или покупке подписок. Не надо мух с котлетами – в одну сковородку...
Повторю ответ на Ваш вопрос. Меня заставляет разделять ошибки транспорта и логики – экономия и эффективность. Имхо, этот путь дешевле.
Вот тут об этом же. Но если есть цифры, какой из путей дешевле и проще, буду рад с ними ознакомиться.
HTTP-коды? Они ж уже реализованы и доступны из коробки на любой платформе. Остается только научиться ими пользоваться. И тогда, да, реализовывать дубль обработки кодов на соседнем уровне не придется.
Только в конкретных узких случаях, что сильно дешевле, чем продублировать всю систему, связать её независимые сервисы в один клубок, и обязать все связанное теперь обрабатывать ошибки настолько детально, насколько это необходимо одному единственному сервису. А Вы предлагает вот так действовать и считаете, что это будет дешевле и проще?
Вот тут ответ на этот вопрос. От общего к частному всегда дешевле, чем сразу все утыкивать частностями без необходимости...
Это 2 разных уровня обработки с разной детализацией. Они не взаимоисключающие. Наоборот...
Реализация на основе HTTP-кодов может быть одна универсальная на все приложение. Да, будут проблемы с точностью описания ошибки. Зато дешево и сердито.
Если нужно дорого и детально прорабатывать, то пожалуйста - можно подниматься на уровень выше (или спускаться на уровень ниже, смотря как располагать уровни) и детализировать.
В этом смысл уровней. Есть один универсальный обработчик, если он не устраивает, дописываете конкретные обработчики на более высоких (низких уровнях) уровнях. За доп.деньги. При этом универсальный код все так же продолжает работать, если вдруг Вы забыли написать более конкретные вещи…
Поэтому заменять обработку HTTP-кодов джейсоном всегда – в корне неверно. Вы заранее обрекаете себя всегда на излишние затраты. Наоборот, правильно делать общие обработчики и потом их дополнять деталями, если это кому-то будет нужно и кто-то это оплатит...
Как-будто и используя систему ошибок HTTP тоже можно...
Вы ж просто расширите WebSocket транспортными ошибками, нет? Их можно придумать свои, а можно взять готовые из HTTP – в чем разница-то?
Как-будто это и есть рабочая, правильная и рекомендованная схема. Ошибки получаются разделенными на 2 уровня - транспортные и логические. При этом они могут быть использованы с любым транспортом (при расширении транспорта, не поддерживающего эти ошибки). Сами ошибки в такой схеме тоже генерируются и обрабатываются на двух разных уровнях и друг с другом не смешиваются, что хорошо.
Как-будто Вы с автором статьи говорите ровно об одном и том же, но разными словами.
Нет страницы? Даже если нет книги, то страницы-то тоже нет. В чем противоречие?
Спасибо за статью.
Позволю себе добавить в миф про кеширование. На мобилах очень популярны библиотеки кеширования – огромное множество библиотек, которые слоем выше HTTP на клиенте полностью дублируют функционал, который уже имеется в HTTP из коробки. Например, SDWebImage для кеширования картинок на iOS. Для меня, например, такие библиотеки – сигнал, что команда (серверные и клиентские разработчики и аналитик) совершенно не проработала свой функционал. Соответственно, библиотеки эти из мобил надо выпиливать нещадно, а команду обучать лучшим практикам кеширования, встроенным в любую систему и сам протокол HTTP.