От автора: общие мысли, проблемы и результаты: миграция технического стека Peerlist с ReactJS на NextJS.
Эта статья охватывает большую часть наших мыслей, связанных с решением и процессом миграции, и, возможно, не будет углубляться в технологии, но, в конце концов, ее стоит прочитать!
React — одна из самых популярных библиотек JavaScript, которая в наши дни широко используется во многих приложениях, а NextJS — это фреймворк, построенный на ReactJS . Вы не поймете истинную силу Next, пока не начнете его использовать, я говорю это по своему собственному опыту!
Я работаю с React уже более 3 лет, и мне всегда нравилось, как он работает. Поэтому, когда мы начали создавать Peerlist с нуля, React был моим очевидным выбором. Из-за выбора MVP мы подумали о том, чтобы использовать наши сильные стороны (конечно, React для внешнего интерфейса) и создать первый рабочий прототип на ReactJS.
Сначала это сработало, мы смогли выполнить заказ в установленные сроки, и все работало гладко. Хотя вскоре мы поняли, что решение перейти на простой React оказалось для нас не таким уж хорошим. Мы знали, что этот технологический стек не будет масштабироваться в соответствии с дорожной картой нашего продукта.
Почему?
Все технологии и фреймворки потрясающие, но они созданы для разных вариантов использования. Поэтому, когда я говорила, что простой React нам не подходит, я имела в виду следующие варианты использования:
Нам нужен был более оптимизированный фреймворк для SEO
React довольно хорош в создании одностраничных приложений, но поисковым роботам Google трудно индексировать и полностью обрабатывать Javascript вашего приложения. Это оказывает существенное влияние на SEO.
Мы хотели, чтобы ваш профиль Peerlist был в топ-5 результатов поиска, когда кто-то ищет вас или профессионала с такими же навыками, как у вас. Нам пришлось взломать алгоритм поиска Google, чтобы отобразить ваш профиль Peerlist.
Мы все знаем, что на создание SEO уходит много времени, и мы потеряли первые пару месяцев из-за того, что не получили должного индексирования и ранжирования в Google.
Поддержка рендеринга на стороне сервера
У нас было два очень конкретных варианта использования, которым требовалось, чтобы наше приложение поддерживало рендеринг на стороне сервера (SSR). Одним из них было SEO, о котором я уже упоминала выше, а вторым — предварительные просмотры пользователей в социальных сетях. Что-то вроде этого:
Предварительный просмотр Peerlist, когда вы делитесь своим профилем в социальных сетях
Для таких сайтов, как Peerlist, где мы полностью сосредоточены на выделении данных о пользователях, нам требовался предварительный просмотр каждой ссылки профиля пользователя. Если я хочу поделиться ссылкой на свой профиль в Peerlist, должна быть выделена моя информация, а не сама платформа. Вы, должно быть, видели подобные превью социальных сетей для таких сайтов, как GitHub, DEV и Hashnode.
Обе эти функции нуждались в SSR, и мы не нашли хорошего, надежного и масштабируемого решения, которое соответствовало бы нашему требованию превратить приложение React в SSR.
Маршрутизация
Приложения React сильно зависят от React-Routers. Хотя React Router — замечательная библиотека для обработки маршрутизации, мы начали сталкиваться с трудностями при поддержке и отслеживании условной маршрутизации. Хотя React Router работал бы с более совершенной реализацией, мы начали искать что-то более простое в обслуживании, реализации и масштабировании.
Экосистема JavaScript
В нашей ранней реализации, бэкэнд был разработан с использованием Springboot и Postgresql. Это было замечательное сочетание, и мы почти не сталкивались с проблемами. Но все же, мы решили полностью перейти на экосистему JavaScript. Это было сделано больше для простоты разработки и использования преимуществ единой структуры проекта и MongoDB.
Но что дальше? NEXT
Помня о разных вариантах использования, мы решили, что Nextjs идеально нам подходит. Next – это отдельный фреймворк, который обеспечивает готовую поддержку SEO, SSR, маршрутизации и маршрутов API для создания бессерверных API. Мы хотели получить все и еще добавить преимущества производительности.
Приведу преимущества Next, которые мы учитывали при его выборе:
SEO и оптимизация изображений.
Оптимизированое объединение и разделение кода для повышения производительности приложения.
Очень интуитивно понятная и динамичная маршрутизация страниц.
Маршруты API для поддержки бессерверных API.
Встроенная поддержка рендеринга на стороне сервера.
Фреймворк, созданный с помощью React
Процесс миграции и проблемы, с которыми мы столкнулись
Мы начали понимать недостатки нашей предыдущей реализации, но вопрос заключался в том, когда самое подходящее время для миграции?
Чтобы создать небольшой контекст, мы запустили закрытую бета-версию нашего приложения два месяца назад и находились в процессе разработки новых функций, их тестирования и сбора все большего количества отзывов пользователей. Итак, нам пришлось выбирать между выпуском новых функций и миграцией.
Из-за небольшой команды инженеров делать и то, и другое параллельно было невозможно. Но начало миграции означало бы, что мы должны приостановить разработку функций. Тем не менее, мы решили продолжить миграцию, потому что чем раньше, тем лучше!
Учитывая предидущий проект Reactjs, миграция внешнего интерфейса была немного проще. Большинство компонентов можно было использовать повторно. Единственная разница, которую мы видили, заключалась в следующих четырех вещах.
Переход с React Router на native Next router
Добавление SSR для определенных страниц
Изменение структуры папок в соответствии с Next
Создание метатегов для улучшения SEO
Исходя из этого, миграция внешнего интерфейса казалась довольно простой. Что нужно было сделать, так это написать бэкэнд с нуля. Как я уже упоминала, наш предыдущий бэкенд был на Springboot и Postgresql, поэтому перенос его на API-интерфейсы JavaScript с MongoDB означал написание и структурирование всего с нуля.
Для миграции, учитывая сроки и ресурсы, мы решили воспроизвести все как есть, не изменяя его. Потому что мы хотели сделать это как можно быстрее, а потом работать над улучшением. Но опять же, кто контролирует желание разработчика реорганизовать код и реализацию?
С другой стороны, миграция дала нам возможность улучшить подходы к реализации. Мы сделали нашу систему более усовершенствованной и стабильной. Хотя разные улучшения заставили нас пропустить дедлайн миграции, общий результат, который мы получили, стоил потраченных усилий.
Если нужно обобщить весь процесс миграции и записать полученные знания, вот они:
Изначально я чувствовала, что нам нужно было больше подумать о выборе правильного стека технологий с первой попытки. Но всегда помните, ваша первая попытка никогда не будет отшлифованным и совершенным продуктом (вот почему он называется прототипом!). Вы уже тестируете свою идею, поэтому ничего страшного, если вы поэкспериментируете со своими знаниями и выберете стек технологий, который вам наиболее удобен.
Ни одна система не может быть доведена до совершенства! Мы все видели ошибки в известных приложениях, сбои, происходящие с приложениями, которые мы считаем идеальными, поэтому вам нужно приложить максимум усилий для создания своего продукта. Ошибки будут частью вашего программного обеспечения, так же как и функции, смысл всегда в улучшении вашей системы и минимизации ошибок, а не в создании идеальной системы.
Рефакторинг кода и импровизация — это хорошо, но очень важно уделить им время. Иначе попадем в кроличью нору.
Это все, чем я хотела поделиться о нашем процессе миграции. Я намеренно старалась сделать эту статью менее технической и больше отобразить мыслительный процесс, через который мы прошли. Дайте мне знать в комментариях или свяжитесь со мной в Твиттере, если вы хотите понять какую-либо конкретную часть процесса. Я обязательно постараюсь рассказать об этом в своей следующей статье. А пока — продолжайте исследовать!
Автор: Yogini Bende
Источник: blog.peerlist.io
Редакция: Команда webformyself.
Читайте нас в Telegram, VK, Яндекс.Дзен