Smashing Podcast Эпизод 22 с Крисом Койером: что такое безсерверность?

Сегодня мы говорим о бессерверных архитектурах. Что это значит и чем это отличается от того, как мы можем создавать сайты в настоящее время? Я поговорил с Крисом Койером, чтобы узнать.

Показать примечания

• Микросайт Криса The Power of Serverless for Front-end Developers
• Крис в Твиттере
• Подкаст ShopTalk Show

Еженедельное обновление

• «Настройка Redux для использования в реальном приложении»,
  Джерри Нави
• «Можете ли вы создать веб-сайт для пяти чувств?»
  Сюзанна Скакка
• «Создание статического блога с помощью Sapper и Strapi»,
  Даниэль Мадалицо Фири
• «Практическое руководство по продуктам в приложениях React»,
  от Благословения Крофеги
• «Как создать Porsche 911 с помощью Sketch»,
  Никола Лазаревич

Стенограмма

Дрю Маклеллан: Он веб-дизайнер и разработчик, которого вы, возможно, знаете по CSS-Tricks, веб-сайту, который он создал более 10 лет назад, и который остается фантастическим учебным ресурсом для тех, кто создает веб-сайты. Он является соучредителем CodePen, браузерной площадки для кодирования и сообщества, которое используют фронтендеры по всему миру, чтобы делиться своими разработками и черпать вдохновение у тех, за кем они следуют. Вместе с Дейвом Руперт является соведущим ShopTalk Show, подкаста о создании веб-сайтов. Итак, мы знаем, что он много знает о веб-разработке, но знаете ли вы, что однажды он выиграл соревнование по поеданию хот-догов, используя только свое обаяние? Мои потрясающие друзья, пожалуйста, поприветствуйте Криса Койера. Привет Крис, как дела?

Крис Койер: Эй, я разбиваю.

Дрю: Я хотел поговорить с вами сегодня не о CodePen, и я не обязательно хочу говорить с вами о CSS-Tricks, который является одним из тех замечательных ресурсов, которые, я уверен, все знают, находятся прямо в верхней части Google. Результаты поиска при поиске ответов на любой вопрос веб-разработки. Вверх всплывает ваше лицо, и есть полезный пост в блоге, написанный вами или одним из ваших приглашенных участников.

Крис: О, я действительно так делал. Это было… я не знаю, наверное, это было во времена, когда у Google была эта странная социальная сеть. Что это было? Гугл плюс?

Дрю: О, Плюс, да.

Крис: Да, когда они связывали веб-сайт с учетной записью Plus, поэтому у моей учетной записи Plus был аватар, и аватаром был я, поэтому он отображался в результатах поиска. Я думаю, что те времена прошли. Я думаю, если вы…

Дрю: Думаю да, да-

Крис: Да.

Дрю: Но я как бы хотел поговорить с вами о чем-то, что было вашим побочным интересом, а именно о концепции бессерверных архитектур.

Крис: Мм (утвердительно).

Дрю: Это то, о чем ты узнал немного больше в последнее время. Это правильно?

Крис: Да, да. Я просто фанат. Кажется, это естественно вписывается в эволюцию фронтенд-разработки, в которой я чувствую, что у меня есть, по крайней мере, некоторый опыт. Я считаю себя гораздо более… гораздо более полезным на фронтенде, чем на бэкенде, не то чтобы я… я делаю это все эти дни. Я работаю достаточно долго, чтобы не бояться взглянуть на небольшой код Ruby, это точно. Но я предпочитаю фронтенд. Я изучил его больше. Я больше участвовал в проектах такого уровня, а затем появилась эта небольшая новая парадигма, которая говорит: «Вы можете использовать свои навыки JavaScript на сервере», и это интересно. Тебе известно? Вот как я думаю об этом. Это гораздо больше, чем это, но вот почему меня это волнует, потому что я чувствую, что фронтенд-разработчики так глубоко погрузились в JavaScript. И теперь мы можем использовать тот же набор навыков в другом месте. Мм, прикольно.

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

Крис: Да, да. Вот и все.

Дрю: Обращаясь к слону в комнате, прямо наверху. Мы говорим о бессерверных технологиях, и, очевидно, назвать что-то сложно. Мы все это знаем. Бессерверная архитектура не означает отсутствия серверов, не так ли?

Крис: Я думаю, что это обязательно, например, если это первый подкаст, который вы слышите об этом, или в первом… вы слышите слово «бессерверный» только в первую дюжину раз, когда вы его слышите, обязательно, чтобы вы иметь интуитивную реакцию и иметь такой вид: «О, но есть еще серверы». Это нормально. Если это происходит с вами прямо сейчас, просто знайте, что это обязательный шаг. Это так же, как все в жизни. Есть этапы понимания. В первый раз, когда вы что-то слышите, вы должны как бы немного отбросить это, и только после того, как раз десять или около того, или после того, как это немного доказало вам свою ценность, вы можете перейти к дальнейшим этапам. понимания здесь. Но слово победило, так что, если вы все еще боретесь со словом «бессерверный», мне неприятно говорить вам, что поезд ушел с этой станции. Слово уже удачное. Ты не собираешься побеждать в этом. Так жаль.

Крис: Но я действительно думаю, что это интересно, что… это начинает казаться, что иногда на самом деле серверы не задействованы. Я думаю, что одной из вещей, которая зафиксировала бессерверную концепцию, была AWS Lambda. Они были как бы первыми на сцене. Лямбда похожа на функцию, которую вы даете AWS, и он помещает ее в волшебное небо, а затем… у нее есть URL-адрес, и вы можете нажать на нее, и она запустит эту функцию и вернет что-то, если вы этого хотите. Тебе известно? Это просто HTTP или что-то в этом роде. Вот как это работает, что… в первый раз, когда вы слышите это, вы думаете: «Почему? Мне все равно». Но тут есть некоторые очевидные вещи. Он может знать мои ключи API, к которым никто другой не имеет доступа. Вот почему вы запускаете серверную часть для начала, потому что она знает секретные вещи, которые не обязательно должны быть в JavaScript на стороне клиента. Поэтому, если ему нужно поговорить с базой данных, он может это сделать. Он может сделать это безопасно, не раскрывая ключи API где-либо еще. Или даже где эти данные или как их получить, это…

