Overview

I just finished doing an evaluation of NextJs for a recent project where a client asked me

I had recently done an analysis and decided to pass on NextJs but couldn’t remember why I felt that way because it had been a few months so with the help of the kind folks on the Rands Slack’s frontend channel I dove in to a reevaluation effort.

TLDR – Our Findings

Attentions spans are short and your time is valuable so below are our findings. We found that NextJs is

Interesting for

• Small teams with low turn over
• Projects Like e-Commerce that Need to Maximize SEO Results
• Serverless Node Architectures with Low DevOps Overhead

Less interesting for

• Larger Projects with Distributed Teams
• SAAS or LOB Projects

Our clients project was for a SAAS platform that is very likely to be successful and will be worked by a distributed team. Because of this we recommended against using NextJs to our client.

We’ve provided detailed analysis of each point above in the following sections.

NextJS Big Features

Below are the bigger features of the platform that we considered in our analysis.

• Static Generation
  Allows creating static pages at build time for improved performance and SEO. This is implemented in a very easy to use intuitive way. Great feature!
• SSR
  Server-side Rendering allows for fetching data on the server and returning more fleshed out generated HTML from your React Components. This allows for better SEO as you can return more content with the first update to the page. This is implemented in a very easy to use intuitive way. Great feature!
• File Based Routes
  This is an alternative to React Routers declarative approach where any file you put under the ./pages directory will resolve as a url. Example, ./pages/foo.js will resolve to www.my-app-domain.com/foo. This feature is implemented in an intuitive way but for us was an over all negative as it discourages collocating code by features and makes it awkward us to organizing files how we like to. We prefer declarative routing as we want each feature in its own folder not in a file in the ./pages subdirectory. You could have each file just expose a component that was imported from the ./features folder but then you have way more overhead and complexity than when using a declarative router.
• API Routes
  This feature is pretty neat and intuitive to use. Any file you put under ./pages/api will resolve as a node express API endpoint handler with a url that matches the filename similarly to File Based Routing above. If you use Vercel hosting that is created by the same folks who created NextJs then each file under ./pages/api will be implemented as an AWS Lambda function. This allows micro-services and horizontal scale out in a very easy way.
• Webpack Blackbox
  Webpack details are hidden from the developers in the same way you find in create-react-app. We didn’t find this feature terribly interesting as it’s not really a differentiator as most React based frameworks offer this.

A Little About File Organization

A lot of our recommendations revolve around our values when it comes to file organization and its impact on development. We work on a lot of different projects with different teams and found plenty of teams who don’t share our values when it comes to file organization so YMMV depending on how you feel about collocating code by features.

We strongly believe in collocating code by features because we:

• are writing code with or for other teams
• we anticipate one day a new team taking over our code
• we anticipate frequently having to ramp up new folks on the code base

Because of these assumptions we find it’s really valuable to have all the code for a features, say Document Archive, located in one place in the code. Because of this we use the following folder structure on most projects

- src
  - features
    - documentArchive
    // other feature folders
    // any shared features are put into their own folders
  - infrastructure 
    // utility features like caching, parsing, ect...
  - widgets 
    // reusable UI widgets

Here each sub-folder of features holds one major feature of the application including all the data flow related pieces, components, unit tests, etc… This allows a new developer on the project who is working on a bug in the Document Archive to easily find their way to all the relevant code. You can find out more about our code organization here.

Our Recommendations

Below are more details about what use cases we thing NextJs is interesting for and the ones we find it less interesting for.

Interesting for Small Teams with Low Turn Over

We felt that NextJs could be a great solution for smaller teams which might not have a seasoned architect. The framework makes a lot of choices for you, you don’t have to worry about webpack and the file based routing would allow FE devs to just drop in a file and start coding.

We felt that as the code base and team grows that without using approaches like collocating code by features you can end up with code that can have a bit more ramp up for new folks as we discussed above.

Interesting for Projects Like e-Commerce that Need to Maximize SEO Results

A quick review of the features section above will show that it’s a great solution if you need to maximize your SEO results as it has many features that will get your SEO content on the screen faster for your users.

Interesting for Serverless Node Architectures with Low DevOps Overhead

If you want to go serverless or use a microservice style architecture but don’t have a lot of DevOps muscle on your team then the API Routes feature combined with Vercel’s hosting would be a great option.

Less Interesting for Larger Projects with Distributed Teams

This really boils down to how we like to organize the code base on our projects to enable good maintenance for complex code bases with large, distributed, dynamic teams. And as we discussed in the features section above when discussing File Based Routing, we find that File Based Routing makes collocation by feature awkward.

Less Interesting for SAAS or LOB Projects

We mostly work on SAAS platforms and Line of Business applications and these apps

• don’t need SEO
• are around for a long time
• will have larger dynamic teams

This coupled with the fact that we are a distributed team makes NextJs a no go on these projects for us. The reasons include

• we don’t need Static Generation or SSR because we don’t need to SEO as the application features are all only for authenticated users
• we like to use FeatherJs for our APIs at it enables high velocity with flexibility and because of this aren’t interested in the API Routes features
• we prefer declarative routing because we like to collocate code by features

Because of this, we wouldn’t be using any of the server side features of NextJs and so also would be unlikely to use Vercel hosting. We would likely be statically building the app for distribution via CDN, S3 ect…

That leaves the only interesting feature we saw being the File Based Routing which makes it harder to collocate files by features and support large, distributed teams as we discussed above several times.

Take Aways

This is what we found when looking at NextJs and comparing its features with our use cases and development values. I spent a good bit of time doing this evaluation so I wanted to capture my notes for our clients in the future and others who might be interested. This is in no way meant to be a post that suggest that NextJs isn’t a great tool or that you shouldn’t use it on your projects.