Forem: Bakare Muideen Adeleke

From Flask App to CI/CD Pipeline with GitHub Actions & Docker Hub

Bakare Muideen Adeleke — Sun, 13 Apr 2025 10:56:23 +0000

DevOps is all about bridging development and operations. For this project, I decided to get hands on by containerizing a simple web application and automating its deployment pipeline.

Here’s how I built a complete CI/CD workflow from scratch using

Python + Flask for the web app
Docker for containerization
GitHub for version control
GitHub Actions for CI/CD
Docker Hub for image hosting

✅ Step 1: Create a Simple Flask Application

1.1 Set up a project folder

1.2 Create a virtual environment and install Flask

1.3 Create your Flask app

Create a file called app.py and paste this in:

1.4 Run the app locally

Then open your browser and go to http://localhost:5000

✅ Step 2: Containerize the Application

2.1 Create a Dockerfile
Create a file called Dockerfile (no extension) in the root folder:

2.2 Create .dockerignore
Create a file named .dockerignore:

2.3 Build the Docker image

2.4 Run the container

Open http://localhost:5000 in your browser again. You should see Hello DevOps!

✅ Step 3: Set Up Version Control

Next, I pushed the project to GitHub to manage changes and integrate CI/CD workflows.

git init
git add .
git commit -m "Run"
git remote add origin https://github.com/adeleke123/flask-devops-app.git
git push -u origin main

🔁 Step 4: Implement CI/CD with GitHub Actions

This is the fun part — automating the build and deployment using GitHub Actions and pushing the Docker image to Docker Hub.

4.1 🔐 Set Up Docker Hub Secrets in GitHub
I created a personal access token in Docker Hub, then added the following secrets to GitHub:

DOCKER_USERNAME – my Docker Hub username
DOCKER_TOKEN – Docker Hub access token

Location: GitHub Repo → Settings → Secrets and variables → Actions

4.2 🛠 Created the GitHub Actions Workflow

Once I pushed the workflow file, the GitHub Action triggered automatically, built my Docker image and pushed it to Docker Hub.

🐳 Final Result

You can find the container image here on Docker Hub:

🔗 https://hub.docker.com/repository/docker/bakare1234844/flask-devops-app

And the source code on GitHub:
🔗 https://github.com/adeleke123/flask-devops-app

12 FACTOR APP METHODOLOGY

Bakare Muideen Adeleke — Tue, 04 Feb 2025 15:24:25 +0000

In the modern landscape of cloud-native applications and continuous deployment, the need for scalable, maintainable and adaptable software systems has never been greater. The 12-Factor App methodology was created to provide a set of best practices for building and deploying web applications in the most efficient way possible, ensuring reliability, scalability and fast iteration cycles. By adhering to these principles, developers can create applications that are not only resilient and easy to maintain but also capable of scaling effortlessly in a rapidly evolving environment.

This methodology is a comprehensive guide, focusing on critical areas like codebase management, dependency handling, configuration, deployment and more. Each factor provides valuable insight into optimizing the way applications are built, managed, and deployed, ensuring that they are both developer-friendly and production-ready.

In this guide, I will explore each of the twelve factors in detail, diving into the specific practices that can be employed to enhance application development, deployment and maintenance. From handling web processes to managing logs, each factor plays an essential role in achieving the agility and scalability that modern web apps demand.

🚀 12-Factor App Methodology: Principle 1 – Codebase
When building scalable and maintainable applications, the 12-Factor App methodology provides a solid foundation. Let's start with the first principle: Codebase.

🔹 One Codebase, Many Deploys
A twelve-factor app follows strict version control practices (e.g., Git, Mercurial, Subversion), ensuring a single source of truth for the application.

🔹 What Does This Mean?
✅ One codebase per app → If you have multiple codebases, you're dealing with a distributed system, not a single app.
✅ Multiple deploys → The same codebase is deployed in different environments (e.g., production, staging, local development).
✅ No shared code between apps → Shared functionality should be extracted into libraries, managed via a package manager.

📌 Key Takeaway: The same codebase powers all environments, ensuring consistency across deployments while allowing different versions to exist in various deploys.

