
Back in the 90's, it was common for websites to have guest books for visitors to
sign. With the exponential growth of the internet in the 2000's, these "Guest
Books" gave way to social media, and you hardly ever see them anymore. 

The other day I started to wonder, how hard would it be to implement on these
days with modern technology. Back then, running a guest book involved setting up
a database and back end, but these days there are tools like Fauna and Gist that
lets you store data without database and takes minimal effort to setup.

## The Setup

My biggest hurdle when setting up my guest book is figuring out where to put the
data. I decided the best place would be in a Gist, when a user submitted their
message, a serverless function would pick it up, call Github to get the current
gist, append the users message to the end, and send it back up to Github.

## Keeping everything secure

One of the reasons guest books died on the internet was it was easy to get
hacked, so one of my biggest considerations was how to secure this thing.
Luckily this turned out to be pretty straightforward. First off since the data
was stored in a gist, I didn't have to worry about my backend getting hacked and
worst case scenario, I could just wipe the gist.

However I still wanted to sanitize the input so I used DOMPurify to sanitize any
user input prior to submission, my guest book accepts any text however if you
try adding a `<script src="verybadscript.js"></script>`, the site will strip
that away before sending up the data.

The last security related hurdle was how was I going to allow users to add to
the guest book anonymously. The Github API allows you to read gists without
authentication; however, you must be authenticated to update it. To get around
this I moved the update logic into a serverless function, this way I could
furnish an access token to the API call without exposing any secrets to
the client.

## The UI

The User Interface was probably the easiest part, but still required some
thought. I had two pieces of state that I had to keep up with: user submission
state, and guest book loading state.

I settled on two pieces of state: `submissionState` and `guestbookLoading`.
The first piece of state track the user submission, and functions like a state
machine with either "pre", "submitting" or "post" states. The second piece of
state tracks the loading of the guest book gist. There is one last piece of
state that is crucial: `shouldFetchGuestbook`.

Whenever you sign the guest book, you want to see your submission. The issue I
ran into is after submitting your message, there was no way to inform the
guest book to reload it's data. To solve this i used `shouldFetchGuestbook`
along with a `useEffect` hook that would re-fetch the data anytime the flag was
flipped to true.


## What's Next

I'm not quite done tweaking the guest book. Some improvements:

* Guest book submissions to the bottom of the document, they should go to the
  top
* There's no profanity filter in place. Shit, I should probably add one....
* Bot detection/prevention: I'm not doing anything right now to prevent bots
  from making repeated submissions. This is not a huge deal as the worst that
can happen is I hit Github's rate limit for their API. I didn't want to bog down
the user experience with a Captcha but a solution will be needed eventually.


