Очень интересно.
Я правильно понимаю, что SSLsplit для клиента превратила https в http-соединение?
А браузер клиента не выдал никаких ошибок, когда изначально пытался открыть https-сайт, а вместо этого получил http?
Вы так и не ответили, зачем это нужно.
Если нужно просто хранить данные карты клиента, что бы ему было удобнее — тогда должен быть вопрос, нужно ли сохранять карту
и при этом не нужно хранить (знаю, что это не панацея, но всё же)
https://youtu.be/6By9j6SaqTo
Вот сравнение времени отклика приложения и сайта.
Сайт, как видите, сперва был закэширован — и всё равно приложение быстрее.
Facebook и некоторые сервисы от гугла
У меня сайты и фейсбука, и gmail-а загружаются заново, если браузер был вытеснен из памяти. А если интернета нет — не загружаются.
Про скорость:
> Ну я и говорю — что это заблуждение. каким образом реквест на апи из браузера будет занимать больше времени чем точно такой же реквест из нативного приложения?
реквест занимает столько же времени.
Разница в количестве реквестов и во времени их обработки.
Браузер не знает заранее, как должен выглядеть сайт, а приложение знает.
Значит приложению не нужно проверять протух ли кэш и не нужно генерить дизан страницы сайта.
То, что браузер компилит на ходу в приложении скомпилено заранее.
Браузер собирает сайт из конструктора, приложение вставляет целевой контент в формы, заранее подготовленные под конкретный сайт.
На практике — да, это приводит к тому, что в приложении работать быстрее и удобнее.
Фичи:
> Notifications api,
Это работает, но требует дополнительных ресурсов от браузера.
> Service workers
Если я сверну браузер, поиграю в игрушку, и вернусь к браузеру когда интернета уже нет — браузер уже выгрузился из памяти и закэшированная статья или инфа о пришедших комментах вместе с ним. В приложении проблем нет.
PS Может вы меня переубедите примером?
Вы знаете примеры сайтов, где всё обсуждаемое выше успешно реализовано для работы в мобильном браузере?
Пример приложения могу предоставить.
Очень интересно.
Я правильно понимаю, что SSLsplit для клиента превратила https в http-соединение?
А браузер клиента не выдал никаких ошибок, когда изначально пытался открыть https-сайт, а вместо этого получил http?
И зачем менять адрес сайта (www>wwww)
Спасибо, это полезная инфа.
Хочу отметить, что по проблеме не очевидно, в чьём логе ошибки искать. Тем более, сообщение появляется там не в момент высокой нагрузки, а при ребуте.
Тем и отличается хороший инженер по производительности, что и в отсутствии очевидного сообщения о ошибке он отыщет корень бед.
Достаточно вставить подставному игроку беспроводную камеру в глаз и иметь способ говорить ему куда ставить фишки
Блиин, не сразу понял, что стол качается
Работа с форматированием текста в веб-морде зимбры — это печалька по сравнению с аутлуком.
Эта культура неуважения личного времени сотрудников — отвратительна.
Ps я сам часто работаю сутками — но потому, что это нравится мне, а не потому, что мне приказали
Такого уровня материал хорош для личного блога.
На хабре нужны технические материалы.
Ага.
Но можно уже не придумывать, в соседней ветке выложили скрины, где объект исследования прямо предлагает фишинговые сайты на продажу
… если дропшиппер очень хочет сэкономить, получает заказ и данные кредитки, и потом просто снимает с неё деньги
Вы так и не ответили, зачем это нужно.
Если нужно просто хранить данные карты клиента, что бы ему было удобнее — тогда должен быть вопрос, нужно ли сохранять карту
и при этом не нужно хранить (знаю, что это не панацея, но всё же)
Для каких вообще легальных действий может понадобиться отправка платёжных данных клиента в телегу?
Я ввёл gmail.com, но он переслал на accounts.чего-то-там, потому, что у анализатора нет своего ящика на гмайле :)
Talater у меня не загрузился с мобильного :(
Про анализатор скорости сайта — смешно то, что сайт гуглоаккаунта ещё медленее ;)
https://youtu.be/6By9j6SaqTo
Вот сравнение времени отклика приложения и сайта.
Сайт, как видите, сперва был закэширован — и всё равно приложение быстрее.
У вас иначе?
Но откуда их ещё брать, кроме как смотреть в окно — хз :)
Спасибо!
Первое, что создаёт проблемы — работа с комментариями.
Узнать о комментариях можно либо проглядев их все, либо через емайл и при клике по ссылке подгружается заново вся страница с комментариями.
В смысле и вовсе api прикрыть?
В крайнем случае на вопросы можно и не отвечать.
> Ну я и говорю — что это заблуждение. каким образом реквест на апи из браузера будет занимать больше времени чем точно такой же реквест из нативного приложения?
реквест занимает столько же времени.
Разница в количестве реквестов и во времени их обработки.
Браузер не знает заранее, как должен выглядеть сайт, а приложение знает.
Значит приложению не нужно проверять протух ли кэш и не нужно генерить дизан страницы сайта.
То, что браузер компилит на ходу в приложении скомпилено заранее.
Браузер собирает сайт из конструктора, приложение вставляет целевой контент в формы, заранее подготовленные под конкретный сайт.
На практике — да, это приводит к тому, что в приложении работать быстрее и удобнее.
Фичи:
> Notifications api,
Это работает, но требует дополнительных ресурсов от браузера.
> Service workers
Если я сверну браузер, поиграю в игрушку, и вернусь к браузеру когда интернета уже нет — браузер уже выгрузился из памяти и закэшированная статья или инфа о пришедших комментах вместе с ним. В приложении проблем нет.
PS Может вы меня переубедите примером?
Вы знаете примеры сайтов, где всё обсуждаемое выше успешно реализовано для работы в мобильном браузере?
Пример приложения могу предоставить.