Какую технологическую связку\язык\фреймворк выбрать?

Question

[Nikolas_Williams]

Добрый день!
Требуется создать сайт, который отображает данные по типу резюме, к нему необходимо создать приложение на android и ios, которые бы позволяли обмениваться данными резюме через NFC или Bluetooth. Сайт должен быть рассчитан на highload и быть быстрым.
На текущий момент знаний в веб-разработке немного, однако хочется их получить при работе над конкретным заданием.
Спасибо за внимание!

Answer 1

[uaSaint]

highload и фреймворк понятия не совместимые в большинстве случаев, на счет вещей вроде rails \ django \ phalcon для реального highload я бы лучше промолчал, не говоря уже о других. Реально 80% highload в web сегодня используют spring. Но это по определению не верный ответ, поскольку само по себе понятие highload - это архитектура, а никак не технология. Я бы предпочел любой "скрипт" на сервере "для дергать базу" (хотя при отсутсвии сложных вычислений и при условии необходимости массы одновременных конектов жил бы в node + nginx + s3) и главное тут совместить это с чем то вроде БЭМ \ React.js во фронтенде. Хотя и это бред по сути, нужно отталкиваться от того, что имеем, а это в первую очередь команда либо личные навыки. А исходя из вашего вопроса .Net и Xamarin для вас должен быть варриант приемлемый.

Answer 2

[Александр Маджугин]

Любую.
Сколько я чего не пробовал - пришел к выводу что на любом фреймворке можно сделать highload ресурс и все будет хорошо. Сейчас моден Laravel

Comments

[Сергей Протько]

Ну или если компилируемые языки ближе можно посмотреть в сторону go. REST апишки на нем доволи таки удобно писать.

[uaSaint]

Можете показать highload ресурс на Laravel ?

[Александр Маджугин]

uaSaint: Нет. Я с ним не работаю. Дело-то не в том чтобы посмотреть, а в том чтобы сделать. Нагрузочная прочность на 99% зависит от правильно спроектированной архитектуры, а нет от используемых решений.

[uaSaint]

Suntechnic: в том то и дело, что фреймворк подразумевает кучу в большинстве случаев не нужных и далеко не оптимальных зависимостей и как раз в laravel эту архитектуру придется "наследовать" иначе получится такая каша, что легче действительно на велосипед сесть... Все его IoC \ Di успешно применяются и без кучи зависимостей, удаление которых сводит весь фреймворк к банальной файловой структуре. Слишком уж тяжеловесен laravel и подобное, его мир - это CMS -ки и всякие там прототипы расчитанные на переписать в будущем, как деньги пойдут... Даже зенд тут лучше с его модульностью. Все, что в highload нужно на этом уровне - быстрая обработка \ формирование запросов к бд и потому лично я бы из скриптов выбрал perl, хотя опять java куда очевидней в качестве решения.

[Александр Маджугин]

uaSaint: вконтактик работает на PHP и это ему никак не мешает. Так что дело не в скриптах видимо. Быструю обработку сейчас может обеспечить все что угодно. Даже java. Тут требования больше к тому что может выдержать база и насколько решение масштабируемо. А это уже никак не зависит от того на чем оно сделано.

[uaSaint]

Suntechnic: Варриант увеличить колличество серверов никто не отменял, а на сколько я помню заявляли как то они, что используют более 10 000 совсем не слабых машин из которых фронтендом занимаются штук 30, я бы не сказал, что такие цифры - это плюсы для php как серверной технологии. Да и костылей там много, уверенн.