Какую архитектуру выбрать для SPA?

Question

Борис Манжела @EKCTPEMICT

FrontEnd Developer

Какую архитектуру выбрать для SPA?

Есть сервис который в 6 шагов (на 6 отдельных зависимых друг от друга страницах) собирает данные о пользователе и выдает отчет. Бекенд на Yii, фронт на смеси js+html где на вьюхах я получаю json с данными и по своему усмотрению строю фронтенд разметку силами js (без фреймворков, события тригерятся по действию пользователя с DOM). Всего на 6 шагов около 5к строк JS Между шагами - POST-запросы

Задача от руководства преобразовать все в SPA-виджет. Мол, подключил js-файл и параметры к нему в виде js-объекта и получить функционал где бы не был подключен виджет (на бложике, на отдельном сайте). Данные обрабатывать будет наша API принимая и отдавая данные.

Кто-то советует взять React.js / Angular (для меня темный лес) или скостылить все без них где:
- виджет будет принимать DOM
- для каждого шага будет собирать и навешивать события
- отправлять данные через апишку.
- между шагами DOM и события будут назначаться заново

Господа? Ваши идеи?

Вопрос задан более трёх лет назад
597 просмотров

12 комментариев

Подписаться 6 Средний 12 комментариев

sim3x @sim3x

Цель какая?
Кто будет генерить страницы для поисковиков?

Написано более трёх лет назад
Борис Манжела @EKCTPEMICT Автор вопроса

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

Написано более трёх лет назад
sim3x @sim3x

Борис Манжела, При чем тут спа тогда?

Такое можно реализовать и на перезагрузке в ифрейме
И на jq
И очень сильно зависит от требуемого функционала

И если нет експертизы в ng/reacte то получится большая кака, особенно если требуется воспроизвести хотя бы часть функционала спа типа kayak

Написано более трёх лет назад
Борис Манжела @EKCTPEMICT Автор вопроса

sim3x, там хочется:
- Адаптивность (в приниципе реализуемо через w:100%)
- Кастомизация цвет/шрифт (параметрами вызова iframe?)
- Разгрузить сервер, что бы за разметку отвечала фронт-часть

Написано более трёх лет назад
Борис Манжела @EKCTPEMICT Автор вопроса

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

Написано более трёх лет назад
sim3x @sim3x

Борис Манжела,
0. Не касается спа - верстка
1. Не качается спа - верстка и кодинг бек енда, чтоб он создавал файл со стилями
2. Только от смены места рендеринга разметки нагрузка не сильно упадет (трафик может быть оптимизирован)

СПА хорошо заходит, когда вы можете перенести часть логики на фронтенд так, чтоб не требовалось два раза кодить
Когда большая часть сайта не меняется и может быть закеширована на клиенте

Подумайте как вы можете перенести часть логики с бека в виджет

В любом случае потребуется хороший кодер на любом из етих фреймворков

Написано более трёх лет назад
Антон Спирин @rockon404

Борис Манжела, на React такое написать без проблем:
плюсы:
1. Разработка будет гораздо быстрей. При условии, что есть опытный разработчик.
2. Легко вносить изменения. Поддержка и масштабирование без трудностей и боли.
3. Любой человек знающий React без проблем сможет в дальнейшем поддерживать ваш проект.
4. Валидация и ветвление в зависимости от введенных данных на React так же реализуется без проблем.
Из минусов то, что придется тянуть в как зависимость React, ну и надо, как минимум, знать эту библиотеку и уметь ee готовить. Можете еще в сторону Vue посмотреть.
На нативе точно будет боль с поддержкой, да и писать значительно дольше.

sim3x,
0. Наоборот, в React разработке сейчас в тренде css in js
1. не обязательно если используется css in js, достаточно запросить нужные параметры и виджет применит их при генерации css.
2. останутся только API запросы с JSON ответами.
Тут больше выгоды будет в скорости разработки и чистой, поддерживаемой и легко масштабируемой архитектуре.

Написано более трёх лет назад
sim3x @sim3x

Антон Спирин,
0. Тренд ето прикольно. Переписывать говнокод после окончания тренда - нет
1. А потом решеть проблемы отрисовки через костыли из-за "тренда"
2. Круто. Сколько занимает рендеринг во всем процессе формирования ответа клиенту? <1%?

Посчитайте время/затраты на синхронизацию кодовой базы между реактом и yii, пожалуйста

Написано более трёх лет назад
Антон Спирин @rockon404

sim3x,
0. вы не знаете о чем говорите и делаете выводы, видимо, на основе своих домыслов. Не профессиональный подход.
1. Нет никаких костылей, тысячи React приложений давно используют в продакшене.
2. Рендеринг почти не уступает инлайн стилям React. Пример производительности одной из библиотек.
Сама библиотека. Аналогов ей тьма.
В случае с ожиданием ответа API с параметрами, думаю тысячные доли секунды на генерацию.

