sincerely-manny / lesta-ships

Каталог кораблей World of Warships

🛠️ Установка

npm install

Для запуска проекта необходимо создать файл .env в корне проекта и указать значение переменной GQL_API_URL.

Пример: GQL_API_URL=https://rickandmortyapi.com/graphql/ (обязательно с слешем в конце)

🚂 Запуск

npm start

🌎 Доступен по адресу:

https://lesta-ships.vercel.app

О проекте:

• Typescript ✒️
• Next.js ⚛️
• Apollo client 🛰️
• Tailwind CSS 💨
• Radix UI components 🧬

Ключевые решения:

• Общение приложения с эндпоинтом через GraphQL осуществляется на сервере. Плюсы: безопасность (позволяет не показывать клиентам эндпоинт), уменьшение клиентского бандла и снижение нагрузки на клиент. И это работает с текущими настройками CORS на сервере GraphQL. Минусы: снижает отзывчивость приложения.
• Перенос запросов к GraphQL на сервер позволил отдавать клиенту статичные серверные компоненты и воспользоваться преимуществами статической генерации и агрессивного кеширования на Vercel, что должно также снижать нагрузку на сам endpoint.
• Отказ от стейт-менеджеров: все состояние приложения хранится в query-параметрах, что позволяет упростить логику и обращаться к состоянию из любого компонента – как серверного, так и клиентского. Еще один плюс – состояние приожения можно сохранить/передать, скопировав ссылку из адресной строки.
• ТТХ и описание корабля подбираются отдельным запросом. Это позволило вписаться в 2Мб лимит кеша.

TODO aka "а вот если бы..."

Сейчас приложению не хватет: более понятной/наглядной логики сортировки и группировки кораблей, отдельной страницы корабля (вне списка) и функций сравнения/избранного/и пр. Направшивается более функциональный текстовый поиск (например, с подсказками ввода).

Неплохо было бы также облагородить шапку и подвал. Стоило бы провести ревизию ui-компонентов, приветсти и к единоообразию и общему стилю. Посмотрев свежим взглядом понял, что копоненты фильтров, сортировки и пагинации лучше вынести из компонента списка на верхний уровень.

🤔 О выбранном стеке

Данный стек был выбран, поскольку на нем можно было быстро собрать необходимый функционал. Те же headless-компоненты radix в обертке shadcn сильно экономят время при сборке ui. Является ли он оптимальным в более длительной перспективе? Возможно. Однако не исключено, что go на бекенде + htmx на фронте лучше подошли бы для реальзации данного функционала: go быстрее справлялся бы с разбором ответов от эндпоинта и генерацией статичных шаблонов, а htmx дал бы минимальный клиентский бандл, притом обеспечивая необходимый уровень интерактивности. Такой проект (go+htmx) занял бы больше времени в разработке (по крайней мере, у меня), однако скорее всего был бы проще в поддержке и развитии.