Тогда второй вопрос, имеет смысл бэк: Play + REST, и фронт - ангуляр?

там есть какой-нибудь аналог spring-security для Play?

Т.е. проверка что этот юзверь именно этот и он может делать то что он делает?

я использую https://github.com/t2v/play2-auth правда переписал под себя чуть имплиментаций в основном добавил работу access_token как у fb

Тогда второй вопрос, имеет смысл бэк: Play + REST, и фронт - ангуляр?

смотря под какие задачи. rest на плее легко реализовывается

смотря под какие задачи. rest на плее легко реализовывается

CRM для предприятия, видимо нам всё же придется её писать. Вот щас и ищу что лучше использовать.

мне кажется вариант не хуже чем Spring Boot. Воскресение сидел вникал - вроде все есть. Да и LinkedIn на play написан, так что почему нет?

Т.е. веб-морда и REST API будет в одном проекте? Тогда самым простым вариантом будет сделать cookie authorization общий, тогда при интеграции с REST API фронтендщикам вообще париться не придется про авторизацию

мне кажется вариант не хуже чем Spring Boot. Воскресение сидел вникал - вроде все есть. Да и LinkedIn на play написан, так что почему нет?

да собственно я сам то не против) Просто ведь надо знать как оно работает и как его делать) Фронт - не моя головная боль. Но если Play я более-менее знаю - то REST вообще до сего момента не трогал

Т.е. веб-морда и REST API будет в одном проекте? Тогда самым простым вариантом будет сделать cookie authorization общий, тогда при интеграции с REST API фронтендщикам вообще париться не придется про авторизацию

нет, морда будет другим проектом пока по планам, но вот надо ли так поступать - пока еще непонятно

ну запросы он обрабатывает, json знает

плюс асинхронность полная

интеграция с БД есть

Кстати если делать одним проектом - то еще может быть CSRF, так?

желательно

хоть и не одним проектом

нет, морда будет другим проектом пока по планам, но вот надо ли так поступать - пока еще непонятно

можете сделать авторизацию частью REST API

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

я бы jwt посоветовал

REST в чистом виде - убогое поделие школоты) это ж надо додуматься смешивать транспорт и сообщения в одном флаконе

можете сделать авторизацию частью REST API

вот я про это думаю, но из того что пока в голову приходит - это или токен при каждом запросе, или тот же токен но в заголовках, так?

в куке

REST в чистом виде - убогое поделие школоты) это ж надо додуматься смешивать транспорт и сообщения в одном флаконе

А как тогда надо?

засуньте все в параметры

тогда не будет проблем со сменой транспорта

а то при смене транспорта начнется - ой, а тут заголовков нет ,а как мне куки передать

ой ой

куки - только для страничек

Лучшее враг хорошего

для запросов к апи - хттп должон использоваться исключительно как транспорт для передачи параметров - про куки вобще лучше заьыть

а то при смене транспорта начнется - ой, а тут заголовков нет ,а как мне куки передать

И часто транспорт менять приходится?

как и про заголовки хттп в целом - нахер не нужны для апи

Вы тут сейчас насоветуете, человеку нужно просто стартонуть. Все равно с первого раза хороший REST не спроектирует

в header имхо самый норм вариант, чтобы параметры не засорять

в ангуляре можно настроить, что оно там в фоне это все будет делать

как и про заголовки хттп в целом - нахер не нужны для апи

т.е. всю инфу пихаем в тело сообщения?

Вы тут сейчас насоветуете, человеку нужно просто стартонуть. Все равно с первого раза хороший REST не спроектирует

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

просто прочитайте пару гайдлайнов по дизайну REST-API, выберите понравившийся и придерживайтесь

т.е. всю инфу пихаем в тело сообщения?

да, даже post&get параметры поддерживают структурную вложенность, а уж просто боди - там и json и xml можно засунуть если сильно хочется. там уже вариантики. plain object - а как ты там дальше будешь интерпретировать - на свое усмотрение

https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md

Имхо, пофиг что куда класть, все равно будет ясен список всех параметров, при необходимости "сменить транспорт" дело чистой механики будет из кук и заголовков все переложить куда-то еще

общие правила: все ответы в json, если запрос ничего не изменяет то это GET запрос, если что-то меняет, то POST. в случае GET-запроса параметры через query string, в случае POST-запроса – в JSON в POST-body

Имхо, пофиг что куда класть, все равно будет ясен список всех параметров, при необходимости "сменить транспорт" дело чистой механики будет из кук и заголовков все переложить куда-то еще

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

Хм... хорошо, с этим разобрались. Но - приложение бдут в течении дня активно пользовать. Но так же возможны варианты "вот это надо переделать вот на такое прямо сейчас". И Play стартует... не быстро. Есть возможность как-то проводить обновления без того что бы у всех всё грохнулось?)

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

зачем куки в рест? куки уже давно не используют для апи, сейчас модно jwt

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

чистая механика займет тогда чуть больше времени ?

http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

зачем куки в рест? куки уже давно не используют для апи, сейчас модно jwt

ну про jwt я не слышал, а куки... вряд ли, разве что просто как идентификатор на основе которго потом можно пользователя авторзовать автоматом

зачем куки в рест? куки уже давно не используют для апи, сейчас модно jwt

