During my brief time programming, I'd say Tailwind is among my top three favorite tools/concepts that I've come across (the other two being switching from Javascript to Typescript, and learning reactive programming).

I've started using it recently; a large part of this website's design has been redone using Tailwind, with the Blog/Quiz section being built almost entirely with Tailwind.

Here's a brief demonstration of how Tailwind's utility classes can simplify the design process:

Let's say we want a grid layout; it should have 3 columns on a large screen, 2 columns on a medium screen, and just one column on a phone.

Large screen:
![Screenshot 2024-01-03 at 00-04-25 Screenshot.png](https://api.lkumar.dev/uploads/in-post-images/eac71afa8710b513f6608fdcf18341924feecfa2.png)


Medium screen:
![Screenshot 2024-01-03 at 00-04-10 Screenshot.png](https://api.lkumar.dev/uploads/in-post-images/27c05fe35b5f52d0c6ebc2a67be279be9dd77d9f.png)


Phone screen:
![Screenshot 2024-01-03 000534.png](https://api.lkumar.dev/uploads/in-post-images/7773bfe9d942dd2932b07fe327cfc1d12504fb4f.png)


To achieve this using traditional semantic CSS and stylesheets, we would have to take the following steps:

### 1. Give the target element a class name in our HTML
```
// index.jsx (or index.html)

<div className="main-column">
    {children}
</div>
```

### 2. Add a class definition in our stylesheet; the default columns value will be for mobile

```
/* style.css */

.main-column {
   display: grid;
   grid-template-columns: 100%;
}
```

### 3. Create more 2 more definitions for different media sizes
```
/* style.css */

@media only screen and (min-width: 768px) {
    .main-column {
       grid-template-columns: 50% 50%;
   }   
}

@media only screen and (min-width: 992px) {
    .main-column {
       grid-template-columns: 33% 33% 33%;
   }   
}
```

For styling one element, this is not such a hassle. But when you have to repeat the process for dozens of elements, your stylesheet can quickly become bloated, and I find the process of copying class names from the HTML, switching tabs, pasting them in the stylesheet, then dealing with media queries when necessary, then switching tabs again, to be a real mental drain.

## The Tailwind approach

We can achieve the same styling with one line of code using Tailwind:
```
// index.jsx (or index.html)

<div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3">
    {children}
</div>
```

That's it! No tab switching, no media queries; with Tailwind, we take a mobile-first approach to CSS; any differences that we want to apply on larger screens are done by prefixing classes with breakpoints (md/lg/xl/2xl). So, the first class, "grid," sets the display for this div to grid; the second class specifies that it should have only one column; the next two classes override this on medium and large screens, which take two and three columns, respectively.

### Isn't this pretty much the same as Bootstrap?

Not quite; advantages of Tailwind include:

->Smaller bundle size upon build; Tailwind compiles only the classes that you use to your production CSS
->You can insert custom values for many of Tailwind's classes by using square brackets; for example: text-[35px] or, text-[0.85em], or text-[#f0f0ef]
->In my opinion, it's much more intuitive, the documentation is excellent, and customizing your configuration is extremely simple.

### What are the limitations?

-When you install Tailwind, it overrides some default settings for headers and other elements; it can be tricky if you want to restore these for other imported libraries. For example, this blog uses the react-markdown library, and its formatting didn't work properly due to Tailwind's settings; restoring its formatting was a bit of a headache.

-I think you need to have a solid foundation in CSS and HTML in order to thrive with this framework; it's maybe not as beginner-friendly as, say, Bootstrap. That being said, you probably shouldn't be learning a CSS framework before having a solid understand of vanilla CSS anyway.

### Helpful tips

-Their documentation is great; they have easy-to-follow setup guides for integrating with NextJS and other frameworks. In their docs, press ctrl+k and search for whatever property you want to modify, and you'll find the appropriate utility class.

-Tailwind has a VS-Code plugin with auto-complete, which lets you see the utility classes available, and what their properties are.  

Simplifying frontend dev with Tailwind

The following are some basic notes about setting up an **Nginx server** on a Debian system to serve static content. This isn't a comprehensive tutorial; it's more of an accompaniment to other tutorials, which are accurate but can be lacking in readability to non-experts. 

For a full tutorial on an Nginx setup with Debian, please see: [https://www.linode.com/docs/guides/how-to-install-nginx-debian-10/]() (it's on the Linode site, but applicable to any server running Debian).

## Confusing concepts for beginners

The term **server** can have a few meanings; servers are *computers* whose purpose is to host content and "serve" it (pass it on) to other computers upon request. There are computers built for the sole purpose of being servers, but really any computer can act as a server.

 But **server** can also also refer to *software* used to manage the traffic coming in to the machine. **Nginx, Apache, Express, and Django** are examples of software that acts to route incoming/outgoing web traffic. **Nginx** and **Apache** are two of the most popular Linux-based servers frameworks, and are widely used; **Express** is the most popular server framework used by Javascript developers. The more you read and work with these concepts, the clearer it will become.

# Intro

Nginx is a popular web server; it's able to handle a high volume of simultaneous requests. Broadly speaking, It boasts asynchronous, event-driven architecture, as opposed to the multi-threaded request handling of Apache (that's the extent of my understanding... note to self, learn more about blocking operations)

It's especially well-suited to serving static content. I originally deployed this site as static files hosted with Nginx, before adding some additional NextJS features and moving to Vercel. But I was very happy with its performance on my modest shared Linode server.

It's also commonly used as a **reverse proxy** to connect server software running locally on a machine to the outside world - for example, this site's API server runs **express** on port 5000, and uses Nginx to *relay traffic* between the local express server and the rest of the web.

### reverse proxy diagram:
![reverse proxy diagram.jpg](https://api.lkumar.dev/uploads/in-post-images/27aa4761147538e2a171e6690d76180e2cea1923.jpg)

This article details setting up an Nginx server as the "main server" (not proxy) to host your content. 

### Nginx server hosting static content:
![static nginx diagram.jpg](https://api.lkumar.dev/uploads/in-post-images/561a2d15fb9a9fd4d8c0500f09032083ba6bb630.jpg)


So, here are some notes on setting up a static site with Nginx, specifically on a Debian system.

**Before you begin**

-Set up a cloud instance running Debian; SSH into your instance. If you're running a Linode, in the dashboard for your instance you'll see a column, "Access," with code to paste into your terminal to connect with your cloud machine.

**1. Install Nginx on your system**

Once you've connected to your instance, run these commands:
```
sudo apt update
sudo apt install nginx
```

**2. Setting up your site config file**

I found the documentation/tutorials confusing for this; there are two folders where it's possible to set up your server's configuration file: 

 => /etc/nginx/conf.d 
 => /etc/nginx/sites-available

I don't know why there are two options, and why some people recommend one or the other, but I went with a tutorial recommending the second. 
In /etc/nginx/sites-available, create a file with your sites name, eg:

```
touch mysite.io
```

then, edit the file with vim (or nano):

```
sudo vim mysite.io
```

Add a basic configuration for your server block:

```
server {
    listen 80;
    listen [::]:80;
    server_name  mysite.io;

    root /var/www/mysite.io
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}
```

This tells nginx to listen on port 80, for requests to our site, mysite.io; when requests are made here, nginx must look in the folder, **/var/www/mysite.io**, for the index.html file, and serve it to the client.

We need to create a symlink between the sites-available folder where we created this server block, and the sites-enabled folder:

```
sudo ln -s /etc/nginx/sites-available/mysite.io /etc/nginx/sites-enabled/
```
This will copy your file to the sites-enabled folder, and any changes that you make in the future to **sites-available/mysite.io** will be applied to **sites-enabled/mysite.io**

**3. Add your site's html**
In /var/www/ , create a folder for your site:
```
mkdir mysite.io
```

Within this folder, for now, just create a basic index.html file:
```
<h1>Hello Murl</h1>
```
This is the location that we told Nginx to look in when it gets requests on port 80 for our domain. 

**4. Reload and test**
Test your Nginx configuration:
```
sudo nginx -t
```

Then, reload the server:
```
sudo nginx -s reload
```

Now, when you type your server's IP address in the browser, you should get this site. The next steps are configuring your DNS, and obtaining an SSL certificate to serve your site over HTTPS (Certbot is a good option). For more details, I recommend the tutorial that I linked to at the top of this page.

## Good to know 

**Uploading files**

You can use the secure copy command for copying your folder of static assets from your local machine to your server:

```
scp -r <path-to-folder-on-local-machine>\* root@<your-server-ip>:/var/www/<your-site-name>
```

You'll be prompted to enter your password; you can also use an SSH key for this process.

**Security**

Your server will need a firewall; many cloud computing providers such as Akamai and Amazon have their own firewalls you can use; alternatively, you can install uncomplicated firewall (ufw) on your instance and use that. 





Hosting static content with Nginx - Basic setup

It's useful to have at least a basic understanding of DNS and what it means for your website.

The most important thing to understand is that DNS tells computers which I.P. addresses to go to when our domain is typed into a browser (or some other internet-capable software).

For example, check out some DNS records for this site:

![dns-diagram.jpg](https://api.lkumar.dev/uploads/in-post-images/6ccec43d7d9882e1a02215b0ef3c85ea375fc30e.jpg)
Above are three DNS records; pay special attention to the **name** and **data** columns. The **name** values tell us about some variation of our domain name (these name values refer to lkumar.dev, api.lkumar.dev, and www.lkumar.dev). @ always refers to the base domain name (eg; lkumar.dev, google.com, wikipedia.org). Any other value here refers to a sub-level domain appended to the front of our domain name (api here refers to: api.lkumar.dev; www refers to www.lkumar.dev).

The **data** values tell us where these different names will point to;  different variations of our domain can point to different I.P. addresses! So, the main website, lkumar.dev, is hosted at a server with I.P. address 76.76.21.21, located in Washington if you must know. The website's API (which manages media uploads and connects to our database) is hosted on a different server, at I.P. address 172.105.26.152, at some data center in Toronto.

Notice that for name value **www** (meaning www.lkumar.dev), it points to our main domain; so, any request made to www.lkumar.dev will be routed to lkumar.dev, which will point us to the I.P. address for our **@** name value. This is an example of a **CNAME record**, which *maps a hostname to another hostname.* 

Whereas the other two records are **A records**, which *map a hostname to an I.P. address.* 

(*hostname* just means some human-readable name; a root domain name or some variation (subdomain) on it.)

That's the main information that you need to know to navigate setting up your hosting.  If you want, you can read more about DNS below.

## Simplest explanation

DNS stands for **domain name system**. It's a way of determining which IP addresses are connected to a **domain** (domains are website URLs like www.google.com). Your domain, example.com, has associated **DNS records** that give instructions about the IP address that can be used to find your website.

## Slightly more complex explanation

A **DNS server**, or **name server**, provides information about sites' **DNS (domain name system)** information. That is to say, a DNS server has the DNS records for a site, meaning the IP addresses associated with that site.

When you buy a domain on GoDaddy.com, your domain's DNS records (IP addresses associated with that domain) are hosted on GoDaddy's name servers, or DNS servers. However, you can choose to move your DNS records to another company's DNS server, or create your own. 

### Metaphor attempt #1

I want to borrow a sled (**website content**) from John's house (**domain**). I need John's address (**IP address**) to get to his house. If I look up his name in the phone book, I find his address (these two together are the **DNS record**; the phone book is the **DNS server,** or **name server**, with a bunch of peoples' DNS records). 

### Simile with like or as?
A website's **content** is like some cake at your friend's house. The site's **domain** (cake.com) is like your friend's house. The website's **IP address** is like your friend's address. You need the address to get to the cake at her house. Your computer needs the **IP address** to access the the **content** at that **domain**. *You can use her name to get her address, to get the cake. Your computer can use a domain name, to get an IP address, to access the content.*

## Domains and subdomains

**Top-level-domains** are the last part of a website: for example: 
.com   .ca   .org   .dev   .io   .nz

**Root domains / Main domains** are a top-level domain plus one word (second-level domain). For example:

example.com
dogs.ca
cats.org
lkumar.dev

**Subdomains** are a top-level domain plus a second-level domain plus a third-level domain. For example:

www.example.com
info.dogs.ca
www.lkumar.dev
api.lkumar.dev


That's it for this summary of basic DNS concepts; for some interactive practice, check out the quiz section.


Summary of lingo related to Domain Name Systems

What is DNS?

Welcome to the blog section of the site! This section contains blog posts and little quizzes related to all things programming and web development. 

## Who is it for?

A few people...

### Employers/Clients 
This is built with employers in the web development world in mind, to demonstrate my knowledge of the field.

### Developers
I'll try to keep posts short and simple. Personally, when starting out I found it difficult to comprehend a lot of the documentation and explanations offered by seasoned developers. So, I will try here to communicate concepts clearly. Some posts will assume prior knowledge in a topic, others will not.

### Myself
Typing these things out helps me to remember them; the quizzes are also quite useful for the same reason. And, building out and maintaining the back-end is a good exercise for me.

## What are the quizzes like?

I like using quizzes to reinforce concepts and consolidate learning. They've been a useful tool for me for a few years; 

I originally built a simple quiz interface for the terminal using python... 

![Screenshot 2024-01-08 120733.png](https://api.lkumar.dev/uploads/in-post-images/2ca0e916ed3c5ed21b4f1b3c0a1f9b5e74c7145e.png)

And later did something more elaborate for Android which incorporated basic voice commands:

![android-formatted-wide.jpg](https://api.lkumar.dev/uploads/in-post-images/2137c181d5bd8faea4d7e6da3986250b90a047fe.jpg)

 My web app for teachers is the most detailed quiz creation/administration tool I've done, incorporating media uploads, marking on the cloud, and a dashboard to keep track of student progress (see [https://www.youtube.com/watch?v=wWu1UZ6Drlw]() for a basic overview).



All that to say, I like quizzes as a learning/review tool. This site has a pretty basic quiz interface, but I find it useful. I try to build quizzes that focus on understanding code, rather than memorizing it. Check it out at the bottom of the blog section!

# How was this made?

The data for this section is stored in a MongoDB Atlas instance. It's connected to an API running express on a remote server. All of the quizzes and blog posts are rendered and cached at build time, for quick loading. 

# So, now what?

Browse the blog section, and see if there are any posts or quizzes that interest you! Or do anything else.

About this section of the website

Awesome resources that I would recommend to anyone learning web development, in no particular order:


## Brad Traversy's 20 Web Projects with Vanilla Javascript
[https://www.udemy.com/course/web-projects-with-vanilla-javascript/]()

*mainly for beginners

These are simple, but impressive projects; most take less than an hour to complete. Some highlights for me were a text-to-speech app, and a "movie-booking" UI. As a beginner, I found this course very empowering. It isn't comprehensive, but it teaches a bunch of useful javascript methods, as well as some vanilla CSS and html.

## Coding in Flow
[https://www.youtube.com/c/codinginflow]()

Florian is an awesome resource for both Android and Web development; very thorough in his explanations of architectural patterns (android), and MERN/NextJS (web). He's provided many hours of quality, free content. He also has some paid courses that you can check out if you like his style; the backend for this blog is modeled after his tutorials.

## Fireship.io
[https://fireship.io]()

Jeff has a lot of useful and hilarious free resources on Youtube, and his site also has a bunch of informative, ultra-concise instructional videos mostly focusing on web development and Firebase services, but also touching on Flutter and Dart. It's not for beginners, but if you've got some experience, I recommend it.

## Josh W. Comeau
[https://www.joshwcomeau.com/]()

One of the best tech writers I've come across; his written tutorials are clear and digestible, and visually satisfying. I've found his writing about React really helpful; he also writes about CSS and javascript in general.

Some of my favorite resources for learning

Some favourite educators in the tech space

### A brief summary of NextJS features (using the Pages routing system):

NextJS lets you render React Pages on the Server (Server-side rendering)

This means that any assets (Images, fonts, data from APIs) **will be loaded on the Next server, and delivered to the client's browser as a fully loaded page**. This is better for SEO than loading Data within the page's main react component, as search engine crawlers will find more meaningful content when they load your page (not just the initial react javascript that must execute to render HTML).

You can either do this rendering **on-demand every time that a page is loaded**, or you can **pre-build a page so that all of its assets are ready**, and the html can be immediately sent upon request. The latter strategy makes sense for pages that don't frequently change. It's the best configuration for SEO, as search engine crawlers will come across a fully ready HTML page. It's also ideal for visitors to your website, as page load time is fastest this way.

With Next, you can decide how each individual page will be rendered: with assets fetched on-demand upon request by a visitor to your site, or with all assets pre-fetched, and the page fully built and cached in server memory when the website code is compiled for deployment. 

When you compile a NextJS project for production, all of the static pages are pre-built and cached in memory. They are **compiled at build time.** 


### Two server-side rendering strategies

#### 1. Fetch props for page when the project is built:
```
// [page].jsx

export const getStaticProps = async ({ params }) => {
    try {
        const slug = params.slug.toString();
        const resource = await api.getResource(slug);
        return { props: { resource }};
    } catch (e) {
        throw e;
    }
};

const page = ({ resource }) => {
  return <>{resource.text}</>
}

```

The **getStaticProps** constant gives our NextJS server instructions on how to retrieve the data for this page. It will fetch the resources and compile the page when the project is built, so that the page is **ready to serve** whenever a client requests it.

#### 2. Fetch props for page when the page is requested:
```
// [page].jsx

export const getServerSideProps= async ({ params }) => {
    try {
        const slug = params.slug.toString();
        const resource = await api.getResource(slug);
        return { props: { resource }};
    } catch (e) {
        throw e;
    }
};

const page = ({ resource }) => {
  return <>{resource.text}</>
}

```
The only difference between this block of code and the previous one is the constant name - here, it's **getServerSideProps**; this tells your NextJS server to fetch any resources for this page **upon request** by a client, then render the page with these resources, and **then serve it to the client**.


The fastest page load times (and best SEO optimization) will come with option #1; but option #2 guarantees the most up-to-date data will be served to the client, because the data is re-fetched every time the page is requested. 

So, which strategy you choose will depend on the function of your page. 

## Strategies for this site

Basically, this site uses these strategies as follows:

**Client-facing blog posts and quizzes** use the first strategy; since these posts are the main focus of this section, it makes sense to prioritize the user experience with optimal load times.

**Editing blog posts and quizzes as admin** uses the second strategy; for myself as admin, I don't care about waiting an extra half-second-to-few-seconds for load time. Also, when editing a post, it's important that it be the latest version.

### Updating edited posts

If we never edit the client-facing blog posts, then we don't need to take any additional steps; the pages that are built when the project is compiled will always be the same. However, *if we update posts, we need these updates to be reflected in the pages cached on the server.* To achieve this, we can combine our compile-time rendering with **Incremental Static Regeneration**. This is a strategy where the server **rebuilds pages** to reflect updates, either *at regular intervals or on demand* .

Here's a page that will be re-built when a client requests it, if the request happens more than 60 seconds after the last time it was built:
```
export const getStaticProps = async ({ params }) => {
    try {
        const slug = params.slug.toString();
        const resource = await api.getResource(slug);
        return { 
          props: { resource },
          revalidate: 60
       };
    } catch (e) {
        throw e;
    }
};
```
The **revalidate** property in our return object tells our server that this page should be rebuilt if a request is made 60 seconds after the previous rebuild. So, if client A requests the page Monday morning, and the next client, B, requests it Monday afternoon, it will be rebuilt when client B requests it.

### On-Demand revalidation

This is more complex. We make use of NextJS's *api routes*, which represent server endpoints on our NextJS server. These endpoints export a handler function which takes a request and response object. The response objects on these functions have access to a next method, **revalidate**; when you call this method, and pass it a route on your website, it tells your server to look up that route's **getStaticProps** method, and use it to rebuild the page. 

So, for the blog posts on this site, the process is:
 =>1. A post is edited in the **browser**
 =>2. The post is updated in the **database**
 =>3. We send a request to our **NextJS server**, telling it to revalidate the page for that post
  =>4. The server runs the method **getStaticProps** that this page uses, and rebuilds the page with the newest data

Here are those steps with relevant code:

### 1. A post is edited in the **browser**
Here's how we send the edited post to the server:
```
const response = await api.post(`/blog/edit/${blogID}`, postData);
```

### 2. The post is updated in the database
```
// express server

const updateResponse = await BlogModel.findByIdAndUpdate(blogId, postData);
```

### 3. We send a request to our NextJS server, telling it to revalidate the page for that post

```
// express server
await axios.get(`${env.WEBSITE_URL}/api/revalidate-post/${slug}?secret=${env.POST_REVALIDATION_KEY}`);
```
### 4a. The NextJS server receives this request, and after verifying that it's legitimate, calls the code to revalidate

```
// pages/api/revalidate/[blog].ts

await res.revalidate(`/blog/${slug}`);
```

### 4b. The server runs the method getStaticProps that this page uses, and rebuilds the page with the newest data

```
// pages/blog/[slug].tsx

export const getStaticProps = async ({ params }) => {
    try {
        const blog = await fetchBlog(params.slug);
        return { props: { blog }};
    } catch (e) {
        throw e;
    }
};
```

And that's it; that last strategy is pretty complex, but if you can understand it, you'll have a pretty solid grasp of the Next pages routing system. 

For more reading, check out the NextJS docs on ISR:
[https://nextjs.org/docs/pages/building-your-application/data-fetching/incremental-static-regeneration]()



ABOUT THIS SECTION OF THE WEBSITE

OVERVIEW OF BLOGS & QUIZZES

READING

Recent Posts

HOSTING

Hosting static content with Nginx - Basic setup

EDUCATION

Some favourite educators in the tech space

NEXTJS

Incremental Static On-Demand Revalidation

SEO

Google indexing issues with 301 redirects

QUIZ

Quizzes

AUTHENTICATION

Username+Password login with PassportJS

CSS

Tailwind utility classes

PROGRAMMING

Intro to algorithms

Test yourself