1. Наш стек до 2016 года: Django и Wordpress
2. Как выглядел наш сайт в 2012 году.
3. Недостатки
4. Мечта разработчика: стать статичным
5. Требования к новому сайту
6. URL
7. Разделы и содержание
8. Блог
9. Выбор генератора статического сайта
10. Оценка Джекилла
11. Пробовать Хьюго
12. Заключение

Мы недавно объявленный редизайн нашего сайта и блога. Пока что это был большой успех . Сайт работает намного быстрее, SEO лучше, чем когда-либо (о чем свидетельствует рост органического трафика), количество отказов пользователей сократилось, количество посещенных страниц возросло, как и продолжительность сеансов. Ура! :-)

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

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

• Что у нас было раньше?
• Почему мы перешли на статичный сайт?
• Почему мы выбрали Хьюго в качестве генератора нашего сайта?
• Что мы узнали о Хьюго в процессе? Как все было сделано, несколько советов и, возможно, несколько хаков.
• Как мы использовали Hugo вместе с Webpack для объединения наших активов?
• Как мы мигрировали и не потеряли SEO? URL изменились, как мы справились с перенаправлениями?
• Как это развернуто?
• Как мы автоматизировали развертывание, так что достаточно одного мастера git push origin?

Далее мы сосредоточимся на первых 3 вопросах.

Наш стек до 2016 года: Django и Wordpress

Исторически мы были пользователями Джанго рамки для разработки веб-приложений. В целом, нам это очень нравится, новичкам легко учиться, они поставляются с батареями и обеспечивают быстрый цикл разработки. В последние пару лет постоянное развитие сообщества Javascript подтолкнуло Джанго к бэкэнду (спасибо, React.js и другие!). Однако тот факт, что шаблоны Django больше не используются широко для сложных веб-приложений, не означает, что инфраструктура утратила свою полезность. Для небольших приложений с ограниченной интерактивностью во внешнем интерфейсе шаблоны могут иметь смысл.

Каждая итерация нашего сайта была построена с использованием Django и его серверных шаблонов. У нас были модели для большей части контента (например, члены команды, клиенты, отзывы и т. Д.), Поэтому его можно редактировать через интерфейс администратора Django.

Как выглядел наш сайт в 2012 году.

Наш стек был:

• Gunicorn в качестве сервера WSGI.
• Nginx перед Gunicorn, и для обслуживания статических активов.
• лакировка как кеш перед nginx. Не то чтобы это было строго необходимо, но мы хотели быть готовы к тому, что мы сделаем новость и получим много одновременных посетителей (она была организована в небольшом Amazon EC2 пример!).
• PostgreSQL в качестве нашей базы данных выбора.

Наш первый блог был построен с использованием приложения Django под названием цинния , Он сделал то, что должен был, но потребовал от нас времени на разработку, чтобы сделать что-нибудь. Для второй итерации нашего блога (в 2014 году) мы переключились на Wordpress так как это было намного лучше поддержано сообществом и имело плагины, доступные почти для всего.

Недостатки

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

Есть поговорка, что сын сапожника всегда ходит босиком . Мы сотни раз настраивали серверы, настраивали автоматические CloudWatch , Datadog , Pingdom и множество других. Если вы серьезно относитесь к приложению / сайту, они просто необходимы.

Дело в том:

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

У нас в основном статический контент; на самом деле мы не интерактивное приложение, так в чем же реальное преимущество использования Django для бэкэнда?

Мечта разработчика: стать статичным

Я мог бы представить себе сценарий, в котором наш сайт представляет собой просто набор файлов .html в папке где-то, как в старые добрые времена . Можем ли мы создать 100% статичный сайт?

Генераторы статических сайтов не новы. Джекил является самым популярным, будучи де-факто генератором в GitHub Pages оказание услуг. Есть многие другие , написано на нескольких языках.

Идея действительно понравилась всем разработчикам в команде. Уметь писать в Markdown, коммитить на git (вы получаете контроль версий бесплатно!) И иметь некоторую систему, которая автоматически развертывается, когда материал перемещается в определенную ветку. Можем ли мы убедить несколько нетехников, что у нас есть, что это был путь? ;)

Требования к новому сайту

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

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

URL

Сайт должен быть размещен под https://tryolabs.com и блог в https://tryolabs.com/blog/ ,

На нашем предыдущем сайте URL блога был http://blog.tryolabs.com , Использование того же домена вместо поддомен блога (возможно) лучше для SEO.

Мы хотим иметь красивые URL и ничего «противного», оканчивающегося на .html.

Разделы и содержание

На главном веб-сайте должны быть такие разделы, как « Наша работа» , « Команда» , « Что мы делаем» и т. Д. Ничего страшного, но для создания сайта мы должны помнить, что некоторые разделы на сайте содержат ссылку на блог:

• Из нашего блога на главной странице показаны последние 2 поста блога.
• Информация о каждом члене команды на странице команды показывает последнее сообщение в блоге, созданное участником группы.

Блог

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