Крис: Так что это довольно круто. Я могу написать функцию, которая обращается к базе данных, получает какие-то данные и возвращает их. Прохладный. Итак, Lambda это то, но AWS работает. Вы должны выбрать регион. Ты такой: «Я не знаю. Где он должен быть, Вирджиния? Орегон? Должен ли я выбрать Австралию? Я не знаю." У них 20, 30. Я даже не знаю, сколько у них сейчас, но даже у лямбд были регионы. У них, я думаю, в эти дни есть Lambda@Edge, что означает, что это все регионы, что довольно круто. Но они были первыми, а теперь у всех есть что-то вроде Lambda. Все облачные сервисы. Они хотят какой-то службы в этом мире. Одним из них является CloudFlare. В CloudFlare есть рабочие. У них гораздо больше местоположений, чем у AWS, но они выполняли их тоже в разное время… как рабочий процесс CloudFlare… он похож на лямбду в том смысле, что вы можете запускать Node. Вы можете запустить JavaScript. Вы также можете запустить ряд других языков, но… Я думаю об этом в основном, самый интересный язык — это JavaScript, просто из-за его распространенности.

Крис: Это происходит только на уровне CDN, который, я думаю, является сервером, но я склонен не думать о CDN как о сервере. Не так явно, как что-то другое. В последнее время он начинает казаться еще более бессерверным. Является ли CDN сервером? Я имею в виду, я думаю, что это где-то компьютер, но он кажется еще менее серверным.

Дрю: Такое ощущение, что да, CDN может быть сервером, но это самая минимальная версия сервера. Это как тонкий сервер, если хотите.

Крис: Да. Конечно.

Дрю: Хорошо. Я слышал, как это было сказано… К сожалению, я не могу вспомнить источник, но я слышал, что бессерверные технологии описывались как «как использование службы совместного использования, такой как Uber или Lyft» или что-то в этом роде. Вы можете быть без автомобиля и не иметь машины, но это не значит, что вы никогда не пользуетесь машиной.

Крис: Да, это не значит, что машин не существует. Мм, это мило.

Дрю: Вы просто вызываете его, когда он вам нужен, но в то же время вы не платите первоначальную стоимость покупки автомобиля. Вы не платите за обслуживание или топливо или-

Крис: Верно, и цена тоже имеет смысл, верно? Это мило. По-моему, хорошая аналогия. И затем, поскольку он тоже на уровне CDN, он просто перехватывает HTTP-запросы, которые уже происходят, а это значит, что вы его не спрашиваете… вы не отправляете ему запрос, и он отправляет запрос обратно. Это происходит естественным образом во время запроса, что также делает его менее серверным. Я не знаю, это интересно. Это точно интересно. Так что это большое дело, что вы подняли вопрос ценообразования. Что вы платите только за то, что используете. Это тоже важно, потому что… скажем, вы back-end разработчик, привыкший всю жизнь раскручивать серверы. И они управляют затратами: «Мне нужен такой-то сервер с такой-то памятью, таким-то процессором и такими-то характеристиками. И вот сколько это будет стоить». Появляется Serverless и отрубает голову этой цене.

Крис: Итак, даже если вы являетесь бэкенд-разработчиком, которому это не очень нравится, что они просто не в этом заинтересованы, например, ваш набор навыков такой, какой он был за эти годы, вы сравниваете цену. и ты такой: «Что? Я мог бы платить 1% от того, что платил раньше?» Вам не позволено не заботиться об этом, верно? Если вы бэкенд-разработчик, который платит за свои услуги в сто раз больше, чем они должны платить, тогда вы просто плохо справляетесь со своей работой. Жаль это говорить. Это произошло, и это сильно повлияло на ценообразование. Вы должны заботиться об этом. И это круто, что есть кто-то еще… Не то чтобы вам вообще не нужно было беспокоиться о безопасности, но это не ваш сервер. У вас нет... вашей лямбда-выражения или облачной функции, или вашего рабочего процесса, или чего-то еще, не сидящего на сервере, который находится рядом с некоторыми действительно конфиденциальными данными в вашей собственной сети. Это не рядом с вашей базой данных.

Крис: Если кто-то пишет код, который каким-то образом пытается извлечь себя из рабочего процесса, или лямбды, или чего-то еще, и пытается получить доступ к другим вещам на своем пути, там нечего будет получить. Так что безопасность тоже имеет большое значение, так что, опять же, если это ваша работа в качестве администратора сервера, вам нужно заняться безопасностью этой штуки. Запуская его, запуская определенные вещи в Lambda, вы просто получаете некоторую естественную безопасность, и это здорово. Так, это намного дешевле. Это намного безопаснее. Это поощряет эту небольшую модульную архитектуру, которая может быть хорошей идеей. Кажется, что это домино за домино хороших идей здесь. Вот почему это примечательно. Тебе известно?

Дрю: Да, я имею в виду, что традиционно с серверной архитектурой, которую мы десятилетиями использовали в Интернете, у вас есть веб-сервер, который вы запускаете сами. Он содержит ваш внешний код, ваш внутренний код, вашу базу данных и все остальное. Затем вам нужно поддерживать это, поддерживать его в рабочем состоянии и оплачивать счета, и даже если он не используется, он постоянно оплачивает счета. Пользователь сделает запрос, и он создаст весь этот HTML-запрос из базы данных, отправит все это в браузер. Этот процесс работает. Так строится множество вещей. Это, вероятно, большая часть того, как построена сеть. Так работают такие вещи, как WordPress. Это действительно проблема, которую нам нужно решить? Я имею в виду, мы немного поговорили о затратах. Какие еще есть проблемы с этим, которые мы… которые нам нужно решить, и с которыми нам может помочь бессерверное решение?

Крис: Да, проблемы с подходом старой школы. Да не знаю, может и нет. Я имею в виду, я не говорю, что вся сеть должна полностью… все изменить за одну ночь. Я не знаю. Может быть, на самом деле это не так, но я думаю, что это открывает двери. Просто кажется, что когда хорошие идеи приходят вот так, они просто медленно меняют то, как работает Интернет. Итак, если есть какая-то CMS, которая каким-то образом построена и ожидает наличия базы данных, это означает, что, возможно, хосты будущего начнут использовать это интересным образом. Возможно, вам кажется, что это все еще просто традиционный сервер, но сами хосты передали его, как они работают, бессерверным архитектурам. Таким образом, вы даже не знаете, что это происходит, но они нашли способ сократить свои расходы, размещая то, что вам нужно, без использования серверов. Может быть, да, даже не нужно заботиться как разработчику, но на метауровне это то, что происходит. Может быть. Я не знаю.

