Как достучаться из веб-приложения к акс2012, акс2009? Сервер OData?

[mazzy]

Цитата:

Сообщение от mazzy

Как достучаться из веб-приложения к акс2012, акс2009?

Предположим, есть традиционное веб-приложение на традиционном для веба LAMP

остальное сознательно не конкретизировано.

Цитата:

Сообщение от Diman

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

Правильно = в долгосрочной перспективе максимизировать удовольствие пользователя от приложения при минимизации трудозатрат разработчиков.

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

скорее всего, при высокой нагрузке будет одно решение. какое?
а при низкой - другое. какое? или то же самое?

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

примеры:
https://angularjs.org/ (начиная со слов Data binding)
http://learn.knockoutjs.com/#/?tutorial=loadingsaving
https://facebook.github.io/react/tutorial/tutorial.html

[Diman]

Цитата:

Сообщение от mazzy

остальное сознательно не конкретизировано.


Правильно = в долгосрочной перспективе максимизировать удовольствие пользователя от приложения при минимизации трудозатрат разработчиков.

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

скорее всего, при высокой нагрузке будет одно решение. какое?
а при низкой - другое. какое? или то же самое?

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

примеры:
https://angularjs.org/ (начиная со слов Data binding)
http://learn.knockoutjs.com/#/?tutorial=loadingsaving
https://facebook.github.io/react/tutorial/tutorial.html

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

[mazzy]

Цитата:

Сообщение от Diman

Не понял причем тут JS фреймворки.

Что можете предложить посмотреть?

[Diman]

Цитата:

Сообщение от mazzy

Что можете предложить посмотреть?

Из очередей: Rabbit, Redis, ActiveMQ
Для интеграции всего этого хозяйства с поддержкой BPM: Apache camel, Mule
Если сервисs не предполагают сложной логики, а так, чисто фасад к БД, то Go, NodeJS
Если сложное, то само собой C# / Java
НО сразу оговорюсь - этот зоопарк есть смысл разводить для больших проектов.
IMHO
Для акса 2012 и выше я бы выбрал сервисы на стороне аксы.

[mazzy]

И вопрос:

Цитата:

Сообщение от Diman

Если сервисs не предполагают сложной логики, а так, чисто фасад к БД, то Go, NodeJS
...
Для акса 2012 и выше я бы выбрал сервисы на стороне аксы.

Если бы подобный "фасад" уже существовал бы, то каков был бы выбор?

В частности, если бы в акс2012, акс2009 была бы спущена реализация сервер OData с акс7?

[Diman]

Цитата:

Сообщение от mazzy

И вопрос:
Если бы подобный "фасад" уже существовал бы, то каков был бы выбор?
В частности, если бы в акс2012, акс2009 была бы спущена реализация сервер OData с акс7?

Я бы сделал так:
AX as a set of services - Queue - facade [LAMP + front (reactJS)]
Можно отказаться от очереди в этой схеме если пользователь готов ждать\терять запрос\ответ и весь роутинг зашить в LAMP