• Сообщения имеют одну категорию и могут иметь несколько тегов .
• У нас есть страницы для перечисления всех сообщений с определенным тегом или категорией.
  • Каждая из этих страниц разбита на страницы , как домашняя страница блога.
• На сообщения назначен автор .
  • У каждого автора есть своя страница с картинкой и мини биографией.
  • Каждая из этих страниц имеет список постов указанного автора, разбитых на страницы .
• Блог должен иметь возможности поиска .
• Каждый URL блога вложен в префикс / blog. Например:
  • / Блог / категория / машина обучения /
  • / Блог / теги / сайт /
  • / Блог / авторы / АЛАН-descoins / страница / 2 /
  • и т.п.
• URL-адрес постов в блоге должен выглядеть примерно так: / blog / YYYY / MM / dd / post-slug /. Если возможно, мы хотели бы сохранить формат URL-адреса сайта Wordpress.

Выбор генератора статического сайта

Посмотрев несколько статически сгенерированных блогов (например, каждый сайт на страницах GitHub), мы поняли, что многое уже можно сделать. В чем мы не были уверены, так это в следующих требованиях:

1. Теги и категории для сообщений.
2. Категории и теги страниц. Нумерация страниц
3. Авторские страницы с мини био и списком постов. Нумерация страниц
4. Функциональность поиска

Пришло время немного покопаться в том, как мы справимся с этим.

Оценка Джекилла

Из-за его большой экосистемы, Джекил это то, где мы начали искать.

Мы искали сайты, созданные с помощью Jekyll, чтобы увидеть, сможем ли мы найти что-то достаточно похожее на то, что мы собирались построить. Судя по нашим выводам, нумерация страниц была самой большой проблемой. В частности, нумерация страниц по авторам / тегам / категориям. С Джекиллом ты может делать теги и категории но это были страницы, которые перечислили их все, а не отдельные страницы для тегов / категорий с поддержкой нумерации страниц.

Мы были рады узнать, что Блог StackExchange является Открытый исходный код и построен с Джекилом, поэтому мы посмотрели здесь. Это дало понять, что Джекилл может сделать несколько довольно сложных сайтов; и это казалось очень близко к тому, что нам было нужно. Он имеет тег и авторские страницы с нумерацией страниц! Как они это сделали? С +400 строк кода Ruby пользовательский плагин плагин они построили. Нам не понравилось, что модифицировать этот плагин, чтобы адаптировать его к нашей реальности, было слишком много.

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

Пробовать Хьюго

Когда я впервые узнал о Хьюго Я был впечатлен и надеялся, что когда-нибудь найду оправдание, чтобы попробовать это. Мы говорим о статическом генераторе, который поставляется как один исполняемый файл (встроенный в Go), который не требует времени выполнения и никаких плагинов - в отличие от Jekyll, который зависит от экосистемы Ruby. Кроссплатформенный, быстрый (~ 1 мс времени сборки на страницу), с живой перезагрузкой для легкой разработки. Надеемся, что функции находятся на одном уровне с этим.

Мы решили, что должны дать Хьюго попробовать (каламбур).

Первое, что мы заметили, было то, что, в отличие от Джекилла, Хьюго имеет нативную поддержку понятия таксономиями , Эти таксономии дают нам возможность классифицировать контент так, как нам нравится. Например, мы можем добавить таксономию для ряда связанных постов.

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

Для требования 3 нам нужно было хранить страницы авторов с аватаркой, небольшой биографией и некоторыми другими данными. Читая документацию, выглядело, как будто Дата файлы где мы можем иметь каждого автора в виде файла TOML. Есть даже Выпуск GitHub откройте с Hugo 0.16, чтобы стандартизировать это, поэтому мы должны получить еще лучшую поддержку в будущем. Хорошо, требование 3 было официально убито.

Перед фактическим запуском реализации осталась только одна вещь: как мы справляемся с функциями поиска на статических сайтах? Мы обнаружили, что было два варианта:

1. Воспользуйтесь услугами какого-либо поставщика услуг поиска. Наиболее распространенными являются Algolia а также Google Custom Search ,
2. Реализуем нашу собственную индексацию и поиск с использованием клиентской библиотеки полнотекстового поиска, такой как lunr или же elasticlunr ,

Мы бы оставили этот выбор на потом; на этом этапе нам нужно было только знать, возможно ли это. Ответ был да: требование 4 больше не было проблемой.

Заключение

Оглядываясь назад, решение использовать Хьюго оказалось очень успешным. Весь сайт создается менее чем за 400 мс , и каждый разработчик в офисе может правильно установить Hugo в течение нескольких секунд для локальной разработки.

Спасибо тебе spf13 и все люди, которые построили Гюго , Вы создали удивительный инструмент!

В следующем посте мы углубимся в то, как на самом деле создается сайт, и как мы решили некоторые возникшие проблемы. Мы представим современный рабочий процесс для статического сайта, используя Hugo и Webpack . Если вы не хотите пропустить это, убедитесь, что вы Подписывайтесь на нашу новостную рассылку ,

Похожие

Комментарии