Владимир,
3) Судя по всему все и идет к реализации второй архитектуры и проведению тестов для выбора оптимального варианта. Было интересно возможно кто-то с этим уже сталкивался и готов поделиться советами для сохранения времени.
1) С universal был опыт. Работает это в разы медленнее и имеет место быть, только для отдачи страницы поисковому роботу для индексации. В иных ситуациях это выстрел по комару из пушки.
2) Серверный рэндеринг работает и страница обращается к АПИ. Каждый запрос отрисовывает страницу, все действия идут через к АПИ через сокеты. Отличается это архитектурой системы.
ПС: не совсем понял как от вопроса про целесообразность смены архитектуры (о плюсах и минусах относительно текущей) мы перешли к обсуждению ангуляра. Мы не сравниваем сингл пэйдж и не сингл. Я пытаюсь понять, насколько плохо использовать рэндеринг прямо в том же аппликейшене на ноде вместе с АПИ, стоит ли разбивать сервера на фронт и бэк.
Рэндерить ангуляр это уж совсем... Для меня он и удобен тем что рэндириться на клиенте и отдавать его можно как статику через nginx. Вопрос не в том как рэндерить страницу, а в том не сильно ли это тормозит тачку с АПИ и есть ли смысл выделять под front еще 2 машины
Да, спасибо, все работает. Я пропустил при разрешении доступа, что нет запроса доступа к стене, изменил redirect_uri и доступ появился. Я смотрю у этого токена expires_in=0, насколько часто он по факту умирает?
По поводу уменьшения понял, спасибо! PS - в данный момент рассматриваю вариант прогнать картинку через мудуль nginx (https://developers.google.com/speed/pagespeed/modu... и после уже вставить уменьшенную картинку в канвас
Т.е. я беру размер канваса и размер картинки. Делю размер картинки на размер канваса (в зависимости от формата картинки либо по высоте либо по ширине) и округляю в большую сторону - это и будет кол-во преобразований. Затем выполняю это кол-во раз уменьшение картинки в двое. Все правильно? В идеале картинка должна быть по размерам канваса исходного.
Еще такой вопрос: есть ли шанс делать обработку с сохранением исходного размера картинки (но канвас при этом меньше картинки)?
По поводу текста - да, просто видел в одной библиотеки как текст добавляется сразу с функцией драг энд дропа и ресайза (как все привыкли, за угол тянуть)
Сделал через Open API создал приложение для сайта, делаю запрос на wall.post получаю это Uncaught TypeError: Cannot read property 'closed' of undefined (openapi.js:583). То ли лыжи не едут то ли я не лыжник уже((
А про фрейм как идея? Вывести в модальном окне фрейм его на авторизацию и оттуда редиректом на вк бланк, адрес скопирую и закрою фрейм? Такое может получиться?
Про засрут уже видел инфу, но для чего подтверждения? Сделайте с ним и все окей будет, уберите скоп оффлайн и нормально. По поводу standealone это не я придумал это такой тип приложения при создании указал.
Хорошо, попробую. А не может как вариан быть такое решение: открываю фрейм с адресом autorize там делать редирект на бланк и потом копировать url с токеном и закрывать фрейм?
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
3) Судя по всему все и идет к реализации второй архитектуры и проведению тестов для выбора оптимального варианта. Было интересно возможно кто-то с этим уже сталкивался и готов поделиться советами для сохранения времени.
1) С universal был опыт. Работает это в разы медленнее и имеет место быть, только для отдачи страницы поисковому роботу для индексации. В иных ситуациях это выстрел по комару из пушки.
2) Серверный рэндеринг работает и страница обращается к АПИ. Каждый запрос отрисовывает страницу, все действия идут через к АПИ через сокеты. Отличается это архитектурой системы.
ПС: не совсем понял как от вопроса про целесообразность смены архитектуры (о плюсах и минусах относительно текущей) мы перешли к обсуждению ангуляра. Мы не сравниваем сингл пэйдж и не сингл. Я пытаюсь понять, насколько плохо использовать рэндеринг прямо в том же аппликейшене на ноде вместе с АПИ, стоит ли разбивать сервера на фронт и бэк.