Машинопись

Я уверен, что вы, вероятно, слышали о TypeScript и знаете, что он в тренде. Если вы погуглите, то найдете что-то вроде «это типизированный расширенный набор JavaScript, который компилируется в простой JavaScript. TypeScript добавляет в JavaScript дополнительную статическую типизацию, классы, модули, интерфейсы и многое другое». Этот результат Google на самом деле ничего не объясняет. Через некоторое время ваш мозг сбросит информацию, которую вы только что прочитали, в Google. К счастью, у нас есть Medium, где такие люди, как я, могут делиться своим чистым опытом. Позвольте мне рассказать вам о моем путешествии с TypeScript. Итак, почему вам следует использовать TypeScript, запомнится вам.

Когда я работал в Sterling, у нас была сессия «Обед и обучение», на которой один из моих бывших коллег рассказал об этом в 2019 году. Команда архитекторов посоветовала нам использовать TypeScript и Cloud Development Kit (CDK). Именно тогда я узнал, что это то, чем мне нужно заняться. Если вы посмотрите на новые библиотеки NodeJS, они все в TS. Вам лучше научиться этому, хотите вы этого или нет.

Я экспериментировал с TypeScript в некоторых приложениях React. Но особой выгоды я не почувствовал. Почему-то мне казалось, что это просто делает мой код многословным и замедляет время разработки. Так что да, я вернулся к Vanilla JavaScript.

Месяц назад я смотрел Внедрение зависимостей, лучший шаблон. По видео я сначала подумал, что это Java-код. Но это был TypeScript, и код выглядел чистым и привлекательным! В тот момент я подумал, что мне действительно нужно снова оглянуться на TypeScript. TypeScript может помочь вам освоить такие мощные методы, как внедрение зависимостей и Объектно-ориентированное программирование.

На днях я писал серверное приложение на NodeJS. Я закончил и развернул его. Я тестировал свой код с помощью Postman. Я получил внутреннюю ошибку сервера. Начал отлаживать свой код. Через час причину не нашел. Я расстроился. Потом наконец нашел, потому что забыл await. Облом! Если бы я использовал TypeScript, он бы включил ошибку раньше и уведомил бы меня: «Вы пропустили ключевое слово await, поскольку оно возвращает обещание». Разработчикам легко допустить подобные глупые ошибки. Typescript может обнаруживать ошибки при написании кода и предотвращать ошибки, устранение которых может занять несколько часов после развертывания приложения.

Кроме того, когда я пишу код на Vanilla JavaScript, я заметил одну вещь: я единственный, кто понимает этот код и знает, что такое ввод и вывод. Ванильный JavaScript подойдет, если вы единственный, кто разрабатывает проект. Но в организации, если у вас есть команда разработчиков, лучше использовать TypeScript, чтобы новые участники и другие члены команды могли знать, как выглядят входные и выходные данные функции. Вы знаете, что использовать сторонние библиотеки, написанные на TS, очень просто.

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

И последнее — структурирование. Я писал микросервис, который хранит в таблице 10 атрибутов. Поскольку таблица представляет собой DynamoDB, она не имеет схемы и в ней можно хранить N атрибутов. Когда я писал свое серверное приложение на NodeJS, я проверял только необходимые параметры. Сможете ли вы догадаться, что произошло после отправки полезной нагрузки с сотней атрибутов от Postman? Он хранил их все на столе. Теперь у вас есть аномальные данные в БД. Это логически неверно. Потому что должно быть ровно 10 атрибутов. Используя TypeScript, я создал тип и решил проблему более естественным и правильным способом.

Буду ли я когда-нибудь снова использовать ванильный JavaScript в своих новых проектах? Большое НЕТ.

Примечание. Я настоятельно рекомендую вам начать использовать AWS CodeWhisperer — инструмент искусственного интеллекта, который поможет вам в кодировании. Я люблю и использую его ежедневно. Это потрясающе, бесплатно и легко начать.

Инфраструктура как код (IaC)

