Технология, лежащая в основе чрезмерно продуманного сайта объявлений о вакансиях

Несколько месяцев назад мы с моим деловым партнером (dillonchanis) выпустили наш первый продукт под нашей зонтичной компанией Everlook.

У нас с ним более пяти лет профессионального опыта, но мы никогда раньше не выпускали собственный продукт. Я уверен, что многие из вас понимают. В прошлом мы потратили массу времени на создание недоработанных идей и наблюдение за тем, как они медленно собирают пыль в частных репозиториях на GitHub.

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

Мы решили хоть раз заняться каким-то проектом. Несколько месяцев назад мы наконец выпустили everlookjobs.com, и вот несколько интересных технологий, которые мы использовали, и некоторые извлеченные уроки, которые могут вас заинтриговать.

При создании продукта первое, что вам понадобится, это идея. Мы хотели создать что-то, что могло бы помочь нам в выпуске продуктов, поэтому мы остановились на уже проверенной концепции. Доска объявлений.

Причина, по которой мы выбрали доску объявлений, заключалась в том, что это относительно простой проект. Простые операции CRUD, манипуляции с базой данных, CRON / фоновые задачи и т. Д.

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

  • Процесс оплаты
  • Выделенный сервер (желательно что-то управляемое, чтобы не беспокоиться о масштабировании в будущем)
  • Аутентификация
  • Базы данных
  • Файловое хранилище
  • Хостинг
  • Cron / фоновые задачи
  • Аналитика
  • Кодовая база внешнего интерфейса с надежным SEO
  • CDN для быстрого обслуживания контента

После того, как мы определили основные концепции нашего приложения, мы решили, что было бы разумно написать несколько архитектурных диаграмм, в которых обозначена ответственность каждой службы. Вот они:

  1. Каждая служба должна была стать микросервисом.
  2. Наша кодовая база пользовательского интерфейса должна была дойти через REST до уровня фасада, который будет действовать как промежуточное ПО для аутентификации. Таким образом, мы не раскрываем наши микросервисы за кулисами.
  3. Сервис, который занимается исключительно платежами / информацией о клиентах.
  4. Служба, занимающаяся управлением файлами.
  5. Сервис, который обрабатывает функциональные возможности размещения вакансий.
  6. Сервис, который обрабатывает информацию о пользователях / компании.

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

Выбор языков:

Когда мы думали о том, какие технологии мы будем использовать для нашего кода, мы автоматически тяготели к использованию Node / JavaScript из-за нашего знакомства с языком.

Серверы:

Обсуждая, какие технологии мы будем использовать, мы знали, что нам нужно что-то, что можно масштабировать, но также не хотели хлопот, связанных с обслуживанием долго работающего сервера. Мы выбрали AWS Lambda из-за довольно дешевой модели ценообразования, простоты использования и языковой поддержки.

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

Если не обращать внимания на несколько странностей, связанных с Lambda, некоторые замечательные аспекты сервиса включают автоматическое масштабирование, модель оплаты за запрос, тот факт, что вы можете запускать лямбда-выражения для таких действий, как удаление файлов S3, интеграция DynamoDB, выполнение очереди, чтобы назвать немного.

Платежи:

Для обработки платежей мы решили использовать полосу, поскольку она очень проста в использовании, документация по API проста в использовании, и все мы знаем, что индивидуальная совместимость с PCI - это проблема. Вся эта платежная логика изолирована от нашего микросервиса платежи.

Аутентификация:

Мы решили использовать Auth0 для всей нашей аутентификации пользователей. Как и в случае с обработкой платежей, управление пользователями может быть немного головной болью, поэтому мы решили использовать сторонний сервис вместо развертывания собственного решения. Это сэкономило нам время и избавило нас от необходимости настраивать регистрацию / вход в систему, сбрасывать пароль, проверять электронные письма, подключаться к социальным сетям и т. Д.

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

Базы данных:

