Дмитрий Энтелис

Странная проблема.
Посмотрите что начинает глючить в обработчике. Если он написан прямыми руками - все должно отлично работать.
Можно конечно и очередь какую впилить, но это реально полезно только если у вас какой то дикий пиковый хайлоад бывает, а ресурсов на ответ требуется много.

UPD на всякий случай уточню: не стоит писать обработчиков бота на базе каких либо тяжелых фреймворков

Вы задавали этот вопрос уже Как правильно покупать web-дизайн? и Вам там много умных людей аргументированно написали почему рисовать страницы поштучно - откровенно хреновая идея.

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

Есть хорошая статья: habrahabr.ru/post/204958
Если кратко: на чистом REST не получится сделать сложную бизнес логику.

Таки null и "" это 2 разные вещи

1. меньше 4gb видеопамяти для современных игр - боль и унижение. Лучше 6gb, но 4 - реальный минимум.
2. Blue серия WD imho ненадежная. Лучше red
3. Как правильно написал nfire - 16 gb оперативки это объективный минимум сейчас.

Если кидает на 404 - значит кидает куда то не туда. Какой url у страницы с формой?
В режиме телепата: попробуйте
action="/mail.php"

Не вижу особого роста количества вакансий на питоне.
Если php чем то не мил - учите лучше Ruby

Если нужна реальная уникальность юзера - привязывайтесь к номеру телефона с смс подтверждением

CMS никакого отношения к скорости загрузки не имеет.
Читать про lazy loading

Depends от того что Вам вкладываете в понятие "работу от которой я бы был доволен".
Если речь идет про сложную математику - то её в вебе действительно очень мало.
Навскидку распознавание голоса, изображений, pathfinding какой то, анализ bigdata.

Если просто хочется писать что то более осмысленное чем "элемент подсветить, вывести из базы товары" - вариантов немного больше:

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

Это очень обманчивое заблуждение.
Сложная логика появляется там где есть сложные бизнес требования.
Если под интернет магазином подразумевается 3 продажи в день - то тут вообще программировать не нужно, любого готового движка хватит.
А вот если это какая нибудь условная www.lamoda.ru - со своим достаточно нелинейным маркетингом, своей системой складского учета, своей системой автоматизации и оптимизации логистики итд - там в штате ~300 разработчиков сидит, а задача "вывести из базы товары" трансформируется в 100 страничное тз кому, когда и какие товары надо выводить.
Ну и от нагрузки многое зависит. Сделать систему которая бронирует 1 квартиру в секунду и 1000 квартир в секунду - принципиально разная сложность и объем кода.

Мы пользовали https://github.com/PHPOffice/PHPExcel

не надо в mysql класть в строку json если предполагается по нему что то искать.

PS предвосхищая ответ "это такой движок который так сохраняет" - меняйте движок на нормальный, или дописывайте что бы данные дублировались в нормальной форме

Ну Вы бы сохранили куда нибудь себе то что приходит в file_get_contents("php://input") при одиночном сообщении.
Приходит там структура

{
"update_id":137806900,
"message":{
  "message_id":553,
  "from":{
    "id":331953,
    "first_name":"Дмитрий",
    "last_name":"Энтелис",
    "username":"dentelis"
  },
  "chat":{
    "id":331953,
    "first_name":"Дмитрий",
    "last_name":"Энтелис",
    "username":"dentelis"
  },
  "date":1439369724,
  "text":"!!!"
  }
}

Соответственно никаких result там нет

Эм... А зачем? Берете любой домен да делаете себе 100500 поддоменов сами.

1. Принципиальных качественных преимуществ у node.js перед остальными языками нет, как впрочем и недостатков. Просто yet another язык со своими особенностями. Соответственно если в вопросе заменить node.js на php/ruby/python итд - ничего не изменится.
Вопрос по сути абстрактный "почему все не перешли на язык %%%%%"

2. Ответ на абстрактный вопрос:
а) Потому что существует огромное количество legacy кода который нужно поддерживать. Работы по поддержке и развитию существующего кода на порядок больше чем написания с нуля нового
б) Потому что у разработчиков есть свой стек любимых технологий, изменять который без явных экономических причин основная масса не готова
в) Потому что умные технические менеджеры выбирают стек технологий проекта исходя из имеющихся под рукой разработчиков и легкости поиска и заменимости оных.

UPD
hbrmdc

У NodeJS есть уникальные и очень весомые преимущества, которых нет ни у одного другого языка. Например то, что это JS, и, следовательно, нет необходимости разучивать лишние языки - можно весь webapp писать на js.
Личные предпочтения обоснованные привычками - это не имеющий значения аргумент в данном вопросе.

1) Есть отличия, да. Только не те о которых Вы пишите. То что это "JS" вообще ни на что не влияет.
JS хорошо знают фронтендщики - а кто пустит фронтэндщика к внутренней архитектуре? Там подход совершенно другой нужен, другие навыки, другое понимание как это все работает. Просто пересадить человека с фронта на бек - нельзя.

На самом деле основные отличия другие:
Постоянно живущий процесс, фактическая однопоточность. В зависимости от задачи - это может быть и плюсом и минусом. Условно для какого нибудь сокет-сервера - плюс (активно используем на живых проектах). Для middleware - я бы подумал. Для нагруженного сервиса с расчетами - точно нет.

2) Личные предпочтения обоснованные привычками это основной аргумент.
Я вот умею в php, умею в ноду, умею в еще десяток умных слов.
Мне нужна новая команда на новый проект.
Я открываю hh и что я вижу: node.js 279 резюме из которых половина фронтэндщики.
PHP - 9613 резюме. Даже если 90% разработчиков PHP на hh - уроды которых к коду нельзя подпускать на пушечный выстрел - останется все равно в 3 раза больше чем есть node.js.
Собственно на этом выбор и закончен.

На малопопулярных языках пишут в случаях:
a) это мелкий сервис с неявными перспективами который можно переписать за неделю
б) это проект "для души" разработчика.

Получается замкнутый круг на самом деле.
Менеджер смотрит резюме, резюме на node.js нет =>
Менеджер не начнет проект на node.js =>
Не возникнет вакансия на node.js =>
Разработчик анализируя вакансии не увидит вакансий на node.js =>
Разработчик будет учить что то другое =>
Менеджер смотрит резюме, резюме на node.js нет...

Переломить ситуацию могут только очень крупные игроки обладающие возможностями формирования рынка (например Apple и Swift), и то не со 100% гарантией (samsung&c и Tizen)