Какие технологии использовать для реализации сервиса предоставляющего API?

Question

[Saveli Tomak]

Доброго времени суток.
Стоит задача реализовать сервис - деловую платформу, включающую в себя:

• Своеобразную доску объявлений
  
• Систему блогов
  
• Форум
  
• Новостной ресурс
  
• Другой незначительный функционал
  

Так же в перспективе планируется ввести систему коммуникации между пользователями, пока сходимся на real-time чате.
Так как работать все это должно на разных платформах: web, apple, android, win phone, было принято решение разработать main сервер общающийся с клиентом по rest (отдавать будем json)
Собственно дошло дело до инструментов, тут выбираем между асинхронной nodejs (говорят, что нода в API хорошо себя чувствует) и обычным php. Примерная аудитория 100-500 тысяч пользователей (не смейтесь с такого разброса, не знаем как все это пукнет) + дальнейший рост, возможно и больше миллиона, все будет зависить от активности ЦА и работе маркетинг отдела. В качестве базы берем postgresql. Что думаете по этому поводу?

Мы и сами понимаем, что инструмент необходимо выбрать тот, с которым имеешь опыт работы, но сервером заниматься будем не мы и студию подрядчика будем выбирать исходя из интересов проекта.

Всем спасибо!

Answer 1

[Евгений Вольф]

А что Вы ожидаете услышать? В АПИ много кто чувствует себя хорошо, и нода и ПХП и даже С++. Наговнокодить можно на чём угодно, заставить проект работать очень быстро - можно и на ПХП. К тому же, большая часть нагрузки, как мне видится - ляжет на БД, а её проектирование и настройка, особенно это относится к Postgres - это целая наука. Я пока не очень представляю, как NodeJS будет держать такое кол-во пользователей (скорее всего от того, что я не очень хорошо знаком с NodeJS), но случаев когда она с треском падала - в истории достаточно.

Что думаете по этому поводу?

Я думаю, что Вы предоставили слишком мало входных данных и конкретики. Так как, например, даже горячо любимый мной Postgres - в ряде случаев, далеко не лучший выбор. А посоветовать пихать "Базу N" везде, где только можно и нельзя, не понимая всей сути проекта, могут только те, кто с другой базой не работал, и считает, что единственная технология с которой он знаком - лучшая из всех возможных. Посему, в виду скудности входных параметров, ответ на Ваш вопрос будет, либо таким же размазанным как мой, либо чем-то из серии "Юзайте NodeJS+MySQL, мой блог с посещаемостью 30 чел./месяц, вот уже 4-ый год как стабильно работает в такой связке! И ещё на WindowsServer всё это установить не забудьте! Лучшее сочетание из возможных."

Comments

[sim3x]

>Postgres - в ряде случаев, далеко не лучший выбор
например?

[Евгений Вольф]

sim3x: например когда нам нужна встраиваемая БД, для небольшого объёма данных <200-500Мб, и/или нужна база для работы в однопользовательском режиме (единственный коннект). Или например, когда нет администратора или иного специалиста, который может заставить эту БД работать как надо. Когда речь идёт о блоге в 500 страниц максимум, куда проще, логичнее и в конечном счёте производительнее - взять MySQL, с настройками "из коробки". Там сразу и кэширование запросов, который в Postgres "из коробки" ни под каким соусом нет, и хост-процесс всего 1, никакие пулеры не нужны, и так далее. И многие вещи гораздо проще, а посему - проще настраиваются и потенциально приведут к гораздо меньшему кол-ву возможных ошибок, нежели безграмотное использование гораздо более функциональной БД. С MySQL'ом "меньше приходится думать" - это весомое преимущество, в ряде случаев, для многих.

Answer 2

[Rou1997]

тут выбираем между асинхронной nodejs (говорят, что нода в API хорошо себя чувствует) и обычным php.

А что из этого вам лучше знакомо?
Ваша основная цель - реализовать проект, а если будете использовать незнакомое то будет еще и цель изучить незнакомое. Тем самым, вы будете тратить гораздо больше энергии и времени.

Тоже самое на вопросы вроде "готовый фреймворк vs самописный фреймворк vs китайский код без фреймворка" - самописный фреймворк это самый заманчивый вариант на будущее, но он же и самый энергоемкий.

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

Так же в перспективе планируется ввести систему коммуникации между пользователями, пока сходимся на real-time чате.

