This Very Website | The web dev space is tremendously productive, with companies and individuals constantly creating new services and transforming older ones to include new features. While the selection of web services today is impressive, it's a bit like the cereal aisle in American supermarkets: which ones are you going to go for? This was the position I was in when I decided to revamp my personal website. There are so many cool web dev technologies out there right now that it only took me a day of research to land on the right tools. After one day of research, one day of designing, and three days of coding, I'm very happy with the result and wanted to share the experience. ## Table of Contents - [Project Requirements](#project-requirements) - [Tools](#tools) - [Design](#design) - [Backend](#backend) - [Frontend](#frontend) ## Project Requirements I should elaborate that in addition to being an intro website, I wanted my personal site to host everything I work on, from my web dev projects to my photography. So I was willing to make a little bit of a tech investment in some tools that might seem strange for a personal website. ### 1. Data should be saved in a database I own I wanted to have a database I actually own, not one that's inherently tied to a backend service, so I have the option of using the DB with another service in the future if something happens (such as the original backend service losing support). ### 2. Online and customizable CMS I wanted a readily available CMS that I didn't have to build or maintain (_that_ is definitely overkill for a personal website, in my opinion), but that I could also customize to fit special cases that might come along in the future. ### 3. Easy Deployment Cycle Although I was willing to invest some initial time into building the website, it would not be worthwhile maintaining a deployment process myself. Both the frontend and backend projects needed to be able to deploy easily. ### 4. GraphQL support The backend needed to support GraphQL. In addition to just being a more straightforward query language than REST APIs, GraphQL also enables me to use [GraphQL Codegen](https://github.com/dotansimha/graphql-code-generator). Since I knew I was going to use Typescript and React in the frontend, having automatically generated types and queries was a necessity. ### 5. Free! (or very low cost) Always trying to stay out of the 21st century monthly subscription vortex. ## Tools I'm happy to say that I found well-funded and supported tools for all of the requirements above and _completely for free_. ### [Strapi](https://strapi.io) For the backend I landed on Strapi! It's a really cool, open-source API/CMS service. You can actually clone the repo and host on your own server with your own database. They have a large selection of plugins you can use. Also, their team regularly publishes tutorials on how to set up Strapi with variety of different technologies. The setup has been easy and the CMS is excellent. I think it's now going to be my go-to for any website that simply needs to publish content. ### [Postgres](https://www.postgresql.org/) I have a lot of experience using Postgres, it's a well-supported database with plenty of documentation and questions on Stack Overflow, and it's easy and free to host on Heroku. ### [Heroku](https://www.heroku.com/) Free and easy-to-use hosting service that I have a lot of experience in from hosting Django apps. ### [Vercel](https://vercel.com/) NextJS is probably the most popular React-based frontend framework out there right now, and for good reason. Guarantees easy and reliable deployments and static site generation. ### [Cloudinary](https://cloudinary.com/) Like Strapi, a completely new service to me. Strapi has good documentation for it and I was able to set up folders and integrate into my Strapi API easily. ### [Figma](https://figma.com) I'm not much of a designer, so Figma was the easy choice for me. It's the de facto standard of design tools in web development and I find it very intuitive to use. ## Design The first thing I started with was the design of the site and, since I'm not a designer, this meant surfing the web and finding cool designs that I could copy :). I really liked the color scheme on the [Mozilla docs](https://developer.mozilla.org/en-US/), it's simple and contrasting. As for the bordered divs, inspiration for that came from the landing page for this cool tech coop call [Partner & Partners](https://partnerandpartners.com/) I found on Github the other day. Here's the [figma project](https://www.figma.com/file/Yjo85Q4XGTCxuFJfTfGiQG/Lspdrz-Design-2?node-id=0%3A1) I came up with, after some helpful guidance from my friend [Roby](https://read.cv/roby)! ## Backend After the design, I started on developing the backend which in this case meant learning how to use Strapi as I went along. Luckily this is a pretty straightforward blog project so I was able to adapt many of the [tutorials](https://strapi.io/blog/categories/tutorials?type=v4) Strapi provides to my use case. In particular, I used the [cloudinary](https://strapi.io/blog/add-cloudinary-support-to-your-strapi-application) and [postgres](https://strapi.io/blog/postgre-sql-and-strapi-setup) tutorials to add those services. After getting the local server up and running, I began to explore using Strapi. They have an interesting development pattern: if you want to make schema changes, you run the server locally and add/edit/remove relations or entities in the local admin UI. Those changes will then result in generated code and metadata DB changes that you can then deploy to your staging or production server. For example, here's the commit where I added a [photo entity to my project](https://github.com/lspdrz/lspdrz-api/commit/ea5b352baf2109adafeb05dfb600b3ced6d7c211). It was all very easy to use and having an out-of-the-box CMS allowed me to focus on other parts of the project. Setting up GraphQL on the Strapi project was also as easy as adding the [graphql plugin](https://docs.strapi.io/developer-docs/latest/development/plugins/graphql.html) that the Strapi devs built. It comes with built-in CRUD schema and operations, so with one simple command to add the plugin you have a fully operational GraphQL endpoint and schema to migrate to your frontend. Automatic deployments using Heroku was also a [breeze](https://strapi.io/blog/deploying-a-strapi-api-on-heroku), especially if you have some Heroku experience. You can also set up a staging server and branch using the same instructions in the linked article. I didn't bother exploring how to create PR apps since I've never found that particular useful for a backend server and this is a small project. All in all, I was impressed with Strapi and its incredible ease of use for small projects such as this blog. I think it could also have serious potential for bigger projects, such as a news-based organization, to quickly get things off the ground with the option of migrating to a more customizable service in the future, since you _always own your data_ in a way that can be decoupled from Strapi. You could even gradually migrate away from Strapi into a custom API service since the database is hosted separately. You can view the repo for this part of the project [here](https://github.com/lspdrz/lspdrz-api). ## Frontend Once I had a staging backend server up and running, I started developing the frontend. Setting up a NextJS project is probably the easiest thing I've ever done in five years of engineering. Infinite thanks to the dev experience team at Vercel. The development is pretty straightforward for a Typescript React project using GraphQL. I basically took a feature from the Figma design, created the schema in the backend (with the GraphQL CRUD operations being automatically generated upon creation) and then worked on the html in the NextJS project. All of the GraphQL types are copied from the server using ApolloClient and GraphQL Codegen. For styling, I used TailwindCSS. It's everything I've ever wanted from a CSS library and support/documentation is incredible. All of the deployments, including PR deployments, are done through Vercel. You can view the repo [here](https://github.com/lspdrz/lspdrz). ## Conclusion Revamping my personal website was way overdue and I'm very happy with the end result. I'm confident it'll be a space where I can publish things I'm working on for a long time and if Strapi ever loses support (that would be a sad day), I still have access to all the data to use something else. For now, I'll probably use the site to publish things without changing too much. The next big feature will likely be creating an indexing system for articles once I have enough to index! :)