Would love to hear your thoughts! Have you worked with the 12-Factor methodology before? How has it shaped your development workflow? 💬👇

🚀 12-Factor App Methodology: Principle 2 – Dependencies

Managing dependencies effectively is critical for building portable and reliable applications. The second principle of the 12-Factor App methodology focuses on declaring and isolating dependencies.

✅ Explicit Dependency Declaration
A twelve-factor app does not assume system-wide dependencies. Instead, all dependencies are explicitly defined in a dependency manifest (e.g., package.json for Node.js, requirements.txt for Python, Gemfile for Ruby).

✅ Isolation for Consistency
Dependency isolation tools (like venv for Python, Bundler for Ruby, or Docker for containerized apps) prevent "dependency leakage", ensuring every environment has the exact same setup.

✅ Why Does This Matter?

New developers can quickly onboard by installing dependencies with a single command.
No surprises in production—every deploy gets a deterministic build.
Avoids breaking changes due to system-wide updates.

📌 Key Takeaway: If your app relies on external tools like curl or ImageMagick, don't assume they'll always be available—they should be included as dependencies or packaged with the app.

What dependency management challenges have you faced in your projects? Let’s discuss! 💬👇

🚀 12-Factor App Methodology: Principle 3 – Config

One of the most common mistakes in application development is hardcoding configuration values into the codebase. The third principle of the 12-Factor App methodology emphasizes storing config in the environment, ensuring flexibility, security, and scalability.

✅ What is Config?
Configuration includes everything that varies between deploys, such as:
Database URLs and credentials 🛢️
API keys and third-party service credentials 🔑
Environment-specific settings (staging, production, dev) 🌍

❌ Common Mistakes

1️⃣ Hardcoding secrets in code → Security risk if the repo is leaked!
2️⃣ Using config files checked into version control → Easy to accidentally commit sensitive data.
3️⃣ Grouping config into predefined environments → Becomes unmanageable as deployments increase.

✅ The Twelve-Factor Way: Environment Variables
📌 Config should be stored in environment variables (ENV VARs), making it:
✔️ Easier to change per deployment (without modifying code)
✔️ More secure (not stored in version control)
✔️ Language-agnostic (works across any OS or framework)

💡 Example (Node.js):
Instead of:
const DB_URL = "mysql://user:password@localhost:3306/db"; // ❌ Hardcoded!

Use:
const DB_URL = process.env.DB_URL; // ✅ Stored in an environment variable

🔎 Key Takeaway
Your code should be open-source-ready at any moment without exposing sensitive credentials. Separating config from code is not just good practice—it’s essential for scalability and security.

How do you manage configuration in your apps? Drop your thoughts below! 💬👇

🚀 12-Factor App Methodology: Principle 4 – Backing Services

In modern software development, applications rely on multiple backing services—databases, caching layers, messaging queues and third-party APIs. A well-architected app should treat these services as attached resources rather than hardwired dependencies.

✅ What Are Backing Services?
Any external service your app communicates with over the network, such as:
🔹 Databases (MySQL, PostgreSQL)
🔹 Caching systems (Redis, Memcached)
🔹 Message queues (RabbitMQ, Kafka)
🔹 Email services (SMTP, SendGrid)
🔹 File storage (Amazon S3, Google Cloud Storage)

❌ Common Pitfalls

1️⃣ Tightly coupling the app to local services → Makes migration difficult.
2️⃣ Hardcoding service configurations → Limits flexibility and scalability.
3️⃣ Differentiating between local and third-party services → Causes inconsistencies.

✅ The Twelve-Factor Way: Treat Backing Services as Attached Resources
📌 Your app should:
✔️ Access all backing services via environment variables (stored config).
✔️ Be able to swap services without code changes (e.g., switch from local PostgreSQL to a managed database like Amazon RDS).
✔️ Treat local and third-party services the same way (via a standard interface like a URL).
💡 Example (Node.js – connecting to a database): Instead of: const db = mysql.createConnection({ host: "localhost", user: "root", password: "password", database: "mydb" }); // ❌ Tightly coupled to localhost DB
Use:
const db = mysql.createConnection(process.env.DATABASE_URL); // ✅ Swappable service

