Створення нашого сайту: Від Django & Wordpress до статичного генератора (Частина I)

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

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

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

У цій публікації та наступних, ми поговоримо про процес, який ми пройшли, і спробуємо відповісти на деякі запитання:

• Що ми мали раніше?
• Чому ми перейшли на статичний сайт?
• Чому ми підбирали Гюго як генератора сайту?
• Які речі ми дізналися про Гюго? Як все було зроблено, деякі поради та, можливо, кілька хакі.
• Як ми використовували Гюго разом з Webpack для нашого комплектування активів?
• Як ми мігрували і не втрачали SEO? URL-адреси змінилися, як ми працювали з перенаправленнями?
• Як це розгортається?
• Як ми автоматизували розгортання, і достатньо одного майстра походження git push?

Нижче ми зупинимося на перших трьох питаннях.

Наш стек до 2016 року: Django і Wordpress

Історично ми були користувачами Django рамки для розробки веб-додатків. Нам подобається це в цілому, це легко для новачків дізнатися, поставляється з батареями включені і дозволяє швидкий цикл розробки. Протягом останніх двох років постійний розвиток спільноти Javascript підштовхнув Django до бекенда (дякую, React.js і інші!). Тим не менш, той факт, що шаблони Django більше не використовуються для складних веб-додатків, не означає, що фреймворк втратив свою корисність. Для невеликих додатків з обмеженою інтерактивністю в інтерфейсі шаблони можуть мати сенс.

Кожна ітерація нашого сайту була побудована за допомогою Django та його шаблонів на стороні сервера. У нас були моделі більшості вмісту (наприклад, члени команди, клієнти, відгуки тощо), тому їх можна було редагувати за допомогою інтерфейсу адміністратора Django.

Як виглядав наш сайт у 2012 році.

Наш стек був:

• Gunicorn як сервер WSGI.
• Nginx перед gunicorn, і для обслуговування статичних активів.
• Лак як caché перед nginx. Не так, як це було вкрай необхідно, але ми хотіли бути готовими у випадку, якщо ми зробимо новини і отримаємо багато одночасних відвідувачів (він розміщувався в невеликій кількості Amazon EC2 наприклад!).
• PostgreSQL як наша база даних вибору.

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

Недоліки

Ми працювали протягом декількох років, але було кілька речей, які ніколи не залишили нас цілком задоволеними цим стеком:

Є приказка, що син шевця завжди йде босоніж . Ми налаштували сервери сотні разів, налаштували автоматичні сигнали тривоги CloudWatch , Datadog , Пінгдом і багато інших. Коли ви серйозно ставитеся до програми / сайту, вони є обов'язковими.

Факт:

Ми хотіли уникнути взагалі серверів і не потрібно налаштовувати будь-які сигнали тривоги для будь-якого сайту, що стосується нашого веб-сайту / блогу.

Ми маємо в основному статичний зміст; ми насправді не є інтерактивним додатком, то в чому полягає реальна перевага використання Django для бекенда?

Мрія розробника: стати статичною

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

Статичні генератори сайтів не є новими. Jekyll є найпопулярнішим, будучи де-факто генератором в Сторінки GitHub обслуговування. Існує багато інших , написана кількома мовами.

Ідея дійсно звернулася до всіх розробників в команді. Уміти писати в Markdown, фіксуватися в git (ви отримуєте контроль версій безкоштовно!) І матимете систему, яка автоматично розгортається, коли речі відсуваються до певної гілки. Чи можемо ми переконати декілька нетехнологів, що ми маємо, що це шлях? ;)

Вимоги до нового сайту

Все було сенс, так що настав час почати працювати. Тим не менш, був такий страх, що в середині розробки нового сайту і блогу, ми дізнаємося, що деякі функції не підтримуються або дуже важко досягти за допомогою статичного генератора сайту нашого вибору. Якби це сталося, ми або завершили б міграцію нашого коду в інший генератор (додавши до нашого часу і витрат), або, з великою сумністю, нам доведеться переглянути наше рішення стати статичним.

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

URL

Сайт повинен розміщуватися під https://tryolabs.com і блог у https://tryolabs.com/blog/ .

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

Ми хочемо мати хороші URL-адреси і нічого «неприємного», що закінчується в .html.

Розділи та зміст

Головний веб-сайт повинен мати такі розділи, як « Наша робота» , « Команда» , « Що ми робимо» і т.д. Немає великого значення, але для створення сайту ми повинні мати на увазі, що деякі розділи на сайті посилаються на блог:

• З нашого блогу на головній сторінці відображаються останні 2 повідомлення в блозі.
• Інформація про кожного члена команди на сторінці команди показує останнє повідомлення в блозі, написане членом команди.

Блог

Окрім стандартного стилю блогу, на якому головна сторінка містить список всіх постів у хронологічному порядку та розбита на сторінки , ми мали такі вимоги:

• Повідомлення мають одну категорію і можуть мати декілька призначених для них тегів .
• У нас є сторінки для переліку всіх повідомлень з певним тегом або категорією.
  • Кожна з цих сторінок розбивається на сторінки, так само як і домашня сторінка блогу.
• Повідомленням призначений автор .
  • Кожен автор має свою сторінку з малюнком і міні біографією.
  • Кожна з цих сторінок має список повідомлень, зазначених автором, paginated .
• Блог повинен мати можливості пошуку .
• Кожна URL-адреса блогу вкладена в префікс / blog. Наприклад:
  • / blog / categories / машинне навчання /
  • / blog / tags / website /
  • / блог / автори / alan-descoins / сторінка / 2 /
  • і т.д.
• URL-адреса блогу повинна бути щось на зразок / blog / YYYY / MM / dd / post-slug /. Якщо це можливо, ми хотіли б зберегти формат URL-адрес сайту Wordpress.

Вибір статичного генератора сайту

Побачивши декілька статично створених блогів (наприклад, кожен сайт на сторінках GitHub), ми знали, що багато чого вже можна зробити. Те, про що ми не були впевнені, були такі вимоги:

1. Теги та категорії для публікацій.
2. Сторінки категорій і тегів. Позначені .
3. Авторські сторінки з міні біо і список повідомлень. Позначені .
4. Функція пошуку.

Це був час копати трохи у як ми би зробили з ними.

Оцінюючи Джекілл

Через велику екосистему, Jekyll де ми почали шукати.

Ми шукали сайти, створені з Джекіллом, щоб побачити, чи зможемо ми знайти щось подібне до того, що ми збираємося побудувати. З нашого висновку, нумерація сторінок була найбільшою проблемою. Зокрема, нумерування за автором / тегом / категорією. З Jekyll ви може робити теги та категорії але це були сторінки, які перерахували їх усі, а не окремі сторінки для тегів / категорій з підтримкою розбиття на сторінки.

Ми були раді дізнатися, що Блог StackExchange є відкрите джерело та побудований з Jekyll, таким чином ми подивилися тут. Це зрозуміло, що Джекілл може зняти деякі досить складні ділянки; і це здавалося дуже близьким до того, що нам було потрібно. Він має сторінки тегів і авторів з нумерацією сторінок! Як вони це зняли? З +400 рядків Ruby коду користувальницький модуль нумерації сторінок вони побудували. Нам не сподобалося, модифікація цього плагіна, щоб адаптувати його до нашої реальності, була занадто великою.

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

Випробовуючи Гюго

Коли я вперше дізнався про це Гюго , Я був вражений та сподіваюсь що одного дня я би знайшов привід пробувати це. Мова йде про статичний генератор, який поставляється як єдиний виконуваний файл (вбудований у Go), який не потребує часу виконання і відсутність плагінів - відмінності від Jekyll, який залежить від екосистеми Ruby. Крос-платформенний, швидкий (~ 1 мс час збірки на сторінку), з перезавантаженням у реальному часі для легкого розвитку. Сподіваюся, функції нарівні з цим.

Ми вирішили ми повинні були дати Hugo іду (каламбур).

Перше, що ми помітили, це те, що, на відміну від Jekyll, Hugo має рідну підтримку поняття таксономії . Ці таксономії дають нам можливість класифікувати вміст, як нам подобається. Наприклад, ми можемо додати таксономію для ряду пов’язаних повідомлень.

Стандартні таксономії - це категорії та теги , які нам потрібні. Чи можемо ми також створити таксономію для автора, а також посади, згруповані за автором? Виявляється, це тривіально. За наявності правильних шаблонів, Hugo автоматично створює сторінки для всього вмісту під кожною таксономією, і вони будуть розбиті на сторінки . Це вбило вимоги 1 і 2.

Для вимоги 3 нам потрібно було зберігати сторінки авторів із зображенням профілю, невеликою біографією та деякими іншими даними. Ознайомившись з документацією, вона виглядала як придатна файлів даних де ми можемо мати кожного автора як файл файлу. Є навіть a Проблема GitHub відкрити, як у Хуго 0.16, щоб стандартизувати це, тому ми повинні мати ще кращу підтримку в майбутньому. Добре, вимога 3 була офіційно убита.

Залишилося лише одне, перш ніж реально розпочати реалізацію: як ми працюємо з функцією пошуку в статичних сайтах? Ми знайшли два варіанти:

1. Використовуйте постачальника послуг пошуку. Найбільш поширеними є Алголія і Користувацький пошук Google .
2. Реалізуйте власну індексацію та пошук за допомогою бібліотеки повнотекстового пошуку на стороні клієнта, наприклад lunr або elasticlunr .

Ми залишимо цей вибір пізніше; на цьому етапі нам треба було тільки знати, чи це можливо. Відповідь була так: вимога 4 вже не була проблемою.

Висновок

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

Дякуємо spf13 і все люди, які побудували Юго . Ви створили дивовижний інструмент!

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