This blog was originally published on school blog website this is a republish and translation of the original content
For the past two weeks I have been busy continuing to work on the Jollycons website.
Adding SSL to the website
At Jollycons we wanted to have https, as it has quite a few advantages. Besides the security for the end user, it also allows us to use methods such as HTTP/2. This makes the website a lot faster.
Before I start setting up https, I first looked at our current setup* (which services we use for hosting). Our current setup was Amazon S3 for the server and Iwantmyname for our domain.
Certificate manager
Amazon has a service called Certificate manager. It allows you to create https certificates for domains you host with Amazon. I created a certificate here for jollycons.com
To get this working, we need to use Route 53 to handle traffic to jollycons.com. So we make route 53 our DNS provider* (the service that determines where the user should be sent when the user types in jollycons.com). I assumed that if we do this I could activate the certificate for jollycons.com.
Unfortunately this does not work, let's see what causes this. I first read Amazon's documentation for this. This did not make me any wiser, so I looked at how we do it at Yummygum.com and on google.
I then found out that to use a certificate from Certificate manager we have to use a service from Amazon like Cloudfront. Since this can get pricey pretty quickly I looked first to see if there were any other options.
Let's encrypt
With my own servers, I often use Let's Encrypt in combination with Certbot. Let's Encrypt is a service that allows you to create SSL certificates. Let's Encrypt is a leader in this field because they gave people the option to create SSL certificates for free.
A certificate from Let's Encrypt is valid for three months, then you have to renew it again. This is quite inconvenient because you then have to do this manually every three months. This is where Certbot comes in, Certbot automatically renews the SSL certificate just before the certificate expires.
Since this option is free I first wanted to see if I could achieve https with it. Unfortunately, I could not install Certbot on the Amazon servers.
Cloudfront
After trying other options, we finally went with Cloudfront. Now let's create a Cloudfront distribution* (a server sitting in front of our server) for Jollycons.
Most of these settings were of no interest to us. The settings I changed are the Alternate Domain Names, here we have to enter the urls we want to listen to. In this case they are jollycons.com and www.jollycons.com
Here we also want to select our own SSL certificate. Which we created in the Certificate manager. We can easily select it here, since this is potentially sensitive data I have hidden it here.
Finally we set the supported HTTP Versions to HTTP/2, this allows us to load multiple files at once, making the page load a lot faster.
Now that we have set the general settings, we still need to tell Cloudfront what to display to the end user. We do this in origins.
Setting this up is fairly self-explanatory we paste the bucket url of our server here. Now we just need to tell Cloudfront how to handle files. For this we create a behavior.
Again, most of the settings here are not important to us so we do not adjust most of them here. For starters, we adjust the viewer protocol policy from HTTP and HTTPS to Redirect HTTP to HTTPS. This ensures that a user is redirected to the https version.
The only other change we make is the compress objects automatically setting. We turn this on, this causes the code to be automatically compressed* (made smaller). This means the user has to download less data and the page loads faster.
Now we only have the problem that images do not work. We can easily solve this by creating the behaviors for these files.
Conclusion
Setting up Cloudfront was a lot harder than I initially thought. This was also because I had never worked with Amazon services before. Although it was a very educational experience I would never use Amazon myself because besides the cost, there are a lot of extra unnecessary steps.
Mistakes and solutions
When setting up https at first it didn't get it working. I then tried many different things. In the end, it was just a matter of waiting for Amazon to make the changes internally. This took more than forty-eight hours.
Once I got https working, the next problem was that Cloudfront stores the files in their cache. This prevents changes to the code from being visible. I solved this by adding cache invalidation* (Telling Cloudfront to delete their current cache) to the build process* (Merging the code and automatically uploading it to the server).
Fixing a Webpack config
When I was doing a QA* (quality assurance) test I found out that something went wrong when compiling* (Getting the code ready for production) the SASS files. I saw all the CSS were inline as a <style> tag. This has the disadvantage of not storing the CSS in the cache. When I was checking the css I saw that no browser prefixes are added to the css either.
Auto prefixer
This problem was a priority because it can cause the website to not work correctly in different browsers. To solve this problem I first checked to see if there were more people with this problem.
With a quick google search I quickly saw that several people have this problem. To solve the problem I modified the webpack config* (the file where defined how the code should be built).
To begin, I define the browsers we want to support and thus the prefixes* (Adding tags such as -webkit- and -ms-) should be created for. In doing so, I specify that we want to support the last two versions of all browsers and versions used by more than 1.6 percent of users are used.
Now to add the prefixes I first extract the current SASS loader and add our modified version. I do this through config.loader , this function expects two values, the name of the loader and an object with the settings of the loader.
The name of the loader is SASS, for the settings we give three values. I will explain each of these one by one. Let's start with test this tells Webpack on which files to run this loader. Here we pass a regex* (regular expression, to explain it very simply we are testing a string for a certain value), we pass /.(sass|scss)/ here. This tests for a . and then followed by sass or scss.
We then pass an exclude, as the name implies we specify here which files we want to exclude. Here we pass a regex again, this time we pass /module.(sass|scss)$/. This will tell us whether the file name contains .module.sass or .module.scss.
And finally, we tell Webpack what to do with files that match this filter. We do this with the loader value, here we tell it to compress the css, with prefixes and convert it from sass to css.
And now we merge all these components together and add them to our gatsby-node.js so we modify our Webpack config.
External CSS sheet
Now that prefixes are added to the CSS, I can now focus on making sure the CSS is placed in an external stylesheet. Modifying this in a Webpack config would be very easy. But the plugin we use for SASS overwrites the changes.
After reading through the Gatsby documentation, I found that we could easily fix this by creating an html.js file. To do this, we first copy the current html.js by typing cp .cache/default-html.js src/html.js in the terminal.
The problem here is in the code that creates the style string and the inline <style> tag. let's remove these. Now when we run the build process there is no more style tag in it. Top unfortunately we also no longer load in CSS so the page has no design.
Let's fix this, to avoid trying to load a style.css file during development we first add a check before production.
Now we just need to add this link to our head, for this we use the following code.
Now when we run the build process we load in the style.css file in production. Now everything works as it should. This is nice since now we can save the CSS files in the cache and thus the website loads faster.
Mistakes and solutions
In fixing these bugs, I ran into some problems because I modify the webpack config via Gatsby and do not work in a large webpack file that contains all the settings. This made finding the cause of problems a lot harder.
My solution here was to read the documentation carefully and read solutions from other users who ran into the same problem.
What did I learn
I have learned a lot about working with Amazon servers over the past two weeks and I have expanded my knowledge on Gatsby and webpack.
I have been working on the following items from my PAP
Core task 2 - Learning more frameworks like Gatsby
At Jollycons we use Gatsby, as I have been working a lot in advanced features such as adjusting the Webpack config over the past two weeks. I have expanded my knowledge of Gatsby very much. And also feel a lot more comfortable now.
Personal development learning objective - Improve communication with my colleagues.
This has definitely come back over the past two weeks because when I run into something I can't figure out on my own, I ask my colleagues for help. Also, when I see that my colleagues are struggling with something I also try to help and give advice.
Learning objective in personal development - Giving feedback to team members
I have been working on this for the past two weeks by giving my feedback on the chosen implementation at pull requests. And if there is a better implementation I also give it.
Learning objective in personal development - Better substantiate my choices
This has happened in the past two weeks because, for example the external CSS file, I explained why a html.js file was the right solution and what caused the CSS file to be put inline.
Practitioner's learning objective - Structured workflow for each task you perform
This came back over the past two weeks as each task I recorded assigned it to me in JIRA. Then set it to IN PROGRESS and start timely with the number of the item from the backlog.
What will I be doing the next two weeks
I will continue optimizing the Jollycons website in the coming weeks. We will also start development of a new project. Here we are going to use React native.