Отдельный сервер REST JSON API и клиент? [закрыто]

Вы можете попробовать что-то вроде следующего, чтобы найти столбец, содержащий символ не-ascii:

select * from your_table where your_col <> asciistr(your_col);
370
задан sivers 8 June 2012 в 01:32
поделиться

18 ответов

На Безграничный мы углубились в вариант # 2 и представили его тысячам студентов. Наш сервер представляет собой JSON REST API (Scala + MongoDB), и весь наш клиентский код обслуживается прямо из CloudFront (то есть: www.boundless.com - это просто псевдоним CloudFront).

Плюсы:

  • Ультрасовременный / захватывающий
  • Много возможностей для вашего бакса: API дает вам основу для вашего собственного веб-клиента, мобильных клиентов, стороннего доступа, и т.д.
  • чрезвычайно быстрая загрузка сайта / переходы по страницам

Минусы:

  • Не оптимизирован для SEO / готов без особого труда.
  • Требуются первоклассные пользователи веб-интерфейса, которые готовы справиться с реальностью сайта, который на 70% состоит из JavaScript, и что это значит.

Я действительно думаю, что это будущее всех веб-приложений.

Некоторые мысли для пользователей веб-интерфейса (вот где вся новизна / вызов дается этой архитектуре):

  • CoffeeScript. Намного проще создавать качественный код.
  • Магистраль. Отличный способ организовать свою логику и активное сообщество.
  • HAMLC. Шаблоны Haml + CoffeeScript => JS.
  • SASS

Мы создали жгут для нашей интерфейсной разработки под названием «Spar» (одностраничное приложение Rocketship), которое фактически представляет собой конвейер ресурсов от Rails, настроенный для разработки одностраничных приложений. В течение следующих нескольких недель мы будем открывать ресурсы на нашей странице github вместе с сообщением в блоге, объясняющим, как использовать его и общую архитектуру более подробно.

ОБНОВЛЕНИЕ:

Что касается проблем людей с Backbone, я думаю, что они переоценены. Магистраль - это скорее организационный принцип, чем глубокая структура. Сам сайт Твиттера - гигантский зверь из Javascript, охватывающий каждый кейс для миллионов пользователей. устаревшие браузеры, загружая твиты в реальном времени, собирая мусор, отображая большое количество мультимедиа и т. д. Из всех «чистых» js-сайтов, которые я видел, Twitter - самый странный. Было много впечатляюще сложных приложений, доставленных через JS, которые очень хорошо работают.

И ваш выбор архитектуры полностью зависит от ваших целей. Если вы ищете самый быстрый способ поддержки нескольких клиентов и имеете доступ к хорошим фронтенд-талантам, инвестирование в автономный API - отличный способ.

135
ответ дан Marwa Hack 8 June 2012 в 01:32
поделиться

Создание JSON API в Rails - это первый класс, гем JSONAPI :: Resources делает тяжелую работу для http://jsonapi.org специального API.

0
ответ дан pixelhandler 8 June 2012 в 01:32
поделиться

Я решил перейти к архитектуре варианта № 2 для Infiniforms , поскольку он предоставил отличный способ отделить пользовательский интерфейс от бизнес-логики.

Преимущество этого заключается в том, что серверы API могут масштабироваться независимо от веб-серверов. Если у вас несколько клиентов, веб-сайтам не нужно масштабироваться в той же степени, что и веб-серверы, поскольку некоторые клиенты будут работать на телефоне / планшете или на настольном компьютере.

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

1
ответ дан Karl Gjertsen 8 June 2012 в 01:32
поделиться

Я лично предпочитаю вариант (3) в качестве решения. Он используется почти на всех сайтах моего бывшего (фамилии) работодателя. Это означает, что вы можете получить некоторых разработчиков интерфейса, которые знают все о Javascript, особенностях браузера и еще много чего, чтобы закодировать ваш интерфейс. Им нужно знать только «curl xyz, и вы получите немного json», и они уходят.

Тем временем ваши тяжелые бэкэнды могут кодировать поставщиков Json. Этим ребятам вообще не нужно думать о представлении, а вместо этого беспокоятся о нестабильных бэкэндах, тайм-аутах, изящной обработке ошибок, пулах соединений с базами данных, потоке, масштабировании и т. Д.

