Включение Node.js в ваше решение для Microsoft Azure

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

Именно это я и собираюсь продемонстрировать в данной статье. Я возьму существующее решение, которое позволяет просматривать документы в хранилище, но требует сигнатуры общего доступа (shared access signature) для их скачивания. В это решение я добавлю простой UI, использующий Node.js. Чтобы упростить эту реализацию, я задействую преимущества некоторых часто применяемых для Node.js инфраструктур. Таким образом, решение будет включать:

• Node.js — базовый механизм;
• Express — инфраструктура в стиле Model-View-Controller (MVC);
• Jade — механизм рендеринга и поддержки шаблонов.

Совместно эти три средства предоставят богатую инфраструктуру для построения UI, во многом аналогичную комбинации ASP.NET MVC 3 и Razor.

Приступаем

Если вы новичок в Node.js, вам лучше начать с изучения материалов, доступных на сайте Microsoft по ссылке windowsazure.com/develop/nodejs. Вам также потребуется установить Node.js SDK for Microsoft Azure. Кроме того, вы, вероятно, понадобится потратить немного времени на эксперименты с Express expressjs.com и Jade jade-lang.com. Вы обнаружите в этих инструментах некоторые привычные концепции, а также смесь знакомого и незнакомого синтаксиса.

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

В существующем решении, как представлено, целью было выдавать пользователю доступ, только если он аутентифицирован, что приводит к генерации Shared Access Signature (SAS). Идея заключалась в том, чтобы предоставлять доступ для чтения аутентифицированным пользователям, а впоследствии выдавать полный CRUD-доступ (Create, Read, Update, Delete) к конкретному документу на основе ролей и уровня членства в группах. Здесь я сосредоточусь исключительно на разрешениях для чтения.

Последовательность запросов

Создание сервисов

Я имитирую сервис аутентификации, возвращающий некий идентификатор. Последующий вызов сервиса возвращает список файлов. Используемый мной контейнер Microsoft Azure Storage («documents») имеет ограниченные разрешения открытого доступа. Я хочу предоставлять список документов, даже если пользователь не аутентифицирован, но запретить неаутентифицированным пользователям возможность открытия файлов. Две сигнатуры вызова для созданного мной API выглядят так:

http://[host]/admin/GetAccess?user=[user]&pwd=[password]

http://[host]/admin/files?accessId=[authId]

Конечно, вам понадобится более реалистичный сервис аутентификации, который использует SSL и не оперирует строкой запроса; эту часть решения я не буду здесь описывать.

Первым делом надо написать метод для получения SAS — он понадобится при создании метода, формирующего список документов.

    public string GetSharedAccessSignature()
    {
      string sas = "";
      sas = (string) System.Web.HttpContext.Current.Cache.
        Get("sas");
     
      // Если SAS нет, создаем его
      if (sas == null)
      {
        // TODO: контейнер "зашит" в код,
        // переместить в конфигурацию
        CloudBlobContainer container =
          blobClient.GetContainerReference("documents");
     
        // Запрашиваем у контейнера передачу SAS
        // в только что инициализированной политике
        sas = container.GetSharedAccessSignature(
          new SharedAccessPolicy()
        {
          SharedAccessStartTime = DateTime.Now,
          SharedAccessExpiryTime =
            DateTime.Now.AddMinutes(MaxMinutes),
          Permissions = SharedAccessPermissions.Read |
            SharedAccessPermissions.List
        });
     
        // Добавляем в кеш для повторного использования,
        // поскольку это SAS, который не является индивидуальным
        // для каждого пользователя
        System.Web.HttpContext.Current.Cache.Add("sas", sas, null,
          DateTime.Now.AddMinutes(MaxMinutes),
          new TimeSpan(0,0,5,0,0), CacheItemPriority.High, null);
      }
      return sas
    }

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

При наличии REST-сервиса я могу запустить быстрый тест через окно браузера. После такой настройки интерфейса сервиса можно достаточно легко имитировать аутентификацию, используя какое-нибудь общеизвестное значение, пока не будет написан цикл for, генерирующий список и пока SAS не начнет должным образом работать. VerifyId(string) просто проверяет, есть ли у меня удостоверение, кешированное с ключом, значение которого равно accessId. Ниже показан список, возвращаемый без аутентификации. А поскольку он возвращается сервисом без аутентификации, значение SAS установлено в nil. Таким образом, использовать данные для визуализации списка можно, но предоставить рабочую ссылку пользователю нельзя, так как SAS нет.

На рис. 5 показан аутентифицированный список, который включает SAS.