Крис: Это также не означает, что… Базы данных все еще существуют. Если выяснится, что архитектурно наличие реляционной базы данных является правильным способом хранения этих данных, прекрасно. Я упоминаю об этом, потому что этот мир Serverless как бы растет в то же время, что и JAMstack. И JAMstack — это архитектура, которая гласит: «Вы должны обслуживать свой веб-сайт со статических хостов, которые вообще ничего не запускают, кроме…». Они похожи на маленькие CDN. Они такие: «Я ничего не могу сделать. Я не запускаю PHP. Я не запускаю Руби. Я ничего не запускаю. Я работаю на крошечном веб-сервере, который предназначен только для обслуживания статических файлов».

Крис: «И затем, если вам нужно сделать больше, если вам нужно извлечь данные из реляционной базы данных, то, пожалуйста, сделайте это в другое время, а не во время сервера. Вы можете сделать это заранее в процессе сборки и вытащить этот материал из базы данных, предварительно собрать статические файлы, и я буду их обслуживать, или сделать это во время выполнения». Это означает, что вы получаете эту оболочку документа, а затем он делает запрос JavaScript для получения некоторых данных и затем предварительно заполняет их. Таким образом, вы делаете это заранее или позже, но это не означает: «Не используйте реляционную базу данных». Это просто означает: «Не позволяйте серверу генерировать его во время запроса документа», что… я не знаю, это небольшой сдвиг парадигмы.

Крис: Это касается не только JAMstack. Мы также живем во времена фреймворков JavaScript. Мы живем в то время, когда становится немного более ожидаемо, что способ загрузки приложения JavaScript заключается в том, что оно монтирует некоторые компоненты, и когда эти компоненты монтируются, оно запрашивает данные, которые ему нужны. Таким образом, для чего-то вроде веб-сайта React может быть вполне естественно говорить: «Ну, я просто нажму на бессерверную функцию, чтобы получить данные, которые ей нужны. По сути, это касается некоторого JSON API. Я получаю данные JSON, которые мне нужны, и создаю себя из этих данных, а затем визуализирую на странице». Теперь, хорошо это или плохо для Интернета, это похоже на: «Я не знаю. Очень жаль. Корабль уплыл. Вот как многие люди строят сайты». Это просто клиентские вещи. Итак, бессерверный и современный JavaScript идут рука об руку.

Дрю: Я полагаю, вам не нужно продавать оптом… смотреть на ту или иную архитектуру. Полагаю, есть область посередине, где части инфраструктуры могут быть более традиционными, а части могут быть бессерверными?

Крис: Да. Ну, они все равно пытаются вам это сказать. Любой, кто хочет продать вам какую-либо часть своей архитектуры, говорит: «Вы не обязаны покупать все прямо сейчас. Просто сделай это немного». Потому что, конечно, они хотят, чтобы вы окунули свой носок в то, что они продают, потому что, как только вы окунете палец ноги, шансы, что вы плюхнетесь в бассейн, намного выше. Итак, я думаю, что… это не ложь, хотя обязательно, хотя мне повезло немного меньше… Я не хочу, чтобы мой стек состоял из всего понемногу. Я думаю, что там есть какая-то техническая смерть, которую я не всегда хочу проглотить.

Дрю: Мм (утвердительно).

Крис: Но это возможно. Я думаю, что наиболее цитируемым является… скажем, у меня есть сайт с элементом электронной коммерции, что означает… и, скажем, крупномасштабная электронная коммерция, то есть 10 000 продуктов или что-то вроде того, что эта архитектура JAMstack не дошла до точки, где это всегда особенно эффективно, чтобы перестроить это статически. Итак, мысль идет: «Тогда не надо». Позвольте этой части естественным образом гидратироваться с помощью… запускать бессерверные функции и получать данные, которые ей нужны, и делать все это. Но остальная часть сайта, которая не… там не так много страниц, не так много данных, вы можете сделать предварительный рендеринг или что-то в этом роде. Так что немного того и другого.

Дрю: Конечно, многие люди имеют дело с устаревшими системами, которые… какая-то старая база данных, созданная в 2000-х годах, на которую они могут наложить своего рода слой JSON API…

Крис: Да.

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

Крис: Да. Хотя мне это нравится, не так ли? Нет… большинство веб-сайтов уже существуют. Сколько из нас полностью разрабатывают веб-сайты с нуля? Большинство из нас работает над какой-то уже существующей хренью, которую нужно зачем-то тащить в будущее, потому что я не знаю, разработчики хотят работать быстрее, или на COBOL уже никого не наймешь, или еще какая история является. Тебе известно?

Дрю: Что касается терминологии, мы говорим о JAMstack, который представляет собой методологию запуска кода в значительной степени в браузере, обслуживающего его из CDN. Итак, на сервере нет ничего динамического. И затем, когда мы говорим о бессерверных серверах, мы говорим о тех небольших функциональных возможностях, которые работают на их сервере где-то еще. Это правильно? То, что мы говорили об этих облачных функциях, вроде-

Крис: Да, я имею в виду, что обе идеи сейчас очень горячие. Так что легко говорить об одном и говорить о другом. Но им не обязательно быть вместе. Вы можете запустить сайт JAMstack, который не имеет ничего общего с бессерверным. Вы просто делаете это, вы просто предварительно создаете сайт и запускаете его, и вы можете использовать без сервера, не заботясь о JAMstack. На самом деле CodePen вообще ничего не делает для JAMstack. Не то чтобы мы обязательно хотели говорить о CodePen, но это приложение Ruby on Rails. Он работает на множестве экземпляров AWS EC2 и множестве других архитектур, чтобы это произошло. Но мы используем бессерверные технологии всякий раз, когда можем, для всего, что можем, потому что это дешево и безопасно, и это просто хороший способ работы. Таким образом, JAMstack не используется вообще, а бессерверный повсюду.

Дрю: Это довольно интересно. Какие задачи вы выполняете без сервера на CodePen?

Крис: Ну, есть целая куча вещей. Один из них, я думаю, надеюсь, достаточно очевиден: мне нужно… смысл CodePen в том, что вы пишете каждый HTML, CSS и JavaScript в браузере, и он отображает их перед вами, верно? Но вы также можете выбрать языки препроцессора. Допустим, вам нравится Sass. Вы включаете Sass в CSS и пишете Sass. Ну, что-то должно обрабатывать Sass. В наши дни Sass написан на Dart или что-то в этом роде.