На React с нуля писать придется. Благо переписать функционал 5k строк не долго.

Написано более трёх лет назад
sim3x @sim3x

Антон Спирин,
0. Я уже пережил несколько трендов
1. Гуд. Но на такого рода аргументацию, я приведу аргумент "Есть миллионы мух"
2. Я про рендеринг на yii

Посчитайте время/затраты на синхронизацию кодовой базы между реактом и yii, пожалуйста
Можно даже примерно

Написано более трёх лет назад
Антон Спирин @rockon404

sim3x, ну тогда это лишь ваш субъективный взгляд.
Рендеринга на yii не будет, так как модуль будет подключаться на других сайтах как плагин.
Как писал выше переписать 5k строк не долго.
А написать REST API итак судя по описанию, является одной из задач автора. Модулю вообще будет параллельно какие технологии используются на стороне сервера. Все взаимодействие по API.
А пользователи легко смогут настраивать стили и прочие вещи, прописывая нужные параметры хоть в window.__data в шаблоне страницы сайта или в data тега подключения плагина.

Написано более трёх лет назад
sim3x @sim3x

Антон Спирин, также как и ваш взгляд всего лиш ваш взгляд

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

Особенно, когда вы не понимаете, сколько кода нужно будет синхронизировать на двух яп

Написано более трёх лет назад

Пригласить эксперта

Ответы на вопрос 3

Комментировать

Ваш ответ на вопрос

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

Войти через центр авторизации

Похожие вопросы

Проектирование программного обеспечения

Простой
На чём писать клиентское приложение с GUI?
- 4 подписчика
- вчера
- 5250 просмотров
12

ответов
Yii

Простой
Можно ли сделать динамическую модель для таблиц в Yii2?
- 1 подписчик
- 14 апр.
- 33 просмотра
0

ответов
Проектирование программного обеспечения

Простой
Как сделать проект-конструктор с зависимостями на Django с переделкой существующей админки?
- 1 подписчик
- 13 апр.
- 87 просмотров
0

ответов
Yii

+1 ещё

Средний
Почему открывается папка (директория) вместо страницы docker yii2?
- 1 подписчик
- 12 апр.
- 67 просмотров
1

ответ
Yii

Простой
Почему приходит пустой массив?
- 1 подписчик
- 09 апр.
- 32 просмотра
0

ответов
PHP

+1 ещё

Простой
Как исправить баг со списком?
- 1 подписчик
- 09 апр.
- 78 просмотров
1

ответ
Одностраничное приложение

Простой
Как работает Веб приложение WAR?
- 2 подписчика
- 05 апр.
- 127 просмотров
1

ответ
Yii

Простой
Как правильно указать путь к файлу который нужно использовать по умолчанию?
- 1 подписчик
- 04 апр.
- 40 просмотров
0

ответов
Проектирование программного обеспечения

Простой
Как разделять относительно одинаковые скрипты между клиентами?
- 2 подписчика
- 03 апр.
- 200 просмотров
3

ответа
Yii

+1 ещё

Средний
Yii2 codeception REST API mock external API?
- 1 подписчик
- 03 апр.
- 73 просмотра
1

ответ
Показать ещё Загружается…

Backend-разработчик на Yii2 на проектную занятость

E-Produce

До 220 000 ₽

PHP разработчик Middle/Middle+

Teletype App

от 180 000 ₽

PHP Backend разработчик (Yii2)

Инмедиапрограмм

от 200 000 до 250 000 ₽

Изменить тему Shopify, добавить несколько категорий товаров

19 апр. 2024, в 18:11

10000 руб./за проект

Протестировать веб-сервис на Django и подготовить отчеты

19 апр. 2024, в 18:05

1000 руб./в час

Доработать проект на Django

19 апр. 2024, в 18:02

80000 руб./за проект

Цель какая?
Кто будет генерить страницы для поисковиков?
sim3x, Цель - дать возможность стороннему сайту поставить виджет, окружить его сеошным текстом или гнать на него трафик с целью сконвертить посетителя через виджета в потенциального партнера. Ну так делают виджеты бронирования билетов.
Борис Манжела, При чем тут спа тогда?

Такое можно реализовать и на перезагрузке в ифрейме
И на jq
И очень сильно зависит от требуемого функционала