Насчет real-time, есть один момент: с WebSocket лучше работать на Node.js.
А если у вас клиентом служит браузер, то вам желателен WebSocket, потому что иного доступа к сокетам в современных браузерах нет (Flash считаем устаревшим), а сами сокеты желательны для real-time.
Но это не самый важный момент.

Comments

[Saveli Tomak]

> А что из этого вам лучше знакомо?
Нам без разницы, реализацией проекта будем заниматься не мы, мы выступает как прослойка, типа технические менеджеры и аналитики, если проект потребует nodejs - мы найдем студию готовую реализовать его на nodejs, если адекватнее справится на php - найдем студию с опытом в php.

[Rou1997]

Saveli Tomak: Для PHP намного проще найти студию.

[Saveli Tomak]

Rou1997: это вы в точку. Но а если посмотреть с технической стороны, php \ python покажут себя лучше в такой среде, нежели javascript ? Мы имеем хороший опыт в python, примерно можем оценить его способности в этом проекте, но нам интересно, не лучше бы было использовать javascript ? ps опыта с нодой мы не имеем никакого.

[Rou1997]

Saveli Tomak:
""""Мы имеем хороший опыт в python"""
То пишете "без разницы", то "хороший опыт в python", определитесь уже, и если все-таки хороший опыт в python и вам важны сроки и невысокая цена, то python.

[Saveli Tomak]

Rou1997: я опять же подчеркиваю, заниматься этим будем не мы, а студия подрядчик, говоря о том, что у нас есть опыт разработки на питоне, я подразумеваю то, что мы понимаем какую нишу он занимает и на что он способен. Вопрос стоит в другом, как вы уже подчеркнули, одну из частей проекта мы будем реализовывать на nodejs (коммуникацию между пользователями) вот мы и задумались, не легче ли будет реализовать весь back end с использованием одного и того же инструмента. Если nodejs хорошо показывает себя в этой среде, то почему бы не использовать его везде?

[malbaron]

Насчет real-time, есть один момент: с WebSocket лучше работать на Node.js.

Real-time в интернете вообще не возможен.
;)
Априори - так как задержки сети непредсказуемы.
Вы имели ввиду нечто иное.

С WebSocket прекрасно работается на чем угодно.
Например, на Go работаю - все удобно и быстро.
Вы назвали Ноду потому что ее лично вы лучше знаете?

[Rou1997]

malbaron: Я лучше знаю PHP.
Но Node.js это "родина" WebSocket и socket.io, если использовать "левые" реализации в PHP и т.п. - то велик риск их "кривизны".

Real-time в интернете вообще не возможен.
;)
Априори - так как задержки сети непредсказуемы.

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

[malbaron]

Rou1997: в первые годы появления websocket - может и были риски "кривых реализаций".
с тех пор все уже устаканилось.

[malbaron]

Rou1997:

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

Ну если 2 минуты это real-time....

[Rou1997]

malbaron:

в первые годы появления websocket - может и были риски "кривых реализаций".
с тех пор все уже устаканилось.

Ну, конечно, г...внокодеров же всех извели! Вот три года назад еще только каждый 100-ый был нормальный, а сейчас наоборот, на сто человек один г...кодер! :)
Вот статья, которая учит создавать реализации WebSocket даже не "заворачивая" Read и Write в try-catch, и такая статья до сих пор существует и не где-нибудь, а... :)
Специалисту конечно ясно, что MDN это всего лишь "вики", кто хочет тот и пишет, но другие-то посетители должны же патрулировать статьи.

Ну если 2 минуты это real-time....

Сегодня скажу заказчику, что 2 минуты подождать это то же самое что пробежаться по всей области по всем 30 компьютерам при 40-градусном морозе, и перезагрузить вручную каждую страницу, ну ведь и то и то не real-time. :)

[malbaron]

Rou1997:

Вот три года назад еще только каждый 100-ый был нормальный, а сейчас наоборот, на сто человек один г...кодер! :)

Зачем тебе 100 реализаций WebSocket?
Достаточно одной.

[malbaron]

Rou1997:

Вот статья, которая учит создавать реализации WebSocket даже не "заворачивая" Read и Write в try-catch, и такая статья до сих пор существует и не где-нибудь, а... :)
Специалисту конечно ясно, что MDN это всего лишь "вики", кто хочет тот и пишет, но другие-то посетители должны же патрулировать статьи

Это всего лишь иллюстрация,
а не рецепт, который следует безголовно тащить в свой код.

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

[malbaron]

Rou1997:

Сегодня скажу заказчику, что 2 минуты подождать это то же самое что пробежаться по всей области по всем 30 компьютерам при 40-градусном морозе, и перезагрузить вручную каждую страницу, ну ведь и то и то не real-time. :)

Ты путаешь понятия "реальное время" и "реальный мир"

[Rou1997]

malbaron:

Зачем тебе 100 реализаций WebSocket?
Достаточно одной.

Я о вероятности того что одну из реализаций напишет именно г..кодер, или ты хочешь сказать, что все г..кодеры понимают что они г..кодеры и не берутся за написание реализаций WS?
К сожалению г..кодеры очень разные, кто-то не берется, но кто-то берется и получается... ну, не то что прямо "лучше бы вообще не брался", но все же мягко говоря плохо.
Например господин Atanas Neshkov, который пишет GUI для декомпиляторов, и даже при всей примитивности своих задумок умудряется делать их очень плохо и хочет чтобы у него покупали лицензии, к реверс-инжинирингу он никакого отношения не имеет и от таких продуктов много вреда а пользы мало, так же как и от декомпилятора Fernflower, который популярен благодаря имени JetBrains, но по факту JetBrains не удосуживается уделять ему достаточно времени, в нем много багов и тем самым он вводит в заблуждение.

Во всех адекватных статьях минимизируют всяческие общие вещи

Я сам пишу статьи, не надо мне тут, кто им мешал в конце хотя бы крупным жирным шрифтом написать что еще нужен try-catch, а лучше вместо Read использовать свой метод tryRead и привести его код?

Ты путаешь понятия "реальное время" и "реальный мир"

Привел пример "не реального времени", а то что у меня на сервере с 2 минутами - это в моем случае вполне "реальное".

[malbaron]

Rou1997:

Я о вероятности того что одну из реализаций напишет именно г..кодер, или ты хочешь сказать, что все г..кодеры понимают что они г..кодеры и не берутся за написание реализаций WS?

А почему тебе не все равно чем занимаются плохие программисты?

То, что можно напороться как на плохую так и на хорошую реализацию - это твоя личная проблема.
Никто за тебя подбирать лучшую библиотеку не будет.

Например господин Atanas Neshkov, который пишет GUI для декомпиляторов, и даже при всей примитивности своих задумок умудряется делать их очень плохо и хочет чтобы у него покупали лицензии

Ты к чему его здесь привел? Завидуешь?
Просто не покупай.

, а лучше вместо Read использовать свой метод tryRead и привести его код?

А почему бы тогда в статье не начать с изложения принципов языка программирования?

Увольте, сударь.
И так 90% статей пишутся на примитивнейшие темы, а вы еще и жевать предлагаете.

[Rou1997]

malbaron:

То, что можно напороться как на плохую так и на хорошую реализацию - это твоя личная проблема.
Никто за тебя подбирать лучшую библиотеку не будет.

Вопрос был о выборе библиотек. Чтобы не напороться, лучше брать проверенную.

Ты к чему его здесь привел? Завидуешь?
Просто не покупай.

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

И так 90% статей пишутся на примитивнейшие темы, а вы еще и жевать предлагаете.

Статья - о реализации протокола WebSocket, а именно этот протокол от своей реализации требует наличие tryRead.
Базовый протокол TCP поддерживает ошибки, какой-то другой протокол на базе TCP мог бы не требовать обработку ошибок, может где-то даже специально требуется НЕ обработка и crash, но не в WebSocket.
Во-вторых, приведу более общий пример, вот допустил заказчик неточность в своем ТЗ, а ты и рад, ведь теперь вместо сложного алгоритма можно написать такое:

int returnRandomNumber() {
  return 8538087654678; //guaranteed to be random
}

Как ты считаешь - действительно ли можно? Как вообще поступить?

[malbaron]

Rou1997:

статья - о реализации протокола WebSocket, а именно этот протокол от своей реализации требует наличие tryRead.

Не путай:

Если статья о протоколе WebSocket, то это статья о протоколе WebSocket.
А вовсе не обучающая статья по основам программирования

Answer 3

[malbaron]

Любой, что лучше знаешь.
PHP, Go, Ruby, NodeJS, Python, Net, C/C++,Perl - да что угодно.
Все варианты реализация имеют право на жизнь.

В качестве базы берем postgresql

Если проект очень перспективен, то:
Я бы выбрал Mongo+Postgres+Tarantool.
Разные описанные вами виды данных удобнее хранить и быстрее обрабатывать в разных СУБД.
Будет и быстрее и ресурсов будет меньше жрать.

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