:toc: :toclevels: 4 :figma: https://www.figma.com/file/p2GoUK7mae7S8yYjfoeBfS/All-Project-Designs?type=design&node-id=0-1&mode=design&t=TevO0FNjbMAdNY7z-0 :sass: https://sass-lang.com :adobexd: https://www.adobe.com/ie/creativecloud.html :tailwindcss: https://tailwindcss.com/ :cockroachdb: https://www.cockroachlabs.com/ :scaleai: https://scale.com/ :youtubevideo: https://youtu.be/B1VlPPYB6y8
= CharlemagneDB
== What is CharlemagneDB? image::../public/images/CDB_youtube_thumbnail.png[thumbnail, link=https://youtu.be/B1VlPPYB6y8]
CharlemagneDB is an website for a concept database platform that is AI oriented in its development process to automate many of the reduntant processes in database configuration for most simple applications.
=== No, what is CharlemagneDB, really?
CharlemagneDB is my first project with React.
I wanted to build something that was cooler and more animated than my previous project and use more technologies. I decided to build the UI with React, TailwindCSS, GSAP (Green Sock Animation Platform) and a sprinkle of Framer Motion.
For more on this, see link:#my-goals-and-learnings-while-making-charlemagnedb[My goals and learnings while making CharlemagneDB].
== My goals and learnings while making CharlemagneDB
As this was my second project I decided to get a bit more elaborate in the technologies that I was using, but also in the design. Therefore I kept it to the following:
=== Designing with Figma
Making CharlemagneDB was a good experience all the way from design to development. I already had a lot of experience with graphics because of my experience with the Adobe suite, so designing this on {adobexd}[AdobeXD] and {figma}[Figma] was a breeze.
=== The Importance of Deign
Something very important that I have learned in the process of making CharlemagneDB is the importance of design, and the realisation of how much time it saves. Something that I had caught myself doing at times in this project is that I would try developing the website only referrencing my imagination. When I did decide to design it the pace of development was much faster.
==== Figma Source
The sources for the {figma}[Figma] design are in the link:./figma[figma] folder.
== My experience using React
I decided to use React to develop this frontend as I wanted to start learning a framework and saw that React was the most popular framework in professional settings, so this was an obvious choice. I found that it was more concise developing in react but the real power of it is all of the plugins that come with react and that you can reuse components. It is very encouraging to see the pace of development with the use of a framework.
=== Implementing with Tailwind
I decided to develop the CSS/styling in {tailwindCSS}[TailwindCSS] because I wanted to expand on my skills, but also on the pace of my development. Tailwind was very helpful in it's simplicity, but I found that at the same time it isn't as organised as SASS or CSS and at times it can be harder to debug the code. Overall though I feel that even though it makes some ugly HTML, overall it is a useful tool and definitely sped up much of the design process.
=== GSAP
When I started making this website I really wanted to use animations more, and animations were one of the main reasons I was excited to start this project and wanted to learn as much as I could from the jump. I started making this project in Framer Motion because their documentation was better at the time which would have been important from the perspective of a beginner. I was soon turned off it however when I saw that IT was rasterizing a dom element when I wanted to change it's shape. When GSAP decided to make a new website however with new documentation right when I needed an alternative, I decided to make the switch. When I used GSAP I preferred it right away. Particularly for the ease of building scroll animations in comparison to Framer Motion, with the markers and also with the fact that you can use percentages. The concept of timelines also appealed to me because it is similar to keyframes in animation softwares like After Effects and Premiere Pro which I had lots of experience in already. Generally I think it is just much more intuitive and provided more options, and also a bigger community of developers. I used much of the GSAP platform, including timelines, scrollTrigger, the core kit, MorphSVG, DrawSVG and text animations. I feel as though I have became relatively fairly advanced in the short time that I began using it.
=== How I implemented OAuth When making this site I wanted to add Google and Github login pages. This was because I had a dashboard component that I wanted users to be logged in for before using. As well as that the need for OAuth is quite ubiquitous in a real world production setting and so I wanted to add it to my arsenal. I used Google Firebase as the database for Charlemagne as it is easy to implement and comes with OAuth features out of the box, which was exactly what I wanted. To implement it I had to make a Firebase project and then go to Build / Authentication / Sign-in-method. Press 'Add New Provider' and select a provider. To add firebase to the project I had to go to my project settings for the CharlemagneDB project and then setup and configure the SDK with the npm configuration. It was quite easy, and would use Firebase again in a heartbeat for any service that doesn't require much complex data.
== How I implemented Continuous Integration and Delivery (CI/CD) My goal with this site was to replicate a real world application as much as possible.
When I was looking for a way in which I could build a CI/CD pipeline for this project I weighed up my options between Jenkins, GitLab and Github Actions. As I was already using GitHub at the time as my source control manager, my choice gravitated towards either Github Actions or Jenkins, but I went with GitHub actions because it seemed more convenient in it's setup and use (there is no need to set up or maintain servers - GitHub Actions provides that out of the box).
See GitHub Actions workflow file: https://github.com/mikeyfennelly1/CharlamagneDB/blob/main/.github/workflows/ci.yml[ci.yml file]. Defining the workflow in yml being one of the benefits of GitHub Actions as it is simple in comparison to Jenkins which uses Groovy to define it's pipelines.
See https://github.com/mikeyfennelly1/CharlamagneDB/actions[GitHub Actions build history]
== Where the idea for CharlemagneDB came from
The idea for a database website came from seeing {cockroachDB}[CockroachDB] and liking the name. Then I saw the company {scaleai}[ScaleAI], and also liked their brand (ScaleAI inspired the black and purple color scheme of Charlemagne and ). The name Charlemagne came from the name of the first Holy Roman Emperor. I thought it was a cool name, but also has some signifigance in that CharlemagneDB is supposedly "the emperor of all databases" (as seen on the website homepage).
== Some of my biggest challenges with CharlemagneDB === Flash of unstyled content (FOUC) with GSAP svg animations
This was a problem that I had noticed when I pushed my code to the remote and therefore Github Pages, that the animation for the server svg on the 'loco' page and on the home page weren't behaving as they were locally. The idea was to have an animation that animated this svg element in by drawing the lines in the shape from a blank screen (a lot of people would know this as a trim paths animation). However the elements that were supposed to animate just on opacity, and not stroke length weren't opaque at all on the intial render. on www.mikeyfennelly1.github.io/CharlamagneDB. Then it would animate the opacity from 1 to 0 quickly, and then perform the animation as intended.
I figured out what this problem was by aggressive googling and found that others have had the same problem. The problem was that the browser renders the HTML and CSS before executing the Javascript. As svg is a native HTML element, this meant that the browser was rendering the SVG and adding the appropriate styling before executing the animation (which was of course in the JS). This gave the FOUC specified.
I found that the reason that it worked locally and not remotely was because locally it executed the process of rendering HTML and CSS, and then executing the JS much faster for some reason. When I inspected the local with the Google devtools I saw the number for the opacity change from 1 to 0, but much faster than in the remote.
The solution I found: To add "visibility: hidden" inline styling to the containing div, and instead of animating the opacity. I changed both the opacity and the visibility with GSAP's 'autoAlpha' property. What this does is change the visibility to 'visible' once the opacity is above 0. So once the svg element initially rendered it has an opacity of 1, but a visibility of hidden. GSAP then animates this opacity down to 0 (the first keyframe), and once at the first keyframe animates it back up to 1. This in turn changes the visibility to 'visible', and the animation works as intended.