Для наших хранилищ данных мы решили использовать DynamoDB. Это еще один сложный сервис, но он полностью управляем (масштабирование по запросу - это хорошо). В наших хранилищах данных не было ничего безумно реляционного, так что это идеально нам подходило. SDK AWS и пакет Dynamoose на NPM упрощают взаимодействие с этим сервисом. Вы просто определяете свои таблицы в стиле MongoDB и приступаете к чтению и записи.

Файловое хранилище:

Из-за нашей потребности в управлении логотипами и другими файлами мы остановились на AWS S3. Эта услуга очень дешевая, на ее основе построены надежные методы аутентификации, включая подписанные URL-адреса, а также с ней очень легко взаимодействовать через SDK. Мы используем это для хранения развернутого кода Lambda, кешированных файлов JavaScript для нашей CDN, а также дампа для наших полезных данных событий.

Запланированные задачи:

Для некоторых частей нашей функциональности требуются задачи, которые выполняются с интервалом (CRON), и правила AWS CloudWatch были идеальным решением. Это связано с тем, что вы можете создать простое выражение расписания и заставить его запускать лямбда-задачу как угодно часто. Наши варианты использования для этого включают прекращение поддержки списков по истечении определенного периода времени, подогрев наших лямбда-выражений для уменьшения задержки API и выполнение других заданий, связанных с аналитикой.

Регистрация и мониторинг:

Очевидно, что ведение журнала необходимо для отладки и мониторинга кода в средах. Использование журналов CloudWatch было для нас очевидным выбором. Вы просто создаете группу журналов, которая соответствует вашей лямбда-выражению, и все журналы отправляются туда в AWS. Также существуют отличные сторонние интеграции для мониторинга журналов (например, DataDog).

CDN:

Мы знали, что для быстрой доставки нашего контента нам нужен какой-то тип CDN. К счастью, у AWS есть отличный сервис CDN под названием CloudFront. Он находится перед нашими корзинами S3 (в которых хранится наш код пользовательского интерфейса) и доставляет кешированные версии нашим пользователям. Когда мы запускаем развертывание из CircleCI, мы запускаем аннулирование CloudFront для обновления этих кешей.

Библиотеки пользовательского интерфейса:

Поскольку и Диллон, и я знакомы с React, мы выбрали его в качестве библиотеки пользовательского интерфейса. SPA, как известно, плохо сказываются на производительности SEO, хотя это может улучшиться с более современными сканерами Google, поэтому мы решили использовать NextJS, чтобы получить лучшее из обоих миров. Вы можете подумать: Вы используете NextJS на долго работающем сервере? ну ответ - нет. Мы используем AWS Lambda для рендеринга наших страниц React на стороне сервера, что в итоге оказалось более эффективным, чем мы думали изначально.

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

  1. Пользователь попадает на желаемую страницу.
  2. Лямбда раскручивается, и SSR отображает запрашиваемую страницу (например, «/ job-detail»).
  3. CloudFront перехватывает + обслуживает кэшированный контент от S3.
  4. Та же лямбда, которая обслуживала вышеуказанный контент, остается теплой для последующих запросов и замедляется после замедления трафика.

Некоторые другие пакеты пользовательского интерфейса, которые мы используем, включают:

  1. Redux - Государственное управление
  2. Попутный ветер css - служебная библиотека CSS
  3. Формик - Для наших форм
  4. Lodash - утилиты JavaScript

Аналитика:

Аналитика - это то, над чем мы усердно работаем, чтобы предоставить нашим пользователям целевые списки и статистику листинга, и мы знали, что нам нужно вводить хронологические данные в базу данных для запроса и запуска фоновых процессов. AWS’s managed ElasticSearch был нашим выбором благодаря быстрому поиску и другим полезным плагинам аналитики.

Хостинг:

У нас есть домен everlookjobs.com для нашего рабочего URL (у нас также есть среды более низкого уровня, которые существуют на других доменах). Route53 и AWS cert-manager были отличным выбором для управления сертификатами и регистрации доменов. Все наши URL-адреса указывают непосредственно на наши дистрибутивы CloudFront. Мы также используем S3 для перенаправления www.everlookjobs.com - › https://everlookjobs.com .

