Node React и тп

[lmike]

тп , как сказал был клитор

Ссылка скрыта от гостей

you got it traditionally

- тому подобное
ни для кого не секрет (я надеюсь) - теперь "хотят" модно/молодежно...
нода стала популярна (отчасти заслужено), а реакт "позволил" писать вебню в стиле пыха (php) - т.е перемешивать код и верстку (добавим JSX)

какое это отношение имеет к домине?!
Ну хотя бы потому что писать фронт на голом JavaScript в более-менее ощутимом масштабе - получим попаболь (в поддержке модификации и далее по списку), а выставлять приложения домины в веб как-то надо
ИБМ, а теперь и ХЦЛ всецело забили на классический интерфейс нотусни... Пилят вот

Ссылка скрыта от гостей

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

Как это можно использовать "в домино"?
поделим всё на две части (ну логично ) фронт - реакт и бэк - нода, гонять можно и напрямую в домину, но что-то "должно" поддерживать обработку страниц и неудивительно что будет нода
Ну раз нода - для теста можно не писать роутинг на домине, а тупо сделать проксирование через

Ссылка скрыта от гостей

Это даст нам приложение на реакте, которое ходит по DAS к домине и отображает данные
Перенос будет (если вообще будет) тупым запихиванием javascript библиотек реакта и иже с ними в "соответствующие" папки проекта в ДД (Домино Дизайнер) и написание роутингов с выдачей REST (xpages/servlet) по типа DAS (а оно там и живет)
Пример проекта но с о своим REST есть на сайте

что еще предстоит учесть?
Прежде всего аутентификацию, я посмотрел/подсмотрел "уроки"

Ссылка скрыта от гостей

мысль - модифицировать в domcfg.nsf (ну или dclf.nsf) форму авторизации, где при ошибке прописывать HTTP header
и его анализировать (не очень изящно, но КМК вполне)
копируем содержимое (ну на всяк пожарный) из вычисляемого текста в CFD поле и дополняем код как на картинке

а в запросе от реакта/ноды анализируем заголовок
всё это (сорцы уроков) в бранчах на гитхабе
быстрофикс для мультисерверной аутентификации (там LtpaToken) будет такой

//filter cookies to only DomAuthSessId (standalolne server)
      const domino_auth_cookie = cookies.filter(function(cookie) {
      return cookie.name === "DomAuthSessId" || cookie.name === "LtpaToken";

 

[NetWood]

По авторизации я один раз делал не совсем безопасный автологин: храним ID плюс что-то в куках и по JS отправляем его на сервер, сравниваем с имеющимся и скриптом+подформой отправляем уже хранимый на сервере лог+пасс и получаем автологин. Работает железобетонно.

 

[lmike]

храним ID

не понял - какой, если про браузер

 

[rinsk]

DAS по моему нифига не покроет нужный функционал.
Справочники - вероятно. Но точно не бизнес - функционал.
Вообще говоря - способов публикаций rest наружу от домино дофига и больше - агенты, вью, xpage, сервлеты и тп.
Абстрагировать фронт от конкретного endPoint легко правилом на сервере в виде:
/api/v1/module/service/method&parameter=xx

Остаётся только согласовать формат.
Но в этом случае не понятно - что будет являтся app сервером в его классическом понимании

 

[rinsk]

Берем нормальную бизнес форму, где например 15-25 селектов и каждый со своим справочником, штук 15 зависимых от данных бэка областей скрытия/показа, валидации. И получается херова туча rest запросов от ноды к домино... В разы больше чем если бы то же самое делали на формула например..
Всё это решается в контексте апп сервера что Java что node с наивным доступом к бд... Но тут какая то хрень получается..
Единственно - использование унаследованных данных.

 

[rinsk]

Проще откинуть все из домино в Постгрес или кочдб и работать с ним из ноды наивно...

 

[rinsk]

По поводу сквозной авторизации нода+домино:
Имхо на ноде можно настроить route в виде прокси в случае если токен протух/или его нет.
Т е банально при первом входе передавать в браузер ответ от домино.
И в случае успеха - в хидеры запросов к домино вставлять нужную куку.
Тут в случае SSO например узлы ноды и домино должны просто иметь одинаковый домен.
SSO нужно будет когда на бэке будет тот же кластер из нескольких серверов за ngix например.

 

[lmike]

Вообще говоря - способов публикаций rest наружу от домино дофига и больше - агенты, вью, xpage, сервлеты и тп.

но это все придется написать в домине (вью и так придётся)

Всё это решается в контексте апп сервера что Java что node с наивным доступом к бд...

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

Т е банально при первом входе передавать в браузер ответ от домино.

описанная схема так и делает, просто вопрос протухания и пр. отражается в хидере DominoAthenticationFailure

 

[NetWood]

не понял - какой, если про браузер

Вот же юзер при любой активности, например, добавляет в корзину или добавляет в избранное, агентом заводит на него карточку и пишет в куки аяксом, например id базы+id юзера. Если он потом решит зарегаться, то на эту карточку набрасывается лог+пас с подтверждением по email и рефрешем в names.nsf и он логинится. Если стоит на вебе чек автологина, то из кук берется id+что-то, например id базы, сравнивается с id в базе и автоподставляется лог+пас из базы или из names в промежуточную форму. И юзер зашел.

- Но это же не эстетично!
- Зато дешево, просто и практычно...

 

[lmike]

автоподставляется лог+пас из базы или из names в промежуточную форму.

из АК неполучится - там захэшированный, хранить отдельно - тоже так-себе..., можно выдавать токен (и вот его хранить в куках) при первом подключении и им шифровать пароль из формы (логина) в к-л базе при удачном логине. Далее, имея куку с токеном всё уже автоматом