jameshadfield
commented
5 months ago Thanks for the review @victorlin! I'm going to merge this and create a few issues for improvements / future work we could do. Next.js should make it possible to take the site in many different directions, some of which I think are sensible. The terminology is somewhat overwhelming but there's a rough heirarchy available for us if we want to do more here:
- build-time compiled JS bundles + client rendering. This is essentially what we are doing here, and what we did in gatsby 95% of the time (we had few pages with some areas of SSG in gatsby).
- True SSG + hydration. Removing
styled-componentsis going to make life much easier for this. There may be an argument to invest in this for the splash page at least. - SSR - depending on the caching used this can be very similar to SSG. Would make custom error pages possible.
- Server components.
For me functionality improvements are more important than these, and hopefully this PR makes such work easier for all of us.
This PR replaces the engine behind the frontend (client) pages within nextstrain.org from Gatsby (v2.32) to Next.JS (v14).
Working review app
The reasons for wanting to move away from Gatsby are many and have been discussed elsewhere. For me the greatest motivation was the high bar for development work within the static site which is (one of) the reasons the frontend site has seen little development recently. We currently have a situation where some people can only develop nextstrain.org by using the heroku review app to test changes as they cannot install/run the frontend locally.
People's ideal implementations for the frontend have been discussed elsewhere but this PR takes a different approach: it keeps the overall structure and design and simply replaces the code which interacted with Gatsby to code which now interacts with Next.js. Importantly we are still using static (build-time) compilation of pages¹. If you would like to implement server-side rendering then this PR can be seen as a step along that path as Next.JS has extensive support for server rendering, however I don't think this is right direction². Similarly, improvements to styling, design, image optimization (etc) are all good ideas which were not in scope for this PR.
Development times and complexity have been significantly improved by this PR. Whilst there is undoubtedly some Next.JS specific concepts to learn, their docs are pretty good and I've tried to highlight relevant concepts in the added documentation here. clades.nextstrain.org uses it moving more of our sites to a shared architecture will hopefully assist in wider development efforts. Compared to the difficulties in maintaining and improving our previous frontend it is night and day. While user performance was not a motivating factor for this PR, first-contentful paint and other metrics have improved.
While this PR touches many files most changes are trivial. Probably the biggest change is the code to generate the blog pages where we move away from Gatsby's GraphQL approach. Along the way there are quite a few bug fixes and removal of unused code and pages. I noticed many more rough edges and little bugs; hopefully with a more pleasant dev experience we can attend to these.
There are still some outstanding tasks which I'll attend to when I get a chance this week:
¹ There are some differences, with our implementation of Next.JS using a more minimal entrypoint HTML which allows reuse and caching of shared components. But the server is not rendering pages in production mode.
² There are some exceptions such as rendering error pages with context about the actual error, however this PR specifically avoids changing our existing approach of generating pages at build time.
Closes #698