Создание SSR веб приложения на React и NodeJS с нуля до деплоя (статья 1)

Содержание

• Предисловие

• Идея сервиса

• Стек

• Архитектура приложения

• Заключение

Предисловие

Добрейшего времени суток %HABRUSER% и проходящим мимо, в первую очередь я очень рад что ты открыл эту статью, без шуток 🙂

Данная серия публикаций посвящена созданию сервиса runwith суть которого вы сможете почитать ниже. Это мой первый независимый проект, поэтому буду очень рад вашим комментариям и конструктивной критике касаемо стиля написания статьи и кода в целом, надеюсь тебе будет полезно и интересно, приятного чтения!

Идея сервиса

Было 2 мотивации для создания приложения. Спорим что почти каждый из нас когда то говорил себе:

Уже завтра начну заниматься спортом (С)

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

Мотивация #2 была технического характера, давно хотелось разобраться в SSR на ReactJS ( если быть точней в создании гибридного приложения SSR & SPA ).

Посидев немного в среде этих мотиваций родилась идея создания сервиса, в котором всяк сюда входящий найдет компаньона для бега в real-time.

Так как проект некоммерческий (а значит времени и средств на его реализацию не слишком много) решил что стоит начать с MVP и допиливать уже в продакшне функциональность.

На момент создания MVP приложение должно уметь

1. Находить напарника (или напарников до 10 участников) для бега в реальном времени (то есть здесь и сейчас).

2. Давать возможность для поиска напарника(ов) по выбранному району, а так же выбирать начальную и конечную точку забега.

3. Отображать список активных комнат.

4. Уметь хорошо проиндексировать себя в поисковике.

5. Делать серверный роутинг

6. Иметь 2 страницы (Главная и новости для ознакомления с тем, что поменялось на проекте для пользователя)

Стек

Так как я фронтенд реактус разрабус, стек будет соответствовать:

• ReactJS (Последних версий, будет писать на хуках)

  • Typescript (Да это увеличит время разработки из-за дополнительной разработки типов, но приложение может сильно расширяться, поэтому типизация нам пригодится во избежания 1 + «1» = 11 и других подобных приколов слабой типизации JS )

  • Sass (Был выбор между LESS и PCSS, PCSS собирается быстрей из-за того что плагины ставятся разработчиком и нет ничего лишнего, но sass как то родней как по мне скорость компиляции не столь критична на данных момент)

  • react-router-dom (Роутинг на клиенте)

• NodeJS (Наш сервер)

  • express (Для упрощения серверной разработки)

  • Socket.IO (Наше все, создание комнат, real-time поиск, отображение комнат на клиенте)

  • react-router (Роутинг на сервере)

• Webpack (Собственно собирает наш проект)

  • cross-env (Нам нужны будут системные переменные, для того чтобы определять как собирать проект для разработки или прода и другие)

  • nodemon (Перезапускает наш сервер при пересборке, чтобы ручками не делать каждый раз при каждом чихе)

Так же другие плагины которые есть в package.json нашего проекта. От статью к статье плагины могут добавляться | удаляться.

Архитектура приложения

Как ты знаешь React это JS библиотека для создания пользовательских интерфейсов и работает она по принципу SPA, то генерация нашей страницы происходит в браузере после получения JS бандла, тк нам нужна наилучшая индексация поисковыми роботами мы будем использовать рендеринг на стороне сервера (и да сейчас 2021 год и многие поисковые роботы уже умеют собирать контент в браузере, однако не все и JS бандл может быть тяжелый, что может повлиять на качество индексации)

Принцип работы SSR (гибридного) — Сервер собирает у себя на стороне React приложение и при запросе отдает в виде строки, при получении браузером происходит восстановление нод и обработчиков и вставка в DOM (если по умному гидратация, делать за нас это будет метод hydrate).

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

// Директория клиентской стороны приложения { client: {   src: {     components: "Директория для переиспользуемых компонентов",       layouts: `       Директория с какими то общими частями приложения,         пригодится когда вместо того, чтобы для каждой страницы приложения,         вставлять каждый раз компоненты Header, Footer и т.д         Мы просто вызовем нашу тему и передадим композицией наш контент         для данной страницы, типа следующего:         <LayoutDefault>         <div>Привет, я контент для страницы о нас</div>         </LayoutDefault>       `,       pages: {       MainPage: "Директория главной страницы",         NewsPage: "Директория страницы с новостями",         index.ts: `         Файл, в который импортируются все страницы приложения           для более удобного последующего использования где-либо,           через именованный импорт, содержимое файла следующее:           export {default as MainPage} from "./MainPage"         `       }     },     stylesCommon: {     app.css: "Общие стили нашего приложения"     },     App.tsx: `     Файл в котором лежит React приложение       и который будет собираться сервером     `,     index.tsx: `     Корневой файл в котором импортируется       вышеописанный App.tsx, в нем вызывается       метод hydrate, для которого необходимо указать       элемент в DOM в который будет отрендерено приложение,       поэтому этот файл для сборки с сервера нам не подойдет,       тк на сервере нет DOM     `   }, }

Не устал читать структуру клиентской стороны?) Я вот очень устал ее писать, однако давай перейдем к архитектуре сервера:

// Директория сервера {   server: {   index.tsx: "Тадааам, пока нам хватит"   } }

Теперь вебпак конфиги (именно конфиг(И), потому что мы должны собрать как клиент, так и сервер)

// Директория вебпак конфигов { webpackConfs: {   webpack.client.js: "Конфиг под сборку клиента",     webpack.server.js: "Конфиг под сборку сервера",     webpack.common.js: `     Тк мы собираем наше приложение на сервере,       конфиги должны быть максимально схожи,       поэтому более общие части вынесем сюда       и будем импортировать в клиентский и серверный конфиг     `   } }

Еще есть файлы корневой директории, такие как конфиг .TS, package.json, однако расскажу о них в следующей статье когда мы перейдем уже к более детальному процессу разработки.

Заключение и источники

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

Если у вас остались какие то вопросы или допустил какие то неточности или статью можно как то улучшить, пожалуйста пишите, буду рад почитать ваши комментарии 🙂