Read Aloud
Text Size
Website • Node.js • Express • MongoDB • Azure • Team Foundation Services
The idea was to redesign our website and expand our portfolio with bleeding-edge technology. We wanted to use React as a framework for our interface, which also required choosing the correct tools and architecture to go along with it. Since we mostly do Microsoft related development, we decided to use Azure as our cloud provider.
What we didn’t think would prove to be so difficult was the selection of the right CMS for our back-end. On our previous website, we used WordPress which wasn’t sufficient enough for our needs. And since we decided to build the complete front-end with JavaScript, the easiest solution seemed to go ahead with Node.js based framework.
A few choices seemed to stand out, most notably Keystone.js and Strapi. We gave both of these frameworks a try and decided to proceed with Strapi because it had a smoother and more user-friendly admin interface.
The developer experience was not bad either. Building content-types took only a couple of minutes (that is, of course, if you know your way around the toolset). It felt carefully thought-out. The biggest issue, however, was that writing in this framework proved to be unstable on Windows platforms.
After we hit a wall with Strapi, we gave Keystone.js a try.
It was just as easy to create content-types in Keystone.js, as it was in Strapi. You had more control over writing your RESTful API endpoints, and the community around it seemed to be bigger. Unfortunately, we saw that the active maintenance was at a stand-still, with version 2 being in sort of a limbo, waiting for active maintainers, and version 3 is still nowhere in sight. Unwilling to expose ourselves to unnecessary risks - we decided to pass on Keystone.js as well.
Since the website was intended to have a blog section, we knew we needed to find an SEO-friendly CMS. With React being the client-side framework, it meant the indexing for search engines would be an issue. Most notably for dynamic blog pages that come from the CMS.
So we knew we needed a server-side rendering (SSR) solution for our React application. Two most well-known frameworks for this specific case are Gatsby and Next.js. Our developers had previously worked in Next.js, so it was a no-brainer. In the end, it turned out to be a great decision, since we ended up building a mailing microservice on the same server. The flexibility in choosing, and building a custom Node back-end of Next.js seemed so apparent at this point. Of course, the server we used was built with Express. And it handles the routing for client-side pages, as well as the back-end REST endpoints.
There is, however, another part of the equation that required additional thinking when doing SSR: the styles, of course. CSS is also a first-class citizen in these types of scenarios, and in order to avoid common flashes of unstyled content, we need to render our styles on the server as well. As with everything regarding CSS, there are already existent solutions. CSS-in-JS is most commonly used in these scenarios because then the styles can be flushed to the head and rendered along with the rest of the markup. Next.js provides similar possibilities, but some CSS-in-JS libraries are harder to implement with it than others. We opted for using Emotion, a library whose 10th version came with default support for SSR. This probably saved us much trouble and initial configuration in order to integrate CSS-in-JS.
There were a lot of benefits that came with using this style library. Styles are encapsulated in the components, meaning there are no conflicting styles on the page. This helped us with code reusability, and it will also help us scale the website in the future, if necessary. It was an outstanding experience overall.
We are very happy with the outcome of the work we did on this application. It was a learning opportunity in a lot of ways. This specific project serves as a reminder that good research and proper planning are the pillars of quality work.
The application is really performant, and we think the user experience is outstanding. Although you’ve probably experienced this yourself seeing as you’re here reading this article. We aim to provide the best software products possible, and with this, we’re sure we did just that.