CI/CD:

При развертывании кода в среде рекомендуется использовать какой-либо тип службы для автоматизации развертывания, который мы используем CircleCI. В основном это связано с их дешевой моделью ценообразования и удобным пользовательским интерфейсом.

Конфигурация инфраструктуры:

Все наши ресурсы AWS (базы данных, сегменты S3, Lambdas и т. Д.) Управляются с помощью AWS CloudFormation (конфигурация инфраструктуры) за капотом, который развертывается во время наших процессов CI / CD для каждого микросервиса.

Решив использовать «горячие» технологии, вы извлечете много уроков. Я расскажу о некоторых из них, которые мы испытали при создании вакансий Everlook.

  1. SSR (рендеринг на стороне сервера) с React выглядит странно после столь долгого написания SPA (одностраничных приложений). Такие вещи, как «локальное хранилище» и другие API-интерфейсы браузера, не существуют при передаче контента с сервера, что определенно может вас укусить, если вы не будете его искать. Об этом легко забыть, если вы привыкли писать код JavaScript на стороне клиента. Перед тем, как погрузиться в подробности, стоит прочитать всю документацию по NextJS. Это поможет избавить вас от разочарования.
  2. Написание и развертывание кода в AWS может быть проблемой, но есть несколько отличных библиотек с открытым исходным кодом, которые помогут с этим. Нашим выбором стала Serverless Framework. Проверить это!
  3. Бессерверный (^) - ваш лучший друг. Существует масса отличных плагинов и шаблонов, которые помогут вам быстро начать работу (вот наш).
  4. Холодный запуск Lambda раздражает и определенно может привести к проблемам с задержкой. Это связано с тем, что Docker используется за капотом. После того, как контейнер в течение некоторого времени бездействовал, лямбда считается «холодной», что означает, что базовому контейнеру Docker требуется некоторое время для раскрутки по запросу. Мы обошли это, «подогревая» наши лямбды или посылая их примерно каждую минуту, чтобы они не остыли.
  5. Некоторые сервисы AWS стоят дорого. В основном это связано с удобством и мощностью, которые эти сервисы предоставляют «из коробки». Обязательно отключите все ресурсы, которые вы не используете! Мы столкнулись с несколькими крупными счетами, когда забыли отключить тестовые базы данных и кластеры EKS (упс).
  6. DynamoDB - это что-то странное. Это распределенная база данных, поэтому управлять такими понятиями, как разбиение на страницы, горячие клавиши и индексирование, может быть непросто. Обязательно проведите исследование, прежде чем погрузиться в простоту этой услуги на поверхностном уровне. Кроме того, не забудьте также включить восстановление на определенный момент времени. Это может быть спасением при использовании DynamoDB.
  7. Управляйте своими ресурсами с помощью CloudFormation или другого языка конфигурации (Terraform тоже хорош), чтобы избежать ручного создания / обновления / уничтожения ресурсов в вашей среде.
  8. Библиотеки компонентов TailwindCSS + значительно экономят время.

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

Если вы думаете о каких-либо улучшениях или у вас есть вопросы, не стесняйтесь оставлять комментарии!

Кроме того, если вы не возражаете, ознакомьтесь с нашим приложением на everlookjobs.com. Мы стремимся предоставить нашим друзьям, ищущим работу, отличные впечатления, а также предоставить надежные инструменты и аналитику нашим партнерам, которые хотят нанять их. Мы также хотели бы продлить ограниченное по времени предложение с 50% скидкой на вакансии (наши цены со временем будут расти). Используйте код WELCOME2020 при оформлении заказа.

Если вы заметили что-то странное, обнаружили ошибку или хотели бы запросить какие-либо функции в будущем, напишите нам по адресу [email protected], и мы это исправим.

Спасибо,

- Ваши друзья из Everlook