🔎 Key Takeaway
Your app should not care whether its database is local or cloud-based, whether email is sent via Postfix or SendGrid—it should just work. This approach ensures flexibility, scalability, and resilience.

How do you handle backing services in your projects? Let’s discuss! 💬👇

🚀12-Factor App Methodology: Principle 5 – Build, Release, Run

Deploying an application isn’t just about pushing code—it’s about ensuring a structured, repeatable and reliable deployment process. The 12-Factor App methodology enforces strict separation between Build, Release, and Run stages.

🔄 Three Stages of Deployment

1️⃣ Build Stage 🛠️
Converts source code into an executable bundle.
Fetches dependencies, compiles binaries, and processes assets.
Example: Running npm run build in a Node.js app.

2️⃣ Release Stage 🎯
Combines the build with environment-specific config (e.g., database URLs, API keys).
Produces a versioned, immutable release ready for execution.

3️⃣ Run Stage ⚡
Executes the selected release in a runtime environment.
Cannot modify code—only runs the built release.

Example: Running docker run myapp:v1.0.0 or deploying to a server.

❌ Common Deployment Pitfalls

🚫 Modifying code in production – Changes don’t persist and may cause inconsistencies.
🚫 Mixing build and runtime logic – Leads to unrepeatable deployments.
🚫 Not versioning releases – Makes rollbacks impossible.

✅ The Twelve-Factor Way: Strictly Separate Build, Release, and Run
✔️ The build never changes after it's created.
✔️ Each release gets a unique, immutable ID (v1.0.3, 2025-02-01T10:00Z).
✔️ Rollbacks are easy—just revert to a previous release.
`
💡 Example (Deploying a Node.js app with Docker):

Build stage

docker build -t myapp:1.0.0 .

Release stage (store image with config)

docker tag myapp:1.0.0 myregistry.com/myapp:1.0.0
docker push myregistry.com/myapp:1.0.0

Run stage (execute release)

docker run -d --env-file=.env myregistry.com/myapp:1.0.0

`
🔎 Key Takeaway
A robust deployment process prevents inconsistencies, unexpected failures, and downtime. By enforcing clear separation, you ensure reliability, easy rollbacks, and predictable deployments.

How do you handle deployments in your projects? Let’s discuss! 💬👇

🚀 12-Factor App Methodology: Principle 6 – Processes

A 12-Factor App is designed to run as stateless, share-nothing processes that can scale independently. This ensures reliability, fault tolerance, and horizontal scaling across multiple environments.

🔄 What This Means
✔️ The app is executed as one or more independent processes.
✔️ Each process should be stateless—it doesn’t store persistent data in memory or local disk.
✔️ Persistent data should be stored in backing services like databases, Redis, or S3.
✔️ Processes should be ephemeral—they can be restarted or replaced at any time.

❌ Common Pitfalls to Avoid

🚫 Relying on local memory for state – Data should persist in a database or cache.
🚫 Using "sticky sessions" – Session data should be stored in Redis, Memcached, or another external store, not in-process memory.
🚫 Saving files to the local filesystem – Use cloud storage (e.g., AWS S3, Google Cloud Storage) instead.

✅ The Twelve-Factor Way
✔️ If a process dies, another one can take over without data loss.
✔️ Horizontal scaling is easier—just add more processes to handle traffic spikes.
✔️ Stateless processes work well in distributed systems, Kubernetes, and serverless environments.
`
💡 Example: Scaling a Node.js App

Start a stateless web process

node server.js

Scale up processes dynamically

pm2 scale app 4 # Run 4 instances of the app

💡 Better approach: Store sessions in Redis
const session = require('express-session');
const RedisStore = require('connect-redis')(session);

app.use(session({
store: new RedisStore({ host: 'localhost', port: 6379 }),
secret: 'your-secret',
resave: false,
saveUninitialized: false
}));

`
🔎 Key Takeaway
By making processes stateless and share-nothing, apps become more scalable, resilient, and easier to manage in cloud-native environments.