Крис: Теоретически это можно сделать в клиенте. Но эти библиотеки, выполняющие предварительную обработку, довольно велики. Я не думаю, что хочу отправлять вам всю библиотеку Sass только для того, чтобы запустить эту штуку. Я не хочу… просто нет, это не обязательно правильная архитектура для этого. Может быть, это будет в будущем, я имею в виду, мы могли бы поговорить об оффлайн-дерьме, бла-бла-бла, веб-воркерах. Мы могли бы сделать миллион архитектурных вещей. Но вот как это работает сейчас, есть ли лямбда. Он обрабатывает Sass. У него есть одна крошечная, крошечная, крошечная, маленькая работа.

Крис: Вы отправляете ему этот кусок Sass, и он отправляет вам обратно обработанный CSS, может быть, карту сайта, что угодно. У него есть одна маленькая работа, и мы, вероятно, платим за эту лямбду, около четырех центов или около того. Потому что лямбды просто невероятно дешевы, и их тоже можно забить. Вам не нужно беспокоиться о масштабе. Вы просто нажимаете на эту штуку столько, сколько хотите, и ваш счет будет удивительно дешевым. Бывают моменты, когда бессерверные решения начинают переступать черту слишком дорого. Я не знаю, что это такое, я не мастер таких вещей. Но вообще, любые бессерверные вещи, которые мы делаем, мы в основном… почти все считаем бесплатными, потому что это так дешево. Но есть один для Сасса. Есть один для Меньше. Есть один для Баббеля. Есть один для TypeScript. Есть один для… Все это отдельные лямбда-выражения, которые мы запускаем. Вот какой-то код, дайте его лямбде, он вернется, и мы сделаем с ним все, что собираемся. Но мы используем его для гораздо большего, даже в последнее время.

Крис: Вот пример. У каждого пера на CodePen есть скриншот. Это круто, да? Итак, люди делают что-то, а затем нам нужен PNG или JPEG, или что-то в этом роде, чтобы мы могли… таким образом, когда вы твитите, вы получаете небольшой предварительный просмотр. Если вы поделитесь им в Slack, вы получите небольшой предварительный просмотр. Мы используем его на самом веб-сайте для рендеринга… вместо iframe, если бы мы могли обнаружить, что ручка не анимирована, потому что изображение iframe намного светлее, так почему бы не использовать изображение? Это все равно не анимация. Просто прирост производительности такой. Таким образом, у каждого из этих снимков экрана, очевидно, есть URL-адрес. И мы разработали его так, что этот URL-адрес фактически является бессерверной функцией. Это рабочий. И поэтому, если этот URL-адрес будет найден, мы можем очень быстро проверить, сделали ли мы уже этот снимок экрана или нет.

Крис: На самом деле это реализовано с помощью CloudFlare Workers, потому что CloudFlare Workers — это не только бессерверная функция, но и хранилище данных. У них есть такая штука, как хранилище ключей-значений, так что идентификатор этого мы можем очень быстро проверить, и это будет: «Правда или ложь, у вас это есть или нет?» Если оно есть, оно служит этому. И он обслуживает его через CloudFlare, что очень быстро. И затем дает вам все эти способности тоже. Поскольку это CDN с изображениями, вы можете сказать: «Ну, подайте его в оптимальном формате. Служи ему как этим измерениям». Мне не нужно делать изображение в этих размерах. Вы просто указываете размеры в URL-адресе, и он волшебным образом возвращается в том же размере. Так что это действительно приятно. Если у него его нет, он запрашивает другую бессерверную функцию, чтобы сделать его действительно быстрым. Итак, он сделает это, а затем положит куда-нибудь в ведро… потому что у вас должно быть происхождение для изображения, верно? Обычно вы должны разместить его где-нибудь. Поэтому мы очень быстро помещаем его в ведро S3, а затем подаем.

Крис: Значит, нет ни сервера очередей, ничего. Это похоже на бессерверные функции, управляющие созданием, хранением и обслуживанием этих изображений. И их где-то 50 или 80 миллионов или около того. Это много, поэтому он довольно хорошо справляется с масштабированием. Мы просто даже не трогаем его. Это просто случается. Все происходит супер быстро. Супер красиво.

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

Крис: Да. Это то, что они пытаются решить с помощью тех. Эти пары ключ-значение, это… Я думаю, что традиционно это было правдой. Они такие: «Избегайте состояния в этом деле», потому что вы просто не можете на него рассчитывать. И работники CloudFlare говорят: «Да, на самом деле, вы можете в какой-то степени иметь дело с состоянием». Это не так красиво, как… Я не знаю, это ключевые значения, так что это ключ в значении. Это не похоже на вложенную реляционную причудливую вещь. Так что, вероятно, есть некоторые ограничения для этого. Но это детские дни для этого. Я думаю, что этот материал будет развиваться, чтобы стать более мощным, поэтому у вас есть некоторая способность делать некоторые вещи, подобные состояниям.

Дрю: И иногда ограничение, своего рода ограниченная способность поддерживать состояние или тот факт, что у вас нет… вы вообще не хотите поддерживать состояние, подталкивает вас к архитектуре, которая дает вам такого рода… Ну, когда мы говорим о философии программного обеспечения «Небольшие кусочки, свободно соединенные», не так ли?

Крис: Мм (утвердительно).

Дрю: Где каждый маленький компонент делает что-то одно и делает это хорошо. И на самом деле не знает об остальной экосистеме вокруг него. И, похоже, это действительно применимо к этой концепции бессерверных функций. Ты согласен?

Крис: Да. Я думаю, вы могли бы вести философские дебаты, хорошая это идея или нет. Тебе известно? Я думаю, что некоторым людям нравится монолит, так сказать. Я думаю, что возможно… есть способы переусердствовать и сделать слишком много мелких деталей, которые слишком сложно тестировать в целом. Приятно иметь тест типа: «О, интересно, работает ли моя функция Sass. Что ж, давайте просто напишем для него небольшой тест и убедимся, что это так». Но допустим, что для пользователя важна какая-то строка из семи из них. Как вы проверяете все семь из них вместе? Я думаю, что эта история становится немного сложнее. Я не знаю, как суперумно говорить обо всем этом, но я знаю, что это не обязательно так, если вы используете все бессерверные функции, которые автоматически становятся лучшей архитектурой, чем любая другая архитектура. Мне это нравится. Мне это кажется прекрасным, но я не уверен, что это конечная цель всех архитектур. Тебе известно?

