SEOVirus, да, без году неделя. Вопрос требований к стабильности вашего предложения.
Я так понимаю, поддержка до сих пор сугубо экспериментальная, и вопрос что будет с обратной совместимостью открытый.
SEOVirus, с чего бы компилируемому решению с поддержкой многопоточности, не быть шустрее чем интерпретируемое, однопоточное?
Моя мысль основная в том, что для первой реализации стоит использовать то что лучше знаешь. Быстро запилил прототип, потестировал. Не взлетает: искать альтернативу.
А по ресурсам:
У C# лучше с типизацией, в то время как NodeJs умеет только в динамическую. По памяти C# должен быть экономнее.
C# - компилируется, NodeJs - интерпретируется виртуальной машиной (с оговорками). У первого варианта больше возможностей по оптимизации. NodeJs проектировался для выполнения в одном потоке. По CPU C# потенциально должен быть эффективнее.
PS: рассуждаю как сторонний наблюдатель, очки на стройке нашёл.
Дополню такой аналогией. Если знаете ООП, и первую букву из SOLID.
Образ - это класс.
Контейнер - объект.
Единая ответственность сервиса(контейнера/образа), такая же хорошая практика как и в ООП, и даёт те же преимущества: локализация изменений и проблем, лучшая декомпозиция задач и логики.
Pyatachok, да, спасибо.
Если у соискателя адекватный github / habr / stackoverflow / toster и в целом общение, то мы тестовое тоже не заставляем делать.
Но если есть сомнения, и нет публичных проектов-исходников, то тестовое -- лучший вариант понять, что не только на словах он Лев Толстой.
Про сертификаты спасибо, забыл что у битрикс есть такая тема.
С использованием классов внутри библиотеки, у меня проблем не возникает.
Затруднения в использовании кода через npm-пакет. Как правильно скомпилировать свой код, чтобы подключить его при помощи require - вот в чём вопрос.
Ну, конкретнее, насколько я понимаю, вы используете глобальный массив $_SESSION как хранилище для корзины пользователя. Пусть так. Хотя лучше абстрагироваться от сессии, введя специальный объект корзины. Задача, судя по имеющемуся коду - при добавлении товара, если такой уже был, увеличить его счётчик. Я предлагаю хранить объекты вместо примитивов.
Я для того и использую TypeScript, чтобы абстрагироваться от нативного js)
В актуальной версии есть поддержка namespace, синтаксически близкая к тому что мне хорошо знакомо по другим языкам, почему бы её не использовать, раз она позволяет использовать Foo.Builder и Bar.Builder не беспокоясь о коллизиях.
Дмитрий Байбухтин: да пробовал, знаю. Сейчас легаси проект на Yii1.
Да, в Yii многое завязано на магии и публичных свойствах, но это не очень хорошо влияет на объектно-ориентированный дизайн. Так что где возможно, стараюсь эту особенность не эксплуатировать: например вместо публичных свойств компонентов использовать приватные + сеттеры. Это улучшает интерфейс классов и в итоге влияет положительно на тестируемость.
Так-то фреймворк неплохой, особенно для быстрого прототипирования, когда database first подходит. Но если приложение большое, или доменная логика сложная, там уже Active Record начинает напрягать - не самый удачный шаблон проектирования, т.к. большая зона ответственности у классов. Хочется через DDD разрабатывать и иметь более абстрагированный от БД слой моделей - ORM, который бы позволял code first подход и соблюдение принципа persistance ignorance.
Дмитрий Байбухтин: Ну, я бы в этом случае сделал метод setServers(array $servers);
а вообще этот конкретный случай уже похоже тянет на интеграционное тестирование, не юнит, т.к. компонент взаимодействует со сторонней подсистемой.
Дмитрий Байбухтин: А можете ссылку на код дать, так мне будет проще понять ситуацию.
У нас как-то без конфигов компоненты.
Вообще я пришёл к тому что в виде юишного компонента реализую только фабрики для каждого сервиса, и именно она доступна через синглтон контейнера. А в юнитах, напрямую инстанцирую объект сервиса, либо, когда сервис должен быть специальным образом сконфигурирован, в тесте получаю его через фабрику.
Дмитрий Байбухтин: А что мешает инстанцировать объект компонента и тестить его методы, как обычно в юнитах?
В первом Yii так делаем. Прошлый проект был на двойке, уже плохо помню, но принципимальных отличий вроде бы нет - компонент это сервис, а Yii::app() - сервис локатор.
"Родной" не обязан. Но вполне себе может. Зависит от требований к фронтенду. Для современных js-фреймворков это более чем приемлемая архитектура взаимодействия с сервером. И если рестовый бэкэнд уже есть, то это возможное решение для фронтенда.
Но не если, кроме вебморды, других клиентов не предполагается, то такая архитектура не всегда может быть оптимальной. Иногда достаточно и более монолитной архитектуры, без клиент-серверного разделения, если речь именно о веб-сайте. Более традиционное решение тогда - любой серверный MVC фреймворк.
Есть ещё третий вариант: рестовое апи есть, было, и будет есть, но вебморда сервиса может быть построена без использованbя оного. Примеры: GitHub, BitBucket, Jira. Redmine (?).
Это клиентский код. А запущен ли сервер, который должен обслуживать сокет?
Почитайте (здесь например learn.javascript.ru/websockets) вводную информацию по ws.
Ну, я как раз и выделил условно "пользователей" (те кому нужно API — для это есть интерфейсы и докблоки, тесты им лишний груз), и "разработчиков" — те которые захотят не просто использовать, а модифицировать и расширять (для них мои тесты могут быть полезны) .
Наверно мне стоит смотреть в сторону системы сборок...
Я так понимаю, поддержка до сих пор сугубо экспериментальная, и вопрос что будет с обратной совместимостью открытый.