How do you manage state in your applications? Let’s discuss! 💬👇

🚀12-Factor App Methodology: Principle 7 – Port Binding

One key principle of 12-Factor Apps is that they should be self-contained and export services via port binding. This means that instead of relying on an external web server (e.g., Apache, Nginx, or Tomcat), the app itself should handle incoming requests by binding to a port.

🔄 What This Means

✔️ The app runs independently and listens on a specified port (e.g., 5000, 8080).
✔️ No need for external web servers to inject dependencies at runtime.
✔️ Routing layers (like Nginx, Kubernetes, or a cloud load balancer) can direct traffic to the app.
✔️ Works with multiple protocols (HTTP, WebSockets, XMPP, Redis, etc.).

❌ Common Pitfalls to Avoid

🚫 Relying on platform-specific web servers (Apache, Nginx) to serve the app instead of embedding a web server.
🚫 Assuming a fixed port instead of making the port configurable via environment variables.
🚫 Hardcoding service URLs instead of dynamically resolving them from the config.

✅ The Twelve-Factor Way
✔️ Web servers are included in the app (e.g., Flask for Python, Express.js for Node.js, Spring Boot for Java).
✔️ The app binds to a port and listens for incoming requests.
✔️ Configuration (including the port) is set via environment variables for flexibility.
`
💡 Example: Running a Node.js Server
const express = require('express');
const app = express();

const PORT = process.env.PORT || 3000; // Bind to a port

app.get('/', (req, res) => {
res.send('Hello, Twelve-Factor!');
});

app.listen(PORT, () => {
console.log(App running on port ${PORT});
});
`
🔎 Key Takeaway

By binding services to ports, apps become portable, scalable and cloud-ready. This approach makes it easy to deploy the same app across different environments (local, staging, production) without modification.

How do you manage port binding in your applications? Let’s discuss! 💬👇

🚀12-Factor App Methodology: Principle 8 – Concurrency

The eighth principle of the 12-Factor App is all about scaling out through the process model. In this model, processes are the foundation of concurrency and scaling for web apps.

🔄 What This Means

✔️ Scaling out via the process model means adding more processes to handle increased load, rather than increasing the size of a single process (vertical scaling).
✔️ Processes in a twelve-factor app are designed to be stateless and independent, so they can be scaled horizontally (across multiple machines or containers).
✔️ Apps are built using different process types, each dedicated to handling a specific type of workload:
Web processes for handling HTTP requests
Worker processes for handling background tasks or jobs

📈 Scaling Out
When scaling, rather than modifying the app’s code, you just add more processes. This horizontal scaling is key to a robust, scalable app that can handle high traffic or complex workloads.

🛠 What to Avoid
🚫 Daemonizing processes: Twelve-factor apps do not daemonize. They rely on operating system process managers (e.g., systemd, Kubernetes, Foreman) to handle processes and restarts.
🚫 Using internal multiplexing as the only form of concurrency: For example, using threads or async models alone won’t scale horizontally if you’re stuck with vertical scaling.

✅ The Twelve-Factor Way
✔️ Processes are first-class citizens and can be added or removed easily without disrupting the app’s functionality.
✔️ Each process type is responsible for a single task. For example, one process might handle web traffic, while another might process background jobs or perform data synchronization.
✔️ No single process holds all responsibilities. This enables you to scale parts of the app independently based on demand.

🔎 Key Takeaway
By embracing horizontal scaling via the process model, your app can grow reliably and efficiently to meet increasing demand without compromising performance or flexibility.

How do you approach scaling in your app architecture? Let’s talk about your experiences! 💬👇

🚀12-Factor App Methodology: Principle 9 – Disposability

The ninth principle of the 12-Factor App is all about maximizing robustness with fast startup and graceful shutdown.

⚡️ Fast Startup
Processes in a twelve-factor app should be disposable — meaning they can be started or stopped quickly at any moment. This results in:
✔️ Fast scaling
✔️ Rapid deployment of code/config changes
✔️ Enhanced production deploys robustness

