Комментарии 20
Попадался на stackoverflow такой же подход.
А еще вопрос, почему не использовать node-canvas и не генерить картинки с помощью него и d3?
Отвечу на оба комментария тут.
1. На стековерфлоу есть куча описаний подобного подхода. В статье я описал уже готовое решение.
2. Node-canvas не рассматривался потому, что а) времени на инвестигейт было мало и первый же вменяемый вариант был реализован и б) построение графиков в дом уже было на клиенте
За наводку на node-canvas спасибо.
UPD: В подходе с node-canvas я вижу проблему в том, что графика будет рендерится самим нодом. Если это так, то по моему мнению это не лучший подход именно для ноды. В случае с фантомом нода получается независимым процессом.
Если я ошибаюсь, я бы хотел, чтобы знающие люди меня поправили.
1. На стековерфлоу есть куча описаний подобного подхода. В статье я описал уже готовое решение.
2. Node-canvas не рассматривался потому, что а) времени на инвестигейт было мало и первый же вменяемый вариант был реализован и б) построение графиков в дом уже было на клиенте
За наводку на node-canvas спасибо.
UPD: В подходе с node-canvas я вижу проблему в том, что графика будет рендерится самим нодом. Если это так, то по моему мнению это не лучший подход именно для ноды. В случае с фантомом нода получается независимым процессом.
Если я ошибаюсь, я бы хотел, чтобы знающие люди меня поправили.
Просто если у вас код на d3 то он останется практически без изменений. А node-canvas позволяет генерить дата-урл, поэтому можно одним запросом весь дашборд стягивать.
«Практически без изменений» не годится. В подходе с фантомом мы полностью переиспользуем логику с клиента. Т.е. дублирования кода нету вообще.
Фантом тоже позволяет генерить дата-урл (точнее base64 encoded картинку, что легко превращается в дата-урл).
Опять же, сохранение картинки — это часть нашей архитектурной модели. Вероятно, на этом стоит акцентировать внимание в статье?
Фантом тоже позволяет генерить дата-урл (точнее base64 encoded картинку, что легко превращается в дата-урл).
Опять же, сохранение картинки — это часть нашей архитектурной модели. Вероятно, на этом стоит акцентировать внимание в статье?
lol
Потому что d3 это SVG но никак не canvas
Потому что d3 это SVG но никак не canvas
Вообще то d3 некоторое время поддерживает canvas.
Вот пример из галлереи. bl.ocks.org/mbostock/1276463
Слова «НАША фирма нашла BigData-стартап, КОМАНДА выйграла тендер и теперь МЫ....» буквально убили мои детские представления… больше ни один стартап не задумаю, а то тоже украдут перепилят и извратят!
Я надеюсь, что это шутка :)
Но на всякий случай уточню. Наш менеджер нашел клиента, которому нужно было запилить стартап. Клиент предоставил набор тестовых заданий и мы их выполнили лучше, чем конкуренты. Теперь мы — удаленная команда, пилящая прототип клиента. Т.е мы аутсорс, который делает проект для американского дяди :)
Но на всякий случай уточню. Наш менеджер нашел клиента, которому нужно было запилить стартап. Клиент предоставил набор тестовых заданий и мы их выполнили лучше, чем конкуренты. Теперь мы — удаленная команда, пилящая прототип клиента. Т.е мы аутсорс, который делает проект для американского дяди :)
1. А зачем SVG конвертировать в bitmap?
2. Я так понимаю — размеры графики прибиты гвоздями на стороне сервера?
2. Я так понимаю — размеры графики прибиты гвоздями на стороне сервера?
1. SCG конвертируется в битмап для того, чтобы на выходе мы имели все же статическую картинку. Эту картинку мы отдаем не веб-клиенту, а потребителю нашего REST API.
2. Размеры прибиты гвоздями, да. Но размер вьюпорта задается — в коде есть намек на это дело. И можно прокидывать параметры непосредственно в скрипт отрисовки.
Но в целом да, на выходе мы имеем статическую картинку определенного размера.
2. Размеры прибиты гвоздями, да. Но размер вьюпорта задается — в коде есть намек на это дело. И можно прокидывать параметры непосредственно в скрипт отрисовки.
Но в целом да, на выходе мы имеем статическую картинку определенного размера.
"… для всех клиентов" имеется ввиду, видимо.
Т.е. вопрос поддержки разных размеров экрана у клиентов, видимо, не стоит?
Т.е. вопрос поддержки разных размеров экрана у клиентов, видимо, не стоит?
Вопрос стоит. Этим занимается веб-клиент: в нем такие же графики рендерятся уже в зависимости от вьюпорта и им добавляется интерактивность. Серверный статические графики нам нужны, чтобы отдавать их «роботам».
Т.о. человек может получить три вида информации:
1. Интерактивная графика через веб-морду
2. Статическая графика через REST API
3. Голые данные через REST API
Т.о. человек может получить три вида информации:
1. Интерактивная графика через веб-морду
2. Статическая графика через REST API
3. Голые данные через REST API
1. IMHO Date.now() маловато для уникальности файла, лучше добавить счетчик.
2. Как собираетесь зачищать устаревшие файлы?
2. Как собираетесь зачищать устаревшие файлы?
На эти вопросы нам отвечать, к счастью, не нужно в ближайшее время.
Поясню почему: для каждого пользователя в системе будет деплоится отдельный REST-server на собственном EC2 микро инстансе. Таково желание клиента на данной стадии.
1. Период запросов на построение графики определенно будет больше сотни миллисекунд, т.к. запросы приходят от одного клиента.
2. Устаревшие файлы очищать пока никак не собираемся. У пользователя в рабочей области потенциально будут лежать гигабайты различных данных. На фоне этого хранение избыточной статики не пугает.
Поясню почему: для каждого пользователя в системе будет деплоится отдельный REST-server на собственном EC2 микро инстансе. Таково желание клиента на данной стадии.
1. Период запросов на построение графики определенно будет больше сотни миллисекунд, т.к. запросы приходят от одного клиента.
2. Устаревшие файлы очищать пока никак не собираемся. У пользователя в рабочей области потенциально будут лежать гигабайты различных данных. На фоне этого хранение избыточной статики не пугает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Визуализация на сервере: NodeJS + D3.js + PhantomJS