Дрю: На мой взгляд, это очень похоже на Интернет, потому что… именно так работает HTML, не так ли? Вы отправляете какой-то HTML-код, а затем браузер переходит к вашим изображениям, загружает ваш JavaScript и извлекает ваш CSS. Кажется, что это расширение этого -

Крис: Это мило.

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

Крис: Мм (утвердительно).

Дрю: Насколько надежен такой бессерверный подход? Что произойдет, если что-то… если один из этих маленьких кусочков исчезнет?

Крис: Это было бы очень плохо. Тебе известно? Это было бы катастрофой. Ваш сайт выйдет из строя, как и любой другой сервер, если он выйдет из строя, я думаю.

Дрю: Есть ли способы смягчить это, в частности...

Крис: Я не знаю.

Дрю: … подходит для такого подхода, с которым вы столкнулись?

Крис: Возможно. Я имею в виду, как я уже сказал, действительно супер-причудливая надежная вещь может быть такой… скажем, вы посещаете CodePen и, скажем, есть реализация Sass на JavaScript, и мы заметили, что вы находитесь в довольно быстрой сети и что вы бездействуете. прямо сейчас. Может быть, мы возьмем этот JavaScript и добавим его в сервис-воркера. Затем, если мы обнаружим, что лямбда выходит из строя, или что-то в этом роде, или что эта штука у вас уже установлена, то вместо лямбды мы нажмем сервис-воркер, и сервис-воркеры смогут работать в автономном режиме. Что ж, это тоже приятно. Это интересно. Я имею в виду, что они на одном языке. Сервисные работники — это JavaScript, и многие облачные функции — это JavaScript, так что есть некоторые… Я думаю, что это возможно, хотя это… просто это серьезная техническая проблема, которая… Меня просто пугает тот кусок JavaScript, который вы доставили. скольким тысячам пользователей, что вы не обязательно знаете, что у них есть и какая у них версия. Фу, но это всего лишь мой собственный страх. Я уверен, что некоторые люди проделали хорошую работу с такими вещами.

Крис: На самом деле я не знаю. Может быть, вы знаете некоторые стратегии, которых нет у меня, относительно отказоустойчивости бессерверных приложений.

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

Крис: Компании, которые обычно предлагают эту технологию, вы должны доверять им, но они также относятся к типу компаний, которые… это их гордость. Это причина, по которой люди используют их, потому что они надежны. Я уверен, что люди могли бы указать на некоторые сбои AWS в прошлом, но они, как правило, немного редки и не очень распространены. Если вы размещали свое собственное дерьмо, держу пари, они выбили вас из процентного уровня SLA. Тебе известно? Так что это не похоже на «Не строить устойчивым образом», но, как правило, компании, которые предлагают такие вещи, чертовски надежны. Вероятность того, что вы выйдете из строя из-за того, что вы испортили эту функцию, намного выше, чем из-за того, что их архитектура дает сбой.

Дрю: Я полагаю, я имею в виду, как и все, что вы используете API или что-то, что может дать сбой, просто убедитесь, что вы структурируете свой код, чтобы справиться с этим режимом сбоя и знать, что произойдет дальше, а не просто бросать выдает ошибку пользователю, или просто умирает, или что у вас. Он знает об этом и просит пользователя повторить попытку. Или попробовать себя снова, или что-то в этом роде.

Крис: Да, мне нравится идея попробовать больше одного раза, а не просто сказать: «О нет. Потерпеть неудачу. Прервать». «Я не знаю, почему бы тебе не попробовать еще раз там, приятель?»

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

Крис: Я думаю, есть несколько способов. Я не знаю, такая же потрясающая история. Это все еще относительно новая концепция, поэтому я думаю, что она становится все лучше и лучше. Но, насколько я знаю, во-первых, вы пишете довольно обычную функцию Node. Предполагая, что вы используете для этого JavaScript, а я знаю, что конкретно в Lambda они поддерживают всевозможные вещи. Вы можете написать чертову облачную функцию PHP. Вы можете написать облачную функцию Ruby. Итак, я знаю, что говорю именно о JavaScript, потому что мне кажется, что большинство из этих вещей — это JavaScript. Я имею в виду, что даже независимо от того, какой это язык, вы можете перейти к своей командной строке локально и выполнить это. Часть этого тестирования… вы просто тестируете его, как и любой другой код. Вы просто вызываете функцию локально и смотрите, работает ли она.

Крис: Это немного другая история, когда вы говорите о HTTP-запросе к нему, это то, что вы пытаетесь протестировать. Правильно ли он отвечает на запрос? И правильно ли возвращает товар? Я не знаю. Сеть может быть вовлечена в это. Поэтому вы можете захотеть написать тесты на этом уровне. Хорошо. Я не знаю. Какая там нормальная история? Вы раскручиваете какой-то локальный сервер или что-то, что его обслуживает. Используйте Postman, я не знаю. Но есть… Фреймворки тоже пытаются помочь. Я знаю, что безсерверный «.com», который просто ужасно сбивает с толку, но буквально есть компания под названием Serverless, и они создают основу для написания бессерверных функций, которая помогает вам их развертывать.

Крис: Итак, если вам нравится бессерверная установка NPM, вы получаете их фреймворк. И многие считают его очень хорошим, потому что он просто очень полезен, но у них нет собственного облака или чего-то подобного. Вы пишете их, а затем это помогает вам превратить их в настоящую лямбду. Или он может работать с несколькими облачными провайдерами. Я даже не знаю в эти дни, но их цель существования состоит в том, чтобы сделать историю развертывания проще. Я не знаю, что… AWS не славится своей простотой. Тебе известно? Существует целый мир инструментов, которые помогут вам использовать AWS, и они являются одним из них.

Крис: У них есть какой-то платный продукт. Я даже не знаю, что это такое. Я думаю, что одна из вещей, которые они делают, это… цель их использования — тестирование, создание среды разработки для тестирования вашей бессерверной функции.

Дрю: Да, потому что, я думаю, это довольно большая часть рабочего процесса, не так ли? Если вы написали свою функцию JavaScript, протестировали ее локально, вы знаете, что она будет работать. How do you actually pick which provider it's going to go into and how do you get it onto that service? Now, I mean, that's a minefield, isn't it?

Крис: Да. I mean, if you want to use no tooling at all, I think they have a really… like AWS, specifically, has a really rudimentary GUI for the thing. You can paste the code in there and hit save and be like, “Okay, I guess it's live now.” That's not the best dev story, but I think you could do it that way. I know CloudFlare workers have this thing called Wrangler that you install locally. You spin it up and it spins up a fake browser on the top and then dev tools below. Then you can visit the URL and it somehow intercepts that and runs your local cloud function against it. Because one of the interesting things about workers is… you know how I described how it… you don't hit a URL and then it returns stuff. It just automatically runs when you… when it intercepts the URL, like CDN style.

