Pull to refresh
4
0.1
Алексей Повар @wert_lex

Server Side Developer

Send message

Постойте, я и не говорю, что нода хороша для CPU-bound операций. Больших фишек у ноды ровно две:


  1. асинхронный io с приятным интерфейсом для простых смертных (нет, последователи Карри, для этого не нужна специальная монада, и да, парни из мира Стандартных Изданий, для этого не нужно упражняться с тредпуллами), который внезапно показывает весьма приятную производительности без лишнего тюнинга.
  2. javascript. Который, внезапно, не смотря на все фу-фу-фу, доступен практически любому разработчику на Java, C, C++, C#, Pascal, PHP итд. А если немного подтянуть матчать и разобраться в том как работает this и прототипное наследование (которое, вообще говоря надмножество Java-like OOP), то внезапно оказывается, что это вполне пристойный инструмент. А если копнуть еще чуть глубже, то внезапно оказывается, что JS можно декорировать типами (flow), проверять линтерами, собирать под платформы разной степени древности (babel) и использовать фичи из черновиков грядущих стандартов прямо вот сейчас (опять, привет babel). Чем, не смотря на некоторую костыльность и соберисамность, может похвастаться далеко не каждый ЯП.

Теперь про CPU-bound и тот-самый excel. Я конечно в офисных xml делах не очень рублю, но что-то мне подсказывает, что если мы собираемся массово генерировать excel- файлики, то я бы предпочёл это действо передавать системе и вызывать отдельным процессом. Потому что наверняка есть хорошая сторонняя/системная тулза, которую не стоит пытаться запихнуть ни в ноду, ни в похапэ, ни в питон.


Это не значит, что надо писать на ноде всё и вся. Но для типовых веб-серверных задач нода — прекрасный, доступный и достаточно мощный инструмент.

Мы в каких-то видимо сильно разных мирах живём, но как мне видится пласт задач вида "сходи в базу, принеси A, потом прими решение на его основе и принеси Б" — довольно широкий и охватывает если не весь веб, то довольно серьезную его часть.


Разумеется, есть еще уйма CPU-bound задач, которые на ноду ложатся мягко говоря не очень. Но это ведь не делает ноду плохим инструментом, для решения io-bound задач.


Ну и многопоточность тоже момент очень хитрый. Безусловно многопоточность в природе нужна. Но в ряде случаев от этого можно отказаться, и поиметь определенный профит от этого — выше уже был пример с nginx.

У латеха есть еще одна проблема, сформулировать её можно так: если у вас есть проблема и вы решили использовать латех, у вас уже две проблемы.


Латех сам по себе весьма неплох, и позволяет сделать с документом практически всё, что угодно, но сам по себе достаточно сложен, и с автоматизацией тоже не всё так гладко, хотя и решаемо.

А на чём всё это написано, и не седеют ли программисты от такого количества асинхронной условной логики?

У меня немного другой опыт (но на скале я уже два года активно не пишу, до этого писал активно о). Если использовать скалу, как Better Java, то ничего хорошего из этого не получается. А если активно писать в около-функциональном стиле, то выясняется две интересных подробности:


  1. для этого надо знать слишком много о том, как работает JVM и во что превращается scala-код
  2. стоит только сделать небольшой шаг дальше композиции функций, как тут же возникает огромное количество вопросов, на которые в "продвинутом" скала-сообществе принято отвечать примерами на хаскеле.

Часть 0. Изучить Haskell, чтобы понимать функциональную магию Shapeless, Scalaz, Iteratee итд.

Да, для этого как раз существуют околобесплатные библиотеки. Те, которые здания.

Это далеко не всегда так.
Отдать страничку с данными и правда не сильно сложно, гораздо сложнее отдать часть приложения с данными. Потому что вдруг выясняется, что у фронтенда есть:


  • внутреннее состояние (любимый цвет кнопок, текст не до конца набранного комментария, настройки какого-нибудь фильтра и еще уйма интересных штук, которые разумеется более чем реализуемы в парадигме "отдать страничку, а при переходе по ссылке отдать следующую страничку", но по какой-то причине очень часто приводят к "я тут накидал на jquery, пожалуйста не трогай это никогда")
  • архитектура. Потому что на чистом HTML, CSS и JS можно реализовать всё что угодно, но на Angular (фанатам фейсбука читать как "React") оно почему-то выходит более поддерживаемым и работоспособным.
  • как ни странно, команда, которая обычно этим самым фронтендом занимаются фуллтайм, и обычно, при SPA подходе decoupling (как это по-русски правильно?) получается значительно выше.

