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

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

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

Делать такое для одного сайта, по сути лишняя работа.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
k12th
@k12th
console.log(`You're pulling my leg, right?`);
Думаю, что лучше взять ES6 + Babel + Webpack. Может я ошибаюсь и лучше взять что-то другое?
Нормально.

Использовать сервер только для получения каких-либо данных, а бизнес-логику поручить клиентсайду? SPA или классический сайт?
Так вы задайте себе вопрос, у вас SPA или классический сайт? Приложение или газета? Gmail нет смысла делать классическим сайтом, визитку нет смысла делать SPA.
Ответ написан
Symbi0t:
Скорее классический сайт, чем полноценное SPA. Но именно клиентсайд хотелось бы сделать модульным, используя ES6.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы