Full Stack - nponeccop/vz GitHub Wiki
Web Development Ideal Full Stack
Постановка задачи
Есть проблемы, реальность которых подтверждена практикой:
(это не вообще а конкретно у нас и нашей практикой)
- монолитные приложения на Node.js долго рестартуют, особенно при использовании in-memory store
- компоненты падают, но редко. Эти падения не должны приводить к нарушениям в работе приложения, в традициях OTP
- наколенный сторадж постоянно повреждается - из-за крешей пишущего приложения, резета хостингом, окончания места
- обновления системных библиотек непредсказуемо разрушают продакшен. Нужно обеспечить чтобы продакшен был точной копией стейджинга.
- откат на прошлые версии затруднён. Теги в сорс-контроле работают плохо. Архив всех прошлых имиджей лучше т.к. не требует дисциплины
- сбор и хранение исходных данных должны быть независимы от производных данных. Производные данные должны считаться кешом, а инвалидация и перезаполнение этого кеша - штатной процедурой, а не исключительным восстановлением после сбоя.
- необходим трекинг и аналитика редких событий - как то переполнение памяти или странные сообщения в логе. Группировка похожих стектрейсов и отслеживание частоты.
- утечку памяти с периодическим перезапуском следует считать нормой. Нужны средства ограничения и мониторинга.
- сложные UI требуют особого подхода к MVC
- большое количество данных требует особого подхода к синхронизации
- персистент-базы (сохраняющие всю историю) и социальная авторизация (отсутствие собственной базы паролей) хорошо себя зарекомендовали
Невыполнимые задачи
Невыполнимую задачу нельзя заткнуть докупив железа. Поскольку она изначально нереализуема ни на каком железе и её приходится урезать до возможностей железа.
Самый простой пример невыполнимой задачи - компьютерная игра. Как только железо ускоряется - усложняется и игра.
Storage
Основное требование ACID (у взрослых дядь, а не хипсторов, решено с 1970х):
- A - не должно быть повреждений "половина записалась". Если сбой в процессе записи - гарантированно ничего не записывается.
- С - нельзя записать противоречащие друг другу данные
- I - не должно быть повреждений ACD из-за того что 2 клиента что-то делают параллельно
- D - один раз записанное не должно повреждаться
Такие базы есть: cписок в ответах на SO
https://www.xaprb.com/blog/2014/06/08/time-series-database-requirements/ - список требований к базе временных рядов. У нас всё наоборот - повышенные требования к целостности, больше чтений и в IO мы не упремся от слова никогда (если правильно готовить SSD а не по-рабочекрестьянски без учета страничной организации и внутреннего паралеллизма).
MS Azure
из аналитикс сервисов есть:
- Машинное обучение - ощные облачные средства прогнозируемой аналитики для диагностического обслуживания
- Stream Analytics - Обработка потоковых данных от миллионов устройств Интернета вещей в режиме реального времени
- HDInsight - Подготовка облачных кластеров Hadoop, Spark, R Server, HBase и Storm. Это единственное полностью управляемое облачное предложение Hadoop, предоставляющее оптимизированные аналитические кластеры с открытым кодом для Spark, Hive, MapReduce, HBase, Storm, Kafka и R Server
- Cognitive Services - Контекстуальное взаимодействие с помощью возможностей интеллектуального интерфейса API
- Azure Bot - Интеллектуальная серверно-независимая служба для программ-роботов, масштабируемая по требованию
- Data lake analytics - Распределенные службы аналитики, которые упрощают работу с большими данными
- Power BI Embedded - Узнайте, как встраивать в свои приложения впечатляющие, полностью интерактивные визуализации данных
Доклады Тонского
Там 100500 докладов, вот по пункту "сложные UI требуют особого подхода к MVC". Это обзор всего что было налеплено прогрессивного с момента создания фейсбуком Реакта в 2013 году:
https://dl.dropboxusercontent.com/u/561580/conferences/2016.12%20Clojure%20eXchange.pdf
Front-end
https://risingstars2016.js.org/