95 110 case studies (#111)

* add APIs for case studies

* dynamise blog to story

* update blogs to be more generic

update the existing components and types to be more generic so they can be reused by case studies

* introduce case studies

* ✨ feat: Use generalized type in API

* 🐛 fix: pages for no blogs and case studies

* 📜 BLOG: Docker+Nginx

_blogs/docker-nginx-reverse-proxy-local-dev.md

@@ -0,0 +1,233 @@
+---
+title: "Mastering Local Backend Development: Docker & NGINX as a Reverse Proxy for Efficient Testing"
+excerpt: "Learn how to set up a local backend environment using Docker and NGINX as a reverse proxy. Streamline your development and testing with this step-by-step guide, optimized for efficient scaling and traffic management."
+coverImage: "/assets/blogs/docker-nginx-reverse-proxy-local-dev/cover.webp"
+date: "2024-10-20T18:13:00.000Z"
+author:
+ name: Umair Jibran
+ picture: "/assets/authors/jibran.webp"
+ogImage:
+ url: "/assets/blogs/docker-nginx-reverse-proxy-local-dev/cover.webp"
+tags:
+ - Docker
+ - NGINX
+ - Backend Development
+ - Reverse Proxy
+---
+
+When developing distributed applications that rely on multiple services, it's crucial to replicate a production-like environment locally. This setup helps you catch bugs early, optimize performance, and reduce the risk of costly errors during deployment. Docker and NGINX are powerful tools for this purpose: Docker containerizes services, while NGINX acts as a reverse proxy to manage traffic and expose a unified interface via a single port.
+
+In this guide, we’ll explore how to:
+
+1. Set up a backend environment locally using Docker.
+2. Configure NGINX as a reverse proxy to efficiently route traffic between services.
+3. Expose all services on a single port for streamlined access.
+
+Whether you're a backend developer managing multiple microservices or someone scaling containerized applications, this tutorial will enhance your local development environment.
+
+## Step 1: Setting Up the Docker Environment
+
+We’ll start by simulating a local backend environment using Docker. Docker offers a streamlined way to containerize services, making it easier to replicate complex production environments on a local machine. Our goal is to run a backend service on port 4000, with requests being routed through NGINX.
+
+### Prerequisites:
+
+- **Docker** installed on your system (Windows, macOS, or Linux).
+- Basic understanding of Docker commands and containerization.
+
+### Steps:
+
+1. **Create a Dockerfile** for your backend service. If you are using a **Node.js** backend, your `Dockerfile` might look something like this:
+
+ ```dockerfile
+ # Use the official Node.js image
+ FROM node:22-alpine
+
+ # Create and set the working directory inside the container
+ WORKDIR /app
+
+ # Copy package files and install dependencies
+ COPY package*.json ./
+ RUN npm install
+
+ # Copy the rest of the application code
+ COPY . .
+
+ # Expose the port the app runs on
+ EXPOSE 4000
+
+ # Command to start the backend service
+ CMD ["npm", "start"]
+ ```
+
+2. **Build the Docker image.** In the directory containing your Dockerfile, run the following command:
+
+ ```bash
+ docker build -t backend-service .
+ ```
+
+3. **Run the container** with this command:
+
+ ```bash
+ docker run -d -p 4000:4000 backend-service
+ ```
+
+This command runs your backend service inside a Docker container, mapping **port 4000** on the host machine to **port 4000** inside the container. You can test the service by visiting `http://localhost:4000` in your browser.
+
+To stop a running container, use:
+
+```bash
+docker stop <container_id>
+```
+
+Replace `<container_id>` with the actual ID of the running container, which you can find using:
+
+```bash
+docker ps
+```
+
+While you now have a working backend service, we’re aiming for a more complex and realistic setup. Next, we’ll introduce **NGINX** to manage traffic between multiple services using **Docker Compose**.
+
+## Step 2: Configuring Docker Compose for Service Orchestration
+
+Instead of manually managing individual containers, we’ll use **Docker Compose** to define and orchestrate multiple services, including our backend and NGINX.
+
+### Why Use Docker Compose?
+
+- **Multi-Service Management**: Easily manage multiple services in a single configuration file.
+- **Scaling**: Define replicas of services for load balancing.
+- **Portability**: Simplifies the process of spinning up environments locally and in production.
+
+### Docker Compose Configuration
+
+Here’s a basic `docker-compose.yml` file to define our backend service with **3 replicas**:
+
+```yaml
+# docker-compose.yml
+name: find-a-cat-backend
+
+services:
+ app:
+ build: .
+ command: node server
+ ports:
+ - "4000" # Expose the app on port 4000 but don't bind it to the host
+ # Load environment variables from a file
+ env_file:
+ - .env
+ # Define the number of replicas and resource limits
+ deploy:
+ mode: replicated
+ replicas: 3
+ resources:
+ limits:
+ cpus: "2"
+ memory: "4096M"
+```
+
+- **Replicas**: Defines 3 instances of the backend service.
+- **Resource Limits**: Limits CPU usage to 2 cores and memory to 4 GB per container.
+- **Environment Variables**: Use an `.env` file to manage your backend configuration.
+
+Once your `docker-compose.yml` file is ready, run the services with:
+
+```bash
+docker-compose up --build
+```
+
+This command will build and run all services defined in your `docker-compose.yml` file. Now that we have a scalable backend service, let’s move on to setting up **NGINX** as a reverse proxy.
+
+## Step 3: Configuring NGINX as a Reverse Proxy
+
+With your backend running in Docker, the next step is to use **NGINX** as a reverse proxy. The reverse proxy directs incoming requests to the correct service, while exposing only one port, simplifying access.
+
+### Why Use NGINX as a Reverse Proxy?
+
+- **Unified Access**: Expose multiple services through a single port.
+- **Security**: Hide service details from the outside world.
+- **Performance**: NGINX offers load balancing and caching, improving overall performance.
+
+### NGINX Configuration
+
+1. **Create an NGINX Configuration File**:
+ Create a file named `nginx.conf` in your project directory with the following configuration:
+
+```nginx
+ events {}
+
+ http {
+ client_max_body_size 100M; # Set the maximum request size
+
+ upstream backend {
+ server app:4000; # Define the backend service running on port 4000
+ }
+
+ server {
+ listen 80;
+ location / {
+ proxy_pass http://backend;
+ proxy_set_header Host $host;
+ proxy_set_header X-Real-IP $remote_addr;
+ }
+ }
+ }
+```
+
+2. **Update the `docker-compose.yml`**:
+
+ Add an NGINX service to your `docker-compose.yml` file:
+
+ ```yml
+ nginx:
+ container_name: nginx
+ image: nginx:alpine
+ ports:
+ - "80:80"
+ volumes:
+ - ./nginx.conf:/etc/nginx/nginx.conf
+ depends_on:
+ - app
+ ```
+
+ This configuration sets up an NGINX service that listens on **port 80** and forwards all requests to the backend service running on **port 4000**. The `depends_on` directive ensures that NGINX waits for the backend to be ready.
+
+3. **Rebuild and Run**:
+
+ Now, run both services together using:
+
+ ```bash
+ docker-compose up --build
+ ```
+
+ At this stage, NGINX is set up as a reverse proxy, routing incoming traffic on **port 80** to any of the 3 backend replicas running on **port 4000**.
+
+At this point, NGINX is set up to act as a reverse proxy, forwarding all incoming traffic on **port 80** to any of the 3 services running backend on **port 4000**.
+
+## Step 4: Testing and Troubleshooting
+
+One of the advantages of using NGINX is that it allows you to route multiple services through a single port, simplifying the interface for external clients or other services. Here, NGINX handles all the traffic management, which makes scaling the architecture easy.
+
+### Testing the Setup
+
+With both the backend and NGINX running, test the setup by navigating to `http://localhost` in your browser. You can also test it using **curl**:
+
+```bash
+curl http://localhost
+```
+
+This request should return the response from one of the backend services. Since NGINX is acting as a reverse proxy, it will forward traffic to any available replica.
+
+### Common Issues and Solutions
+
+- **502 Bad Gateway**: If NGINX returns a 502 error, it may be unable to connect to the backend service. Ensure both NGINX and the backend service are running and can communicate on the same Docker network.
+- **Port Conflicts**: If port 80 is already in use, modify the `docker-compose.yml` file to expose NGINX on a different port (e.g., `8080:80`).
+- **Container Logs**: Use the following command to inspect logs and identify issues:
+
+ ```bash
+ docker-compose logs
+ ```
+
+## Conclusion
+
+By combining Docker and NGINX, you can efficiently replicate a complex backend environment for local development. Docker Compose simplifies managing multi-service setups, while NGINX handles traffic routing and load balancing across services. This architecture not only mirrors production environments but also streamlines testing and scaling.
+
+Whether you’re developing microservices or handling a monolithic backend, this approach provides flexibility and scalability. By following these steps, you can create a local environment that closely resembles your production setup, improving both your workflow and your deployment pipeline.

src/app/(blogs)/blogs/[slug]/page.tsx

@@ -2,8 +2,8 @@ import { Metadata } from "next";
 import { notFound } from "next/navigation";
 import { getAllBlog, getBlogBySlug } from "@/lib/api";
 import markdownToHtml from "@/lib/markdownToHtml";
-import { BlogBody } from "@/components/BlogBody";
-import { BlogHeader } from "@/components/BlogHeader";
+import { StoryBody } from "@/components/StoryBody";
+import { StoryHeader } from "@/components/StoryHeader";
 
 import profile from "@/data/profile.json";
 
@@ -19,13 +19,13 @@ export default async function Blog({ params }: Params) {
  return (
  <main>
  <article className="container mx-auto">
- <BlogHeader
+ <StoryHeader
  title={blog.title}
  coverImage={blog.coverImage}
  date={blog.date}
  author={blog.author}
  />
- <BlogBody content={content} />
+ <StoryBody content={content} />
  </article>
  </main>
  );

src/app/(blogs)/blogs/page.tsx

@@ -1,23 +1,32 @@
-import { HeroBlog } from "@/components/HeroBlog";
+import { HeroStory } from "@/components/HeroStory";
 import { MoreStories } from "@/components/MoreStories";
 import { getAllBlog } from "@/lib/api";
 
 export default function Index() {
- const allBlog = getAllBlog();
- const heroBlog = allBlog[0];
- const moreBlog = allBlog.slice(1);
+ const allBlogs = getAllBlog();
+ const heroBlog = allBlogs[0];
+ const moreBlogs = allBlogs.slice(1);
+
+ if (allBlogs.length === 0) {
+ return (
+ <main className="container mx-auto flex justify-center">
+ <div>oops... I should write some up</div>
+ </main>
+ );
+ }
 
  return (
  <main className="container mx-auto">
- <HeroBlog
+ <HeroStory
  title={heroBlog.title}
  coverImage={heroBlog.coverImage}
  date={heroBlog.date}
  author={heroBlog.author}
  slug={heroBlog.slug}
  excerpt={heroBlog.excerpt}
+ type={heroBlog.type}
  />
- {moreBlog.length > 0 && <MoreStories blogs={moreBlog} />}
+ {moreBlogs.length > 0 && <MoreStories stories={moreBlogs} />}
  </main>
  );
 }

src/app/(caseStudies)/case-studies/[slug]/page.tsx

@@ -0,0 +1,70 @@
+import { Metadata } from "next";
+import { notFound } from "next/navigation";
+import { getAllCaseStudies, getCaseStudyBySlug } from "@/lib/api";
+import markdownToHtml from "@/lib/markdownToHtml";
+import { StoryBody } from "@/components/StoryBody";
+import { StoryHeader } from "@/components/StoryHeader";
+
+import profile from "@/data/profile.json";
+
+export default async function CaseStudy({ params }: Params) {
+ const caseStudy = getCaseStudyBySlug(params.slug);
+
+ if (!caseStudy) {
+ return notFound();
+ }
+
+ const content = await markdownToHtml(caseStudy.content || "");
+
+ return (
+ <main>
+ <article className="container mx-auto">
+ <StoryHeader
+ title={caseStudy.title}
+ coverImage={caseStudy.coverImage}
+ date={caseStudy.date}
+ author={caseStudy.author}
+ />
+ <StoryBody content={content} />
+ </article>
+ </main>
+ );
+}
+
+type Params = {
+ params: {
+ slug: string;
+ };
+};
+
+export function generateMetadata({ params }: Params): Metadata {
+ const CaseStudy = getCaseStudyBySlug(params.slug);
+
+ if (!CaseStudy) {
+ return notFound();
+ }
+
+ const title = `${CaseStudy.title} | Case Study | ${profile.name.firstName} ${profile.name.lastName}`;
+
+ return {
+ title,
+ openGraph: {
+ title,
+ images: [CaseStudy.ogImage.url],
+ },
+ twitter: {
+ card: "summary_large_image",
+ },
+ description: CaseStudy.excerpt,
+ authors: [CaseStudy.author],
+ keywords: CaseStudy.tags,
+ };
+}
+
+export async function generateStaticParams() {
+ const caseStudies = getAllCaseStudies();
+
+ return caseStudies.map((caseStudy) => ({
+ slug: caseStudy.slug,
+ }));
+}