TL/DR: новая популярная среда выполнения JavaScript от Райана Даля — стильная, мощная и простая в использовании. Самое главное, это нативный TypeScript с моделью смешанного использования, поэтому вы можете перевести свою кодовую базу с JS на TS в своем собственном темпе без транспиляции или волшебного ПО. Меньшая экосистема по сравнению с Node.js ограничивает ваши варианты использования, поэтому это действительно зависит от того, для чего вы хотите ее использовать, но это не все плохие новости, меньшая экосистема также может означать, что ваш проект не раздувается зависимостями. Команды, думающие о переходе на Golang, могут подумать об этом, прежде чем двигаться дальше, так как варианты использования во многом совпадают.

Привет, меня зовут Стивен де Салас. Я был инженером-основателем и техническим директором стартапа Series-A в Мадриде, и мы запустили Deno в производство чуть меньше года.

В основном мы являемся магазином JavaScript, использующим службы Node.js, и я хотел прокомментировать свой опыт настройки службы API Deno и ее запуска. Вы, вероятно, заняты, поэтому я постараюсь быть максимально кратким. Не стесняйтесь писать комментарий, если вы хотите получить дополнительные разъяснения.

ЧТО ТАКОЕ DENO.JS:

Deno (No-de перевернуто) — это новая среда выполнения JavaScript, анонсированная в 2018 году создателем Node.js Райаном Далем после того, как он выразил сожаление по поводу своих ошибок в теперь известной презентации.

По сути, это переписанный движок JavaScript Node.js (известный тем, что он привнес в массы серверный JavaScript), и в последнее время он набирает обороты. Вы можете подробнее прочитать об этом в Википедии.

ДЛЯ ЧЕГО МЫ ИСПОЛЬЗОВАЛИ DENO:

В основном мы использовали Deno для интеграции API. Наш стартап собирает информацию и взаимодействует со многими провайдерами парковок, и у большинства из них есть какой-то JSON API, с которым мы можем общаться, в других случаях мы полагаемся на информацию, предоставленную их веб-сайтом. Это все HTTP в любом случае. Легко решается внутренними вызовами fetch().

Наш стек по сути такой: Deno на докеризированном Debian, с Oak для фреймворка Web/API и SuperOak для тестирования. При необходимости добавляются различные библиотеки. Все они работают как контейнеры с балансировкой нагрузки, размещенные в AWS.

❤️ ЧТО НАМ ПОНРАВИЛОСЬ:

  • Родной TypeScript. Не нужно возиться с ts-node, babel, esbuild или любыми другими способами вставить квадратный штифт (TS) в круглое отверстие (Node.js). TypeScript изначально поддерживается Deno. Нет необходимости в установке, настройке или инструкциях. Это просто работает. Мы использовали TS для всех наших библиотек и основных служебных сценариев, а JS — для маршрутов. Совместимость довольно проста, просто измените расширение файла на .ts, и все готово.

👍 ЧТО ЕЩЕ БЫЛО ХОРОШИМ:

  • Стабильная работа. Никогда не было заминок в процессе. Нагрузки были невелики, но это была важная часть нашей инфраструктуры, и она работала без сбоев до такой степени, что вы даже забываете, что она выполняет свою работу.
  • Простота упаковки. Благодаря единственному исполняемому и легкодоступному образу Docker Deno легко упаковывается для производства. Даже если образы докеров не были опубликованы, простой Dockerfile на основе debian:slim со сценарием установки без проблем запустит ваш код.

👎 ЧТО БЫЛО РАЗДРАЖАЮЩИМ ИЛИ ОТСУТСТВУЕТ:

  • Менее зрелая экосистема. Посмотрим правде в глаза, Node.js имеет NPM, поэтому, с какой бы проблемой вы ни столкнулись, вы обычно находитесь в одном npm install от ее решения. Это может раздражать в Deno, но заставляет вас быть минимальным в отношении зависимостей… слишком много npm install также может испортить ваш проект. Например, если вы хотите создать автоматизированные тесты для своего API, в Node.js вы можете сделать это 20 различными способами. В Deno у вас меньше выбора, или вам придется создавать свои собственные. В итоге мы остановились на superoak.

