🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕🦕

Отказ от ответственности

Начнем с того, что фреймворк, который я сейчас использую OAK / Snowlight, предназначен для написания RESTful API, который в настоящее время является стабильной версией Deno 1.0.0.

Среди разработчиков есть несколько предположений и гипотез, которые гласят:

Собирается ли Deno заменить Node?

Deno лучше, чем Node?

Неужели все усилия, время и энергия, вложенные в изучение Node, совершенно бессмысленны?

Как заявил Райан Даль в своем выступлении на JSConf 10 вещей, о которых я сожалею о Node.js

«Узел мог бы быть намного лучше»

Когда Райан начал работу с Node; он упустил очень важные аспекты, которые он вспомнил в своей речи в 10 вещах, о которых я сожалею о Node.js.

Подводя итог этим недостаткам дизайна в Node.js, о которых упоминал Райан, можно сказать следующее:

  1. Безопасность. У узла нет защиты. Поскольку вы используете пакеты NPM и не знаете полностью, что в этом коде; возможно, в этих кодах могут быть необнаруженные лазейки или серьезные уязвимости, облегчающие сетевые атаки или взломы. Легкий доступ к компьютеру был очень открытым.

    Deno преодолела эту проблему безопасности, поместив среду Deno в песочницу по умолчанию, где каждая операция вне контекста выполнения была явно разрешена пользователем.
  2. Импорт URL-адресов:. Одним из основных изменений было требование модулей из папки node_modules, где Node.js использовал синтаксис, опуская расширения. в файлах, вызывала проблемы со стандартами браузера. Чтобы решить эту проблему, они объединили алгоритм разрешения модулей, чтобы найти запрошенный модуль в узле .

    Чтобы преодолеть это, Deno придумал использование import вместо require. У вас не было пакетов локально; вместо этого вы можете заполнить его URL-адресом, с которого вам нужен модуль. Это проливает свет на другой аспект; объяснено в следующем пункте.
  3. Излишняя потребность в node_modules: с Node пакеты NPM содержат слишком много кодовых баз, уязвимости которых точно не были известны. Кроме того, каждый раз, когда вам нужно использовать модуль из node_modules; вам это нужно; который должен был бы снова запустить алгоритм разрешения модуля, который сам по себе довольно сложен.

    В Deno не было необходимости в папке node_modules. Модули импортируются с использованием URL-адресов; которые кэшируются и используются для проекта, который вы выполняете, и доступны во всем мире. Это может заставить вас задуматься; всегда ли для работы требуется подключение к Интернету?
    Ну нет. Когда пакеты изначально импортируются; они загружаются и кешируются, точно так же, как это работает с NPM. Они кэшируются в папке
    В Linux: $XDG_CACHE_HOME/deno или $HOME/.cache/deno
     В Windows: %LOCALAPPDATA%/deno (%LOCALAPPDATA% = FOLDERID_LocalAppData)
    Другой файл с именем .deno_plugins также создается в самом каталоге проекта при первом запуске, когда вы используете для установки определенные пакеты, такие как node_mongo. двоичные файлы ржавчины того же самого.
  4. package.json: с двумя указанными выше основными недостатками; поддержка package.json была ненужной абстракцией. Семантическое управление версиями было одной из основных целей, которым служил package.json.

    Напротив, Deno не поддерживает использование диспетчера пакетов, такого как npm. Следовательно, отпадает необходимость в семантическом управлении версиями, что устраняет необходимость в package.json, как в манифесте.
  5. Обработка асинхронных операций:. В Node первоначальная эволюция обработки асинхронных операций заключалась в использовании шаблона обратных вызовов. Со временем он развивался с использованием Promise API в ранних версиях v8; которые были включены в конце 2009 года и удалены в начале 2010 года. К тому времени произошла вспышка эпидемии, появилось несколько пакетов / библиотек, которые использовали шаблоны обратного вызова для асинхронных операций. Node был разработан задолго до того, как в Javascript появился API обратных вызовов / обещаний.

    В Deno самым фундаментальным или, скажем так, самым низким уровнем привязки Promises API является привязка «ops» для обработки асинхронных Операции.
  6. По умолчанию встроенный компилятор TypeScript: Node поддерживает сценарии JavaScript с файлами .js. Если бы нам пришлось писать TypeScript в Node Environment; нам пришлось настроить Конфигурацию TypeScript для проекта вместе с пакетом TypeScript.

    С Deno эта проблема настройки решена, которая сразу же выдает без первоначальной настройки приложения. Использование ограничено конфигурациями по умолчанию компилятора TypeScript Deno. В любом случае, если вы хотите изменить конфигурацию по умолчанию, вы можете добавить файл tsconfig.json; используя флаг «- -config = tsconfig.json».
    Обычный JS также работает с Deno; в основном даже файлы с расширениями .js.
  7. Наконец, использование await, поддерживаемое v8 - Async верхнего уровня: Node поддерживает шаблон async-await для обработки асинхронной операции после выпуска. из ES5 / ES6. Если вы определяете функцию, которая выполняет некоторую асинхронную операцию, вам придется использовать этот стандартный шаблон async-await.

    У Deno была замечательная функция использования await напрямую, поскольку она была привязана непосредственно к обещания. Проще говоря, вы можете использовать «await» без использования ключевого слова async в программе.

Имея все эти недостатки, и каждый из них обрабатывается в Deno; Дено выглядит многообещающе.

