SPA архитектура
 

Всем Привет! :)

Воображаемое облачное приложение - это большой список задач 1000+ (тудушки)

Каждая задача достаточно обьемна и содержит в себе этапы, сроки, всякие статусы, приритеты, исполнителей, комментарии и тд. Все это можно менять.

Список можно фильтровать по тэгам, алфавиту, дате, статусам, приоритетам.. короче почти по всем пунктам.

Какая больше подходит архитектура, с учетом того что должно работать и на мобильных?

1) Снять все обязанности с фронта и доверить фильтрацию серверу,
каждое изменение отдавать его величеству. (гоняем большие json-ы)
+ Легко реализовать.
- 100 маленьких компаний, по 1000 задач в каждой, и 600 человеками прсото ddos-нут сервер, придется тратится на железо.;)
- Отзывчивостью и не пахло(и старничку обновлять нид, чтобы изменения подтянуть), особенно плохо если гонять по 3г

2) Каждый пользователь асинхронно скачивает себе дамп задач и записывает в локальное хранилище, далее работает исключительно с ним, Каждое изменение попадает в планировщик, а тот уже синхронизирует с сервером. Остальные могут получать изменения например по сокетам.

- Сложнее реализовать, т.к много тонких мест.
+ Можно работать в офлайне или со слабым инетом
+ Можно юзать более дешевое железо
- Отзывчивость сильно зависит от мощности девайса, но грамотное кэширование, кусочек асинхронности и все будет летать.

3) другие способы??


А что Вы думаете по этому поводу? :)

Опять с бэкендером спорил..)

п.1

Я сейчас чем-то подобным занимаюсь.

По сути у нас есть конструктор таблиц (конфигурируется с сервера)
т.е. вся таблица строится динамически на клиенте (колонки, фильтры etc.)

https://yadi.sk/i/jIyrSM98bphUv

Если тебе не нужна работа offline, то не заморачивайся и делай всё на сервере.

Хранить по максимуму на сервере. Работать тоже с ним. Данные гонять на сервер. Можно частично кэшировать, но обязательно синхронизировать при первой возможности. 100 компаний моментально сделают тебе git из твоего приложения, если не синхронизировать постоянно.

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

Каждая компания живет в отдельной песочнице. Косяк п.2 в том что запилить сложно?
Я просто думал что нагрузку на сервер нужно уменьшать по возможности, и такие вещи как например фильтрация поручать клиенту, а тогда так или иначе нужно отдавать ему дамп, или хотя бы модели, чтобы он отфилтровал.

Если не указано иного считаем что клиент работает с утюга.)

Наверное регулярно ругаюсь с бэкендерами пттому что хочу сделать клиет толще))

только не в том месте, в кот. ты хочешь это сделать

с сапога :D

жирным и неповоротливым :)

А в каком?

будь моя воля я бы от бэка избавился и воцарился бы p2p среди клиентов, но блин приложенице не подходящее и как сделять я хз пока))

Кст о p2p, кто то может объяснть как с помощью DHT находятся узлы в p2p сети? ИЛи я не правильно понимаю что такое DHT ?

Товарищи, поясните пожалуйста за SEO-оптимизацию?
Есть некое SPA. Нужно, чтобы по прямому(переход с другого сайта или браузерной строки) GET-запросу грузилась уже "собранная" страница, а если пользователь перешёл по внутренней ссылке, то просто отдавался, например, JSON и обрабатывался на клиенте.
Как вы определяете как отдавать данные?

Это же элементарно: если на сервер приходит урл, то он отдаёт страницу, а переходы по самой странице проксятся через HistoryAPI. Желательно иметь один и тот же шаблонный движок для сервера и клиента.

kobezzza,
это, в общем-то, понятно. Но на сервер в любом случае пойдёт тот же гет-запрос(?). Или когда переход осуществляется по самой странице нужно просто поставить флаг, скажем, type=ajax?

Safort,
Можно определить на сервере откуда делается запрос. referrer, наличие кук и т.д. Но можно и как ты написал.

Gozar,
про реферрер тоже думал, но разве у поисковика он отличается от пользовательского?

Я обычно делаю так:

/kobezzza/profile - простой URL

/h/kobezzza/profile - URL для AJAX

kobezzza,
а что значит /h/ ?)

Это палочка, буква h и снова палочка ;)

Если урл разбираешь с начала, то удобно наверное.

handlers конечно же :)

И это на меня по поводу сокращений на форуме некоторые гонят... Буду ставить в пример :)

Gozar,
И не поспоришь)


kobezzza,
А, ок.

----

Всем спасибо за помощь.