Pull to refresh
61
0
Сергей Пугачёв @WizardBox

Пользователь

Send message

Классные анонсы и хорошая идея с Twitch трансляциями

Вообще мы, конечно, живём в 4G мире, но к сожалению не всегда. Подключение в городах очень нестабильно, задержки достаточно большие. Во многих квартирах не то что 4G нет, а 3G плохо работает. Люди выезжают за город, ездят в электричках, ходят по торговым центрам и, если на улице может быть вполне хороший коннект, то в конкретном магазине в ТЦ, всё может быть очень грустно.


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

Интересный вопрос — какой поиск назвать "полноценным", так как больше половины завпросов идёт как раз через мобильную версию ;) На десктопе открытие AMP из поиска Google ещё не делал.

Сейчас иконка показывается только в мобильной выдаче


Это странно, у меня в точности такая же версия Chrome, и адресная строка появляется корректно.

Да, всегда считал что для PWA в сравнении с нативными приложениями, индексанция поисковиками — это плюс, так как PWA индексируются лучше нативных, а уж с server side rendering — всё вообще прекрасно.

Очень правильное замечание. Хоть большинство PWA и являются SPA, но есть много и таких, которые не SPA, и я и статье специально про это пишу, так как это самое большое заблуждение, наверное, что PWA доллжны быть SPA. Такого требования нет.

А вы точно ничего не путаете и статья была именно про PWA? Очень бы хотелось посмотреть на такую статью. Потому что обсуждение с позиции выгодности-невыгодности были про AMP. По PWA же есть консенсус, и все вендоры от Apple до Microsoft поддерживают соответствующие старндарты.

Рассматривайте это не как зоопарк, а как framework. Просто при использовании каждой новой возможности нужно проверять поддерживается ли она браузером. Ну и нужно использовать полифилы. Поэтому с обеспечением совместимости конечно есть проблемы, с этим не поспоришь, но всё так плохо.

Web как раз и прекрасен тем, что можно делать прогрессивные улучшения. И для большой части технологий есть полифилы. Поэтому пользователь на IE10 может получить работающую версию сайта с хорошим дизайном и контентом, а люди с новым Chrome'ом или Firefox'ом с Edge получат новые фичи. Если какая-то возможность не поддерживается везде — это не значит что её нельзя использовать. Хороший пример JavaScript. Сейчас подавляющее большинство приложений используют свежие версии стандарта.

Так как наш сервис, использующий Tarantool и .NET Core c Linux, ещё в процессе разработки, то нормальных данных по нагрузке нет.


Но я склонен верить результатам тестов ASP.NET
(конечно потом проверю всё сам для нашего сервиса):
https://github.com/aspnet/benchmarks


И Tarantool:
https://habrahabr.ru/company/mailru/blog/281841/

На самом деле ответ на этот вопрос потянет на целую статью. На эту тему есть поста на facebook: https://www.facebook.com/leo.yuriev/posts/553318381522430?pnref=story


Но основное — это конечно то, что Tarantool — это полноценная СУБД:


Redis ориентирован на in-memory обработку с возможностью сохранять данные периодически или при остановке. Тарантул же может обеспечивать постоянную консистентность данных на диске.

Тарантул: Кроме снимков (aka snapshots, checkpoints, syncpoints) есть полноценный WAL (write ahead log). Соответственно "из коробки" можно обеспечить сохранность данных после каждого изменения.

Redis: Фактически есть только снимки базы. Технически есть AOF (append-only лог, в который пишутся все операции), но он требует ручного управления, в том числе ручного восстановления.
Проще говоря, в Redis вам необходимо "ручками" переодически приостанавливать сервер, формировать снимки и архивировать AOF.

Да, надо поправить формулировку. Речь идёт про конкретный микросервис авторизации и аунтетификации. Потребители микросервиса естественно на .NET.

Я конечно не призываю всё переписать на Lua (хотя технически так можно сделать). Идея в том, что не стоит рассматривать Tarantool исключительно как простое хранилище данных. У него гораздо больше возможностей. Поэтому можно обращаться к Tarantool напрямую из .NET, а можно построить REST-сервис и обращаться уже к нему. Я показал оба эти варианта. Естественно основная часть бизнес-логики в нашем случае на C#.

Да, там Linux образ. А правда, какие преимущества будут от запуска в Azure на Windows виртуалках вместо Linux виртуалок?

Не могу не согласиться, что иметь нативные exe-шники для Windows — это лучше чем не иметь их, с этим трудно поспорить. Но в статье я описал свой опыт, а у меня каких-либо проблем с использованием Tarantool при разработке на Windows не возникло.

Не сказал бы что с Linux подсистемой — это именно "пляски". Данная подсистема является всё-таки встроенной функциональностью Windows 10 и запустить почти любой продукт в ней можно достаточно быстро (это дело минут).


С другой стороны если бы был exe-шник, то не потребовалось бы писать так много про установку Tarantool. Пока, к сожалению, либо Windows Subsystem for Linux, либо Docker.


При установленном Docker всё вообще запускается одной командой в один шаг. Куда уж проще:


> docker run -d tarantool/tarantool:1.7

>Tarantool.CSharp
Возможно выбрано не самое удачное название NuGet пакета. Каких-то привязок именно к C# в исходном коде я не нашёл. Поэтому в Visual Basic и F# нужно подключать этот же пакет.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity