Архитектура проекта

Question

[Oleg Sheshin]

Коллеги!

Помогите пожалуйста советом где можно прочитать про архитектуру веб-проекта, в частности очень интересует вопрос о схеме взаимодействия между front-end'om и back-end'om посредством запросов к API на сервере (беке). Какие у этого решения плюсы и минусы в сравнении с классической архитектурой проекта. Насколько я знаю по такой схеме работал twitter, но в последствии ушёл от неё.
Буду благодарен за ссылки, а также ваше мнение по этому поводу.

Comments

[EugeneOZ]

Никуда он от неё не уходил.

Answer 1

[EugeneOZ]

Точных ссылок не скажу, но могу подсказать ключевые слова: NoBackend movement, AngularJS, Firebase, Polymer, Shadow DOM, MeteorJS.
К тому, что я прочитал в Ваших комментариях к ответам, могу добавить, что на бэкэнде придётся оставить ещё и логику, на которую не должен иметь права влиять пользователь. В остальном Вы правильно рассуждаете.

Answer 2

[Kir ---]

Не понимаю сути вопроса.
В данном случае API отличается от набора экшенов лишь тем, что оно документировано.
Далее, что вы подразумеваете под архитектурой(не понимаю с какой стороны вы смотрите на проблему)?

Если же вопрос состоит в том, создавать ли полностью AJAX приложение, то мой совет прост — нет. Потому что это очень сильно затягивает разработку и усложняет код. На серверных языках, типа PHP люди пишут кое как, а с JS вообще беда поголовно у всех. И даже не потому что не знают как писать, а потому что сроки жмут и делают так что бы побыстрее.

Comments

[Oleg Sheshin]

Я не понял то что вы написали :(. Мой вопрос заключается в том. насколько целесообразно и логично хранить весь фронтенд проекта (верстку js) на клиенте и при этом через него же слать запросы к api бекенда для получения данных. Уточню — я не программист на данный момент и как программист никогда с хайлоадом не работал, я проект-менеджер, который пытается глубже вникнуть в вопрос, отсюда и проблема — я несу всякую ересь.:) Насколько я понял из прочтения вышеуказанной книги фронтенд как сервер необходим, для обработки простых запросов (дай мне картинку, дай мне сообщение), бекенд же служит для вычислений и логики проекта и к нему надо обращаться только в случаях когда запрос сложный и не может быть обработан фронтендом самостоятельно или фронтенд не может взять данные из хранилища просто так. Для меня же при написании вопроса смысл имело обоснование хранения на машине пользователя всего интерфейса, но сейчас я так понимаю это уже неважно, потому что оно и так будет хранится на машине пользователя.

[EugeneOZ]

Абсолютно не согласен. Во-первых, то, что Вы видите API только как сервис для ajax это уже полный бред — с API могут работать другие сайты, мобильные приложения — тут ajax это крохотная верхушка айсберга.
Во-вторых, современные js-фреймворки позволяют значительно ускорить разработку, при этом уменьшая количество кода, багов и повышая usability. И порог вхождения — ниже, чем у PHP, т.к. JsvaScript очень уж простой язык.

[EugeneOZ]

Уточню: мой коменнтарий — к ответу, не к комментарию.

[Oleg Sheshin]

SowingSadness, а чем это усложнит код? По сути ведь мы как раз разделяем всё на логичные блоки. Интерфейс у нас никак не привязан (жёстко) к логике, он лишь берёт и отдаёт данные и он может быть переписан в любой момент не затрагивая при этом логику работы проекта. Также мы значительно упрощаем разработку клиентов для мобильных систем и даём возможность писать приложения для сайта сторонним разработчикам (при условии наличия публичных функций API). То есть если вдруг девелопер ajax приложения накосячит, надо будет исправлять косяки только в этом приложении не затрагивая бекенд проекта. Или я опять чего-то не догоняю?

[Kir ---]

EugeneOZ Ох уж сколько я разработчиков повидал в РФ. Тех кто пишет грамотный структурированный JS код — единицы. Многие кто изучают JS-фреймворки вообще не могут ответить на вопрос, чем же подход который они используют упрощают их код. Т.к. когда смотришь на их детище, то там чёрт ногу сломит.
Порог вхождения в язык меньше, а вот уровня когда можно разработать что-то более менее значимое достигают среди тех кто вошел в него гораздо меньше, чем тех же Пыхеров.

Вы словами про API ни сколько не опровергли мои тезисы, зачем вы сейчас мне это написали?

IIIyT
Далее, если в один прекрасный момент всё приложение просто отображает белую страницу в браузере, значит где то в вашей тонне кода появилась ошибка, пойдика разгреби. Это может быть как вселенский просчет в архитектуре, так и простая точка с запятой.
С классической схемой разработки, в определенный момент вы увидете конкретный эксепшен в логах или в браузере. Либо Вообще все отвалится кроме небольшого виджета. Другие словами, с отловом ошибок всё гораздо хуже чем с языками на серверной стороне.

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

Сейчас есть множество кодагенераторов CRUD которые экономят тонну времени, для создания каркаса. Под одностраничное приложение придется всё делать ручками.

При появлении нового члена команды он быстрее вольётся в разработку(значительно быстрее)

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

p.s.
Сколько знаю full ajax проектов(больших) во всех большая проблема со скоростью разработки. Мы успевали за то время, когда js команда запустит 1 такой сайт разработать 3 подобных по сложности проекта на Symfony 2 и\или на Yii

[EugeneOZ]

SowingSadness посмотрите, куда двигается мир IT-разработчиков, в том числе крупнейшие сайты. И подумайте, Вы или они совершают ошибку.

[Kir ---]

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