так и говорю, что в попец эти куки и хедеры вместе с ними если делаешь апи

и request method тоже в попец с ними же

ну так jwt в хэдер пихать надо

а не в GET параметры

наркоманы чтоли?

Хм... хорошо, с этим разобрались. Но - приложение бдут в течении дня активно пользовать. Но так же возможны варианты "вот это надо переделать вот на такое прямо сейчас". И Play стартует... не быстро. Есть возможность как-то проводить обновления без того что бы у всех всё грохнулось?)

blue green deployment o; ?

так и говорю, что в попец эти куки и хедеры вместе с ними если делаешь апи

Хм... я тут совсем не разбираюсь, но если без кук - где клиент будет хранить инфу на основе которой я ему буду выдавать данные?

в локал сторедже

Хм... я тут совсем не разбираюсь, но если без кук - где клиент будет хранить инфу на основе которой я ему буду выдавать данные?

какую инфу? текущий юзер?

в тех же куках лол )

в локал сторедже

т.е. это проблема чисто клиента и я на это просто не обращаю внимания, так?

да

какую инфу? текущий юзер?

текущий зашифрованный идентификатор юзера который я ему даю на основе его логина и пароля

т.е. это проблема чисто клиента и я на это просто не обращаю внимания, так?

да, сейчас фронты раздувают redux state и хранят в local storage

почитайте, что я сбросил

Хм... я тут совсем не разбираюсь, но если без кук - где клиент будет хранить инфу на основе которой я ему буду выдавать данные?

а зачем тебе что-то хранить на клиенте, кроме идентификатора сесиии? только он и нужен, а дальше ты по нему на сервере все что надо в привязке хранишь

текущий зашифрованный идентификатор юзера который я ему даю на основе его логина и пароля

jwt

почитайте, что я сбросил

читаю

а зачем тебе что-то хранить на клиенте, кроме идентификатора сесиии? только он и нужен, а дальше ты по нему на сервере все что надо в привязке хранишь

понятно, собственно так и думал, просто почему то этот индетификатор привязал к бэку а не фронту

Вообщем про это - сообразил

Щас еще гляну что за blue green deployment

Т.е. фактически он означает одновременную работу сразу минимум двух инстансов которые будут работать параллельно и смогут понимать что один из них этого пользователя уже авторизовал, так?

Щас еще гляну что за blue green deployment

сейчас простой crud превратится в CQRS ебу, которую нужно деплоить через k8s

Т.е. фактически он означает одновременную работу сразу минимум двух инстансов которые будут работать параллельно и смогут понимать что один из них этого пользователя уже авторизовал, так?

с jwt да

даже redis/memcached не нужен

Т.е. фактически он означает одновременную работу сразу минимум двух инстансов которые будут работать параллельно и смогут понимать что один из них этого пользователя уже авторизовал, так?

не должен, потому что CRUD подразумевает отсутствие состояния

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

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

haproxy или nginx + upstream, k8s в самом начале это оверхед

т.е. просто инстанс я конечно отключить могу, но часть клиентов упадет

ставите перед апчиками реверс прокси (nginx), деплоите новую версию, переключаете nginx на порт новой версии, ждете минуту, гасите старую

тем более для крада

nginx при переключении порта апстрима не дропает запросы, которые уже открыты

ставите перед апчиками реверс прокси (nginx), деплоите новую версию, переключаете nginx на порт новой версии, ждете минуту, гасите старую

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

т.е. просто инстанс я конечно отключить могу, но часть клиентов упадет

да вобще пофиг, даже если там парочка человек рефреш лишний раз нажмет)

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

отдельный сервис для job queue, который не зависит от фронт апи

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

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

да вобще пофиг, даже если там парочка человек рефреш лишний раз нажмет)

ну если вам пофиг - вам хорошо, а мне в случае чего отвечать придется

если у вас задачи выполняются несколько часов, нужно перепроектировать API таким образом, что бы не держать долгих открытых запросов

отдельный сервис для job queue, который не зависит от фронт апи

так я сейчас вообще не про фронт а про бэк говорю

если у вас задачи выполняются несколько часов, нужно перепроектировать API таким образом, что бы не держать долгих открытых запросов

так он и не держится

он отдал сообщение что начал считать, и всё, потом мы просто получаем инфу о статусе рассчетов

когда закончит - увидим результат

можно намутить микросервисную архитектуру и передеплоивать только отдельные части

ну если вам пофиг - вам хорошо, а мне в случае чего отвечать придется

а если интернет лагает и пакеты пропадают, тоже ты отвечаешь перед начальством?

но в это время он считает

ерундой болтаешь товарищ

можно намутить микросервисную архитектуру и передеплоивать только отдельные части

не уверен что хватит знаний(

ерундой болтаешь товарищ

а если у вас в локальной сети пакеты теряются вы что, на это просто забиваете что ли?...

он отдал сообщение что начал считать, и всё, потом мы просто получаем инфу о статусе рассчетов

а какие задачи?

типа составления отчетов?

так я сейчас вообще не про фронт а про бэк говорю

эм, я не имею в виду бразуер как фронт, я про фронт api, который можно перезапускать сколько угодно раз и не влиять на выполнение тасков в фоне

а вообще, лучше написать монолит и только потом делить все на части