Выбор архитектуры для web-приложения

Question

[Максим]

Создается прототип web-приложения. В качестве базы уже выбрана Neo4j. Теперь выбор за всем остальным (БЛ, интерфейс и т.д.). Возникла идея: реализовать приложение полностью на клиенте, AngularJS например, и общаться с СУБД по REST'у (например с помощью этого). Получаем довольно легкое и гибкое приложение, написанное по максимуму на одном языке и относительную непривязанность к базе.
Как думаете, что из этого может получится. Если у кого похожий опыт, может не с Neo4j, а например с CouchDB или еще чем?

Comments

[zarincheg]

А почему вы выбрали Neo4j?

[Максим]

Планируется гибкая структура данных, где сущности определяет сам пользователь, может связывать их, заполнять данными, а затем делать запросы к ним (причем достаточно сложные, как визуальные так и на каком-либо языке запросов) и (самое главное) на основании этих выборок производить расчеты. Т.е. грубо-говоря, некая смесь экселя и аксесса в вебе, заточенная под расчетные задачи.
EAV был отброшен, т.к. есть опыт работы с ним, все минусы хорошо известны, да и скучно это, решил попробовать что-нибудь графовое.
Многие конечно говорят, что вся эта «гибкость» из-за неправильной постановки задачи, и что можно ограничиться обычной реляционкой, если болле четко поставить задачу, но я этого пока не могу сделать.

Answer 1

[max_mara]

Я бы на самом деле написал бы RESTful JSON API, вместо прямого общения с БД, по крайней мере больше возможностей для управления политиками доступа.

С CouchDB тоже такое можно провернуть и всю логику перенести прямо в БД, а общение у них там через HTTP-JSON.

Comments

[Максим]

Я бы на самом деле написал бы RESTful JSON API, вместо прямого общения с БД, по крайней мере больше возможностей для управления политиками доступа.

Т.е. промежуточный слой на сервере?

[SleepwalkerOne]

Возникла идея: реализовать приложение полностью на клиенте

Реализовать полностью на клиенте UI часть веб приложения. Общение с сервером через RESTful JSON API. Бизнес логика тоже на сервере между RESTful интерфейсом и слоем доступа к данным. Мне кажется такой подход верный при проектировании веб приложений с использованием клиентской части. А вот выносить «все» приложение в клиент — это очень не понятно и очень не правильно.
AngularJS поможет вам реализовать ту самую UI часть приложения, быстро и красиво… Но только UI, он для этого и проектировался, не более того.

Answer 2

[stepank]

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

Answer 3

[EugeneOZ]

ВСЁ на клиентской стороне не реализуете, но чем больше вынесете — тем лучше. В случае с AngularJS можно вообще отдавать HTML-страницы с сервера и потом уже заполнять их данными после ajax-запросов. Но напрямую с БД вообще без backend… Есть такое движение, No Backend!, но и там понимают, что полное избавление от backend недостижимо. Для примера подумайте про интеграцию с PayPal.

Comments

[EugeneOZ]

И ещё один момент — SEO. Вот инструкция про SEO в AngularJS