Chris: So, one of the things it can do is manipulate the HTML on the way through. The worker, it has access to the complete HTML document. They have a jQuery-esque thing that's like, “Look for this selector. Get the content from it. Replace it with this content. And then continue the request.” So you can mess with code on the way through it. To test that locally, you're using their little Wrangler tool thing to do that. Also, I think the way we did it was… it's also a little dangerous. The second you put it live, it's affecting all your web traffic. It's kind of a big deal. You don't want to screw up a worker. You know? You can spin up a dev worker that's at a fake subdomain, and because it's CloudFlare, you can… CloudFlare can just make a subdomain anyway. Я не знаю. It's just kind of a nice way to do a… as you're only affecting sub-domain traffic, not your main traffic yet. But the subdomain's just a mirror of a production anyway, so that's kind of a… that's a testing story there.

Chris: It brings up an interesting thing, though, to me. It's like… imagine you have two websites. One of them is… for us it's like a Ruby on Rails app. Что бы ни. It's a thing. But we don't have a CMS for that. That's just like… it's not a CMS, really. I think there's probably Ruby CMSs, but there's not any renowned ones. You know? It seems like all the good CMSs are PHP, for some reason. So, you want a quality CMS. Drew, you've lived in the CMS market for a long time -

Drew: Absolutely.

Chris: … so you know how this goes. Let's say you want to manage your sites in Perch or whatever, because it's a good CMS and that's the proper thing to use to build the kind of pages you want to build. But you don't want to run them on the same server. Unless you want to manage the pages on one site, but show them on another site. Well, I don't know, there's any number of ways to do that. But one JavaScript way could be, “Okay, load the page. There's an empty div there. Run some JavaScript. Ask the other site for the content of that page and then plunk it out on the new page.” That's fine, I guess, but now you're in a client side rendered page. It's going to be slow. It's going to have bad SEO, because… Google will see it eventually, but it takes 10 days or something. It's just a bad story for SEO. It's not very resilient, because who knows what's going to happen in the network. It's not the greatest way to do this kind of “content elsewhere, content on site B, show page of site A”, situation.

Chris: You could also do it on the server side, though. Let's say you had… Ruby is capable of granting a network request too, but that's even scarier because then if something fails on the network, the whole page could die or something. It's like a nervous thing. I don't love doing that either. But we did this just recently with a worker, in that we… because the worker's JavaScript, it can make a fetch request. So, it fetches site A, it finds this div on the page, and then it goes and asks site B for the content. Gets the content. Plugs it into that div, and serves the page before it gets anything. So it looks like a server rendered page, but it wasn't. It all happened at the… on the edge, at the worker level, at the serverless level.

Chris: So it's kind of cool. I think you can imagine a fetch request on the browser probably takes, I don't know, a second and a half or something. It probably takes a minute to do it. But because these are… site B is hosted on some nice hosting and Cloudflare has some… who knows what kind of super computers they use to do it. They do. Those are just two servers talking to each other, and that fetch request happens just so super duper, duper fast. It's not limited to the internet connection speed of the user, so that little request takes like two milliseconds to get that data. So it's kind of this cool way to stitch together a site from multiple sources and have it feel like, and behave like, a server rendered page. I think there's a cool future to that.

Drew: Are there any sort of conventions that are sort of springing up around serverless stuff. I'm sort of thinking about how to architect things. Say I've got something where I want to do two sort of requests to different APIs. I want to take in a postal address and geocode it against one, and then take those coordinates and send that to a florist who's going to flower bomb my front yard or something. How would you build that? Would you do two separate things? Or would you turn that into one function and just make the request once from the browser?

Chris: Mm (affirmative). That's a fascinating question. I'd probably have an architect function or something. One function would be the one that's in charge of orchestrating the rest of them. It doesn't have to be, your website is the hub and it only communicates to this array of single sources. Serverless functions can talk to other serverless functions. So I think that's somewhat common to have kind of an orchestrator function that makes the different calls and stitches them together, and returns them as one. I think that is probably smart and faster, because you want servers talking to servers, not the client talking to a whole bunch of servers. If it can make one request and get everything that it needs, I think that's probably generally a good idea-

Drew: Yeah, that sounds smart. Ага.

Chris: But I think that's the ultimate thing. You get a bunch of server nerds talking, they'll talk about the different approaches to that exact idea in 10 different ways.

Дрю: Ага. No, that sounds pretty smart. I mean, you mentioned as well that this approach is ideal if you're using APIs where you've got secret information. You've got API keys or something that you don't want to live in the client. Because I don't know, maybe this florist API charges you $100 dollars every time flower bomb someone.

Chris: Easily.

Drew: You can basically use those functions to almost proxy the request and add in the secret information as it goes, and keep it secret. That's a viable way to work?

Chris: Yeah, yeah. I think so. I mean, secrets are, I don't know, they're interesting. They're a form of buy in I think to whatever provider you go with, because… I think largely because of source control. It's kind of like, you could just put your API key right in the serverless function, because it's just going to a server, right? You don't even have to abstract it, really. The client will never see that code that executes, but in order for it to get there, there's probably a source control along the way. It's probably like you commit to master, and then master… then some kind of deployment happens that makes that thing go to the serverless function. Then you can't put your API key in there, because then it's in the repo, and you don't put your API keys in repos. That's good advice. Now there's stuff. We've just done… at CodePen recently, we started using this git-crypt thing, which is an interesting way to put keys safely into your repos, because it's encrypted by the time anybody's looking at that file.

Chris: But only locally they're decrypted, so they're useful. So it's just kind of an interesting idea. I don't know if that helps in this case, but usually, cloud providers of these things have a web interface that's, “Put your API keys here, and we'll make them available at runtime of that function.” Then it kind of locks… it doesn't lock you in forever but it kind of is… it's not as easy to move, because all your keys are… you put in some input field and some admin interface somewhere.

Drew: Yeah, I think that's the way that Netlify manage it.

Chris: They all do, you know?

Дрю: Ага. You have the secret environment variables that you can set from the web interface. That seems to work quite nicely.

