2015-10-27 4 views
8

Что я хотел бы знать, как вы создали свое веб-приложение? Я действительно смущаюсь, какой метод следует использовать для моего проекта.Какой способ быстрее, экспресс: рендеринг на стороне сервера и рендеринг на стороне клиента

Уже решили, какие технологии выбрать.

1) Node.js и выражают в качестве своей основы

2) MongoDB

3) React + Флюс

Но проблема сейчас, следует использовать метод (А) или метод (Б)

метод (А) - Serverside рендеринга для HTML

app.get('/users/', function(request, respond) { 
    var user = "Jack"; 
    respond.render("user", { user: user }); 
}); 

Метод (Б) - рендеринг для клиентского HTML

app.get('/users/', function(request, respond){ 
     var user = "Jack"; 
     respond.json({ user: user }); 
    }); 

Метод А будет оказывать HTML с сервера и, а также данные.

Метод B будет просто отвечать на данные, которые необходимы клиенту, который является React.js, чтобы он мог манипулировать данными.

Моя забота, какой метод я должен использовать? Большинство стартапов используют какой метод?

спасибо.

+0

Если вы собираетесь создавать приложение с использованием React, вы должны следовать шаблону Flux. –

+0

Woops, не читал Express над заголовком.Не слишком знакомы с Экспрессом, поэтому могут быть разные. –

+0

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

ответ

5

Это не одно или тоже предложение.

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

Ответ? Если сможешь, ДА!

Вы получите преимущества SEO и начальное повышение производительности путем рендеринга на стороне сервера. Но вам все равно придется делать один и тот же рендеринг на стороне клиента.

Я предлагаю googling «изоморфно реагировать» и делать некоторые чтения. Вот одна статья по этому вопросу. http://www.smashingmagazine.com/2015/04/react-to-the-future-with-isomorphic-apps/

+0

Это правильный ответ. –

+0

отметить: «Изоморфный ответ» в отношении рендеринга на стороне севера. Реакция теперь называется «Universal React». – Sgnl

4

Ну, это действительно зависит от того, какое видение у вас есть на современной сети, и что вы готовы делать.

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

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

Вы можете увидеть этот пост с Twitter блог говорят, что они улучшают свою первоначальную загрузку страницы на 1/5, что они были раньше, перемещая рендеринг на сервер:

https://blog.twitter.com/2012/improving-performance-on-twittercom

Другой статью, на этот раз от Airbnb, описывая проблемы вы можете иметь с клиентской стороны рендеринга себя:

http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/

Существует также другая интересная статья идет о стороне клиента/На стороне сервера визуализации, в результате чего дебаты о том, когда мы должны использовать/не использовать на стороне сервера или на стороне клиента визуализации и почему:

https://ponyfoo.com/articles/stop-breaking-the-web

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

https://www.terlici.com/2015/03/18/fast-react-loading-server-rendering.html

http://reactjsnews.com/isomorphic-javascript-with-react-node/

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

Эта концепция называется «изоморфным javascript», и в наши дни она становится все более популярной.

+0

Возможный контраргумент для дела, который вы делаете: [Оставляя JSP в пыль: перемещение LinkedIn в шаблоны клиентской стороны dust.js] (https://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates). Ваша производительность также может зависеть от того, как вы реализуете шаблоны на стороне клиента. – jfriend00

+0

Да, я думаю, что, судя по многим другим способам, вы можете фактически реализовать рендеринг на стороне клиента или «изоморфные» приложения. – schankam

+0

Я прочитал большинство ссылок, которыми вы поделились, и это действительно открывает мне представление об обоих, но, поскольку рендеринг на стороне сервера выполняется быстро, мне нужно дублировать мои коды для API, если я хочу перейти на мобильный? –

2

Простейшая архитектура заключается в том, чтобы просто выполнять динамический рендеринг html на сервере без Ajax и с новой HTML-страницей, запрошенной практически для любого клика. Это «традиционный» подход, и есть плюсы и минусы.

Следующим простейшим является предоставление полностью статического html + js + css (ваше приложение React) для клиента и обращение к веб-службам XMLHttpRequest для получения требуемых данных (т. Е. Вашего метода B).

Самый сложный, но идеальный подход (с точки зрения производительности и SEO) заключается в создании «изоморфного» приложения, которое поддерживает оба подхода. Идея состоит в том, что сервер делает все необходимые WS-вызовы, которые клиент делает и отображает начальную страницу, которую посетил пользователь (что может быть глубоко связанной частью приложения), немного похожее на вариант A, но с использованием React to выполнить рендеринг, а затем передать управление клиенту для будущих обновлений DOM. Затем это позволяет быстро увеличивать обновления страницы через вызовы веб-сервиса, когда пользователь взаимодействует (например, как B). Навигация между разными страницами на данном этапе предполагает использование API истории, чтобы он выглядел так, будто вы меняете страницу, когда на самом деле вы просто управляете текущей страницей с помощью веб-сервисов. Но вы, а затем обновили браузер, ваш сервер отправит обратно полный HTML текущей страницы, прежде чем передавать управление на клиентскую сторону React снова. Есть много примеров React + Flux + Node этого подхода, доступных в Интернете, с использованием различных вкусов Flux, которые поддерживают рендеринг на стороне сервера.

Независимо от того, стоит ли этот подход, зависит от вашей ситуации. Вероятно, имеет смысл начать использовать подход B (вы можете поделиться своим HTTP API между мобильными приложениями и веб-сайтами), но используйте архитектуру Flux, которая поддерживает рендеринг на стороне сервера и помнит об этом. Таким образом, если вам нужно улучшить производительность загрузки начальной страницы, у вас есть средства для этого.

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