Но ведь на текущем витке фронтендовых технологий SPA и правда удобнее и проще делать. Каноничный клиент-сервер кажется проще ровно до тех пор, пока внезапно не оказывается, что фильтры в интернет-магазине должны работать без перезагрузки страницы, справа внизу должен быть уютный чятик, а блок сравнения товаров желательно сделать так, чтобы он тоже не требовал перезагрузки страницы.
Современный веб уже очень сильно не про "отдать отрендеренную сервером страничку".

Разработка на Scala как она есть. Вообще нам в половину сервисов надо передавать неявно контекст, а в половину не надо. Поэтому мы не будем использовать implicit (прим. пер. — неявно) и дефолтный аргумент для него, а запилим свой микрофреймворк на 5kloc на шаблонах и с макросами, подвязанный через недокументированное api sbt и без документации, но зато с веб-интерфейсом на локалхосте, и вот оно :)

Это я пропустил, или автор в самом деле сравнивает перфоманс:


  • многопоточной непрогретой JVM, с JSP в Томкате
  • PHP, который сидит за непонятным дефолтным конфигом Apache (в целом тоже многопоточном)
  • и однопоточную node.js

Автор немного лукавит)
Тут дело скорее не в самих монадах, а в do-notation.

Компилируется это на этапе сборки проекта перед публикацией. Т.е. в браузере работает уже "скомпилированная" версия. Не совсем скрипты, совсем не PHP.


Ну, в общем идея такая, что с языком (JS) все более-менее в порядке. Дело в том, что HTML и CSS слишком низкоуровневы для Rich Internet Applications. Поэтому логичным образом появились более высокоуровневые абстракции, который приближают решение проблемы к оперированию над объектами предметной области. В случае с React и Vue отдельно стоит упомянуть Virtual Dom и те проблемы, которые он решает (и создает, ага): https://habrahabr.ru/post/256965/


Отдалённо, связь такая же как и между языком ассемблера и си. На первом можно реализовать абсолютно всё, но долго и дорого.

Вполне пристойно обстоят, есть некоторые нюансы, но можно и без server-side рендеринга обойтись: http://andrewhfarmer.com/react-seo/

300 000 страниц в сутки это 3.5 запроса в секунду.
Парни, вам есть еще куда расти во-первых, а во-вторых положите уже всё в память, она по-прежнему быстрее любого SSD

Это да. Вопрос в том, когда бы оно было разработано, во сколько бы обошлась разработка нинзя-отрядом матёрых С++ разработчиков это всё. Для не самой концептуально сложной Джавы хорошие программисты стоят не дешево, а уж для плюсов… я даже не знаю, есть ли такие люди среди нас.


Ну и еще большой вопрос, насколько оно быстрее бы вышло грамотно настроенного netty. Смущают разве что паузы GC.


Есть у меня подозрение, что highload это в первую очередь не про производительность одного единственного веб-сервера, а про масштабирование всей системы в первую очередь.

Стойте-стойте. А как же качество продукта? Или у вас производительность программиста исчисляется не в числе решенный задач, а в строках кода, которые он написал?


Задача программиста не писать код, а решать поставленные задачи с помощью написания кода. Как программист должен узнать, что задача решена и решена корректно, если у него нет инструмента проверки валидности логики?


Код, который запускается это далеко не тот же самый код, который работает корректно. Даже если вы пишете на Haskell и Scala.

Код в первую очередь должен быть понятным на уровне предметной области. А преждевременная оптимизация — зло. Будь то функции по 100+ строк или вынос каждого оператора в отдельную функцию.


Код в первую очередь должен быть читабелен человеком.

Еще с момента анонса беспроводных наушников от Apple мучает вопрос — современный Bluetooth 4.x принципиально может передать звук без потерь?
Вроде бы не может, и потому использует разные кодеки вроде aptX, которые пережимают декодированный на хосте аудиопоток. В результате получаем двойное кодирование с потерями.
Так ведь?

Вопрос. Если все worker-ы симметричные, то не проще было ли писать приложение без cluster (особенно учитывая что усложнять пример не хотелось), а запускаться потом через PM2? Там и gracefull reload, и cluster, и auto restart, и даже логи в реальном времени.


И таки для request request-promise, которые для тестирования кода, лучше таки --save-dev использовать.

Information

Rating
2,592-nd
Location
Россия
Registered
Activity