За някои изисквания на проекта статичното генериране на страници не е само достатъчно , това е и най-много ефективно по отношение на скоростта и мащабируемостта.
В първата половина от тази поредица , комбинирахме Node.js , Express, MongoDB, cron и Heroku да достави CI-готов заден край, който консумира API на GitHub според ежедневния график. Сега сме готови да добавим Gatsby към микса, за да завършим нашия проект за генериране на статични страници.
Разработване на предния край: Направете го уебсайт на Gatsby
Защото уебсайтовете на Гетсби са базирани на Реагирайте , полезно е, ако вече сте запознати с това как да създадете уебсайт с React.
За стайлинг предпочитах Bootstrap, responsestrap и response-markdown. Може би знаете това бележките за изданието в GitHub се съхраняват във формат Markdown , оттук и нуждата ни от конвертор.
Статична структура на проекта на уебсайта
Нашата структура на файл / папка ще бъде както следва:
За какво са тези файлове? Да видим:
env.developmentиenv.productionса конфигурационни файлове с променлива среда.all-repositories.jsшаблонът ще бъде използван за нашата начална страница, съдържащ списък с хранилища.repository.jsшаблонът ще се използва за показване на подробности за дадено хранилище.gatsby-node.jsе мястото, където консумираме нашата крайна точка отзад и стартирамеcreatePageметоди.package.json, както винаги, съдържа зависимости и свойства на проекта.global.cssе нашият основен файл със стилове.
Внедряване на уебсайт Gatsby
Както при нашия заден край, изпълнете npm install (или yarn, ако имате инсталирана прежда) след добавяне на необходимите зависимости към предния край package.json:
{ // ... 'dependencies': { 'axios': '^0.18.0', 'bootstrap': '^4.3.1', 'gatsby': '^2.0.0', 'react': '^16.5.1', 'react-dom': '^16.5.1', 'react-markdown': '^4.0.6', 'reactstrap': '^7.1.0' } // ... } env.development и env.production файловете имат само back-end URL за съответните им среди. Първият има:
API_URL=http://localhost:3000 ... докато производството има:
API_URL=https://[YOUR_UNIQUE_APP_NAME].herokuapp.com gatsby-node.js ще се изпълнява само веднъж, докато изграждате кода си. Затова трябва да съберем цялата необходима информация от нашия край тук. След това отговорът ще се използва с нашите шаблони за генериране на подходящите статични страници.
В нашия случай, all-repositories.js се нуждае от всички хранилища и repository.js се нуждае от съответното хранилище за всяка итерация. Накрая можем да генерираме динамично пътеки на страници, като предаваме хранилището owner и name параметри като част от path поле:
const axios = require('axios'); require('dotenv').config({ path: `.env.${process.env.NODE_ENV}` }); const getRepositoryData = async () => { console.log(process.env.API_URL); return axios.get(`${process.env.API_URL}/repositories`); }; exports.createPages = async ({ actions: { createPage } }) => { let repositories = await getRepositoryData(); repositories = repositories.data; // Create a page that lists all repositories. createPage({ path: `/`, component: require.resolve('./src/templates/all-repositories.js'), context: { repositories } }); // Create a page for each repository. repositories.forEach(repository => { createPage({ path: `/repository/${repository.owner}/${repository.name}`, component: require.resolve('./src/templates/repository.js'), context: { repository } }); }); }; За all-repositories.js и repository.js, ако пропуснем стила, просто събираме данни от pageContext и го използваме, както използваме параметри в React.
В all-repositories.js ще използваме repositories поле на pageContext като този:
export default ({pageContext: {repositories}}) => ( // ... {/* Because the repositories parameter is a list, we are iterating over all items and using their fields */} {repositories.map(repository => (repository.tagName && // ... {`${repository.repositoryDescription}`} // ... ))} // ... ); Що се отнася до repository.js, вместо това ще използваме repository поле на pageContext:
export default ({pageContext: {repository}}) => ( {repository.tagName && // ...
{/* This the place where we will use Markdown-formatted release notes */} } // ... ); Сега се уверете, че задният ви край работи и работи. Ще си спомните за този проект, който го зададохме като http: // localhost: 3000 .
След това изпълнете gatsby develop от корена на вашия фронт-енд проект и отворете http: // localhost: 8000 .
Ако все пак сте добавили няколко хранилища (собственик / име) към вашия заден край и стартирате функцията update-via-GitHub-API поне веднъж, трябва да видите нещо подобно:
И след като щракнете върху едно от хранилищата, трябва да видите нещо подобно:
След нашите промени по-горе, нашето изпълнение отпред е готово .
Страхотен! Сега просто трябва да се разположим.
Разполагане на предния край
В тази част не е необходимо да правим промени в нашето външно приложение. Ние просто ще го разположим в Netlify - там ще ви трябва акаунт.
Но първо трябва да разположим нашия код в GitHub, GitLab или Bitbucket. Както при задния край, Разположих кода си в GitHub .
След това влезте в Netlify и кликнете върху бутона „Нов сайт от Git“ на таблото си за управление. Следвайте екранните стъпки, за да изберете вашия доставчик на Git и да намерите вашето хранилище.
За последната стъпка, ако сте структурирали правилно кода си, Netlify автоматично ще зададе командата за изграждане и ще публикува директно директорията, както следва:
След това кликнете върху „Разполагане на сайта“. Той ще разположи вашия сайт на произволно генериран поддомейн Netlify, но можете да го промените по всяко време - промених внедряването си на https://sample-create-page-api-gatsby.netlify.com , където можете да намерите демонстрация на живо на завършеното приложение.
Дотук добре. Но тъй като това е приложение за статични страници, трябва да го възстановяваме ежедневно, за да го поддържаме актуално.
Ежедневна актуализация с помощта на кука за изграждане
Изграждайте куки в Netlify, които работят като тригери за изграждане, така че можете да ги задействате от задния си край след завършване на заданието cron. За да направите това, първо създайте кука за компилация в Netlify.
В раздела „Изграждане и внедряване → Непрекъснато внедряване“ можете да намерите „Куки за изграждане“. Кликнете върху „Добавяне на кука за компилация“.
Дайте му име и го запазете. (Обадих се на моя build-from-backend.) След това копирайте връзката, която генерира.
Сега нека отворим нашия back-end проект и добавим тези няколко реда към cron.controller.js файл. Ние просто изпращаме POST заявка за URL адрес на компилация на Netlify.
const Axios = require('axios'); const Config = require('../config/env.config'); const NETLIFY_BUILD_HOOK_URI = Config.netlifyEndpoint; function updateGatsby() { if (NETLIFY_BUILD_HOOK_URI) { console.log('Gatsby build request will be send'); Axios.post(NETLIFY_BUILD_HOOK_URI).then(() => { console.log('Gatsby build request was successful'); }); } } След това актуализирайте нашите updateDaily функция:
function updateDaily() { RepositoryController.updateRepositories().then(() => { updateGatsby(); }); } И накрая, актуализирайте нашите env.config.js файл за задаване на netlifyEndpoint свойство, което се събира от променливи на околната среда:
'netlifyEndpoint': process.env.NETLIFY_BUILD_HOOK || '' Сега ще трябва да зададете NETLIFY_BUILD_HOOK среда, която сте копирали от Netlify преди малко. В Heroku, можете да зададете променливи на средата от раздела „настройки“ на вашето приложение .
След натискане на вашия ангажимент, back-end приложението ще изпрати заявка за изграждане до Netlify и вашите страници ще се актуализират ежедневно, в края на вашата cron работа. Ето как трябва да изглежда репото след добавяне на функционалността на куката за изграждане, заедно с окончателните версии на back-end репо и репото на предния край .
Като завършек на проекта ще покажем как да се използва AWS Ламбда функция, задействана от AWS CloudWatch, която ще събужда вашия гръб навреме за всяка дневна актуализация.
AWS Lambda и AWS CloudWatch проста заявка
AWS Ламбда е безсървърна изчислителна платформа. Ние се нуждаем само самите основи на тази платформа за нашите цели тук. Ще ви трябва акаунт в AWS.
Първо влезте в AWS с вашия акаунт и намерете конзолата за управление на Lambda. Например за us-east-2 може да се намери на https://us-east-2.console.aws.amazon.com/lambda/home .
Ако още не е избран, отидете в раздела „Функции“:
Тук ще създадем нашата функция от нулата, като щракнем върху „Създаване на функция“. Нека му дадем обяснително име. Ще използваме Node.js като език за изпълнение. След това щракнете върху следващата „Създаване на функция“, за да я финализирате.
Той ще ни пренасочи към страницата на новата функция, където можем да напишем кода си в index.js
Нека да приложим първата си ламбда функция. Тъй като нямаме зависимости на трети страни, трябва да използваме основните модули на Node.js. (Ако вместо това искате да активирате зависимости на трети страни, моля следвайте това ръководство от AWS .)
Уверете се, че името на експортирания метод (handler в този случай) съответства на параметъра “Handler” на страницата:
Останалото е просто GET заявка към вашия гръб:
const https = require('https'); exports.handler = async (event) => { return new Promise((resolve, reject) => { https.get(process.env.HEROKU_APP_URL, (resp) => { let data = ''; resp.on('data', (chunk) => { data += chunk; }); resp.on('end', () => { resolve(JSON.parse(data)); }); }).on('error', (err) => { reject('Error: ' + err.message); }); }); }; Уверете се, че сте задали HEROKU_APP_URL среда на страницата и запазете вашата конфигурация:
Последната стъпка е добавяне на правило за задействане на CloudWatch, за да стартира тази функция десет минути преди всяка дневна актуализация - в тази серия статии, която работи до 23:50:
Нашият тип правило за задействане на CloudWatch ще бъде „Израз на графика“ и, според приетия формат, нашият cron израз ще бъде cron(50 23 * * ? *)
информация за кредитна карта безплатно хакната
Вече конфигурирахме нашата функция AWS Lambda да се задейства от нашето правило CloudWatch.
Сега захранваме нашите статични уеб страници: Gatsby / React и Netlify
С тире на AWS Lambda / CloudWatch, добавено към нашия Node.js / MongoDB / Heroku отзад и Gatsby и Netlify, генериращи и хостващи нашия преден край, нашето приложение е завършено!
Споделих демонстрационна връзка на живо по-рано, но не се колебайте да разгледате подобрена версия на моя прототип —Има някои допълнителни промени, които знам, че ще ви харесат.
Можете да използвате това като план за подобни проекти - надявам се, че тези статии ще ви помогнат да прототипирате приложенията си по-бързо и по-рентабилно. Благодаря за четенето!
Разбиране на основите
Какво е Гетсби?
Gatsby.js (или просто „Gatsby“) е рамка за статично генериране на сайтове с отворен код, базирана на React.
Какво е Netlify?
Netlify е статичен хост на сайт, подобен на GitHub Pages, но с някои допълнителни функции.
Какво е статичен генератор на сайтове?
Статичният генератор на сайтове създава статичен уебсайт от шаблон, използвайки текущи данни. Полученият сайт е много бърз, но възможността да го генерира периодично означава, че той може автоматично да бъде актуален.