You can sign my guest book [here](https://sunnygolovine.com/guestbook)


Building a Guest Book for my Site


With the site nearing completion I still had two things that needed doing:
Adding a links landing page and building a better blogging workflow

## Links Landing Page

If you've ever seen something like Linktree or Blue Social, the idea isn't far
off, a simple landing page that directs your visitors to connect with you on
social media, email you, etc.

I had previously a built a version and hosted it on
[sunny.gg](https://sunny.gg). However this time around I wanted something that
was integrated into my bigger site. Doing this was pretty straightforward, my
frontend code for sunny.gg was already written in React and used TailwindCSS so
I was good to go there. The incompatibility came to which framework it used.
While I built sunny.gg to use Gatsby, I built this site on top of NextJS.
Beyond that I also used a different contact form backend, using Netlify
Forms rather than SendGrid (which I use now on this site).

The first step would be to get data routed. For this I repeated React Context
API pattern I was already using to fetch data for other parts of the site, I
simply added another Context that would provide data to this landing page. This
was a pretty straightforward task and from there I moved on to migrating my
contact form to use SendGrid.

I had already written all the logic around sending a message to SendGrid via
Netlify Functions; however, in it's current state the logic was bound to a
component. I quickly refactored this logic, moving it from the component it was
in to a hook that could be used by both components, you can see how I setup the
hook [here](https://github.com/sgolovine/sunnygolovine.com/blob/master/src/hooks/useContactForm.tsx).

With the data and contact form being adapted to NextJS, I was able to copy the
project wholesale from the old repository and drop it into my new site, easy
peasy.

## Blogging Workflow

One other annoyance I wanted ot solve for the site was the blogging workflow.
Because I opted not to use a CMS, there was zero user friendliness around
creating a blog post. Here I opted for a minimal setup using a few scripts:

`createPost.js` - The first script I created was to help me create new blog
posts. My blog posts use FrontMatter for metadata so the script does 2 thing:
One it creates the file in `/posts`, the second thing it does is automatically
pre-fill the FrontMatter in the new post so I don't have to worry about missing a
field. I also added several checks to make sure the blog post filename doesn't
collide with any other post filenames.

`deletePost.js` - Just as the name implies, this script just deletes a given
post. Apparently at some point I decided that simply deleting a post using `rm -rf` was too difficult.

`listPosts.js` - Again just as the name implies, give you a list of files in
the `/posts` directory.

All three of these commands are linked in package.json under the commands:
post:create, post:delete, and post:ls. With these commands I can more quickly
create blog posts with less hassle, and ever increasing laziness.

You can find these scripts [here](https://github.com/sgolovine/sunnygolovine.com/tree/master/scripts)

## Looking Forward

That's it for now. The site is coming along nicely but there are still places to
improve. One big issue is the image used in my landing page isn't optimized like
it was in Gatsby. Gatsby has one of the best image optimization libraries and
replicating that with NextJS has proved to be more challenging that I previously
thought.


With most of the site up, in this post I want to talk about landing pages and the my blogging workflow

Building SunnyGolovine.com - Part 3


In my last post I talked about some of the decisions I made leading up to
building my site. In this post I wanted to talk more about the architecture
decisions that went into building SunnyGolovine.com

## Getting Data

One decision I did not include in my last post was the decision **not** to use a
CMS for managing content on the site. However, I also didn't want to have all my
data in my code, I needed something in the middle.

My solution for now is to keep all website data, with the exception of blog
posts, in JSON. The data is kept in the `/data` folder while blog posts are kept
in the `/posts` folder. As far as getting the data to display on the site, I had
several options. The simplest method was to use `getStaticProps` in my pages to
grab JSON data from my `/data` folder. The problem is this solution just doesn't
scale. I wanted a single API that I could route my data into and then plug into
any component in the app. My solution to this was React Context.

For the longest time I never quite understood Context, I knew I had to dive into
it eventually. So when the problem of getting data into my site presented
itself, I found a perfect candidate for Context.

I currently use two Contexts: Site Context and Resume Context. With each context
I import JSON files and combine the data into one object. From there I just use
hte `useContext` hook to provide data wherever it's needed. I previously did
this with Redux however for a unidirectional data flow, Redux is way to much
overhead.

## Optimizing Images

I never put much thought into image optimization. NextJS after all recently
introduced `next/image` which automatically optimizes your images. I put it in
and didn't think much of it until my builds started to fail. Digging into the
issue, it turns out that `next/image` with it's default loader is not compatible
with `next export`.

My solution here was to use another image optimization library called
`next-optimized-images`. While the docs looked pretty scary at first, getting
image optimization boiled down to adding a just a few lines of code to my
Next configuration.

## Sending Emails

If someone wants to reach out to discuss hiring me for something, I want to make
it as easy as possible for that person to reach me. As such, having just a link
to my email and LinkedIn profile wasn't enough, I needed "Send me a Message"
component.

Luckily this problem couldn't be easier to solve using Netlify. Netlify gives
you two options when it comes to solving this problem: Forms or Functions.
Netlify forms lets users submit forms on your site and will be collected by
Netlify.

While this solution seems the most straightforward, it came with two
drawbacks. First, the setup in a React project isn't straightforward and
requires some workarounds, having already done this on a previous project, I
wasn't looking forward to it. Second, getting the message to Netlify was only
one piece of the puzzle. I would then have to route that message to my inbox or
check Netlify religiously for any new messages, not ideal.

The alternative to Forms is to use Functions. Netlify Functions lets you write
serverless functions that you can trigger from your frontend. This is great if
you don't need a full on API but you still need a backend. I ended up writing a
basic mailer function using Sendgrid and then had the messages routed to my
Inbox.

There are still some drawbacks here, on Sendgrid's default plan I'm limited to
just 100 messages per day so if I ever start getting high amounts of traffic on
my site, I may have to reconsider this approach.

## Looking Forward

This site is still an active work in progress and there are still more things I
want to implement. Namely a Dark Theme, SEO and Performance. My Lighthouse score
is still >90% so there's a good bit of work to do.


In my last post I talked about some of the decisions I made when building my site. In this post I'll talk about the architecture

Building SunnyGolovine.com - Part 2


Earlier this year I had decided to rebuild my personal website. Over the years
I've added more and more to my exising site, from a blog to an online resume.
The way I added these modules was to create a new React project, publish it to
Netlify, and point a subdomain under `glvn.co` to the new project.

This worked well for a time but keeping up with all the projects and keeping
them up to date was becoming more and more of a chore. So about 2 weeks ago I
decided to rebuild all of these various projects into one site.

## Decision Time

When I set out to build the site, my initial plan was to use a new technology in
my stack that I've not previously used. Usually my decisions fall into two
categories when starting new projects, either try out a new technology or stick
with tried and true tech that's worked for projects in the past.

For this project I decided to try something new, and that new thing was
[snowpack](https://snowpack.dev). My initial impressions of snowpack were very
postive, here's a build tool that is _seriously fast_ and not a nightmare to
configure like Webpack. However as time went on I started to encounter issues.
My dealbreaker issue though was spotty support for babel aliases. I had setup
babel aliases like `~/`, `@media` and `@data`. These worked for me before in the
past when using Webpack so I thought nothing of bringing them in. For some
reason though it just refused to work.

This wasn't a huge issue on it's own, but this also wasn't the first issue I had
configuring Snowpack and I made the decision to move to something more battle
tested: NextJS. It's been a while since I had used NextJS for a project but I
knew thier lastest release included bunch of new features so I wanted to give
them a go.

For the UI I went with TailwindCSS. Last year I fell in love with TailwindCSS
after using it on a project and have since incorporated it into more and more
projects that I work on. TailwindCSS is great because I'm not a designer and the
UI's I'm able to crank out with TailwindCSS look top notch without the downside
of all looking the same (something you encounter if you use Bootstrap).

When it came to the blog I decided to keep things simple and copy the example
the NextJS devs provide in their
[blog starter](https://github.com/vercel/next.js/tree/canary/examples/blog-starter).
And used
[tailwindCSS typography](https://github.com/tailwindlabs/tailwindcss-typography)
to style the content generated by remark.

## What's Next.

So far I've only thought of things for the initial build, after which I will
likely be retrofitting the site with more upgrades. In Part 2 I will talk about
building the site and some of the issues I had to overcome in the process.


I recently rebuilt my personal website. In this part I'll talk about some of the decisions I made.