2015-05-13 1 views
0

Я начинаю проект, который в основном представляет собой одностраничное приложение, которое загружает и показывает кучу статистики (с использованием d3.js). Уровень данных Mongo-powered, обслуживается через RESTful API, а клиентское приложение будет закодировано в Ember.js. Мы хотим, чтобы все данные обменивались через API, так как у нас также есть некоторые мобильные приложения на заднем плане, которые подключаются к одному и тому же API.Внедрение веб-приложения на основе RESTful API. Нужен ли мне серверный интерфейс?

Я обсуждаю вопрос о том, следует ли писать API (используя Express.js или другую серверную инфраструктуру MVC) или просто использовать API, используя Deployd, а не использовать серверную структуру вообще, помимо Deployd. Я дам несколько советов о характеристиках проекта:

  • Основная особенность - это, в основном, панель мониторинга, которая показывает агрегированную статистику, которая уже вычисляется и хранится в базе данных Mongo.
  • Пользовательское взаимодействие минимально, достаточно, чтобы пользователи могли настраивать свои информационные панели, но пользователи никогда не загружают данные (другие параметры настройки).
  • Большинство приложений - это множество d3.js для создания и рендеринга кучи графиков, которые можно настроить разными способами.
  • Для этого требуется очень богатый и отзывчивый пользовательский интерфейс.

Я предложил полностью отказаться от серверной структуры и просто пойти с кучей статического HTML + CSS и сделать весь тяжелый подъем с клиентской MVC, такой как Ember.js. Поскольку все загрузки и выгрузки данных могут обрабатываться Deployd, чистый статический сайт будет загружаться намного быстрее, а также проще масштабировать. Кроме того, (я думаю) все пользовательские данные и проверка могут быть сделаны с помощью Deployd.

Дело в том, что некоторые из моих коллег имели сердечный удар, когда я упомянул об этой идее. Поэтому мне бы хотелось проверить реальность: действительно ли мне нужна серверная инфраструктура помимо Deployd, чтобы справиться с проблемами, которые я пока не могу предвидеть? Являются ли преимущества наличия чистого статического сайта достаточно хорошим компромиссом против наличия, скажем, Express.js на всякий случай?

ответ

1

Я не работал с Deployd раньше, но из-за быстрого просмотра его документов он находится в : a server-side framework. Он принимает запросы и отвечает json. Он просто ориентирован на API и json и пренебрегает html, в отличие, скажем, по умолчанию Ruby on Rails.

Основные проблемы, которые могут возникнуть из-за отсутствия традиционной серверной структуры, такие вещи, как auth, CORS и XSS/CSRF/other common security issues. Вы можете использовать это через Deployd, если он встроен или легко добавлен, но это может быть сложно.

Оглядываясь в документы Deployd, я вижу, что есть guide для пользователей и CORS. Я ничего не могу найти о XSS или CSRF.

+0

Спасибо. В итоге я решил пропустить Deployd в пользу более традиционного API Express.js для поддержки многих из этих вещей, таких как аутентификация с использованием удивительного Passport, CORS и безопасности. –

Смежные вопросы