Стварэнне нашага сайта: ад Django і Wordpress да статычнага генератара (частка I)

1. Наш стэк да 2016 года: Django і Wordpress
2. Як наш сайт паглядзеў яшчэ ў 2012 годзе.
3. Недахопы
4. Мара распрацоўшчыка: ідзі статычны
5. Патрабаванні да новага сайта
6. URL
7. Раздзелы і змест
8. Блог
9. Выбар статычнага генератара сайта
10. Ацэнка Jekyll
11. Паспрабуйце Х'юга
12. Выснова

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

Аднак змены былі значна больш глыбокімі, чым проста візуальная рэканструкцыя. Мы вырашылі перагледзець стэк, які працуе на сайце больш за 6 гадоў. Гэта была добрая магчымасць стварыць сайт, які мы заўсёды хацелі, і вучыцца ў гэтым працэсе.

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

• Што ў нас было раней?
• Чаму мы перайшлі на статычны сайт?
• Чаму мы выбралі Уга ў якасці генератара сайта?
• Што мы даведаліся пра Х'юга ў працэсе? Як усё было зроблена, парады і, магчыма, некалькі хакі.
• Як мы выкарыстоўвалі Hugo разам з Webpack для нашага аб'яднання актываў?
• Як мы пераехалі і не гублялі SEO? URL змянілася, як мы справіліся з перанакіраваннямі?
• Як гэта разгорнута?
• Як мы аўтаматызавалі разгортванне, так што дастаткова майстар-адзінкі паходжання паходжанні?

Далей мы засяродзімся на першых трох пытаннях.

Наш стэк да 2016 года: Django і Wordpress

Гістарычна склалася, мы былі карыстальнікамі Джанго асновы для распрацоўкі вэб-прыкладанняў. Усё гэта нам вельмі падабаецца, для пачаткоўцаў лёгка вучыцца, пастаўляюцца з акумулятарамі і забяспечваюць хуткі цыкл распрацоўкі. У апошнія пару гадоў пастаяннае развіццё супольнасці Javascript падштурхнула Джанга да бэкдэна (дзякуй, React.js і іншыя!). Аднак той факт, што шаблоны Django больш шырока не выкарыстоўваюцца для складаных вэб-прыкладанняў, не азначае, што структура страціла карыснасць. Для малых прыкладанняў з абмежаванай інтэрактыўнасцю ў інтэрфейсе шаблоны ўсё яшчэ могуць мець сэнс.

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

Як наш сайт паглядзеў яшчэ ў 2012 годзе.

Наш стэк быў:

• Ганёкор як сервер WSGI.
• Nginx перад gunicorn, і служыць статычным актывам.
• Лак у якасці кэша перад nginx. Не падобна на тое, што гэта было строга неабходна, але мы хацелі быць гатовымі да таго, што мы зробім навіну і атрымалі шмат адначасовых наведвальнікаў (яна размяшчалася ў невялікім Amazon EC2 напрыклад!).
• PostgreSQL у якасці базы дадзеных нашага выбару.

Наш першы блог быў пабудаваны з дапамогай дадатку Django пад назвай Zinnia . Гэта рабіла тое, што меркавалася, але патрабавала ад нас інвеставаць час распрацоўшчыка, каб зрабіць усё, што заўгодна. На другую ітэрацыю нашага блога (у 2014 годзе) мы перайшлі на Wordpress паколькі ён быў значна лепш падтрымліваецца супольнасцю і меў даступныя ўбудовы для амаль усяго.

Недахопы

У нас быў гэты прабег на працягу некалькіх гадоў, але было некалькі рэчаў, якія ніколі не прымушаюць нас цалкам задаволены гэтым стэкам:

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

Справа ў тым, што

Мы хацелі пазбягаць сервераў наогул і не трэба наладжваць сігналы трывогі на што-небудзь, што датычыцца нашага сайта / блога.

У нас у асноўным статычны змест; мы не вельмі інтэрактыўнае прыкладанне, і ў чым заключаецца рэальная перавага выкарыстання Django для бэкенда?

Мара распрацоўшчыка: ідзі статычны

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

Статычныя генератары сайта не з'яўляюцца новымі. Джэкіл з'яўляецца самай папулярнай, будучы дэ-факта-генератарам у GitHub Старонкі сэрвіс. Ёсць шмат іншых , напісаны на некалькіх мовах.

Ідэя сапраўды спадабалася ўсім распрацоўнікам каманды. Будзьце ў стане пісаць у Markdown, здзейсніць git (вы атрымліваеце кантроль версіі бясплатна!) І маеце нейкую сістэму, якая аўтаматычна разгортваецца, калі рэчы перасоўваюцца ў пэўную галіну. Ці можам мы пераканаць нешматлікіх тэхналогій, што ў нас ёсць, што гэта шлях. ;)

Патрабаванні да новага сайта

Усё мела сэнс, таму прыйшоў час пачаць працаваць. Тым не менш, існуе такая асцярога, што ў разгар распрацоўкі новага сайта і блога мы даведаемся, што нейкая функцыя не падтрымліваецца альбо вельмі складана дасягнуць з дапамогай статычнага генератара сайта. Калі гэта адбудзецца, мы б у канчатковым выніку перайшлі наш код на іншы генератар (дадаўшы да нашага часу і выдаткі), альбо, з вялікай сумай, нам прыйдзецца перагледзець наша рашэнне стаць статычным.

Каб пазбегнуць няшчаснага сцэнара, разумным было зрабіць, каб запісаць патрабаванні да новага сайта і блога. Такім чынам, мы маглі загадзя выявіць патэнцыйна праблемы.

URL