A key trait of disposable processes is short startup times. Ideally, a process should be up and running within seconds, allowing for rapid scaling and more agile releases. The faster a process starts, the quicker it can respond to changes and traffic spikes.

🛑 Graceful Shutdown
Processes also need to handle graceful shutdowns. When a process receives a SIGTERM signal (from the process manager), it should:
Stop accepting new requests
Allow in-progress requests or jobs to finish
Exit cleanly

For example, when a web process gets a SIGTERM:
🔄 It ceases to listen on the service port, ensuring no new requests are processed.
⏳ Ongoing requests are allowed to finish before the process exits.
For worker processes, graceful shutdown means returning unfinished tasks to the queue, ensuring the system can retry jobs as needed.

⚠️ Handling Sudden Death

While graceful shutdowns are ideal, sudden hardware failures or crashes can still happen. A twelve-factor app is designed to handle such failures through mechanisms like:
✔️ Robust queueing backends (e.g., Beanstalkd, RabbitMQ)
✔️ Jobs are safely returned to queues or handled in a way that guarantees no data loss, even during unexpected shutdowns.

✅ Best Practices
✔️ Crash-only design: Systems should be built to handle failures gracefully, and restart automatically when needed.
✔️ Use transactional, idempotent job processing: To ensure jobs can be retried without side effects.

🔎 Key Takeaway
By embracing disposability, apps become more agile, resilient, and robust, capable of handling scaling demands and sudden failures with ease.

How do you handle graceful shutdowns and rapid deployments in your system? Share your experiences! 💬👇

🚀12-Factor App Methodology: Principle 10 – Dev/Prod Parity

The tenth principle of the 12-Factor App emphasizes the importance of keeping development, staging, and production environments as similar as possible to ensure smooth and rapid deployment cycles.

⏳ Close the Gaps

In traditional app development, there have historically been three significant gaps between development and production environments:
Time Gap: Development can take days, weeks, or even months before the code is deployed to production.
Personnel Gap: Developers write code, but different teams (e.g., ops engineers) handle deployment.

✔️ Tools Gap: Developers use a different stack (e.g., SQLite, Nginx) than what’s used in production (e.g., MySQL, Apache).

🕰 The 12-Factor Approach to Closing the Gaps
The twelve-factor app reduces these gaps and aims for:
✔️ Small time gap: Code written by developers gets deployed hours or even minutes later.
✔️ Small personnel gap: Developers who wrote the code are directly involved in deployment and monitoring production behavior.
✔️ Small tools gap: Development and production environments are kept as similar as possible, reducing friction and errors.

🔄 Continuous Deployment
By minimizing the gaps, twelve-factor apps can achieve continuous deployment, where new code and changes are rapidly deployed to production with little friction or downtime.

⚙️ Backing Services in Dev/Prod Parity
A crucial element is maintaining consistency in backing services, such as databases, queues, and caches, between dev and production. Differences in backing services (e.g., SQLite in dev and PostgreSQL in production) can introduce tiny incompatibilities, which lead to bugs and friction in deployment.

Examples of backing services that need parity:
🔗 Database: ActiveRecord in Ruby on Rails, supporting MySQL, PostgreSQL, SQLite.
🔗 Queue: Celery in Python/Django, supporting RabbitMQ, Beanstalkd, Redis.
🔗 Cache: ActiveSupport::Cache in Ruby on Rails, supporting memory, filesystem, or Memcached.

The goal is to resist using lightweight services locally, as this can cause small, difficult-to-diagnose issues when deploying to production.

⚡️ How to Achieve Dev/Prod Parity
Modern packaging systems like Homebrew, apt-get, Docker, and Vagrant make it easy to set up local environments that mimic production setups.
Using declarative provisioning tools like Chef or Puppet ensures your local and production environments are in sync.
Always use the same type and version of services across environments to avoid surprises.

✅ Key Takeaway
By maintaining dev/prod parity, you improve continuous deployment, reduce friction, and ensure that what works in development works in production without unexpected failures.

How do you ensure dev/prod parity in your environment? Share your strategies! 💬👇

