有关我们从 ReactJS 迁移到 NextJS 的一切

大家好👋，

两个月前，我们在十一月发布会上宣布了技术迁移。从那时起，我就计划写这篇博客，但觉得需要花些时间才能更清楚地了解所有情况。由于现在情况已经相当稳定（但我们仍在改进），所以我想分享一下整个思考过程以及我们是如何做出决策的。

剧透预警！本文涵盖了我们做出这一决定背后的大部分想法和过程，可能不会深入探讨技术层面，但请继续往下读，最终它绝对值得一读！

React 是最流行的 JavaScript 库之一，如今已广泛应用于众多应用程序，而 NextJS 则是基于 ReactJS 构建的框架。只有真正使用 Next，你才能真正体会到它的强大之处，这完全是我自己的经验之谈！

我使用 React 已经三年多了，一直很喜欢它的工作方式。所以，当我们从零开始构建Peerlist时，React 是我的不二之选。由于处于 MVP 阶段，我们决定发挥各自的优势（当然，前端是 React），用 ReactJS 构建第一个可运行的原型。

起初，这种方法很有效，我们能够在规定时间内交付产品，一切进展顺利。但很快我们就意识到，使用纯 React 的决定对我们来说并不理想。我们知道，这个技术栈无法与我们现有的产品路线图兼容。

为什么？

所有技术和框架都很棒，但它们是为了满足不同的用例而创建的。所以当我说普通的 React 不适合我们时，我考虑的是以下用例：

React 在创建单页应用方面非常出色，但 Google 爬虫很难索引并完整处理应用的 JavaScript。这会开始影响你的 SEO。对于像Peerlist这样的网站来说，用户的内容才是最重要的。

我们希望当有人搜索您或与您拥有类似技能的专业人士时，您的 Peerlist 个人资料能够出现在搜索结果的前 5 位。为了显示您的 Peerlist 个人资料，我们必须破解 Google 搜索算法。

我们都知道，SEO 的构建需要花费大量时间，而我们最初的几个月就因为没有被 Google 收录和排名而损失了。这成了我们交易的败笔！

我们有两个非常特殊的用例需要我们的应用支持服务器端渲染 (SSR)。其中一个是我上面提到的 SEO，另一个是自定义社交预览。例如：

对于像 Peerlist 这样专注于突出用户数据的网站，我们需要为每个用户个人资料链接定制社交预览。如果我想分享我的个人资料链接，我的信息应该在平台上突出显示。你一定见过 GitHub、DEV 和 Hashnode 等网站上有这样的自定义社交预览。

这两个功能都需要 SSR，但我们还没有找到一个好的、健壮的、可扩展的解决方案来满足我们将 React 应用程序转变为 SSR 的要求。

React 应用严重依赖 React-Routers。虽然 React Router 是一个处理路由的优秀库，但我们开始发现使用它来维护和遵循条件路由存在困难。虽然 React Router 的实现更精细一些，但我们开始寻找更易于维护、实现和扩展的方案。

在我们之前的实施中，我们的后端是用 Springboot 和 Postgresql 开发的。这是一个非常棒的组合，我们几乎没有遇到任何困难。尽管如此，我们还是决定完全迁移到 JavaScript 生态系统。这主要是为了方便开发，并充分利用单一项目结构和 MongoDB 的优势。

考虑到所有这些用例，我们认为 Nextjs 是我们的理想之选。Next是一个自成体系的框架，它为 SEO、SSR、路由和 API 路由提供开箱即用的支持，可用于创建无服务器 API。我们想要所有这些功能，并且还希望获得性能优势。

特别是这些是我们在选择 Next 时考虑的好处

我们开始了解早期实施的缺点，但问题是什么时候才是迁移的最佳时机？

简单介绍一下背景：两个月前，我们刚刚发布了应用的封闭测试版，目前正在发布新功能、进行测试，并收集越来越多的用户反馈。那么，我们究竟该在发布新功能还是迁移之间做出选择呢？

由于工程团队规模很小（🧑‍💻x2），同时进行两项工作并非可行。但迁移意味着我们必须暂停功能开发。尽管如此，我们还是决定继续迁移，因为越早越好！

考虑到早期的 React.js 项目，前端迁移会更容易一些。之前的大多数组件都是可复用的。我们认为唯一的区别在于以下四个方面：

由此看来，前端迁移似乎相当简单。只需要从头开始编写后端即可。正如我之前提到的，我们之前的后端是基于 Springboot 和 Postgresql 的，将其迁移到带有 MongoDB 的 JavaScript API 意味着需要从头开始编写和构建所有内容。

考虑到时间和资源的限制，我们决定在这次迁移中原封不动地复制所有内容，不做任何修改。因为我们想尽快完成迁移，并在之后持续改进。但话说回来，谁能控制开发人员重构代码和实现的冲动呢？

但积极的一面是，这次迁移让我们有机会改进实施方法。我们的系统变得更加完善和稳定。虽然这些改进让我们错过了迁移截止日期，但系统整体的改进值得我们付出这些努力。

如果我需要总结整个迁移过程并写下经验教训，那么以下是：

最初，我总觉得我们应该在第一次尝试时多加考虑选择正确的技术栈。但请记住，你的第一次尝试永远不会是一个精致完美的产品（这就是为什么它被称为原型！）。你已经在测试你的想法了，所以你可以发挥自己的优势，选择你最擅长的技术栈。
任何系统都不可能完美无缺！我们都见过知名应用中的 bug，也见过我们认为理想的应用崩溃，所以你只需要尽最大努力创造出一个好东西。bug 和功能一样，都是软件的一部分，关键在于改进系统，尽量减少 bug，而不是打造一个完美的系统。
代码重构和改进固然好，但时间限制至关重要。否则，我们就会掉进“兔子洞”。

这就是我想分享的迁移过程的全部内容。为了使其更具现实意义，我特意减少了文章的技术性，更多地介绍了我们经历的思考过程。如果您想了解迁移过程中的任何特定部分，请在评论区留言。我一定会在下一篇文章中详细介绍。

到那时，继续探索吧！✌️

如果您喜欢我的文章，也可以在Twitter上联系我，或者请我喝杯咖啡。我每周二都会发布一篇关于 Web 开发、前端、我的学习以及一些有趣的想法的文章。