copal: Модель !== приложение. Модель (а именно информационная модель) - это упрощенное представление реального объекта. Есть физические модели, математические. Приложение - это совсем другое, приложение может вообще не быть моделью чего-то. Например, архиватор RAR - это модель чего? Браузер Chrome - это модель чего?
copal, ну удивили, я еще такого потока сознания на Тостере не видел, на Хабре постоянно, а на Тостере - впервые.
1. В первоисточнике тоже написана лажа, потому, что отделять код от данных и модель от логики - это идея противоестественная для фоннеймановской архитектуры вычислительной техники. Весь смысл которой в том, чтобы смешивать данные и код в одной универсальной памяти и обрабатывать код как данные, а данные как код, вперемешку, это очень сильная концепция, хоть и не абсолютная. Но реализовывать противную этому идею на ЭВМ с фоннеймановской архитектурой - это безумие. Выделять представление отдельно - это хорошая идея, будь оно в виде шаблонов, визуальных компонентов или чего другого, но представление можно отделить от модуля. Если отделять представление от клиентского ПО, то выходит GUI, если от сервера, то выходит API. Я за то, чтобы не делать MVC правильно по кошерной поваренной книге, а выбросить его нафиг и делать классическую многослойную архитектуру, которая себя оправдала десятилетиями.
2. Вы поддались очарованию объектно-ориентированного подхода, потому, что он позволяет жонглировать абстракциями и выкручивать из них что угодно, но ООП как подход совершенно не состоятелен, я Вам это говорю, как программист с 20-летним стажем, из которых 15 лет писал на ООП и был счастлив этим, который сам написал объектно-ориентированную СУБД в 1999 году, протокол аналог CORBA для объектного маршалинга по сети, свой формат сериализации и использовал ORM когда об этом подходе еще мало кто слышал вообще. Я Вам скажу, что ООП позволяет занять 100 человек задачей моделирования, которая яйца выеденного не стоит, и они будут вести бесконечные холивары о том, у кого должен быть метод "сесть", у "стула" или у "жопы" или нужно сделать клсса "усаживание", который создается на время этого действия и держит ссылки на экземпляры этих двух, или нужно сделать специальные абстрактные интерфейсы "усаживаемое" и "жоповместилище", которые будут соответственно реализованы у обоих классов, а третий будет с пеной у рта доказывать, что модель должна быть анемичной (без методов), а все действия нужно вынести в универсальный контроллер "мирСтульевИЖоп", который хостает все порожденные в нем объекты и оживляет их.
3. В статье habrahabr.ru/post/204958 я описываю старый метод, который был до всего этого грехопадения, метод слоеной архитектуры. Еще раз говорю, что представление отделять хорошо (шаблоны, gui) и это не противоречит этому подходу.
4. Вы скажете, что так можно отказаться от всего удобного и действительно прийти к процедурному программированию, а это каменный век. Но модульное программирование, которое является развитием процедурного до сих пор не устарело и имеет приличный запас прочности, но у него конечно уровень абстрактности слишком низкий, чтобы писать прикладной код, это я согласен. Так есть же реактивное программирование, функциональное и метапрограммирование. На этих трех концепциях я и пишу сейчас весь свой код. Вот тут пару статей: habrahabr.ru/post/137446 и habrahabr.ru/post/227753
Хомяки пишут rest-crud-mvc-middleware-stateless-orm и что не напишут, все контроллер выходит))) а я чхал на пасочки, у меня системы предназначены для Поднебесной империи, а там столько населенич, что этот маркетинговый цирк некогда разводить, нежно что-то работающее, вот и как только я понял, что все имеющееся в наличии слишком мало, то довелось делать... Ине фиолетово, сколько людей подключатся к этому, главное их качество, квалификация и опыт. В принципе уже мнйчас людей достаточно, чтобы сднлать полноценный сервер приложениц.
У меня как-бы не специфическое, а наоборот, универсальное решение сервера приложений, которое уже работает на кластерах из десятков серверов и протестировано на обслуживание миллионов пользователей и сотен тысяч RPS.
Если Вы хотите маршрутизировать разные URLы в разные воркеры, то cluster (и child_process) с передачей хендла сокета - не катят, потому, что мастер-процесс из сокета может взять только IP, даже заголовков HTTP не может взять и, следовательно, не может получить путь. Если бы мастер это делал, то воркер бы уже не мог прочитать из сокета эти данные. Тут есть два пути:
1. Не пробрасывать запросы, а проксировать, т.е. разбирать заголовки и из мастера делать опять HTTP-запрос в воркеры, и тогда воркеры это совершенно отдельные приложения, открытые на отдельных портах или даже разных машинах. С этой точки зрения, лучше даже использовать nginx, в котором можно правильно проксировать или даже написать свой модуль/плагин к nginx.
2. Передавать запросы от мастера к воркерам не через IPC и не через HTTP, а передавать запросы через MQ (очереди сообщений), как ZeroMQ, RabbitMQ, Redis и т.д.
Это все равно, что спросить, что мне может предложить ресторан, чего нет в сборнике рецептов. ESB - это чаще всего сервер приложений, комплексное решение для обеспечения всех задач предприятия, как то SAP, JBoss, WebSphere, все включено. А MQ - это отдельные технологические решения, ZMQ - это целый конструктор из технологических решений, это поваренная книга, к которой еще нужен хороший повар, чтобы провести проектирование архитектуры и использовать эти рецепты в разработке приложения.
Делаете
npm install -g coffee-script
Потом в первой строке своего coffee файла добавляете #!/usr/bin/env coffee
Потом добавляете файлу атрибут запускаемого.
И запускаете.
"Пока напишете SAAS, то он будет везде." т.е. пока сделаете проект, то ES6 будет без специальных ключей работать в node.js полностью и во всех браузерах. Сейчас же ES6 приходится компилировать в ES5 для старых сред запуска, как CffeeScript и TypeScript. По поводу архитектуры, возможно, конечно она есть, но удостоверьтесь в этом еще раз, чтобы не спутать архитектуру с ТЗ или стеком технологий или паттернами проектирования.
Ни кому еще не удавалось создать универсальную экспертную систему "обо всем", это вещи очень специализированные и просто нашпигованные спецификой предметной области. Без понимания отрасли невозможно подсказать что-то стоящее. Для выбора или построения архитектуры так же важно понимать набор знаний, кто ее будет делать, с какими навыками, для кого это делается, какая будет нагрузка и что за конечный пользователь?
А чем multiparty не подходит? Парсайте, потом кладите все во временную папку или проверяйте прямо из буферов памяти, как удобнее и если не подходят файлы - выбрасывайте их. Ничего сложного.
getimagesize только после загрузки, ее уже нельзя будет отменить. Метод через filesize, который Вы указали выше, работает тоже уже после загрузки. А то, что Вам кажется отменой - это просто не перекладывать файл из временной папки в свою. Загрузку файла это не прерывает. А о чем говорю я - так загрузку действительно можно отменить посередине, если отпарсить частичные MIME заголовки, пока файл качается. И то, только по размеру и типу файла. Его разрешения в пикселях из частичных MIME заголовков не взять. Этот метод можно сделать в node.js и нельзя сделать в PHP ни как. Но это сложно, готового решения для этого нет, парсать MIME нужно будет вручную, учитывая, что он может быть порванным в любом месте. Не парьтесь, используйте модуль мультипарти или попробуйте узнавать о картинке все необходимое еще на стороне браузера, через HTML5 API.