Сайт павінен быць размешчаны пад https://tryolabs.com , і блог у https://tryolabs.com/blog/ .

На нашым папярэднім сайце быў адрас блога http://blog.tryolabs.com . Выкарыстоўваць той жа дамен, а не блог, паддомен (магчыма) лепш для SEO.

Мы хочам мець прыгожыя URL і нічога "непрыемнага", які заканчваецца ў .html.

Раздзелы і змест

На галоўным сайце павінны быць такія раздзелы, як " Наша праца , каманда" , " Што мы робім" і г. д. Няма вялікай справы, але для стварэння сайта мы павінны мець на ўвазе, што некаторыя часткі сайта спасылаюцца на блог:

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

Блог

Акрамя стандартнага стылю блога з галоўнай старонкай, у якім змяшчаюцца ўсе паведамленні ў храналагічным парадку і пазначэнні , у нас былі наступныя патрабаванні:

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

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

Убачыўшы некалькі статыстычных блогаў (напрыклад, кожны сайт на старонках GitHub), мы ведалі, што ўжо шмат можна зрабіць. Мы не былі так упэўнены ў тым, былі наступныя патрабаванні:

1. Тэгі і катэгорыі для паведамленняў.
2. Катэгорыі і пазнакі старонак. Paginated .
3. Аўтары старонак з міні-бія і спіс паведамленняў. Paginated .
4. Пошук функцыянальнасці.

Прыйшоў час крыху падумаць, як мы з гэтым справімся.

Ацэнка Jekyll

З-за вялікай экасістэмы, Джэкіл вось дзе мы пачалі шукаць.

Мы шукалі сайты, створаныя з Jekyll, каб убачыць, ці можна знайсці нешта падобнае да таго, што мы збіраемся будаваць. Зыходзячы з нашых вынікаў, размалёўка, здавалася, была самай вялікай праблемай. У прыватнасці, размяшчэнне па аўтарах / тэгу / катэгорыі. З Джэкіл ты можна рабіць тэгі і катэгорыі але гэта былі старонкі, якія пералічвалі іх усе, а не асобныя старонкі для тэгаў / катэгорый з падтрымкай размяшчэння.

Мы былі рады даведацца, што гэта Блог StackExchange ёсць з адкрытым зыходным кодам і пабудаваны з Джэкілам, таму мы глядзелі тут. У ёй было ясна, што Джэкіл можа зняць некалькі даволі складаных сайтаў; і гэта здавалася вельмі блізкім да таго, што нам трэба. Ён мае старонкі тэгаў і аўтараў з раздражненнем! Як яны вырвалі яго? З +400 радкоў кода Ruby карыстацкі убудова яны пабудавалі. Нам гэта не спадабалася, мадыфікацыя гэтага плагіна, каб адаптаваць яго да нашай рэчаіснасці, была занадта шмат.

Падобна на тое, што Джэкіл не можа быць найлепшым. Можа быць, быў нейкі іншы статычны генератар з убудаванай падтрымкай?

Паспрабуйце Х'юга

Калі я ўпершыню даведаўся пра Уга , Я быў уражаны і спадзяваўся, што калі-небудзь знайду падставу паспрабаваць гэта. Гаворка ідзе пра статычным генератары, які пастаўляецца як адзіны выкананы файл (убудаваны ў Go), які не патрабуе часу выканання і ніякіх убудоў - у адрозненне ад Jekyll, які залежыць ад экасістэмы Ruby. Крос-платформавы, хуткі (~ 1 мс час зборкі на старонку), з перагрузкай у рэжыме рэальнага часу для лёгкага развіцця. Спадзяюся, асаблівасці супадаюць з гэтым.

Мы вырашылі, што нам трэба будзе адпраўляць Хьюга (каламбур).

Першае, што мы заўважылі, было тое, што, у адрозненне ад Джэкіла, Уга падтрымлівае паняцце таксанаміі . Гэтыя таксанаміі даюць нам магчымасць класіфікаваць змест, які нам падабаецца. Напрыклад, мы можам дадаць таксанамію для шэрагу адпаведных паведамленняў.

Таксанаміі па змаўчанні - гэта катэгорыі і тэгі , якія менавіта нам патрэбныя. Ці маглі б мы стварыць таксанамію для аўтараў, а таксама мець паведамленні, згрупаваныя па аўтарах? Аказваецца, трывіяльна рабіць. Пры наяўнасці правільных шаблонаў Hugo аўтаматычна стварае старонкі для ўтрымання ў кожнай таксанаміі, і яны будуць размяркоўвацца . Гэта забіла патрабаванні 1 і 2.

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

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

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

Мы пакінем гэты выбар для наступнага; на гэтым этапе нам трэба было толькі даведацца, ці магчыма гэта. Адказ быў так: патрабаванне 4 больш не было праблемай.

Выснова

Наадварот, рашэнне аб выкарыстанні Уга аказалася вельмі паспяховым. Увесь сайт пабудаваны ў памеры 400 мс , і кожны распрацоўшчык у офісе можа ўсталяваць Hugo належным чынам на працягу некалькіх секунд для мясцовага распрацоўкі.

Дзякуй spf13 і ўсё людзі, якія пабудавалі Уга . Вы стварылі дзіўны інструмент!

У наступным пасце мы разгледзім больш падрабязную інфармацыю пра тое, як сапраўды ствараецца сайт, і як мы вырашым некаторыя праблемы, якія ўзніклі. Мы прадстаўляем сучасны працоўны працэс для статычнага сайта, выкарыстоўваючы Hugo і Webpack . Калі вы не хочаце прапусціць яго, пераканайцеся, што вы падпішыцеся на нашу рассылку .