Разбор того, что именно возвращает сервис при аутентифицированном вызове, возлагается на клиент Node.js; кроме того, он должен визуализировать гиперссылки с SAS, который записывается в конец URI. Чтобы упростить эту задачу, я предоставил элемент CombinedUri, и клиенту нужно будет обращаться только к этому элементу. Наконец, хотя XML — хорошая штука, я все же работаю в Node.js, а потому имеет смысл изменить атрибуты интерфейса так, чтобы он возвращал JSON. Благодаря этому ответ сервиса можно будет напрямую использовать как объект:

    [WebGet(UriTemplate = "Files?accessId={accessId}",
      ResponseFormat=WebMessageFormat.Json)]

Вот как примерно выглядит JSON-вывод:

    [{"CombinedUri":"https://footlocker.blob.core.windows.net
    /documents/AzureKitchen-onesheet.docx?st=2012-03-05T05%3A22%
    3A22Z&se=2012-03-05T05%3A27%3A22Z&sr=c&sp=rl&sig=Fh41ZuV2y2z
    5ZPHi9OIyGMfFK%2F4zudLU0x5bg25iJas%3D","Name":"/documents/
    AzureKitchen-onesheet.docx","Sas":"?st=2012-03-05T05%3A22%
    3A22Z&se=2012-03-05T05%3A27%3A22Z&sr=c&sp=rl&sig=Fh41ZuV2y2z
    5ZPHi9OIyGMfFK%2F4zudLU0x5bg25iJas%3D","Uri":"https://
    footlocker.blob.core.windows.net/documents/AzureKitchen-
    onesheet.docx"}]

Как отмечалось, в конечном счете здесь нам нужен JSON, так как его можно прямо использовать в Express и Jade.

Node.js UI

Я уже установил Node.js, Express и Jade, так что я готов к созданию UI. Я развернул роли Node.js и запустил их в Visual Studio, но это довольно кропотливый и полностью ручной процесс. Поскольку никаких средств интеграции для этой части Node.js нет, я буду выполнять редактирование с помощью Sublime Text 2, а отладку — через Chrome (как описано в блоге Томаша Янчука [Tomasz Janczuk] по ссылке bit.ly/uvufEM).

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

• Restler — облегчает REST-вызовы (считайте его упрощенным WebClient);
• Express — универсальная прикладная инфраструктура в стиле MVC;
• Jade — механизм рендеринга шаблонов, аналогичный Razor, который применяется в ASP.NET MVC.

Все эти модули являются компонентами Node.js (как DLL в .NET) и обычно устанавливаются с GitHub через Node Package Manager (NPM). Например, чтобы установить Restler, введите в папке проекта команду «npm install restler». Эта команда установит модуль и добавит ссылку на него в проект.

И еще одно для непосвященных. Вы увидите массу анонимных функций, вложенных в другие функции. Мой совет — просто переформатируйте код так, чтобы можно было видеть вложение в процессе работы с этим кодом, пока вы не привыкнете разбираться в нем без переформатирования. Я старался сделать свои примеры максимально удобными для чтения, а также использовать экранные снимки из Sublime, код на которых выделяется разными цветами (это тоже помогает восприятию кода).

При создании приложения AzureNodeExpress я применял команды New-AzureService и New-AzureWeb¬Role. Я также внес несколько других изменений. В server.js я добавил маршруты к странице Index; аналог в ASP.NET — метод MapRoutes, применяемый в проектах MVC.

Изменения в server.js

Мне нужно сообщить Node.js, какими библиотеками я буду пользоваться; это делается во многом по аналогии с выражениями using в C#. В Node.js такие ссылки задаются присваиванием переменной значения, возвращаемого функцией require(‘[имя_библиотеки]’). После задания ссылок я настраиваю некоторые конфигурационные переменные (например, устанавливаю view engine в «jade»). Особый интерес представляют view engine, router, bodyParser, cookieParser и session.

Я опускаю некоторые более прозаичные элементы, но настроить маршруты необходимо. Для команды Get в своей странице Index я буду просто визуализировать представление:

    app.get('/index',
      function(req, res){
        res.render('index.jade', {title: 'index'});
      }
    );

Но в случае команды Post я хочу передавать обработку модели индекса (index model). Для этого нужно «связать» определенный метод модели:

app.post('/index', index.GetAccessKey.bind(index));

После этого можно переходить к настройке как представления, так и модели.

Представление: index.jade

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

    html
    head
      title Default
    body
      h1 File List Home Page
      br
      label Welcome #{username}
     
      form(method='post', action='/index')
        label Username:
          input(name='username', type='text')
        br
        label Password:
          input(name='password', type='password')
        br
        button(type='submit') Login
      h2 Files 
      form
        table(border="1")
          tr
            td Name
            td Uri
            each doc in docList
              tr
                td #{doc.Name}
                td
                  a(href=#{doc.CombinedUri}) #{doc.Name}

Заметьте, что здесь используются #{[var]} для ссылок на переменные и шаблон table с циклом внутри, который является своего рода сокращенной формой foreach. Я произвольно назвал список перебираемых элементов docList. Это важно, так как на странице index.js, где я прошу Jade визуализировать это представление, мне потребуется передать значение для docList. Остальное понятно и без пояснений, поскольку я создаю UI для разработчика — очень простой и безо всяких украшений.

Модель: index.js

Настроив инфраструктуру исполняющей среды в server.js и шаблон конечного представления в index.jade, остается написать прикладной код, выполняемый в index.js. Вспомните, что я связал app.Post со страницей Index. Эта привязка будет загружаться и запускать прототип, созданный мной в index.js. Для этого я добавлю функции в прототип индекса, как показано далее. По сути, я создаю именованную функцию (например, GetAccessKey) и определяю анонимную функцию как ее тело. В каждой из этих функций я буду использовать модуль Restler для упрощения необходимых мне REST-вызовов.
После связывания Post первой вызывается GetAccessKey, которая просто принимает имя пользователя и пароль, переданные через форму, дописывает их в URI как часть querystring и с помощью Restler выполняет Get. Вспомните, что в Node.js все взаимодействия происходят асинхронно, и это одна из причин обилия вложенных анонимных функций. Храня верность этому шаблону в вызове rest.get, я определяю анонимную функцию, выполняемую по завершении обработки запроса. Без кода обработки ошибок все сводится к следующему:

    rest.get (uri).on('complete',
      function(result){
        accesskey = result;
    this.ShowDocs (req, res);}
      )

К счастью, такое переформатирование помогает понять, что здесь делается. Как только я получаю ключ от своего сервиса, я добавляю его в конец URI в этом методе, чтобы получить список документов. А теперь порядок вещей начинает отличаться от обычного. В анонимной функции, обрабатывающей данные, которые возвращаются REST-вызовом, для получения списка документов, я запрашиваю Jade визуализировать результаты:

    res.render ('index', {title: "Doc List",
      layout: false,
      docList: result,
      username: req.BODY.username});

Ранее я отметил, что в шаблоне я создал переменную с именем docList. Теперь мне нужно убедиться, что я использую именно это имя. Вызов res.render сообщает инфраструктуре Express визуализировать ресурс «index», а затем передать параметры через список пар «имя: значение», разделяемых двоеточиями и запятыми.

Исполняющая среда

Если попытаться перейти к одному из файлов, чтобы скачать его, на странице ничего не появляется. Эта веб-страница не найдена. Возможно, вы ожидали, что Microsoft Azure Storage сообщит об ошибке, связанной с неавторизованным доступом, но, если вы пытаетесь обратиться к какому-либо закрытому ресурсу, возвращается ошибка «ресурс не существует». Так и задумано, и это поведение предпочтительно, потому что частный ресурс не должен существовать в общедоступном пространстве. Если бы вместо этого возвращалась ошибка 401, она указывала бы на то, что такой ресурс на самом деле есть, и таким образом раскрывала бы сам факт его наличия.

Поскольку я защищаю свое хранилище, прямой доступ запрещен. Однако, как только я запускаю код примера, ситуация несколько меняется. Я публикую приложение командой Publish-AzureService из Windows PowerShell, перехожу к странице и ввожу свои удостоверения; после этого мне предоставляется список ссылок на файлы.

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

Заключение

Если вас интересуют новые технологии для развития вашего приложения Microsoft Azure и вы следите за тем, что делается в сфере, связанной с Node.js, то Microsoft Azure — именно то, что вам нужно: она не только обеспечивает хостинг вашего решения, но и предоставляет вам при разработке различные варианты, например клиентскую библиотеку для Node.js, прямой или опосредованный (показанный в этой статье) доступ к REST API. Разработка, безусловно, была бы гораздо эффективнее и проще, если бы Node.js был обеспечен должной инструментальной поддержкой, но я уверен, что в конечном счете мы увидим ту или иную форму интеграции с Visual Studio, если популярность Node.js будет по-прежнему расти.

Автор: alexandfox

Источник