Вариант 3 дает хорошую, прочную трехуровневую архитектуру. Это означает, что материал, который вы выплевываете из внешнего интерфейса, оптимизирован для SEO, может быть приспособлен для работы со старыми или новыми браузерами (и с отключенным JS), и все же может быть Javascript на стороне клиента, если хотите (можно делайте что-то вроде обработки старых браузеров / googlebot со статическим HTML, но отправляйте JS встроенные динамические приложения людям, использующим последний браузер Chrome или любой другой).

Во всех случаях, которые я видел в Варианте 3, это была пользовательская реализация некоторого PHP, который не особенно переносим между проектами, не говоря уже о том, чтобы выходить на землю с открытым исходным кодом. Я предполагаю, что совсем недавно PHP, возможно, заменили на Ruby / Rails, но то же самое по-прежнему верно.

FWIW, $ current_employer мог бы сделать с вариантом 3 в нескольких важных местах. Я ищу хороший Ruby-фреймворк для сборки чего-либо. Я уверен, что смогу собрать воедино множество драгоценных камней, но я бы предпочел один продукт, который в целом предоставляет шаблонное, «скручиваемое», дополнительное аутентификация, дополнительное решение для кэширования с использованием memcache / nosql. Там я не могу найти ничего связного: - (

0
ответ дан Ralph Bolton 8 June 2012 в 01:32
поделиться

Очень хороший вопрос, и я удивлен, поскольку думал, что это очень распространенная задача в настоящее время, так что у меня будет достаточно ресурсов для этой проблемы, однако оказалось, что это не так.

Мои мысли заключаются в следующем: - Создать какой-то модуль, который имеет общую логику между контроллерами API и контроллерами HTML без возврата json или рендеринга html, и включить этот модуль как в контроллер HTML, так и в контроллер API, затем делайте что хотите, например:

module WebAndAPICommon
    module Products

        def index
            @products = # do some logic here that will set @products variable
        end

    end
end


class ProductsController < ApplicationController
    # default products controlelr, for rendering HMTL pages 
    include WebAndAPICommon

    def index
        super
    end

end



module API
    class ProductsController
        include WebAndAPICommon

        def index
            super
            render json: @products
        end

    end
end
1
ответ дан Loai Ghoraba 8 June 2012 в 01:32
поделиться

Для atyourservice.com.cy мы используем серверные отрендеренные шаблоны для страниц, особенно для покрытия самой части. И использование API для взаимодействия после загрузки страницы. Поскольку наша структура MVC, все функции контроллера дублируются на вывод json и вывод html. Шаблоны чистые и получают только объект. Это может быть преобразовано в JS шаблоны в считанные секунды. Мы всегда поддерживаем шаблоны на стороне сервера и просто возвращаемся к js по запросу.

1
ответ дан xatzistnr 8 June 2012 в 01:32
поделиться

Я выбрал гибридный подход, в котором мы используем Sinatra в качестве основы, ActiveRecord / Postgress и т. Д. Для обслуживания маршрутов страниц (тонкие шаблоны), чтобы предоставить REST API, который веб-приложение может использовать. На ранних этапах разработки такие вещи, как заполнение опций выбора, выполняются посредством рендеринга помощников в тонкий шаблон, но по мере приближения к производству это заменяется вызовом AJAX REST API, поскольку мы начинаем больше заботиться о скорости загрузки страниц и так далее.

Вещи, которые легко визуализировать в Slim, обрабатываются таким образом, а вещи (заполнение форм, получение данных POST формы из jQuery. Validation submitHandler и т. Д., Все явно AJAX)

Тестирование - это проблема , Сейчас я в тупике , пытаясь передать данные JSON в тест Rack :: Test POST .

0
ответ дан Community 8 June 2012 в 01:32
поделиться

Мы выбрали № 2 при создании колеи. Я работал над API (ruby, sinatra и т. Д.), А мой деловой партнер, Стив Смит, работал над интерфейсом (клиент javascript).

Плюсы:

  1. Быстро двигаться параллельно. Если бы я работал раньше Стива, я мог бы продолжать создавать API для новых функций. Если бы он работал впереди меня, он мог бы очень легко подделать API и создать пользовательский интерфейс.

  2. API бесплатно. Наличие открытого доступа к данным в вашем приложении быстро становится стандартной функцией. Если вы начнете с API с нуля, вы получите это бесплатно.

  3. Чистое разделение. Лучше думать о вашем приложении как о API для клиентов. Конечно, первым и самым важным клиентом может быть веб-клиент, но он настраивает вас на простоту создания других клиентов (iPhone, Android).

Минусы:

  1. Обратная совместимость. Это больше относится к API, чем к вашему прямому вопросу, но как только ваш API появится, вы не сможете просто сломать его или сломать всех своих клиентов на двоих. Это не означает, что вам нужно двигаться медленнее, но это означает, что вам часто приходится заставлять две вещи работать одновременно. Добавление в API или новые поля - это хорошо, но изменение / удаление не должно выполняться без контроля версий.

Я не могу больше думать о минусах прямо сейчас.

Вывод: клиент API + JS - это то, что нужно, если вы планируете выпустить API.

P.S. Я также рекомендовал бы полностью документировать ваш API перед его выпуском. Процесс документирования API Gaug.es действительно помог нам чертить

http://get.gaug.es/documentation/api/

28
ответ дан John Nunemaker 8 June 2012 в 01:32
поделиться

Здесь уже есть несколько хороших ответов - я определенно рекомендую № 2 или № 3 - разделение хорошо как в концептуальном плане, так и на практике.

Может быть трудно предсказать такие вещи, как загрузка и шаблоны трафика для API, и клиенты, которых мы видим, кто обслуживает API независимо, имеют более легкое время предоставления и масштабирования. Если вам нужно сделать это в сочетании с шаблонами доступа в Интернет, это будет не так просто. Кроме того, использование вашего API может в конечном итоге расширяться намного быстрее, чем ваш веб-клиент, и тогда вы сможете увидеть, куда направить свои усилия.

Между № 2 и 3 это действительно зависит от ваших целей - я согласен, что № 2, вероятно, будущее веб-приложений - но, возможно, вы хотите что-то более прямолинейное, если этот канал станет одним из многих!

1
ответ дан steve 8 June 2012 в 01:32
поделиться

Я предпочитаю идти по маршруту № 2 и № 3. Главным образом потому, что № 1 нарушает разделение проблем и смешивает все виды вещей. В конце концов вы обнаружите необходимость иметь конечную точку API, которая не имеет соответствующей HTML-страницы / и т. Д., И вы получите ручей с смешанными конечными точками HTML и JSON в одной и той же базе кода. Это превращается в ужасный беспорядок, даже если его MVP, вам придется переписать его в конце концов, потому что он настолько грязный, что его даже не стоит спасать.

Использование # 2 или # 3 позволяет вам полностью иметь API, который действует одинаково (по большей части) независимо. Это обеспечивает большую гибкость. Я еще не продан на 100% на Backbone / ember / whats / etc.js. Я думаю, это здорово, но, как мы видим в твиттере, это не оптимально. НО ... Твиттер также является огромным зверем компании и имеет сотни миллионов пользователей. Таким образом, любое улучшение может иметь огромное влияние на практический результат в различных областях различных бизнес-единиц. Я думаю, что в этом есть нечто большее, чем просто скорость, и нас это не пускает. Но это только мое мнение. Однако я не сбрасываю со счетов магистраль и его конкурентов. Эти приложения удобны в использовании, очень чисты и очень отзывчивы (по большей части).

Третий вариант также имеет определенную привлекательность. Здесь я следую принципу Парето (правило 80/20) и получаю 20% вашей основной разметки (или наоборот) на сервере, а затем выполняю хороший клиент JS (магистраль / и т. Д.) Для запуска остальной части. , Возможно, вы не на 100% обмениваетесь данными с API REST через JS-клиент, но при необходимости вы будете выполнять некоторую работу, чтобы улучшить работу с suer.

Я думаю, что это одна из тех «это зависит» от вида проблем, и ответ «это зависит» от того, что вы делаете, кому вы служите и какой опыт вы хотите, чтобы они получили , Учитывая, что я думаю, вы можете выбрать между 2 или 3 или гибрид из них.

10
ответ дан Donn Felker 8 June 2012 в 01:32
поделиться

Мне нравится №3, когда мой сайт не будет 100% CRUD-реализацией моих данных. Что еще должно произойти.

Я предпочитаю sinatra и просто разделю приложение на несколько разных стоечных приложений с разными целями. Я сделаю специальное приложение для стойки, которое охватит все, что мне нужно для API. Тогда, возможно, приложение пользовательской стойки, которое представит мою веб-страницу. Иногда эта версия будет запрашивать API при необходимости, но обычно это касается только html-сайта.

Я не беспокоюсь об этом и просто делаю запрос уровня персистентности со стороны пользователя, если мне это нужно. Я не слишком озабочен созданием полного разделения, поскольку они обычно служат различным целям.

Вот очень простой пример использования нескольких стоечных приложений. Я добавил быстрый пример jquery, чтобы вы увидели, что он работает с приложением API. Вы можете увидеть, насколько просто это может быть с sinatra и монтированием нескольких стоечных приложений для разных целей.

https://github.com/dusty/multi-rack-app-app

4
ответ дан Dusty 8 June 2012 в 01:32
поделиться

У меня около 2 месяцев в 3-месячном проекте, который использует второй подход, который вы изложили здесь. Мы используем серверную часть RESTful API с backbone.js на передней панели. Handlebars.js управляет шаблонами, а jQuery обрабатывает манипуляции с AJAX и DOM. Для более старых браузеров и поисковых пауков мы остановились на рендеринге на стороне сервера, но мы используем те же шаблоны HTML, что и интерфейс Handlebars, используя Mozilla Rhino.

Мы выбрали этот подход по многим различным причинам, но очень хорошо знаем, что это немного рискованно, учитывая, что это еще не было доказано в широком масштабе. Все то же самое, пока все идет довольно гладко.

Пока что мы только что работали с одним API, но на следующем этапе проекта мы будем работать со вторым API. Первый предназначен для больших объемов данных, а второй действует больше как CMS через API.

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

Боюсь, я не Ruby, поэтому не могу комментировать другие подходы. Иногда можно рисковать. В других случаях лучше не рисковать. Вы будете в зависимости от типа проекта.

Желаем удачи с вашим выбором здесь. Желая увидеть, что разделяют и другие.

6
ответ дан Iarfhlaith Kelly 8 June 2012 в 01:32
поделиться

Обычно я выбираю второй вариант, использующий Rails для создания API, и основу для JS. Вы даже можете получить панель администратора бесплатно, используя ActiveAdmin . Я поставил десятки мобильных приложений с таким бэкэндом. Однако это сильно зависит от того, является ли ваше приложение интерактивным или нет.

Я сделал презентацию об этом подходе на последнем RubyDay.it : http://www.slideshare.net/matteocollina/enter-the-app-era-with -ruby-on-rails-rubyday

Для третьего варианта, чтобы получить отзывчивость второго, вы можете попробовать pajax , как это делает Github.

7
ответ дан Matteo Collina 8 June 2012 в 01:32
поделиться

В настоящее время я работаю над преобразованием огромной CMS из варианта 1 в вариант 3, и все идет хорошо. Мы выбрали визуализацию на стороне сервера, потому что SEO очень важен для нас, и мы хотим, чтобы сайты работали на мобильных телефонах.

Я использую node.js для серверной части клиента и несколько модулей, чтобы помочь мне. Я немного рано в этом процессе, но основа заложена, и это вопрос просмотра данных, чтобы все было правильно. Вот что я использую:

  • Экспресс для основы приложения.
    (https://github.com/visionmedia/express)
  • Запрос на получение данных.
    (https://github.com/mikeal/request)
  • Подчеркнуть шаблоны, которые обрабатываются на стороне сервера. Я повторно использую их на клиенте.
    (https://github.com/documentcloud/underscore)
  • UTML оборачивает шаблоны подчеркивания, чтобы они работали с Express.
    (https://github.com/mikefrey/utml)
  • Upfront собирает шаблоны и позволяет выбирать, какие из них отправляются клиенту.
    (https://github.com/mrDarcyMurphy/upfront)
  • Express Expose передает извлеченные данные, некоторые модули и шаблоны во внешний интерфейс.
    (https://github.com/visionmedia/express-expose)
  • Backbone создает модели и представления на внешнем интерфейсе после проглатывания данных, которые были переданы.
    (https://github.com/documentcloud/backbone)

Это ядро ​​стека. Некоторые другие модули, которые я нашел полезными:

  • fleck (https // github.com / trek / fleck)
  • moment (https // github.com / timrwood / moment)
  • стилус (https // github.com / LearnBoost / stylus)
  • smoosh (https // github.com / fat / smoosh)
    … хотя я ищу в grunt (https // github.com / cowboy / grunt)
  • трассировка консоли (//github.com/LearnBoost/console-trace).

Нет, я не использую coffeescript.

Этот вариант работает очень хорошо для меня. Модели на внутреннем сервере не существуют, потому что данные, которые мы получаем от API, хорошо структурированы, и я передаю их дословно внешнему интерфейсу. Единственное исключение - наша модель макета, где я добавляю один атрибут, который делает рендеринг умнее и легче. Я не использовал для этого никакой библиотеки модных моделей, просто функцию, которая добавляет то, что мне нужно при инициализации, и возвращает себя.

(извините за странные ссылки, я слишком много n00b для переполнения стека, чтобы позволить мне публиковать так много)

7
ответ дан Darcy Murphy 8 June 2012 в 01:32
поделиться

REST-сервер + тяжелый JavaScript-клиент был принципом, которому я следовал в своей недавней работе.

REST-сервер был реализован в node.js + Express + MongoDB (очень хорошая производительность записи) + Mongoose ODM (отлично для моделирования данных, включая проверки) + CoffeeScript (я бы сейчас использовал ES2015 вместо этого), который хорошо сработал для меня. Node.js может быть относительно молодым по сравнению с другими возможными серверными технологиями, но это позволило мне написать надежный API с интегрированными платежами.

Я использовал Ember.js в качестве среды JavaScript, и большая часть логики приложения была выполнена в браузере. Я использовал SASS (в частности, SCSS) для предварительной обработки CSS.

Ember - зрелая структура, поддерживаемая сильным сообществом. Это очень мощный фреймворк, в котором в последнее время проводится много работы, ориентированной на производительность, например, новый движок рендеринга Glimmer (по мотивам React).

Ember Core Team находится в процессе разработки FastBoot , который позволит вам выполнить вашу логику Ember JavaScript на стороне сервера (в частности, node.js) и отправлять предварительно отрендеренный HTML-код вашего приложения (что будет обычно запускается в браузере) пользователю. Это здорово для SEO и пользовательского опыта, так как он не ждет так долго, пока страница не появится.

Ember CLI - это отличный инструмент, который помогает вам организовать ваш код, и он хорошо масштабировался с ростом кодовой базы. Ember также имеет свою собственную аддонную экосистему, и вы можете выбирать из множества Ember Addons . Вы можете легко взять Bootstrap (в моем случае) или Foundation и добавить его в свое приложение.

Чтобы не обслуживать все через Express, я решил использовать nginx для обслуживания изображений и клиент с большим количеством JavaScript. Использование прокси-сервера nginx было полезно в моем случае:

upstream app_appName.com {
  # replace 0.0.0.0 with your IP address and 1000 with your port of node HTTP server
  server 0.0.0.0:1000;
  keepalive 8;
}

server {
  listen 80 default_server;
  listen [::]:80 default_server ipv6only=on;

  client_max_body_size 32M;

  access_log  /var/log/nginx/appName.access.log;
  error_log  /var/log/nginx/appName.error.log;

  server_name appName.com appName;

  location / {
     # frontend assets path
     root /var/www/html;
     index index.html;

     # to handle Ember routing
     try_files $uri $uri/ /index.html?/$request_uri;
  }

  location /i/ {
    alias /var/i/img/;
  }

  location /api/v1/ {
    proxy_pass  http://app_appName.com;

    proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
    proxy_redirect off;
    proxy_buffering off;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Pro: Мне нравится разделение API & amp; клиент. Умные люди говорят, что это путь. Великолепно в теории. Кажется передовым и захватывающим.

Я могу сказать, что это также здорово на практике. Еще одним преимуществом разделения REST API является то, что вы можете использовать его позже для других приложений. В идеальном мире вы должны иметь возможность использовать один и тот же API REST не только для веб-страниц, но и для мобильных приложений, если решите написать его.

Против: не так много прецедентов. Не много примеров этого сделано хорошо. Публичные примеры (twitter.com) чувствуют себя вялыми даже отказываются от этого подхода.

Теперь все выглядит иначе. Есть много примеров использования REST API + много клиентов, использующих его.

1
ответ дан Daniel Kmak 8 June 2012 в 01:32
поделиться

Мы используем следующий вариант # 3: Создаем только JSON-сервер REST API. Сделать сервер веб-сайта HTML. Веб-сервер HTML, как и в вашем варианте, не является клиентом сервера API REST. Вместо этого оба сверстники. Недалеко от поверхности находится внутренний API, который обеспечивает функциональность, необходимую двум серверам.

Мы не знаем ни о каком прецеденте, так что это своего рода эксперимент. Пока (собирается войти в бета-версию), это сработало довольно хорошо.

7
ответ дан Thomas Becker 8 June 2012 в 01:32
поделиться

Изоморфный рендеринг и прогрессивное улучшение. К чему, я думаю, вы клонировали в третьем варианте.

изоморфный рендеринг означает использование того же шаблона для генерации разметки на стороне сервера, который используется в коде на стороне клиента. Выберите шаблонный язык с хорошими реализациями на стороне сервера и на стороне клиента. Создайте полностью запеченный HTML для своих пользователей и отправьте его по проводам. Используйте кеширование тоже.

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

Да, конечно, напишите автономный JSON API для функциональности этого приложения. Но не заходите так далеко, что вы пишете JSON API для вещей, которые отлично работают как статические HTML-документы.

1
ответ дан sirtimbly 8 June 2012 в 01:32
поделиться
1131 Очень хорошо спросили. +1. Конечно, это будущие полезные ссылки для меня. Также @Aaron и другие добавили ценность для обсуждения. Как и Ruby, этот вопрос в равной степени применим к другим средам программирования.

Я использовал первые два варианта. Первый для многочисленных приложений и второй для моего проекта с открытым исходным кодом Cowoop

Вариант 1

Этот, без сомнения, самый популярный. Но я считаю, что реализация очень много http-иш. Каждый исходный код API относится к объекту запроса. Таким образом, код API - это больше, чем просто код ruby ​​/ python / другого языка.

Вариант 2

Я всегда любил это.

Эта опция также подразумевает, что HTML не генерируется во время выполнения на сервере. Это отличает вариант 2 от варианта 3. Но он создается как статический html с использованием сценария сборки. При загрузке на стороне клиента эти HTML будут вызывать сервер API как клиент JS API.

  • Разделение интересов является большим преимуществом. И очень по вашему вкусу (и моему) бэкэнд-эксперты внедряют бэкэнд-API, тестируют их легко, как обычный языковой код, не беспокоясь о коде запроса framework / http.

  • Это действительно не так сложно, как звучит на внешней стороне. Вызовы API и полученные данные (в основном, json) доступны для вашего клиентского шаблона или MVC.

  • Меньше обработки на стороне сервера. Это означает, что вы можете перейти на обычное оборудование / менее дорогой сервер.

  • Легче тестировать слои независимо, проще создавать документы API.

У него есть некоторые недостатки.

  • Многим разработчикам это сложно и сложно понять. Таким образом, есть вероятность, что архитектура может подвергнуться критике.

  • i18n / l10n сложно. Поскольку HTML по сути генерируется, время сборки статично, для каждого поддерживаемого языка требуется несколько сборок (что не обязательно плохо). Но даже при этом вы можете иметь угловые случаи около l10n / i18n и вам нужно быть осторожным.

Вариант 3

В этом случае внутреннее кодирование должно совпадать со вторым вариантом. Большинство пунктов для варианта 2 применимы и здесь.

Веб-страницы отображаются во время выполнения с использованием шаблонов на стороне сервера. Это значительно облегчает работу с более устоявшимися / принятыми методами. Может быть на один HTTP-вызов меньше для некоторого существенного контекста, необходимого для рендеринга страницы, такого как пользователь, язык, валюта и т. Д. Таким образом, обработка на стороне сервера увеличивается при рендеринге, но, возможно, компенсируется меньшим количеством http-вызовов к API-серверу.

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

Случай с Твиттером

Как я понимаю, Twitter может выполнять свою первоначальную визуализацию страниц на сервере, но для обновления страниц он все еще имеет некоторые вызовы API и шаблоны на стороне клиента для манипулирования DOM. Таким образом, в таком случае у вас есть двойные шаблоны для обслуживания, что добавляет некоторые накладные расходы и сложность. Не каждый может позволить себе этот вариант, в отличие от Twitter.

Наш проект Stack

Я использую Python. Я использую JsonRPC 2.0 вместо REST. Я предлагаю REST, хотя мне нравится идея JsonRPC по разным причинам. Я использую ниже библиотеки. Кто-то, рассматривающий вариант 2/3, может найти его полезным.

  • API-сервер: Python Быстрый веб-микро-фреймворк - Flask
  • Фронт-сервер: Nginx
  • Клиентский MVC: Knockout.js
  • Другие соответствующие инструменты / библиотеки:

Мой вывод и рекомендация

Вариант 3!.

В общем, я успешно использовал вариант 2, но теперь для простоты склоняюсь к варианту 3. Генерация статических HTML-страниц с помощью скрипта сборки и их обслуживание на одном из сверхбыстрых серверов, специализирующихся на обслуживании статических страниц, очень заманчиво (вариант 2).

47
ответ дан Kazelin 8 June 2012 в 01:32
поделиться
Другие вопросы по тегам:

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