Почему различие в производительности между C# (вполне немного медленнее) и Win32/C?

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 + много клиентов, использующих его.