Тем не менее, необходимо увидеть, как эта среда и фреймворки, построенные на Deno, в зависимости от степени их принятия и гибкости, увидят, как Deno меняет отрасль.

В этой статье я буду обсуждать настройку сервера приложений с использованием Oak Framework, подключенного к базе данных MongoDB с использованием собственного драйвера Deno Nano_mongo.

Давайте углубимся в Deno, а затем начнем с создания RESTful API с использованием Deno
[Oak Framework - На основе Koa Framework].

Что это за `Deno`?

  • Простая, современная и безопасная среда выполнения для JavaScript и TypeScript, использующая движок v8, созданный с использованием Rust.
  • Недавно, в мае 2020 года, официально вышла версия 1.0.0 Deno.
  • В основе Deno лежит Rust.
  • Поддерживает TypeScript без явной настройки.
  • Не совместим с модулями узлов и npm

Подробности можно найти в официальном Deno v1.

Теперь начнем с создания простого RESTful API с использованием фреймворка Deno под названием Oak.

В этой статье мы будем создавать Сервер приложений, используя

  • Oak: платформа промежуточного программного обеспечения для HTTP-сервера Deno; вдохновлен Koa Framework.
  • identify_mongo: это драйвер базы данных MongoDB, созданный для платформы Deno. Встроенный драйвер базы данных для MongoDB.

Для начала, перед тем, как начать сборку приложения, это простое приложение для создания сервера приложений, создания пользователя и получения сведений о пользователе.
Ниже представлена ​​структура папок мини-проекта следующим образом.

  • models содержит определение модели, в нашем случае только пользовательский интерфейс.
  • маршрутизаторы содержат маршруты API для обработки запросов API.
  • контроллеры будут содержать файлы, которые имеют дело с проверкой данных, независимо от того, что было отправлено из внешнего интерфейса.
  • сервисы содержат всю бизнес-логику маршрутов API.
  • репозиторий содержит файлы, которые обрабатывают все запросы, связанные с базой данных.
  • ПО промежуточного слоя содержит файлы с различным промежуточным ПО уровня маршрута.
  • helpers содержит файлы, которые выполняют какие-то вспомогательные функции.
  • ключи содержат файлы, в которых хранятся файлы .json / .js / .ts для хранения постоянных значений или значений ключей.
  • .deno_plugins при первом запуске; эта папка создается, просто кешированная версия библиотек или модулей, импортированных в базу кода.
  • app.ts - это точка входа в приложения.

Начиная с файла «app.ts».

Теперь у нас есть папка маршрутизаторов, в которой есть набор маршрутов, связанных с той же службой. Здесь, допустим, Пользователь как самостоятельный сервис.

Теперь давайте создадим маршрутизатор для пользователя, у которого есть методы HTTP.

  • POST → ‘/ user’
  • GET → ‘/ user /: id’

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

Создайте папку «маршрутизаторы» и создайте еще один файл «userRoute.js». Этот файл имеет дело только с маршрутизацией к пользовательской службе.

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

Затем создайте папку служб, содержащую еще один файл userServices.ts, который полностью обрабатывает бизнес-логику API.

Наконец, идет уровень репозитория, который занимается запросами к базе данных. В основном после DRY (D но не R повторять Y самостоятельно); напишите эти запросы один раз на уровне репозитория, и при необходимости их можно будет вызывать несколько раз.

Затем мы создаем класс «база данных» для связи с базой данных, чей объект мы можем использовать для создания экземпляра, для написания запросов.

Создайте папку базы данных с файлом «config.ts», который выглядит следующим образом:

Наконец, создание пользовательского интерфейса, модели для пользовательской базы данных; поскольку в настоящее время у нас нет ORM для Deno; создание интерфейса;

В папке модели создайте файл userInterface.ts;

Это основные требования, необходимые для запуска серверного приложения на базе Oak Framework.

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

Если вы хотите клонировать проект, над которым я работаю, клонируйте ветку oak.

git clone -b ‘oak’ https://github.com/shravan20/deno-crud-api.git

Теперь запустим проект. Откройте терминал / командную строку в корневом каталоге проекта.

deno run --allow-net --allow-write --allow-read --allow-plugin --unstable app.ts
  • - разрешить запись - разрешить сеть; - это флаги, необходимые для разрешения Deno на доступ к сети и другим ресурсам.
  • Когда вы запускаете эту команду в первый раз; он загрузит все необходимые файлы библиотеки и поместит их в кэш локально в папку с именем ./.deno_plugins; который мы в основном вставляем в .gitignore перед коммитом вашего кода.

Ресурсы

  1. 10 вещей, о которых я сожалею о Node.js - Райан Даль - JSConf
  2. Дубовый каркас
  3. Deno - драйвер MongoDB
  4. Deno - это новый способ JavaScript - Райан Даль и Китсон Келли

Поскольку мы находимся в самом начале Deno.land и текущий сценарий выглядит так, как будто он имеет очень многообещающие перспективы на будущее. С нетерпением жду работы над будущими фреймворками в среде Deno.

Мне уже нравится другая, называемая Snowlight Framework (На основе Express Framework в Node); который также доступен в кодовой базе GitHub в ветке «SnowLight».
С моей точки зрения, Deno уже выглядит лучше, чем Node. С нетерпением жду возможности изучить множество других фреймворков и библиотек на платформе Deno.

А пока закончу на день.

Удачного обучения. :)