evnuh

Оправдано ли будет использование NodeJS в качестве бэкенда крупного приложения?

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

На ноде легко быстро говнять, это главное ее преимущество. Для крупных проектов на первый план, как правило, становятся: безопасность, поддерживаемость, тестируемость, расширяемость и надежность.
Что бы сделать что-то действительно крупное вам потребуются драконовские соглашения, которые во многом будут противоречить идеологии этой платформы, которые в других экосистемах будут излишними.

Приведу несколько примеров.

Валидация аргументов, да можно заюзать typescript, как базу для этого, но есть момент: по хорошему, если вы вызвали некий метод с неправильными данными - его штатная работа не возможна, не плохо бы бросить исключение, но не все так просто, если ваш даже синхронный метод вызовется асинхронно - вы обязаны, либо сделать его сразу асинхронным и передавать ошибку, либо всюду хреначить try-catch, чего оптимизатор v8 не любит.

С тестами асинхронного кода все очень плохо, вам придется обмазываться всякими proxyquire, sinon и т.д. При этом очень внимательно следить за очисткой состояния. Да, я понимаю, что моки и в других языках нужно юзать, но тот же proxyquire можно сравнить с php-шным runkit, что как бы вообще по хорошему трогать не надо, а придется. Примите также за исходную, что вы будете много времени тратить на то, что бы понять какой из тестов асинхронщины у вас сфейлился.

Рано, или поздно у вас возникнет потребность в неком DI контейнере, привычный require 'myService' уже не прокатит. Пробросы зависимостей станут источником ошибок. Если вы не будете это дело покрывать функциональными тестами много ошибок обнаружите уже на stage сервере.

Изоморфные приложения - это просто маркетинговый булшит)) Для крупных проектов характерно использование одних и тех же сущностей в абсолютно разных контекстах, причем на бэке в своих, а на фронте в своих. Но, конечно же, если очень хочется - можно делать более абстракные сущности, что бы они работали и там и там, очень скоро ваш код станет не саппортабельным.

Лука Никитин
Не проводили тест, когда по 2 сервера и на ноду и на php?

не пользоваться

поисковики сами решают, так лучше кликают

Unix socket будет быстрее, ввиду отсутствия затрат на сетевом уровне. И в таком случае, PHP должен быть запущен на той же машине, что и nginx.

Если это будет nginx + fpm в одном экземпляре, и уверены, что справитесь с нагрузкой - берите сокеты.
Если понимаете, что возможно будет горизонтальный скейл - берите TCP и настраивайте балансер.

И получается дико неудобно и значительно медленнее в итоге.
Не касаясь лимита на число открытых файловых дескрипторов, кучу internal статистики планировщика и прочих деталей реализации.

Форум. Банальная страница профиля пользователя, достать последние 10 сообщений этого пользователя - как? union all по всем темам с filesort последующим вместо простого index scan по составному ключу даже без необходимости в сортировке?
Статьи. Показать для модерации последние комментарии

А распилить большую таблицу (только на самом деле большую, а не в смешные лям строк) на части - вещь неплохая. Только не так надо пилить. Есть у mysql штатное партицирование.

О, набежали подписанты )
Идея дурацкая и вредная, всем коментам место в одной таблице, и быстрее будет, и сохраннее.
Почитать про индексы даже не советую - бесполезно.

Заэкранировать кавыки.
system("gcc \"C:/Folder/My Folder/example.c\"" );

Точно так же экранируется и обратный слэш, если вдруг потребуется.

system("gcc \"C:\\Folder\\My Folder\\example.c\"" );

Экранирование символов — механизм, имеющийся в текстовых языках и протоколах. Он служит, чтобы символы, которые считаются служебными и имеют особое значение, этого значения лишить и объявить «просто символами». Нам нужно двойное экранирование: для ОС (строка с пробелами закавычивается) и для Си (перед кавычкой слэш).

Под винду на старте будет проще .NET (например WPF). Естественно, Visual Studio в качестве IDE, и язык C#