Поскольку у меня есть время время от времени вести блог, я хочу дать вам как можно больше преимуществ. Это большая тема, но я изложу ее быстро и кратко. Неважно, работаете ли вы в небольшом стартапе или в таком гиганте, как FAANG. Цель всех технологических компаний — добиться максимально плавной автоматизации. Например, у вас есть приложение, работающее на одном сервере. Вам нужно было масштабировать приложение и добавить второй сервер. Будете ли вы заново настраивать сервер и приложение на втором сервере? Ну, возможно, да. А как насчет сотен или тысяч серверов? В этом случае вам, вероятно, понадобится автоматизация, которая настраивает сервер и приложение. Вот что такое Инфраструктура как код (IaC). Люди достигают этого, используя такие инструменты, как Terraform и Kubernetes. В AWS вы можете автоматически выделять ресурсы с помощью CloudFormation.

Я достиг 80% автоматизации своих проектов с помощью CloudFormation. Есть несколько одноразовых настроек, которые я делал вручную. Чего мне не следует делать. Недавно мы внесли много изменений в приложение. Все изменения в настоящее время находятся в аккаунте разработки. Мне нужно развернуть это на рабочей учетной записи. Честно говоря, я боюсь это делать. Просто слишком много дел. Если я пропущу одну конфигурацию, я испорчу производство. Это возможно, поскольку я еще не автоматизировал 20%.

Выполнять всю автоматизацию в CloudFormation наивно. В некоторых случаях изменить шаблон A невозможно, поскольку от него зависит шаблон B. Так

  • Сначала я обновляю зависимость B и удаляю ее.
  • Затем обновите зависимость A.
  • Затем верните изменения в зависимости B, которые я сделал ранее.

Это просто не удобно и отнимает много времени и нервов. Я ждал инструмента, который автоматически генерирует идеальный шаблон. В Reinvent 2022 они анонсировали Application Composer. Возможно, это так, но я еще не экспериментировал с этим. Я пробовал SAM и Amplify. Они бесполезны, пожалуйста, не используйте их. Потому что:

  • Amplify — очень мало контроля над вашим приложением. Ограниченные конфигурации. Это может быть полезно для тех, кто хочет создать приложение в облаке и не имеет опыта работы с облаком или серверной частью.
  • СЭМ — То же, ограниченный контроль. Например, я являюсь мастером службы API Gateway. Это потрясающий сервис. Когда вы используете SAM, он автоматически генерирует шлюз API, над которым вы не имеете контроля.
  • Пул удостоверений Cognito — не имеет отношения к этой теме. Но просто для вашей информации. Та же самая причина. Вы не можете ввести свою логику авторизации. Вместо этого я рекомендую вам написать собственную лямбду авторизатора.

Я нашла идеальное средство! Удивительно, но это существовало уже много лет, но почему-то я не использовал AWS Cloud Development Kit (CDK). С его помощью мне удалось добиться 100% автоматизации. Что также помогло мне добиться этого, так это то, что CDK поддерживает TypeScript. Итак, я могу выполнить любую настройку в VsCode.

Я также хочу поделиться одним исправлением ошибки в CDK. Поскольку я не мог найти решение в Интернете, я придумал это решение. Когда вы хотите передать параметр в конструкцию (а не в стек), она добавляет случайные префиксы и суффиксы. Чтобы это исправить, прочитайте параметр в файле TS основного стека и передайте его дочерним конструкциям в качестве реквизита.

Стек технологий, который я рекомендую. Если приложение маленькое или среднее, то это означает, что счет составляет менее 10 тысяч долларов в месяц:

  • CDK(TypeScript) в качестве инструмента IaC
  • API-шлюз и специальный авторизатор Lambda (TypeScript)
  • Lambda(TypeScript) в качестве вашего приложения или бизнес-логики.
  • DynamoDB — ваша база данных.

Я также изучил OpenSearch и бессерверные RDS. У них есть бессерверный тег, но плата взимается каждый час. Это не имеет смысла. Потому что бессерверная технология должна быть нулевой при отсутствии запросов. Так что они никуда не годятся. Я также экспериментировал с StepFunctions, которые мне не очень понравились, потому что:

  • Не гибкий
  • Возможно, это чрезмерная инженерия
  • Шаблон становится таким большим
  • Могло бы быть дороже

Если приложение большое или счет за облако превышает 10 тысяч долларов в месяц:

  • Купить или арендовать серверы или виртуальные машины
  • Терраформировать
  • Кубернетес
  • Инструменты мониторинга

Приятного строительства!