Chris: Yeah, right. But then you got to leave… I don't know, it's not that big of a deal. I'm not saying they're doing anything nefarious or anything. How do you deal with those secrets? Well, it's a hard problem. So they kind of booted it to, I don't know, “Just put them in this input field and we'll take care of it for you, don't worry about it.”

Drew: Is there anything that you've seen that stands out as an obvious case for things that you can do with serverless, that you just couldn't do with a traditional kind of serverfull approach? Or is it just taking that code and sort of almost deploying it in a different way?

Chris: It's probably mostly that. I don't know that it unlocks any possibility that you just absolutely couldn't run it any other way. Yeah, I think that's a fair answer, but it does kind of commoditize it in an interesting way. Like, if somebody writes a really nice serverless function… I don't know that this exists quite yet, but there could kind of a marketplace, almost, for these functions. Like, I want a really good serverless function that can take a screenshot. That could be an open source project that lots of eyeballs around, that does a tremendously good job of doing it and solves all these weird edge cases. That's the one I want to use. I think that's kind of cool. You know? That you can kind of benefit from other people's experience in that way. I think that will happen more and more.

Drew: I guess it's the benefit that we talked about, right at the top, of enabling people who write JavaScript and may have written JavaScript only for the front-end, to expand and use those skills on the back-end as well.

Крис: Да, да. Я так думаю, я думаю, что… потому что бывают такие моменты, как… вам не нужно быть чрезвычайно опытным, чтобы знать, что подходит, а что нет для веб-сайта. Например, на прошлой неделе я сделал небольшое руководство, где был этот глюк, использующий это… когда вы сохраняете глюк, они дают вам слаг для вашей вещи, которую вы построили, это: «Виски, танго, фокстрот. 1000». Это как умная штучка. Шансы на то, что он уникальный, очень высоки, потому что я думаю, что они даже добавляют к нему номер или что-то в этом роде. Но в конечном итоге они превращаются в эти забавные мелочи. Они открывают исходный код своей библиотеки, в которой есть все эти слова, но там сотни, тысячи слов. Файл огромен. Тебе известно? Это мегабайты просто словаря слов. Вероятно, в первый год разработки вы узнали: «Не отправляйте файл JavaScript, который занимает мегабайты словаря». Это не хорошо для отправки. Тебе известно? Но Ноде все равно. Вы можете отправить сотни из них. Скорость сервера не имеет значения.

Дрю: Ага.

Крис: На сервере это не имеет значения. Так что я мог бы сказать: «Хм, тогда я просто сделаю это в Node». У меня будет утверждение, в котором говорится: «Слова равны, требуются слова» или что-то еще, и примечание вверху: «Пусть оно рандомизирует число. Вытащите его из массива и верните». Итак, эта бессерверная функция представляет собой восемь строк кода с packaged@JSON, который извлекает эту библиотеку с открытым исходным кодом. И затем мой интерфейсный код, есть URL-адрес бессерверной функции. Он попадает на этот URL. URL-адрес возвращает одно слово, группу слов или что-то еще. Вы создаете для него свой собственный небольшой API. И теперь у меня есть действительно хорошая, эффективная вещь. Что было приятно в этом, так это то, что это так просто. Я не беспокоюсь о его безопасности. Я не… понимаешь?

Крис: Просто… я думаю, очень средний или начинающий разработчик JavaScript может справиться с этим, и это круто. Это возможность, которой у них не было раньше. Раньше они говорили: «Ну, вот массив слов размером 2 МБ». «О, я не могу отправить это клиенту». — О, тогда ты просто заткнешься. Вы можете столкнуться с этой стеной и сказать: «Тогда я просто не могу сделать эту часть. Мне нужно попросить кого-нибудь еще помочь мне с этим, или просто не делать этого, или выбрать более скучных слизняков, или что-то в этом роде…» Просто вам нужно идти каким-то другим путем, который является стеной для вас, потому что вы не можете этого сделать. И теперь вы говорите: «О, хорошо, я просто…» Вместо того, чтобы помещать это в косую черту моего сценария или в исходную папку скриптов косой черты, я поместил бы это в свою папку функций.

Крис: Вы вроде как переместили сценарий из одной папки в другую. И вместо этого он развертывается как бессерверная функция. Как это круто? Тебе известно? Вы используете почти тот же самый набор навыков. В нем все еще есть некоторые шероховатости, но это довольно близко.

Дрю: Это супер круто. Вы создали что-то вроде маленького микросайта, посвященного этим идеям, не так ли?

Крис: Да. Я немного раньше начала игру. Я как раз работал над этим сегодня, потому что… он получает пулл-реквесты. Идея… ну, она на serverless.css-tricks.com и… кстати, в CSS-Tricks есть тире. Итак, это поддомен CSS-Tricks, и я тоже создал его без сервера, так что это… CSS-Tricks похож на сайт WordPress, но это сайт-генератор статических сайтов. Весь его контент находится в репозитории GitHub с открытым исходным кодом. Так что, если вы хотите изменить содержимое сайта, вы можете просто отправить запрос на опрос, что приятно, потому что со временем их было около сотни. Но я построил весь оригинальный контент.

Дрю: Это очень полезное место, потому что здесь перечислены… Если вы думаете: «Хорошо, я хочу начать работу с бессерверными функциями», здесь перечислены все провайдеры, которых вы могли бы попробовать, и…

Крис: В основном это списки технологий. Да.

Дрю: И это здорово, потому что в противном случае вы просто ищете что-то в Google и не знаете, что находите. Да, это списки провайдеров API, которые помогают вам делать подобные вещи.

Крис: Forms — один из примеров этого, потому что… итак, в ту минуту, когда вы решите… скажем, вы пойдете в JAMstack, что, я знаю, не обязательно в этом смысл, но вы видите, как они рука об руку . Внезапно у вас нет PHP-файла или чего-то еще для обработки этой формы. Как вы делаете формы на сайте JAMstack? Ну, есть множество способов сделать это. Очевидно, все и их сестры хотят помочь тебе решить эту проблему. Поэтому я думаю, что если бы я был изобретателем слова JAMstack, то они пытались бы помочь вам естественно, но вам не нужно их использовать.