🚀12-Factor App Methodology: Principle 11 – Logs

Logs are essential for understanding the behavior and health of a running app. But, according to the 12-Factor App methodology, logs are treated as event streams—continuous and aggregated data that provide real-time visibility into your app's activity.

📜 Logs as Event Streams
Rather than writing logs to files on disk, logs in a twelve-factor app are a stream of time-ordered events generated from the output streams of all running processes and backing services. These logs are unbuffered and continuously flowing as long as the app is running.
The log events are typically in plain text format, one event per line (with multi-line events for backtraces). Importantly, logs have no fixed beginning or end—they keep streaming as the app operates.

🧳 No File Management
The app should never manage its own log files. It doesn’t concern itself with routing or storage of logs. Each running process simply writes its event stream to stdout (standard output).
During local development, developers can view logs in the terminal to monitor behavior.
In production, the environment captures and collates the logs, routing them to destinations like log indexing systems (e.g., Splunk) or data warehousing systems (e.g., Hadoop).

🔄 Routing and Archiving Logs
Logs are not visible to the app, nor can they be configured by it. Instead, they are routed to external destinations for viewing and long-term archival. Tools like Logplex or Fluentd can help with routing, making logs accessible for monitoring and post-mortem analysis.
Logs are captured and processed in ways that help to:

📅 Find specific events in the past.
📊 Graph trends like request volume over time.
🚨 Set up alerts for critical metrics (e.g., errors per minute).
📈 Log Analysis and Power

By sending logs to systems like Splunk or Hadoop, developers gain the power to:
Visualize app behavior over time.
Set up real-time alerting for abnormal patterns (such as spikes in errors).
Build detailed graphs to track things like requests per minute, latency, and error rates.

✅ Key Takeaway

In the 12-Factor App world, logs aren’t just about checking file logs—they are powerful, continuous, and routed to sophisticated platforms for analysis and alerting. Treating logs as event streams maximizes the ability to monitor, scale, and debug the app.

How do you manage logs in your application? What tools do you use to analyze log data? Share your experiences! 💬👇

🚀12-Factor App Methodology: Principle 12 – Admin Processes

When it comes to performing administrative or maintenance tasks in your app, the 12-Factor App methodology recommends that you run these tasks as one-off processes. These tasks are separate from the regular business processes of the app, such as handling web requests, but they are equally important for maintaining and managing the app.

🛠️ What are Admin Processes?
Admin processes include tasks such as:
Database migrations (e.g., rake db:migrate in Rails, manage.py migrate in Django).
Running a REPL shell to interact with the app's live database or inspect models (e.g., rails console for Rails, python for Python).
Executing one-time scripts, such as running a fix for bad records (e.g., php scripts/fix_bad_records.php).

🔄 Consistency with Regular Processes
The key principle here is that admin processes should run in the same environment as your regular long-running processes. This ensures consistency, as they are using the same codebase and configuration.
For example, if your web process uses bundle exec thin start, your migration should use bundle exec rake db:migrate. Similarly, if you're using Virtualenv for Python, admin tasks like migrations should also use the same isolated environment.

🖥️ Local vs. Production
In local development, you invoke admin processes through direct shell commands. In production, you would typically use SSH or another remote command execution mechanism provided by your deploy environment to run the tasks.

✅ Key Takeaway
The 12-Factor App methodology ensures that admin processes are just as reliable and consistent as regular processes. By maintaining a consistent environment and dependency isolation, you can avoid issues where admin tasks fail due to environmental inconsistencies.

What’s your approach for running admin tasks in your apps? Let’s chat in the comments! 💬👇

Day 2: Creating a Signup Page with Express.js – Building the Foundation for User Registration

Bakare Muideen Adeleke — Sun, 01 Sep 2024 08:58:13 +0000

Despite a busy schedule as a Customer Engineer, I found time to explore the process of creating a signup page using Express.js. Here’s a step by step breakdown of the process:

Explanation of Steps

Create an Express App: Start by initializing a new Express.js application.

Create a Port for the Server: Define a port where your server will listen for requests.

