Как грамотно связать работу backend и frontend?

Question

[Symbi0t]

Приветствую!
Хочу написать сайт исключительно под свои нужды. Для бэкенда решил взять фреймворк phalcon. А вот с фронтендом всё сложнее. Раньше, мой процесс создания клиентской части сводился к использованию jquery, что выливалось в кучу неупорядоченного кода.
Теперь же, перечитав кучу статей про модульное проектирование приложений, узнал про такие вещи как: ES6, AMD, requirejs, commonjs, node.js, Webpack и т.п. Но признаться, из-за недостатка опыта, так и не решил на чем остановиться для фронтенда. Думаю, что лучше взять ES6 + Babel + Webpack. Может я ошибаюсь и лучше взять что-то другое?
Также, не совсем понятно как реализовать клиент-серверное взаимодействие. В частности, на что больше делать акцент. Использовать сервер только для получения каких-либо данных, а бизнес-логику поручить клиентсайду? SPA или классический сайт?
Приведу пример. На сайте есть блок навигации. Как будет лучше, от сервера получать json-данные и формировать блок на клиенте, или делать всё это на сервере и просто выводить блок навигации в представлении (view)? Понимаю, что однозначного ответа нет, но хотелось бы понять где провести грань между "это делаем на бэкенде" и "это делаем на фронтенде".

Comments

[VZVZ]

"под свои нужды" и ни слова об этих самых нуждах. А ведь любой инструмент выбирают именно по задаче.

[Symbi0t]

VZVZ: Нужды достаточно тривиальны: создание списков, сохранение интересных материалов, муз.плеер со своим функционалом, некий агрегатор соц.сервисов и т.п.

[VZVZ]

Symbi0t: ну берем телевизор, вставляем в мурманский полуостров

[Айдар]

VZVZ, Ахахах)))

Answer 1

[Денис Инешин]

Просто выберите концепцию:
1. Тонкий клиент. Все рисует сервер, клиент лишь берет на себя чисто визуальные штучки, вроде анимаций, переключений элементов и т.п.
2. Толстый клиент. Сервер передает клиенту только данные через Rest API. Желательно наличие на стороне клиента како-то фреймворка (эмбер, ангуляр и т.п.)

Имейте в виду, что толстый клиент или SPA не имеет смысла сам по себе, ну разве что вы уже их сотню сделали и вам ничего не стоит сделать еще один. Он имеет смысл тогда, когда ваш сервер одновременно работает на приложения для разных платформ (смартфоны, планшеты и десктоп). В таком случае проще сделать единый сервер и общий Rest API, через который разные клиенты будут получать данные.

Делать такое для одного сайта, по сути лишняя работа.

Comments

[Сергей Протько]

на самом деле SPA + API даже дешевле чем "тонкий клиент". Мы замеряли.

[Сергей Протько]

Просто у этого подхода есть свои подводные камни (серверсайд пререндеринг отдельно нужно будет пилить или юзать платные сервисы).

[Symbi0t]

Спасибо.
Вообще, в перспективе видится адаптация сайта под моб.платформы. Исходя из этого, мне больше подойдет вариант с толстым клиентом. Но вопрос "что выбрать для фронтенда?" всё же остаётся. Использовать ангуляр не хочется, т.к. версия 1.5 постепенно уходит в историю, а 2.0 еще сыровата. С другими фреймворками не знаком. Но дело не в том, что нет желания изучить какой-нибудь, а в том, что хочется приобщиться к ES6(2015) и постепенно создавать модульное приложение на клиентсайде.

[Роман Макаров]

Symbi0t: ember.js по-умолчанию юзает бабель + строгая архитектура будет приятным дополнением для новичка.

[Symbi0t]

Роман Макаров: интересно. Большое спасибо, посмотрю.

[Денис Инешин]

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

[Денис Инешин]

Symbi0t: https://www.codeschool.com/courses/try-ember вот посмотрите курс, эмбер действительно очень классный и хорошо структурирован.

[Symbi0t]

Денис Инешин: Еще раз спасибо! Обязательно посмотрю.

[Сергей Протько]

Денис Инешин: ну это полностью согласен. Я это больше к тому что смысл их делать есть даже если не планируется мобильной платформы. Но что бы выходило выгодно нужно хорошо представлять что делать и на клиенте и на сервере.

Answer 2

[Константин Китманов]

Думаю, что лучше взять ES6 + Babel + Webpack. Может я ошибаюсь и лучше взять что-то другое?

Нормально.

Использовать сервер только для получения каких-либо данных, а бизнес-логику поручить клиентсайду? SPA или классический сайт?

Так вы задайте себе вопрос, у вас SPA или классический сайт? Приложение или газета? Gmail нет смысла делать классическим сайтом, визитку нет смысла делать SPA.

Comments

[Symbi0t]

Скорее классический сайт, чем полноценное SPA. Но именно клиентсайд хотелось бы сделать модульным, используя ES6. Отсюда и вытекает проблема. Как организовать весь этот зоопарк технологий и взаимодействие с сервером. Взять, как посоветовали выше, концепцию "толстый/тонкий клиент" или сделать гибрид обычного сайта с модульной архитектурой на клиенте.

[Константин Китманов]

Symbi0t: ES6 можно использовать и без фреймворков.

Answer 3

[Роман Макаров]

Symbi0t:

Скорее классический сайт, чем полноценное SPA. Но именно клиентсайд хотелось бы сделать модульным, используя ES6.

Вот это плохой подход. Инструменты нужны, чтобы решать проблему. А у вас подход - "Проблемы нужны, чтобы использовать инструменты".
Тем более получить поверхностные знания одно, а использовать - другое. С большой вероятностью проект будет настолько медленно развиваться, что вы забьете на дизморали.
выберите одно, на нем сконцентрируйтесь, сделайте прототип рабочий, потом постепенно переписывая допиливая с использованием новых технологий (CommonJs/AMD, к примеру, в небольшом проекте вполне нормально заменить на анонимные самовызывающиеся функции). Поймите зачем вам вообще этот проект, если это что-то большее чем песочница для обучения, то сконцентрируйтесь на этом большем (контенте).
Попробуйте реализовать какой-нибудь типовой архитектурный шаблон на нативном js, чтобы лучше видеть +/- фреймворков(библиотек), какие проблемы решают, да и вообще понимать, что там происходит.

Comments

[Symbi0t]

Спасибо за советы.
Задача выяснить +/- фреймворков не стоит, хотя конечно же, было бы полезно. Главная задача поднять сайт с необходимым функционалом и постепенно его развивать. Причем важны 2 нюанса: скорость разработки и постепенное (растянутое во времени) допиливание новых фич. Понимаю, что это противоречит моему желанию взяться за ES6, и писать модульное приложение почти с нуля. Просто, впечатлили новые возможности и захотелось использовать их в долгосрочной перспективе.
Думаю воспользоваться вашим советом по поводу ember.js.