Concept/Ideation

After several years of using website builders like Weebly, I wanted to build a website from the “ground-up” — marrying my love of web design with my new-found knowledge of React. I also hoped that the website can serve as a professional “business card” for design commissions/competitions. Content-wise, I wanted to specifically showcase my web development projects along with some notable architecture/BIM projects.

My previous Weebly site utilized a minimalist theme, featuring a simple side bar with different page categories, and a central area for text and images. I wanted to maintain the clarity of the site while implementing a more modern, “material UI” aesthetic. Individual should be more central to the website, and page navigation should be easier for users, with more room for routing redundancies.

Precedents

Looking at various portfolio sites and “modern” landing pages, I was inspired by websites developed by Dixon & Moe and Aris Acoba. I appreciate the hierarchy of graphic & text elements presented, as well as the architectural and “drawing-like” quality of the pages. My previous web projects (Oculus Weather, Context Explorer) served as precedent for a simple neutral color scheme with a gradient of more muted, desaturated colors.

Site Architecture & Next

Developing and using NextJS were a big challenge for me. I had never built a complex, multi-page website before, beyond the limits of a create-react-app application (see previous projects). I initially investigated using GatsbyJS, but I found the framework to be overly opinionated (and too tied to the founder’s own needs). NextJS provides a more flexible React framework without intense “proprietary” plugins, while still offering the speed and efficiency of server-side rendering.

In general, NextJS simplifies the process of building a complete React application from scratch, and it is particularly good for static websites such as blogs and portfolios. From the official documentation, NextJS offers:

• Simple, page-based routing system eliminates the need for React routers and provides easy site organization

• Pre-rendering (Static Generation and Server-side rendering) allows for faster page loading and prefetch

• Built-in CSS, Sass, and CSS-in-JS support provides multiple avenues for styling

• Great development environment with fast refresh (‘npm run dev’)

Wireframing and Development

After understanding basics of the NextJS framework and doing several tutorials, development is quite straightforward and similar to any basic React project: create a design blueprint on Figma, determine the design standards and basic web elements, and work through components nesting through wireframing and prototyping.

Backend Data Integration & “Blog Hacking” with WPGraphQL

Finally, after setting up the front-end “skeleton”, it was time to populate the site with content. As part of its “personal blog starter kit”, NextJS recommends setting up blog pages via Markdown files, directly within the front-end code. However, for large amounts of data/pages, NextJS can use GraphQL, which pulls HTML exports from a back-end CMS, to create dynamic pages from page components. The plugin WPGraphQL provides an extendable GraphQL schema and API through which a front-end NextJS can quickly access and serve up pages from a headless WordPress site. In this instance, GraphQL is more efficient than REST API calls, in that the client can specifically define the data structure to be pulled from the server.

My portfolio site consists of two main content streams: “projects” and “blog posts”. NextJS must generate a dynamic page for each unique project and post. For my blog posts, I am maintaining the pages as Markdown files within the front-end. For projects, however, I developed each individual project as a unique “blog post” on WordPress, then made GraphQL queries to generate the pages.

Troubleshooting and Final Thoughts

Throughout the development process, I encountered several roadblocks that required some creative workarounds/troubleshooting. NextJS is a relatively young framework (as of late 2021), and there are still a myriad of functional issues to be resolved. As a beginner developer, I am also learning to overcome my own shortcomings and “blind spots”, particularly on the backend systems.

• Styling Architecture in NextJS – There are a myriad of ways to style web pages within React (CSS, Sass, CSS-in-JS), and dozens of free/paid CSS frameworks (Bootstrap, Tailwinds, Material UI) out there to suit project needs. For this project specifically, I used a combination of CSS and SCSS to determine styling requirements and reusable components, on an as-needed basis. While this worked for what I needed, I found the styling system to be cumbersome as the project grew in size and scope. I eschew methods such as “CSS-in-JS”, which seemed to mix up too many systems together. I also avoided generic frameworks like Material UI to keep a level of “handicraft” within the project, and to avoid a generic “UI look”. I think that as projects and systems grow in scale, having proper design patterns in place will help avoid development confusion, and help projects stay unified and consistent.

• Next/Image & Image Organization – Images are “fussy” components within the NextJS framework. Due to the specific requirements of server-side renderings, images are a separated as an independent component with its own default loader, to prevent behaviors such as “lazy loading” on the client-side. When used with a headless CMS with dynamic pages, “next/image” requires some finessing to allow images within HTML exports to be processed correctly.

• Headless CMS – The use of NextJS with a headless CMS, via GraphQL, is still relatively new, and I believe the first use case of this functionality dates to 2019. While this feature is great, and allows folks to build sites and back-ends quickly, I don’t believe the CMS is truly “headless”. WPGraphQL still requires a publicly accessible WordPress site for it to pull data into the NextJS site, rendering the WordPress site redundant and “floating in the ether”. I wonder if the next iteration of WPGraphQL can allow the original WordPress site to be somehow “locked” from a publicly accessible address, or be redirected directly to the NextJS site. Thus far, this feature does not exist yet.