Accept Body Data (Middleware): Middleware functions are crucial in Express.js to handle and process requests before they reach your route handlers. Use middleware like express.json() to handle incoming JSON or URL-encoded data.

Have HTML Pages for Signup Form: Design HTML pages to serve as the signup form interface. These pages will be served by your Express app.
Name the API Endpoint as /api/v1/signup: Define the signup API endpoint in your routes. This is where users will submit their signup information.

Check if User Already Exists: Implement logic to verify if the user is already registered in the database.

Validation of Input Data: Validate the data submitted by the user, ensuring it meets the required criteria. Here's an example of the validators:

Use Bcrypt to Encrypt the Password: Utilize the Bcrypt library to hash the user's password for secure storage.

Save User Data to Database: If validation passes, save the user's data in the database.

If Error Occurs, Send an Alert: Handle errors gracefully by sending an alert or error message. For example:

Redirect to Login Page or Dashboard: Upon successful signup, redirect the user to the login page or directly to the dashboard.

Project Directory Structure

Here's the link to the source code

By following these steps and understanding the underlying code, you can create a secure and efficient signup page using Express.js. Stay tuned as I continue to explore more topics in my #100DaysOfMiva challenge.

Next up, I’ll be diving into authentication with a database to further enhance the security and functionality of this signup page.

Day 1: Understanding APIs – The Backbone of Web Communication

Bakare Muideen Adeleke — Wed, 21 Aug 2024 10:38:14 +0000

Welcome to Day 1 of my #100DaysOfMiva challenge! Today, we’re diving into the fascinating world of APIs (Application Programming Interfaces). APIs are crucial in the backend development world, enabling different software systems to communicate seamlessly. Let’s break down the key concepts.

What is an API?

An API, or Application Programming Interface, is a set of rules and protocols that allows one software application to interact with another. Think of it as a bridge that connects different systems, allowing them to exchange information and functionality.

How APIs Work

In a typical web application, the communication happens between a client (the web browser) and a server. Here’s a simplified overview:

Client-Server Model: The client sends a request to the server, which processes this request and sends back a response. The client is typically a web browser, mobile app, or any other application that needs data from a server.

Endpoints and Routes: APIs use endpoints (specific URLs) and routes (paths) to handle requests. Each endpoint corresponds to a particular function or resource. For example, a GET /users endpoint might return a list of users, while a POST /users endpoint could create a new user.

Making API Calls
APIs use HTTP methods to define actions. Here are the most common methods:

GET: Retrieves data from the server. For instance, a request to GET /products would fetch a list of products.

POST: Sends data to the server to create a new resource. For example, POST /orders might be used to place a new order.

PUT: Updates an existing resource. A PUT /users/123 request could update the user with ID 123.

DELETE: Removes a resource. Sending a DELETE /items/456 request would delete the item with ID 456.

HTTP Status Codes
When the server responds to an API request, it also sends an HTTP status code. These codes indicate the result of the request.

200 OK: The request was successful.

201 Created: The request was successful, and a new resource was created.

400 Bad Request: The request was invalid or cannot be served.

404 Not Found: The requested resource could not be found.

500 Internal Server Error: The server encountered an error.

Practical Example

Let’s look at a practical example where i will send a GET request to retrieve a list of users:

Request:

https://jsonplaceholder.org/users

Response:

[ { "id": 1, "firstname": "John", "lastname": "Doe", "email": "johndoe@example.com", "birthDate": "1973-01-22", "login": { "uuid": "1a0eed01-9430-4d68-901f-c0d4c1c3bf22", "username": "johndoe", "password": "jsonplaceholder.org", "md5": "c1328472c5794a25723600f71c1b4586", "sha1": "35544a31cc19bd6520af116554873167117f4d94", "registered": "2023-01-10T10:03:20.022Z" }, "address": { "street": "123 Main Street", "suite": "Apt. 4", "city": "Anytown", "zipcode": "12345-6789", "geo": { "lat": "42.1234", "lng": "-71.2345" } }, "phone": "(555) 555-1234", "website": "www.johndoe.com", "company": { "name": "ABC Company", "catchPhrase": "Innovative solutions for all your needs", "bs": "Marketing" } }, { "id": 2, "firstname": "Jane", "lastname": "Smith", "email": "janesmith@example.com", "birthDate": "1983-02-22", "login": { "uuid": "2a0eed02-9430-4d68-901f-c0d4c1c3bf22", "username": "janesmith", "password": "jsonplaceholder.org", "md5": "c1328472c5794a25723600f71c1b4586", "sha1": "35544a31cc19bd6520af116554873167117f4d94", "registered": "2022-06-10T12:45:20.022Z" }, "address": { "street": "456 Oak Street", "suite": "Suite 200", "city": "Anytown", "zipcode": "12345-6789", "geo": { "lat": "42.3456", "lng": "-71.6789" } }, "phone": "(555) 555-5678", "website": "www.janesmith.com", "company": { "name": "XYZ Corporation", "catchPhrase": "Leading the way in innovation", "bs": "Finance" } } ]

Day 2, I will be discussing authentication in APIs, which is an essential aspect of securing access and ensuring that only authorized users can interact with the API. Stay tuned!

Day 0: Introduction to Backend Development - Setting the Foundation

Bakare Muideen Adeleke — Mon, 19 Aug 2024 21:54:46 +0000

Welcome to Day 0 of my #100DaysOfMiva challenge! Today, I'm diving into the world of backend development, starting with a foundational understanding of what backend development is and how it fits into the broader scope of web development.

What is Backend Development?
In web development, there are two main parts: frontend and backend. The frontend is the part of a website or web application that users interact with, the visuals, buttons, text and layout. It's like the friendly face of a cute puppy. The backend, on the other hand, is the complex and powerful engine that drives the whole application, it's the beast that handles the logic, processes data and ensures everything runs smoothly behind the scenes.

When you visit a website like YouTube, everything you see is the frontend. But behind the scenes, the backend is working tirelessly to handle complex tasks like video streaming, user authentication and data processing.

Frontend vs. Backend

Frontend: The part of the application that users see and interact with, typically built using HTML, CSS and JavaScript.

Backend: The part of the application that users don't see, where all the magic happens, involving servers, databases and APIs.

Understanding Backend Technologies
Backend development involves working with various technologies and languages that power the server-side of web applications. Some popular backend languages include Node.js, Python, Go and PHP. Today, we will focus on Node.js.

Installing Node.js
To get started with Node.js, we will need to install it on our system. The best way to do this is by using Node Version Manager (NVM), which allows us to manage multiple versions of Node.js on the same machine.

Install NVM: Search for Node Version Manager install to find the official installation guide for your operating system (Windows, macOS, Linux). Follow the instructions to install NVM.
Install Node.js: Once NVM is installed, you can install the latest version of Node.js by running the command:

nvm install latest
Or, if you need a specific version:

nvm install v16.14.0

Switch Between Versions: You can switch between installed versions using:

nvm use v16.14.0

How the Internet Works From Browser to Server to Database

When we type a URL into our browser, a fascinating series of events takes place:

Browser Request: Our browser sends a request to the server. For example, when we visit google.com, our browser requests the index.html file from Google's server.
Server Processing: The server receives the request and processes it. The server is like a translator, it understands the language of the backend which is Node.js and knows how to handle the request.
Database Interaction: If the request requires data (like fetching your YouTube video recommendations), the server interacts with the database. The database stores all the data, like user information, videos and comments.
API Calls: To communicate between the browser, server and database, the backend uses APIs (Application Programming Interfaces). An API acts like a bridge, enabling different parts of the application to talk to each other.
Response to Browser: After processing the request, the server sends the required files (like index.html and other assets) back to the browser, which then renders the page we see.

Understanding APIs
APIs are the language of the internet, allowing different systems to communicate. For example, when you request a webpage, the server uses an API call to retrieve the necessary data from the database and send it back to the browser.

Tomorrow, we will explore APIs in more detail, diving into how they work, their importance in backend development and practical examples of API calls.

Stay tuned for Day 1 of the #100DaysOfMiva challenge, where we will build on today's foundation and start coding our first APIs!