И если нет експертизы в ng/reacte то получится большая кака, особенно если требуется воспроизвести хотя бы часть функционала спа типа kayak
sim3x, там хочется:
- Адаптивность (в приниципе реализуемо через w:100%)
- Кастомизация цвет/шрифт (параметрами вызова iframe?)
- Разгрузить сервер, что бы за разметку отвечала фронт-часть
Меня смущает что очень много валидаций данных на фронте. Много дома пересобирается в зависимосити от выбранных значений в селектах. И так тонна JS неподдерживаемого. А тут будет гайки
Борис Манжела,
0. Не касается спа - верстка
1. Не качается спа - верстка и кодинг бек енда, чтоб он создавал файл со стилями
2. Только от смены места рендеринга разметки нагрузка не сильно упадет (трафик может быть оптимизирован)

СПА хорошо заходит, когда вы можете перенести часть логики на фронтенд так, чтоб не требовалось два раза кодить
Когда большая часть сайта не меняется и может быть закеширована на клиенте

Подумайте как вы можете перенести часть логики с бека в виджет

В любом случае потребуется хороший кодер на любом из етих фреймворков
Борис Манжела, на React такое написать без проблем:
плюсы:
1. Разработка будет гораздо быстрей. При условии, что есть опытный разработчик.
2. Легко вносить изменения. Поддержка и масштабирование без трудностей и боли.
3. Любой человек знающий React без проблем сможет в дальнейшем поддерживать ваш проект.
4. Валидация и ветвление в зависимости от введенных данных на React так же реализуется без проблем.
Из минусов то, что придется тянуть в как зависимость React, ну и надо, как минимум, знать эту библиотеку и уметь ee готовить. Можете еще в сторону Vue посмотреть.
На нативе точно будет боль с поддержкой, да и писать значительно дольше.

sim3x,
0. Наоборот, в React разработке сейчас в тренде css in js
1. не обязательно если используется css in js, достаточно запросить нужные параметры и виджет применит их при генерации css.
2. останутся только API запросы с JSON ответами.
Тут больше выгоды будет в скорости разработки и чистой, поддерживаемой и легко масштабируемой архитектуре.
Антон Спирин,
0. Тренд ето прикольно. Переписывать говнокод после окончания тренда - нет
1. А потом решеть проблемы отрисовки через костыли из-за "тренда"
2. Круто. Сколько занимает рендеринг во всем процессе формирования ответа клиенту? <1%?

Посчитайте время/затраты на синхронизацию кодовой базы между реактом и yii, пожалуйста
sim3x,
0. вы не знаете о чем говорите и делаете выводы, видимо, на основе своих домыслов. Не профессиональный подход.
1. Нет никаких костылей, тысячи React приложений давно используют в продакшене.
2. Рендеринг почти не уступает инлайн стилям React. Пример производительности одной из библиотек.
Сама библиотека. Аналогов ей тьма.
В случае с ожиданием ответа API с параметрами, думаю тысячные доли секунды на генерацию.

На React с нуля писать придется. Благо переписать функционал 5k строк не долго.
Антон Спирин,
0. Я уже пережил несколько трендов
1. Гуд. Но на такого рода аргументацию, я приведу аргумент "Есть миллионы мух"
2. Я про рендеринг на yii

Посчитайте время/затраты на синхронизацию кодовой базы между реактом и yii, пожалуйста
Можно даже примерно
sim3x, ну тогда это лишь ваш субъективный взгляд.
Рендеринга на yii не будет, так как модуль будет подключаться на других сайтах как плагин.
Как писал выше переписать 5k строк не долго.
А написать REST API итак судя по описанию, является одной из задач автора. Модулю вообще будет параллельно какие технологии используются на стороне сервера. Все взаимодействие по API.
А пользователи легко смогут настраивать стили и прочие вещи, прописывая нужные параметры хоть в window.__data в шаблоне страницы сайта или в data тега подключения плагина.
Антон Спирин, также как и ваш взгляд всего лиш ваш взгляд

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

Особенно, когда вы не понимаете, сколько кода нужно будет синхронизировать на двух яп

Answer 1 · 2018-01-19 05:21:20

Vue куда больше подходит для интеграции в уже существующие приложения. К тому же он намного проще в освоении, нежели Angular и React.

Answer 2 · 2018-01-18 19:52:57

Если не имели дело с react/vue, то быстрее будет на js+jq, ангуляр для этого случаю можно отбросить. Я так понимаю сервис сам по себе не большой, поэтому кода много не будет. В виджет отдали селектор, внутри он сгенерировал разметку и обработчики, все запросы аяксом.
Ну а если есть время и желание, то react/vue будет самое оно, это их дело компоненты стругать, на выходе у Вас будет js с нужным апи.

Answer 3 · 2018-01-19 21:37:14

Если выбирать между React и Angular , то React просто идеален для такой задачи. Не нужен роутинг, редакс, никаких заморочек. Работать будет быстро, подключить легко. Ангуляр слишком тяжёл для этого.

Какую архитектуру выбрать для SPA?

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

Минуточку внимания

Войдите на сайт