Выбор технологии для нового сайта. Derby или Backbone + PlayFramework?
Хочу сделать новый сервис, но всё не могу определиться с технологией. На сайта будет достаточно интерактива, поэтому на клиенте хочу однозначно всё структурировать с помощью MVC фреймворка. Остается вопрос относительно серверной части. Взаимодействие сервера и клиента планирую посредством RESTfull api. Как по вашему, какая технология сможет дать хороший фундамент для развития, с учетом того что сервис будет развиваться и потребуется прикручивать дополнительные функции? И так же интересно, насколько успешно эти технологии будут справляться с высокой нагрузкой?
Начнем с того, что аббревиатурой MVC называют что угодно. Но в любом случае, важно не разделять три компонента, а создавать уровни абстракции - создавать слои: слой доступа к БД (в нем все три компоненты), над ним - слой серверной логики (в нем все три компоненты), над ним - слой клиентского приложения (в нем все три компоненты). Все слои общаются друг с другом через специфицированный API. Разделять нужно "горизонтально" - слои, а не "вертикально" - внутри слоя. Ту статью я уже давно написал, но похоже, что сейчас пришло время еще раз пересмотреть этот вопрос, написать более простыми и четкими словами, а то каша в головах встречается не только у задающих вопросы и желающих разобраться, но и у авторов и даже докладчиков на конференции.
MVC конкретно собираюсь использовать для создания структурированного кода. Если есть такая возможность, не могли бы дать ссылки где можно почитать про Statefil RPC, потому что либо я плохо искал, либо просто недостаточно интересовался не нашел хорошей информации по этой теме
RPC - это удаленный вызов процедур, он всегда stateful, в отличие от REST - stateless подхода. Часть полезных ответов можно найти тут toster.ru/q/49346 в моем развернутом ответе. А вообще, собрался как раз по этой теме написать статью на этой неделе.
@Fesor, с тех пор, как появилась возможность делать высоконагруженные сервера приложений с состоянием для каждого соединения, а node.js, о котором задан вопрос - как раз одно из таки средств. На PHP и других языках, которые работают с веб-серверами через cgi и каждый раз порождают и убивают процессы для каждого HTTP-запроса, для них просто нельзя написать серверную часть с состоянием, а node.js - совершенно другое дело, процессы не выгружаются между запросами, все структуры данных можно оставлять в памяти, остаются соединения с БД, кеши, таймеры, можно развернуть сложную модель в памяти и она будет там сидеть месяц. И с этой моделью может взаимодействовать клиентская часть через API, это работает гораздо быстрее, чем каждый раз устанавливать соединения с БД, создавать структуры данных, готовить среду, потом исполнять серверную логику и все это погибает после отправки ответа на клиент и при следующем запросе строится заново. А теперь немного арифметики, представьте, что состояние пользователя 32Кб, а у нас есть 16Гб памяти, этого хватит на 524288 (более полумиллиона) пользователей. Пост уже закончился, жирное можно, нет смысла далее поститься при помощи REST.
А если учитывать только представленные в вопросе технологии, то какой бы Вы отдали предпочтение именно на серверной части. Я конечно новичек, но почему то считаю что на Java/Scala больше возможностей. Поправьте меня если я не прав
представленные технологии: для клиента вы предлагаете backbone.js, но он не даст вам ничего особо для реализации той самой интерактивности. Он хорош для синхронизации данных с сервером и дает довольно гибкую структуру. Но с ним можно легко отстрелить себе ногу. Я предлагаю angular.js, который можно спокойно использовать вместе с backbone (хотя я лично смысла не вижу в этом).
По поводу сервера... node.js быстрее, проще в поддержке... но как бы там ни было, менее надежен. И не потому что технология сырая, вовсе нет. Просто разработчики сторонних модулей/библиотек/фреймворков очень любят ломать обратную совместимость в самый неподходящий момент. Благо это не так сильно проявляется с фреймворками типа express.js. В любом случае с использованием асинхронного io и грамотной архитектурой, можно сделать очень эффективную api-шку. Лично я выбрал бы node.js, но если вы не сильно знакомы с серверным javascript то все же лучше выбрать более знакомые технологии, что бы в какой-то момент не пришло осознание того, что вы совершили пару роковых ошибок в момент проектирования.
Простой
