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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rou1997:

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

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

malbaron:

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

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

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

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

Rou1997:

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

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

Rou1997:

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

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

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

Rou1997:

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

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

malbaron:

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

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

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

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

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

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

Rou1997:

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

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

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

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

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

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

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

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

malbaron:

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

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

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

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

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

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

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

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

Rou1997:

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

Не путай:

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