Крис: На самом деле, я был очень удивлен, создавая этот сайт. Давайте посмотрим. Есть шесть, девять, двенадцать, пятнадцать, восемнадцать, двадцать один, двадцать два сервиса, которые хотят помочь вам безсерверно обрабатывать ваши формы на этом сайте прямо сейчас. Если вы хотите быть 23-м, добро пожаловать, но у вас есть конкуренты. Итак, идея заключается в том, что вы пишете форму в HTML, буквально как элемент формы. А затем атрибут действия формы, он не может никуда указывать внутри, потому что не на что указывать. Вы не можете обработать, поэтому он указывает снаружи. Он указывает на то, на что они хотят, чтобы вы указали. Они обработают форму, а затем, как правило, сделают то, что вы от них ожидаете, например отправят уведомление по электронной почте. Или отправьте Slack. Или затем отправьте его в Zapier, а Zapier отправит его куда-нибудь еще. Все они имеют немного разные наборы функций, цены и прочее, но все они пытаются решить эту проблему за вас, например: «Вы не хотите обрабатывать свои собственные формы? Без проблем. Мы обработаем его для вас».

Дрю: Да, это очень полезный ресурс. Я действительно рекомендую всем проверить это. Это serverless.css-tricks.com. Итак, я узнал все о бессерверных технологиях. Что ты узнал в последнее время, Крис?

Крис: Ну, я тоже все еще в этом мире и изучаю бессерверные штуки. У меня была идея… Когда-то давно я играл в эту ролевую онлайн-игру. Я только недавно обнаружил, что он все еще жив. Это текстовая средневековая фэнтезийная игра. Я играл в нее, когда AOL был популярен, потому что AOL хотела иметь эти игры, в которые нужно было войти, чтобы играть в них, потому что они хотели, чтобы вы проводили часы и часы в AOL, чтобы они могли присылать вам эти огромные счета, что было , я уверен, почему они так хорошо в какой-то момент.

Дрю: Итак, выставление счетов по секундам. Да.

Крис: Да. Так что игры были для них большими. Если бы они могли заставить вас играть в игры с другими людьми там. Итак, эта игра как бы… она не дебютировала там, но она перешла на AOL, потому что я уверен, что они заключили за нее выгодную сделку, но это было так… Я имею в виду, что это просто не могло быть более занудным. Вы дварфский маг, и вы получаете рунический посох из кожаных ножен. И вы вводите в него команды, как в терминал. Тогда игра ответит вам. Я очень долго играл в эту игру. Я был очень в этом. Я проникся этим сообществом и его духом. Это было как бы… как будто я был один за своим компьютером, но все же я оглядываюсь назад на то время в своей жизни и думаю: «Это было прекрасное время в моей жизни». Я был действительно… Мне просто нравились люди, игра и все такое. Но потом я вырос и перестал в нее играть, потому что жизнь случается с тобой.

Крис: Я узнал об этом только недавно, потому что кто-то снова начал делать об этом подкаст… Не знаю, как я наткнулся на это, но я просто наткнулся. Я подумал: «Эта игра жива и процветает в современном мире, ты что, шутишь? Эта текстовая штука». И я был более чем счастлив повторно активировать, вернуть своих старых персонажей и сыграть в них. Но только чтобы узнать, что клиенты, которые они вам загружают для этой игры, совсем не эволюционировали. Они ужасны. Они почти предполагают, что вы используете Windows. Есть только эти ужасно дрянные плохие рендеринг… и он основан на тексте, вы думаете, что у него, по крайней мере, была бы хорошая типографика. Нет. Я такой: «Я мог бы участвовать. Я мог бы написать клиент для этой игры. Поместите в него красивую типографику». Просто модернизируйте эту вещь, и я думаю, что игроки оценили бы это, но мне это казалось ошеломляющим. "Как мне это сделать?" Но я нахожу несколько проектов с открытым исходным кодом. Один из них похож на… вы можете играть в игру через реальное окно терминала, и он использует некоторые библиотеки с открытым исходным кодом, чтобы сделать графический интерфейс из окна терминала.

Дрю: Правда?

Крис: Я не знаю. Так что это было круто. Я подумал: «Если они это написали, значит, там должен быть код, как подключиться к игре, запустить все это и все такое. Так что, по крайней мере, у меня есть стартовый код. Я пытался продвигать приложение: «Может быть, я сделаю это во Flutter или что-то в этом роде», чтобы конечный продукт работал на мобильных телефонах, и «Я мог бы действительно модернизировать эту вещь». Но потом я был ошеломлен. Я подумал: «Ах, это слишком много… Я не могу. Я занят." Но я нашел другого человека, у которого была та же идея, и он был намного дальше в этом, так что я мог просто внести свой вклад на уровне дизайна. Работать над этим было действительно весело, но я также многому научился, потому что мне редко приходится прыгать в проект, который является чужим детищем, и я лишь немного вношу свой вклад, а это совершенно другое. технологический выбор, чем я бы когда-либо выбрал.

Крис: Это приложение Electron. Они выбрали это, что тоже довольно круто, потому что это мои навыки работы в Интернете… так что я не узнаю ничего сверхъестественного, и это кроссплатформенно, и это здорово. Итак, я многое узнал об Электроне. Я думаю, это весело.

Дрю: Это увлекательно. Всегда удивительно, как небольшие побочные проекты и вещи, которые мы делаем для развлечения, в конечном итоге становятся местом, где мы иногда учимся больше всего. И приобретайте навыки, которые затем могут использоваться в нашей повседневной работе.

Крис: Только так я учусь. Меня втянули во что-то, что… Я подумал: «Они не…». Это визуализируется с помощью библиотеки JavaScript под названием Mithril, которая… не знаю, слышали ли вы когда-нибудь об этом, но это странно. Это не… это почти как писать React без JSX. Вы должны «создать элемент» и сделать все это… но предполагается, что он будет намного лучше, чем он… И это действительно имеет значение, потому что в этой текстовой игре текст просто летает. Существует множество манипуляций с данными, что-то вроде… вы могли бы подумать, что эта текстовая игра будет настолько простой для запуска в окне браузера, но на самом деле это не так. Происходит так много манипуляций с данными, что вы действительно должны быть очень... мы должны быть добросовестными в отношении скорости рендеринга. Тебе известно?

Дрю: Это увлекательно-

Крис: Довольно круто.

Дрю: Ага. Если вы, дорогой слушатель, хотели бы услышать больше от Криса, вы можете найти его в Твиттере, где он @chriscoyier. Конечно, CSS-Tricks можно найти на css-tricks.com, а CodePen — на codepen.io. Но больше всего я рекомендую вам подписаться на подкаст ShopTalk Show, если вы еще этого не сделали, на сайте shoptalkshow.com. Спасибо, что присоединился к нам сегодня, Крис. У тебя есть напутствие?

Крис: Smashingpodcast.com. Я надеюсь, что это настоящий URL.