🤘 ЧТО БЫЛО НЕМНОГО РАСПРОСТРАНЕНО:

  • Модель безопасности. Deno.js рекламируется как модель безопасности, превосходящая Node.js, где разрешения явно объявляются во время выполнения и применяются исполняемым файлом. Хотя в теории это звучит великолепно, практика запуска реального варианта использования, такого как служба API, заключается в том, что по мере расширения проекта и изменения ваших потребностей вы просто будете продолжать добавлять разрешения для основного исполняемого файла в своем сценарии запуска. Это означает, что потребности одного пути выполнения (т.е. GET /document/{documentId}) также будут применяться к КАЖДОМУ ДРУГОМУ пути выполнения, поэтому в целом мало что получается, особенно по мере того, как проекты расширяются и становятся более сложными. Есть способы обойти это, но, честно говоря, я думаю, что было бы полезнее применять разрешения во время выполнения к каждому файлу в каждом конкретном случае.

🤔 ПРОБЛЕМЫ:

  • Сложные зависимости. Единственная серьезная проблема, с которой мы столкнулись, была при попытке обновить наш сервис, чтобы включить в наше развертывание среду выполнения Puppeteer Chromium. Я думаю, что эта проблема возникла бы и с Node.js. Запуск полноценного браузера в качестве фонового процесса имеет слишком много специфичных для платформы требований с точки зрения библиотек и настроек, а также разветвленного процесса, работающего в фоновом режиме. Такие компоненты, как правило, делают решения немного более деликатными. Мы могли бы запустить его, если бы у нас было достаточно времени, но это не стоило усилий, поскольку были другие способы добиться того, что нам нужно, без браузера без головы.

КТО ХОЧЕТ ЭТИМ ПОЛЬЗОВАТЬСЯ?

Давайте посмотрим правде в глаза. Такой проект набирает обороты только потому, что люди хотят его использовать. Я заметил, что Golang в последнее время сильно вытянулся из Node.js для среднего уровня.

И почему? Мне кажется, что основные причины частично совпадают с вариантами использования Deno.js.

  • Bloatware. Проекты, написанные на Node.js, страдают от множества незащищенных зависимостей. Просто попробуйте npm auditпроект старше 6 месяцев. В последнее время ситуация ухудшилась, и дело не в том, что Golang или Deno тоже не страдают от проблем с безопасностью, просто у них гораздо меньше зависимостей, о которых нужно беспокоиться.
  • Стандартный способ выполнения определенных действий: в Golang предусмотрены самостоятельные анализы, тестирование и управление зависимостями. То же, что Дено.
  • Безопасность типов. Golang предоставляет сильные типы, но синтаксические издержки также довольно малы. TypeScript в Deno не совсем «безопасен для типов», но он немного пересекается с точки зрения требований.
  • Преграда для входа. Node.js слишком прост для начала. Это означает, что пул доступных программистов не самого высокого качества. Такие среды выполнения, как Go или Deno, по-прежнему остаются прибежищем для «знатоков» программистов.

На мой взгляд, Deno должен заинтересовать старших разработчиков, работающих над проектами, которые устали от экосистемы Node.js, но хотят использовать аналогичную среду выполнения вместо переноса своей кодовой базы на Golang.

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

об авторе

Стивен де Салас — инженер-основатель/технический директор LetMePark, стартапа серии А, базирующегося в Мадриде. Его суперсила — кодирование платформ с нуля с помощью Node.js, любой базы данных и любого внешнего интерфейса, но у него есть много других талантов, таких как игра в настольные игры и объяснение домашних заданий своим 8-летним близнецам.

Нравится статья?

Пожалуйста, нажмите 👏 прямо под вами. Это помогает большему количеству людей увидеть это.