This repository uses a multi-environment GitLab CI/CD pipeline for a Spring Boot Reactive (WebFlux) application.

The pipeline provides:

• Automated build and deployment
• Parallel deployment to multiple test environments
• Mattermost notifications with changelog support
• Automatic handling of unavailable GitLab runners
• Deployment status tracking
• Production deployment authorization controls
• Deployment failure notifications with job logs

Architecture

Test Environments

Both environments build and deploy independently.

Pipeline success requires at least one test deployment to complete successfully.

Pipeline Stages

notify_start
    │
    ▼
build_test
    ├── build_test_th
    ├── build_test_kp
    └── pending_job_monitor_build_test
    │
    ▼
deploy_test
    ├── deploy_test_th
    ├── deploy_test_kp
    └── pending_job_monitor_deploy_test
    │
    ▼
pipeline_complete
    │
    ▼
deploy_prod (manual)

Stage Details

1. notify_start

Purpose

Sends a pipeline start notification to Mattermost.

Features

• Includes pipeline link
• Includes changelog
• Displays recent commits

Example:

🚀 Build STARTED

Changes in this build:

- abc123 Fixed login issue
- def456 Added Kafka consumer
- ghi789 Updated API validation

2. build_test

Jobs

build_test_th

Builds application for TH environment.

build_test_kp

Builds application for KP environment.

Build Process

1. Copy example property files
2. Generate environment-specific property file
3. Run Gradle build

./gradlew clean build \
-Pspring.config.additional-location=file:./application-test.properties

Generated Artifacts

build/libs/spring-boot-template-cqrs-1.0.0.jar
application-test.properties

Artifacts expire after:

1 day

3. Runner Availability Monitoring

pending_job_monitor_build_test

Problem:

If a dedicated runner is unavailable, jobs can remain stuck in Pending.

Solution:

After 30 seconds:

1. Wait configured timeout
2. Query GitLab API
3. Detect pending jobs
4. Cancel stuck jobs automatically

Current timeout:

PENDING_JOB_TIMEOUT=15

4. deploy_test

Jobs

deploy_test_th

Deploys build artifact to TH environment.

deploy_test_kp

Deploys build artifact to KP environment.

Deployment Flow

Step 1

Backup existing JAR

old.jar -> old.jar_bkp

Step 2

Upload new JAR

scp build/libs/app.jar

Step 3

Upload generated property file

scp application.properties

Step 4

Execute remote deployment command

Example:

docker compose restart

or

systemctl restart my-service

Deployment Validation

Deployment only proceeds if:

Build succeeded
AND
Artifact exists

Otherwise deployment is skipped.

5. Runner Availability Monitoring (Deploy)

pending_job_monitor_deploy_test

Automatically cancels deploy jobs that remain pending due to unavailable runners.

6. pipeline_complete

Purpose

Determines final pipeline status.

Success Criteria

Pipeline succeeds if:

TH deployment succeeded
OR
KP deployment succeeded

Failure Criteria

Pipeline fails if:

TH deployment failed
AND
KP deployment failed

Examples:

7. deploy_prod

Type

Manual deployment.

Authorization

Only approved GitLab users can deploy to production.

Validation:

GITLAB_USERS_IDS_FOR_PROD_DEPLOY

contains:

GITLAB_USER_ID

Unauthorized users receive:

❌ User is not authorized for production deployment

Production Deployment Steps

1. Backup current JAR
2. Upload new JAR
3. Upload property file
4. Execute production deployment command
5. Send Mattermost notification

Mattermost Notifications

Start Notification

Color:

Blue

Example:

🚀 Build STARTED

Deployment Success

Color:

Purple

Example:

✅ TH Deploy SUCCESS

Pipeline Success

Color:

Green

Example:

🎉 Pipeline SUCCESS

Failure Notification

Color:

Red

Includes:

• Error details
• Last 50 log lines
• Pipeline link
• Job URL

Example:

❌ Deploy FAILED

Job Log:
...

Changelog Generation

Each pipeline automatically generates a changelog.

Information included:

• Commit hash
• Author
• Commit message

Example:

- abc123 Added Kafka consumer [John]
- def456 Fixed Redis configuration [Mike]

Limits:

Required GitLab Variables

General

APP_NAME

GYRI_TEST_PROPERTY_FILE

GYRI_TEST_MATTERMOST_WEBHOOK
ALL_FAIL_MATTERMOST_WEBHOOK

GITLAB_API_TOKEN

TH Environment

GYRI_TEST_TH_SERVER_USER
GYRI_TEST_TH_SERVER_01
GYRI_TEST_TH_SERVER_01_DEPLOYMENT_PATH

TEST_TH_DEPLOY_COMMAND

TEST_TH_APP_LOG_FILE_PROPERTY
TEST_TH_APP_BASE_SERVER_URL
TEST_TH_SWAGGER_SERVER_URL

TEST_TH_REDIS_HOST
TEST_TH_REDIS_PORT
TEST_TH_REDIS_TOPIC_PREFIX

TEST_TH_MONGO_HOST
TEST_TH_MONGO_PORT
TEST_TH_MONGO_DATABASE
TEST_TH_MONGO_USERNAME
TEST_TH_MONGO_PASSWORD
TEST_TH_MONGO_AUTH_DATABASE

TEST_TH_KAFKA_SECURITY_PROTOCOL
TEST_TH_KAFKA_SASL_MECHANISM
TEST_TH_KAFKA_SASL_JAAS_CONFIG
TEST_TH_KAFKA_SERVERS
TEST_TH_KAFKA_CONSUMER_GROUP_ID
TEST_TH_KAFKA_TOPIC_PREFIX

KP Environment

GYRI_TEST_KP_SERVER_USER
GYRI_TEST_KP_SERVER_01
GYRI_TEST_KP_SERVER_01_DEPLOYMENT_PATH

TEST_KP_DEPLOY_COMMAND

TEST_KP_APP_LOG_FILE_PROPERTY
TEST_KP_APP_BASE_SERVER_URL
TEST_KP_SWAGGER_SERVER_URL

TEST_KP_REDIS_HOST
TEST_KP_REDIS_PORT
TEST_KP_REDIS_TOPIC_PREFIX

TEST_KP_MONGO_HOST
TEST_KP_MONGO_PORT
TEST_KP_MONGO_DATABASE
TEST_KP_MONGO_USERNAME
TEST_KP_MONGO_PASSWORD
TEST_KP_MONGO_AUTH_DATABASE

TEST_KP_KAFKA_SECURITY_PROTOCOL
TEST_KP_KAFKA_SASL_MECHANISM
TEST_KP_KAFKA_SASL_JAAS_CONFIG
TEST_KP_KAFKA_SERVERS
TEST_KP_KAFKA_CONSUMER_GROUP_ID
TEST_KP_KAFKA_TOPIC_PREFIX

Production

GYRI_PROD_SERVER_USER
GYRI_PROD_SERVER_HOST
GYRI_PROD_SERVER_SSH_PORT
GYRI_PROD_SERVER_DEPLOYMENT_PATH

PROD_DEPLOY_COMMAND

GYRI_PROD_MATTERMOST_WEBHOOK

GITLAB_USERS_IDS_FOR_PROD_DEPLOY

GitLab Runner Registration

The pipeline requires three runners:

Install GitLab Runner

Ubuntu/Debian

curl -L \
https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh \
| sudo bash

sudo apt install gitlab-runner

Verify:

gitlab-runner --version

Register TH Runner

sudo gitlab-runner register

Prompts:

GitLab URL:
https://gitlab.example.com

Registration Token:
<project-runner-token>

Description:
th-runner

Tags:
th-runner

Executor:
shell

Register KP Runner

sudo gitlab-runner register

Prompts:

GitLab URL:
https://gitlab.example.com

Registration Token:
<project-runner-token>

Description:
kp-runner

Tags:
kp-runner

Executor:
shell

Register Production Runner

sudo gitlab-runner register

Prompts:

GitLab URL:
https://gitlab.example.com

Registration Token:
<project-runner-token>

Description:
prod-runner

Tags:
prod-runner

Executor:
shell

Verify Registered Runners

sudo gitlab-runner list

Example:

th-runner
kp-runner
prod-runner

Start Runner Service

sudo systemctl enable gitlab-runner
sudo systemctl start gitlab-runner

Check status:

sudo systemctl status gitlab-runner

Deployment Directory Structure

Expected structure on target servers:

template-spring-cqrs-reactjs/

├── server/
│
├── artifacts/
│   ├── application.jar
│   └── application.jar_bkp
│
└── server-config/
    └── application.properties

Failure Handling

The pipeline is designed to tolerate infrastructure failures.

Examples:

TH Runner Offline

TH Build → Failed

KP Build → Success

KP Deploy → Success

Pipeline → SUCCESS

KP Runner Offline

TH Build → Success

TH Deploy → Success

Pipeline → SUCCESS

Both Runners Offline

TH Build → Failed

KP Build → Failed

Pipeline → FAILED

Summary

This pipeline provides:

• Multi-location deployment (TH + KP)
• Spring Boot Reactive build automation
• Automatic changelog generation
• Mattermost notifications
• Job log reporting on failures
• Runner health monitoring
• Automatic cancellation of stuck jobs
• Production deployment authorization
• Artifact backup and rollback preparation
• High availability deployment strategy

If you've recently upgraded to React Redux v9 and are using IntelliJ, VS Code, or another TypeScript-aware IDE, you may have noticed a warning when hovering over connect():

@deprecated
We recommend using the useSelector and useDispatch hooks instead.
See https://react-redux.js.org/api/hooks

If you need to use connect without this visual deprecation warning,
import legacy_connect instead:

import { legacy_connect as connect } from 'react-redux'

This can be surprising, especially because many existing React applications still use connect() extensively.

Let's understand what's happening and explore the available options.

Is connect() Actually Deprecated?

Not exactly.

React Redux v9 adds a TypeScript/JSDoc deprecation annotation to encourage developers to adopt the modern Hooks API:

• useSelector()
• useDispatch()

However, connect() still works and remains supported.

The warning is primarily intended to guide developers toward the recommended pattern for function components.

Example: Existing connect() Implementation

Many applications use a pattern similar to this:

import { useNavigate } from 'react-router-dom';
import { useEffect } from 'react';
import { connect } from 'react-redux';

const ForgotPassword = ({ auth }) => {
  const navigate = useNavigate();

  useEffect(() => {
    if (auth.loggedIn) {
      navigate('/dashboard');
    }
  }, [auth.loggedIn, navigate]);

  return <div>Forgot Password</div>;
};

const mapState = (state) => ({
  auth: state.auth,
});

export default connect(mapState)(ForgotPassword);

This code is completely valid and will continue to work.

The only issue is the IDE warning.

Option 1: Migrate to Hooks (Recommended)

For function components, React Redux recommends using hooks instead of connect().

Before

export default connect(mapState)(ForgotPassword);

After

import { useSelector } from 'react-redux';

const ForgotPassword = () => {
  const auth = useSelector((state) => state.auth);

  return <div>Forgot Password</div>;
};

export default ForgotPassword;

A more complete example:

import { useNavigate } from 'react-router-dom';
import { useEffect } from 'react';
import { useSelector } from 'react-redux';

const ForgotPassword = () => {
  const navigate = useNavigate();

  const auth = useSelector((state) => state.auth);

  useEffect(() => {
    if (auth.loggedIn) {
      navigate('/dashboard');
    }
  }, [auth.loggedIn, navigate]);

  return <div>Forgot Password</div>;
};

export default ForgotPassword;

Benefits

• Less boilerplate
• No mapStateToProps
• Better TypeScript support
• Officially recommended by React Redux

Option 2: Continue Using connect()

If your application already contains many connected components, there is no immediate need to refactor everything.

You can simply keep using:

import { connect } from 'react-redux';

The warning is informational and does not affect runtime behavior.

This approach is often preferred in mature enterprise applications where consistency is more important than adopting the latest syntax.

Option 3: Use legacy_connect

React Redux v9 introduces a special alias called legacy_connect.

Replace:

import { connect } from 'react-redux';

with:

import { legacy_connect as connect } from 'react-redux';

The rest of your code remains unchanged:

const mapState = (state) => ({
  auth: state.auth,
});

export default connect(mapState)(ForgotPassword);

Why Use legacy_connect?

• Removes IDE deprecation warnings
• No behavior changes
• No refactoring required
• Useful for large existing codebases

Recommended Approach for Different Scenarios

New Projects

Use hooks:

useSelector()
useDispatch()

This is the modern React Redux pattern.

Existing Applications

If your project already contains dozens or hundreds of connected components:

import { legacy_connect as connect } from 'react-redux';

can be a practical intermediate solution.

Gradual Migration Strategy

Many teams adopt the following approach:

1. Keep existing connect() components.
2. Use hooks for all new components.
3. Gradually migrate old components when they are modified.
4. Use legacy_connect to suppress warnings during the transition.

This avoids large-scale refactoring while moving toward modern React Redux patterns.

TypeScript Bonus: Typed Hooks

For Redux Toolkit applications, consider creating typed hooks.

// store.ts
export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

// hooks.ts
import { useDispatch, useSelector } from 'react-redux';

export const useAppDispatch =
  useDispatch.withTypes<AppDispatch>();

export const useAppSelector =
  useSelector.withTypes<RootState>();

Usage:

const auth = useAppSelector((state) => state.auth);

This provides stronger type safety and a better developer experience.

Conclusion

The connect() warning in React Redux v9 is not an indication that the API has been removed. It is a recommendation from the React Redux team to use the Hooks API in modern React applications.

You can choose one of three paths:

• Best for new code: useSelector() and useDispatch()
• Best for existing code: continue using connect()
• Best for removing warnings without refactoring: legacy_connect

For most teams, a gradual migration strategy offers the best balance between modernizing the codebase and minimizing risk.

Introduction

After installing Ubuntu, one of the first things many users encounter is the Linux terminal. By default,Ubuntu uses Bash (Bourne Again Shell) as its command-line shell. While Bash is powerful and widely used,many developers and Linux enthusiasts prefer an alternative shell called Zsh (Z Shell).
This guide explains what Zsh is, why it is popular, how to install it on Ubuntu, and what happens during its
first-time setup. The explanations are written with beginners in mind, breaking down every command used
during the installation process.

What is a Shell?

Before understanding Zsh, it is important to understand what a shell is.

A shell is a program that allows users to interact with the operating system through commands. Whenever commands such as the following are executed:

ls
cd
mkdir

the shell interprets those commands and communicates with the operating system to perform the requested actions.

Ubuntu uses Bash (Bourne Again Shell) as its default shell.

What is Zsh?

Zsh stands for Z Shell. It is an advanced shell that provides all the features of Bash while adding many enhancements that improve the command-line experience.

Some of the most popular features of Zsh include:
• Better command auto-completion
• Easier navigation through directories
• Command suggestions and corrections
• Customizable themes
• Plugin support
• Improved productivity for developers

Because of these features, Zsh has become one of the most widely used shells in the Linux community.

Why Use Zsh?

Many users choose Zsh for the following reasons:
Better Auto-Completion
Zsh provides intelligent suggestions when typing commands, file names, and directories.
Improved Productivity
Frequently used commands can be executed more quickly with the help of plugins and shortcuts.
Customization
The terminal appearance can be customized using themes, making it more informative and visually appealing.
Learning Modern Linux Tools
Many developers use Zsh along with frameworks such as Oh My Zsh, making it a valuable tool for anyone learning Linux development environments.

Installing Zsh

Step 1: Updating Package Information
Before installing any software, Ubuntu's package information should be updated.
sudo apt update
Understanding the Command
• sudo = Super User DO. Temporarily grants administrator privileges.
• apt = Advanced Package Tool used to manage software packages.
• update = Downloads the latest package information from Ubuntu repositories.
This command does not upgrade software. It only refreshes the package database so Ubuntu knows which software versions are available.
Step 2: Installing Zsh
Install Zsh using the following command:
sudo apt install zsh -y
Understanding the Command
• sudo = Runs the command with administrator privileges.
• apt = Ubuntu package manager.
• install = Installs a software package.
• zsh = The package to be installed.
• -y = Automatically answers "Yes" to confirmation prompts.
This command downloads and installs Zsh along with any required dependencies.
Step 3: Verifying Installation
After installation, verify that Zsh has been installed correctly.
zsh --version
Understanding the Command
• zsh = Runs the Zsh executable.
• --version = Displays version information.
Example output:
zsh 5.9
Displaying a version number confirms that the installation was successful.
Step 4: Making Zsh the Default Shell
Installing Zsh does not automatically replace Bash. To make Zsh the default shell, execute:
chsh -s $(which zsh)
Understanding the Command
This command consists of multiple parts.
which zsh
• which = Finds the location of an executable program.
• zsh = The program being searched for.
Example output:
/usr/bin/zsh
This shows the location of the Zsh executable.
$(which zsh)
The $() syntax is known as command substitution.
It executes the command inside the brackets and uses its output.
Therefore:
$(which zsh)
becomes:
/usr/bin/zsh
chsh -s
• chsh = Change Shell.
• -s = Specifies which shell should be used.
Therefore:
chsh -s $(which zsh)
effectively becomes:
chsh -s /usr/bin/zsh
This tells Linux to use Zsh as the default login shell for the current user.
After running the command, log out and log back in.

First Launch of Zsh

After logging back in and opening the terminal, Zsh may display a configuration screen called zsh-newuser-install.
This happens because no Zsh configuration files currently exist in the user's home directory. Zsh therefore launches a setup wizard to create an initial configuration.
The setup wizard presents four options.
Option (q)
(q) Quit and do nothing.
• Exits the setup wizard.
• The wizard will appear again the next time Zsh starts.
Option (0)
(0) Exit, creating the file ~/.zshrc containing just a comment.
• Creates a minimal .zshrc file.
• Prevents the setup wizard from appearing again.
• Useful for users who want to configure everything manually.
Option (1)
(1) Continue to the main menu.
• Opens the advanced configuration menu.
• Allows customization of history settings, key bindings, completion settings, and other shell features.
Option (2)
(2) Populate your ~/.zshrc with the configuration recommended by the system
administrator.
• Automatically creates a recommended .zshrc file.
• Applies sensible default settings.
• Recommended for beginners.

Recommended Choice for Beginners
For users who are new to Zsh, selecting:
2
is generally the best option.
This option:
• Creates the configuration file automatically.
• Applies useful default settings.
• Allows immediate use of Zsh without manual configuration.

Understanding the .zshrc File
During the setup process, a file named:
~/.zshrc
is created.
Breaking It Down
• ~ = Home directory of the current user.
• .zshrc = Zsh Run Commands file.
• The dot ( . ) indicates that it is a hidden file.
The .zshrc file stores:
• Shell settings
• Aliases
• Plugins
• Themes
• Environment variables
• Custom terminal configurations
Every time Zsh starts, it reads this file and applies the stored settings.

Verifying the Configuration File
To verify that the configuration file was created successfully:
ls -la ~/.zshrc
Understanding the Command
• ls = Lists files and directories.
• -l = Displays detailed information.
• -a = Shows hidden files.
• ~/.zshrc = Path of the configuration file.
If the file exists, Linux displays its details.

Key Takeaways
Installing Zsh introduces several important Linux concepts:
• Linux supports multiple shells.
• Users can choose their preferred shell.
• Shell behavior is controlled through configuration files.
• Commands can be combined using command substitution.
• Terminal environments can be customized extensively.
Understanding these concepts provides a strong foundation for further Linux learning.

Conclusion
Zsh is a modern and feature-rich shell that enhances the Linux terminal experience through improved auto-completion, customization, and productivity features. Installing Zsh is a simple process, but it also serves as an excellent opportunity to learn about package management, shell configuration, and Linux command-line fundamentals.
For beginners exploring Ubuntu and Linux, Zsh provides a practical introduction to terminal customization while maintaining compatibility with familiar Bash workflows.

Definition:
Kafka, in simple terms, is a distributed-infrastructure used to store, manage and process events in real-time.

In traditional software world, developers visualized data as tables which represents things in real world like for example, items in an inventory, signed-up users, cars in a showroom, etc.
But what about things like item being dispatched from storeroom, user clicking somewhere on your website, driver picking up the client from a particular location?
You guessed it right! These are all events.
So, Kafka helps us process these events in real time, meaning the moment that particular event took place.
Hence, there is no such concept of storing these events in a file or a table for processing them in a batch in future.
However, this does not goes on to conclude that Kafka cannot remember events that already took place. Kafka is built to remember these events.

Lets understand the need for Kafka with the help of this simple example.

Consider a thermostat_readings table.

Now, suppose we need to update the thermostat reading for sensor_id 42 from 24 to 20, we will destructively change the value in temperature column for sensor id 42 from 24 to 20.
So our new table, looks like:

The critical issue here is that, we lost our previous info (context) of the sensor_id in Mumbai, like how quickly the temperature shoots up here or at what time of day it heats up.

To overcome this crucial challenge, Kafka implements logs.

Now you might be wondering what are logs?
Logs can be interpreted as an abstraction used by Kafka to store events as a sequence of data items. Mostly these data items are referred as events and quiet rarely called as messages.
The data items are appended at the very end, and items which are already present are never changed! You never modify these logs.
In Kafka, logs are known as Topics. So topics are where our messages get accumulated. And ALWAYS remember, messages in Kafka are IMMUTABLE! Once you write them into a topic, you cannot modify them. Basically, its an event which has happened and you cannot rewrite history; as same as you cannot change your past, simple as that!

So, in a gist, a topic is analogous to a table in a database, and we have numerous tables in a database; similarly we can have numerous topics in a single Kafka cluster.

NOTE: The messages in a topic can be of different format unlike a schema which needs to be followed in a database table.
The reason behind this is, that Kafka stores these messages as plain bytes. So format or schema doesn't matter.

How do you filter out messages out of a topic then?
Just like we deal with immutable data structures in various programming languages. Create a copy of that topic and filter out the unnecessary messages.

MISCONCEPTION: Topics are Logs. Not queues.
When a queue is read, the item is taken out of the queue and read. Now, nobody else can read that value. In a Kafka topic, when a message is read, it still stays intact. I can comeback after a few years and read that same message again!

More on Kafka message:
Its a value, associated with a key.
For example, consider this JSON:
{
"sensor_id": 42,
"location": "Mumbai",
"temperature": 22,
"read_at": 1700
}
Here, the 'sensor_id' becomes the key. This key is basically an identifier the payload relates to. Generally any unique id is taken as the key. Its not mandatory, but highly recommended to have a key!
We also got the timestamp, which tells us the moment the producer created that message.
The message also has some light-weight headers, and the most important parts of a Kafka message are topic, partition and offset!

Policies available in Kafka to prevent your disk from running out of space:
1. Log retention: delete old data or trim logs by size
2. Log compaction: keep only the latest value per key as sometimes context or history is irrelevant to maintain.

How Kafka scales?
If we limit our Kafka topic to a single node, then we will be restricting the topic's ability to scale to the node's disk space.
Since, Kafka is a distributed system, we partition the topic into several partitions.
Once partitions are created we need to decide to which partition the message goes to.
The message key helps us to make this decision. If the key is NULL, the messages are distributed in a round robin fashion. If not NULL and to ensure that a message with a certain key ALWAYS goes into a particular partition, hash the message key against a hash function mod the number of partitions and the output of this hash function is the partition number where the message goes to. This also helps us order our messages.

A few terminologies:

1. Cluster: A collection of one or more Kafka brokers working together to share the workload and provide redundancy (simply, a network of nodes).
2. Node: The underlying physical or virtual infrastructure that hosts a broker (simply, machine with some disk space for storage purposes).
3. Broker: A single Kafka server process that receives, stores, and fetches data (simply, a Kafka software process running on a node).

Point to note here is that, a broker has access to disk space on that node on which it's running; this disk space is basically SSD which is tightly coupled next to the processor.

Brokers are responsible for handling incoming requests to write new messages to partitions as well as read messages out of them.

Replication (for fault tolerance):

What is Replication factor?
Number of copies created for each partition.

We set the replication factor (n), which in above case is 3. The darker one is termed as Leader (lead replica) whereas the remaining (n-1) copies are called as followers.
Messages are preferred to be written into and read from the leader but in rare scenarios we might write and read from a replica which is nearest to us in the network.
Meanwhile, as messages are written into the lead replica, the followers keep scrapping out the newly written messages from the leader to keep themselves updated and have everything replicated.

Now in case the Broker 1 fails, we still have copies of Partitions 0 (with brokers 2, 3) and 2 (with brokers 3, 4).
Here, Broker 1 had the leader of partition 0. So new leader will be elected for partition 0.

PRODUCER:
A producer is nothing but a Kafka client which writes data into the Kafka partition.
CONSUMER:
A consumer is a Kafka client that reads from the Kafka topic.

In short, anything which is not a broker, is, at the end of the day a producer or a consumer.

REFERENCE:
Apache Kafka 101 - https://developer.confluent.io/courses/apache-kafka/events/

SSH stands for Secure Shell.
It is a secure protocol used to:

• Connect to remote servers
• Clone Git repositories
• Push and pull code securely
• Deploy applications

Instead of using passwords, SSH uses cryptographic key pairs.

Step 2: Understand SSH Key Pair

When you create an SSH key, two files are generated:

How it works:

1. You give your public key to GitLab.
2. GitLab stores it.
3. When you connect, GitLab verifies you using your private key.
4. If matched → Access granted.
   
   No password needed.

Step 3: Why We Use SSH in GitLab

GitLab is used for:

• Hosting repositories
• CI/CD
• Version control
• Collaboration

Without SSH (using HTTPS):

git clone https://gitlab.com/username/project.git
Every push asks for username & password.

With SSH:git clone git@gitlab.com:username/project.git
Push → Done instantly 🚀
That’s why developers prefer SSH.

Step 4: Generate SSH Key on Ubuntu

1️⃣ Open Terminal

Press:Ctrl + Alt + T

2️⃣ Check If SSH Already Exists
ls -al ~/.ssh
If folder doesn’t exist → no problem.

3️⃣ Generate New SSH Key

Recommended modern algorithm:
ssh-keygen -t ed25519 -C "your_email@example.com"
If not supported:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
Press Enter to accept default location:/home/username/.ssh/id_ed25519
Set passphrase (optional but recommended).

4️⃣ Start SSH Agent
eval "$(ssh-agent -s)"

5️⃣ Add Key to SSH Agent
ssh-add ~/.ssh/id_ed25519

6️⃣ Copy Public Key
cat ~/.ssh/id_ed25519.pub
Copy the entire output.

Step 5: Generate SSH Key on Windows

Option 1: Using Git Bash (Recommended)

1. Install Git for Windows
2. Open Git Bash

Run:ssh-keygen -t ed25519 -C "your_email@example.com"
Keys are stored in:C:\Users\YourUsername\.ssh\

View public key:cat ~/.ssh/id_ed25519.pub

Option 2: Using PowerShell

Open PowerShell and run:

ssh-keygen -t ed25519 -C "your_email@example.com"
Same process..

Step 6: Generate SSH Key on macOS

1️⃣ Open Terminal

Cmd + Space → Terminal

2️⃣ Generate Key

ssh-keygen -t ed25519 -C "your_email@example.com"

3️⃣ Start SSH Agent

eval "$(ssh-agent -s)"

4️⃣ Add Key

ssh-add ~/.ssh/id_ed25519

5️⃣ Copy Public Key

pbcopy < ~/.ssh/id_ed25519.pub

Step 7: Add SSH Key to GitLab

1. Login to GitLab
2. Click Profile → Preferences
3. Click SSH Keys
4. Paste copied public key
5. Click Add Key

Now GitLab trusts your machine.

Step 8: Test SSH Connection

Run: ssh -T git@gitlab.com
If successful, you’ll see:Welcome to GitLab!

Step 9: Clone Using SSH

Instead of HTTPS:
git clone git@gitlab.com:username/project.git
Now: git push
No password required.

Step 10: Security Best Practices

✔ Use ed25519
✔ Protect private key
✔ Add passphrase
✔ Never share private key
✔ Set correct permissions (Linux/macOS):

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519

Bonus: How SSH Works Internally

1. Client connects to GitLab
2. GitLab checks public key
3. GitLab sends encrypted challenge
4. Your private key decrypts it
5. Verified → Access granted

This uses asymmetric cryptography — extremely secure.

Final Conclusion

Setting up SSH keys:

• Improves security
• Removes password dependency
• Enables automation
• Essential for DevOps
• Industry best practice

If you are serious about professional development, SSH is not optional — it’s foundational

This guide outlines the technical requirements, dependency changes, and configuration updates necessary to migrate a Spring Boot application to version 4.0.1.

1. Build Environment Update
Before updating application dependencies, ensure your build tool is compatible with Spring Boot 4.0.1.
Gradle Version: Update to Gradle 9.2.1. This version is required to support the updated Spring Boot plugins and dependencies.

2. Dependency Management
Update your build.gradle.kts dependencies to their compatible versions.
Spring Boot Starters: Ensure all standard starters are updated to the managed versions provided by the Spring Boot 4.0.1 BOM:

• spring-boot-starter-actuator
• spring-boot-starter-data-mongodb-reactive
• spring-boot-starter-security
• spring-boot-starter-webflux
• spring-boot-starter-oauth2-client

Third-Party Library Updates: You must manually update several key libraries to versions compatible with Spring Boot 4:

• Redisson: Update redisson-spring-boot-starter to 4.1.0.
• SpringDoc OpenAPI (Swagger): Update to springdoc-openapi-starter-webflux-ui:3.0.1 to maintain API documentation support.

3. Breaking Change: Jackson 3 Migration
Spring Boot 4.0.1 moves from Jackson 2 to Jackson 3, which introduces significant namespace changes. This will cause compilation errors until references are updated.

Dependency Changes: Replace the standard Kotlin module dependency:

// Remove or Update
implementation("com.fasterxml.jackson.module:jackson-module-kotlin")
// Add New Tools Module
implementation("tools.jackson.module:jackson-module-kotlin")
// Maintain backward compatibility if needed for specific libs
implementation("com.fasterxml.jackson.module:jackson-module-kotlin:2.20.1")

Code Refactoring Required:

• Imports: Update your import statements for the object mapper.
  From: com.fasterxml.jackson.module.kotlin.jacksonObjectMapper
  To: tools.jackson.module.kotlin.jacksonObjectMapper

• Codecs: If you are using Redisson or custom codecs, update TypedJsonJacksonCodec to TypedJsonJackson3Codec.

4. Configuration Properties Updates
Several properties in application.properties have been renamed or require explicit enablement.
MongoDB Configuration: The spring.data.mongodb prefix has been simplified. You must remove the .data segment from your keys.

Full Mapping:

spring.mongodb.host=192.168.1.122
spring.mongodb.port=27017
spring.mongodb.database=AppDBTest
spring.mongodb.username=admin
spring.mongodb.password=secret
spring.mongodb.authentication-database=admin

Swagger UI: SpringDoc now requires explicit properties to enable the UI and API docs endpoints:

springdoc.api-docs.enabled=true
springdoc.swagger-ui.enabled=true

5. Tooling: Replacing Ktlint with Spotless
Older versions of ktlint may not be supported in this environment. It is recommended to switch to the Spotless Gradle plugin for code formatting.

Implementation: Add the plugin to your build.gradle.kts:

plugins {
    id("com.diffplug.spotless") version "8.1.0"
}

Configuration: Configure Spotless to handle both Kotlin and Java formatting:

spotless {
  kotlin {
    target("**/*.kt")
    ktfmt("0.53")
    trimTrailingWhitespace()
    endWithNewline()
  }

  java {
    target("**/*.java")
    googleJavaFormat("1.19.2")
    removeUnusedImports()
    trimTrailingWhitespace()
    endWithNewline()
  }

  // Bind to compilation tasks
  tasks.named("spotlessCheck") { dependsOn("compileKotlin", "compileJava") }
  tasks.named("spotlessApply") { dependsOn("compileKotlin", "compileJava") }
}

• Update and Install Dependencies

We need the web server and all PHP modules required by Nextcloud.
Run this on Server 1 AND Server 2:

sudo apt update

sudo apt install apache2 php libapache2-mod-php php-mysql php-common php-gd php-curl php-imagick php-mbstring php-xml php-zip php-intl php-bcmath php-gmp unzip -y

• Enable Required Apache Modules

Run this on Server 1 AND Server 2:

sudo a2enmod rewrite headers env dir mime
sudo systemctl restart apache2

• Create the Directory Structure

Run this on Server 1 AND Server 2:

sudo mkdir -p /var/www/html/nextcloud
sudo mkdir -p /var/www/html/nextcloud/data

• Set Permissions

Apache (www-data) must own these folders to write files.
Run this on Server 1 AND Server 2:

sudo chown -R www-data:www-data /var/www/html/nextcloud
sudo chmod -R 755 /var/www/html/nextcloud

• Download and Unzip

Run this on Server 1 AND Server 2:

cd /var/www/html
sudo wget https://download.nextcloud.com/server/releases/latest.zip
sudo unzip latest.zip

unzip will extract everything into the nextcloud folder we created

• Final Permission Fix

Ensure the new files are owned by the web server.

sudo chown -R www-data:www-data /var/www/html/nextcloud

• Configure Apache

Run this on Server 1 AND Server 2 to create the web config:

sudo nano /etc/apache2/sites-available/nextcloud.conf

Paste this content:

<VirtualHost *:80>
    DocumentRoot /var/www/html/nextcloud
    
    <Directory /var/www/html/nextcloud>
        Require all granted
        AllowOverride All
        Options FollowSymLinks MultiViews
    </Directory>
</VirtualHost>

Enable the site:

sudo a2ensite nextcloud.conf
sudo a2enmod rewrite
sudo systemctl restart apache2

Database setup (Master slave replication)

• Set up the Master (Server 1 Only)

1. Secure the installation:

sudo mysql\_secure\_installation

2. Create the Database:

sudo mysql -u root -p

CREATE DATABASE nextcloud;
CREATE USER 'nc\_admin'@'localhost' IDENTIFIED BY '12345';
GRANT ALL PRIVILEGES ON nextcloud.\* TO 'nc\_admin'@'localhost';

-- Create the User for Server 2 to copy data

CREATE USER 'replicator'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON \*.\* TO 'replicator'@'%';
FLUSH PRIVILEGES;

3. Enable Binary Logging: Edit /etc/mysql/mariadb.conf.d/50-server.cnf:

bind-address = 0.0.0.0
server-id    = 1
log\_bin      = /var/log/mysql/mysql-bin.log
binlog\_do\_db = nextcloud

Restart & Get Coordinates:

sudo systemctl restart mysql
sudo mysql -u root -p -e "SHOW MASTER STATUS;"

• Set up the Slave (Server 2 Only)

1. Do NOT create a database. (It will copy Server 1's DB).

2. Configure Config File: Edit /etc/mysql/mariadb.conf.d/50-server.cnf:

bind-address = 0.0.0.0
server-id    = 2
log\_bin      = /var/log/mysql/mysql-bin.log
binlog\_do\_db = nextcloud

3. Restart:

sudo systemctl restart mysql

• Connect Slave to Master

1. Run on Server 2: Note: If servers are on different networks (192.168 vs 10.10), open the SSH tunnel first.

STOP SLAVE;
CHANGE MASTER TO
MASTER\_HOST='192.168.0.135', -- Or '127.0.0.1' if using Tunnel
MASTER\_USER='replicator',
MASTER\_PASSWORD='password',
MASTER\_LOG\_FILE='mysql-bin.000001', -- From Phase 2, Step 1
MASTER\_LOG\_POS=123;                 -- From Phase 2, Step 1
START SLAVE;

2. Copy Config to Server 2:

On Server 1: Open /var/www/html/nextcloud/config/config.php and copy the text.

sudo nano /var/www/html/nextcloud/config/config.php

On Server 2: Create the file:
Paste the text.

sudo nano /var/www/html/nextcloud/config/config.php

Important Change: Find the line 'dbhost' => 'localhost', and ensure it stays localhost (so Server 2 reads its own replica DB).

File Synchronization (Unison)

• Install Unison (Both Servers)

sudo apt install unison -y

• Configure SSH Key (Server 2 -> Server 1)

ssh-keygen -t ed25519
ssh-copy-id gyriexp@192.168.0.135

• Create Sync Profile (Server 2)
  Create ~/.unison/default.prf:

root = /var/www/html/nextcloud/data
root = ssh://gyriexp@192.168.0.135//var/www/html/nextcloud/data
auto = true
batch = true
prefer = newer
perms = 0     # Ignore permissions

• Running the Sync

Run this sequence whenever you want to backup files:

1. On Server 1 (Unlock):

sudo chown -R gyriexp:gyriexp /var/www/html/nextcloud/data

2. On Server 2 (Sync):

unison default

3. On Server 1 (Lock):

sudo chown -R www-data:www-data /var/www/html/nextcloud/data

Special conditions

Server 1 Fails → Make Server 2 Master → Restore Server 1 as Slave

• Promote Server 2

Run these on Server 2 to make it the independent Master.

1.Stop it from looking for the dead master:

sudo mysql -u root -p -e "STOP SLAVE; RESET SLAVE ALL;"

2.Enable Writes (if Read-Only was on)

sudo mysql -u root -p -e "SET GLOBAL read\_only = OFF;"

3. Update Nextcloud Config: Ensure config.php points to localhost.

sudo nano /var/www/html/nextcloud/config/config.php

Ensure: 'dbhost' => 'localhost',

• Server 1 is Back (Make it the Slave)

1. Create Backup on Server 2:

Run on Server 2

sudo mysqldump -u root -p --all-databases --master-data > production\_backup.sql

2. Send Backup to Server 1:

Run on Server 2

scp production\_backup.sql user@server1\_ip:/home/user/

3. Import & Configure Slave on Server 1:

Run on Server 1

sudo mysql -u root -p < /home/user/production\_backup.sql

4. Start Replication on Server 1:

Run on server 2

sudo mysql -u root -p -e "SHOW MASTER STATUS;"

Run on server 1

sudo mysql -u root -p
STOP SLAVE;
CHANGE MASTER TO
MASTER\_HOST='Server2\_IP',
MASTER\_USER='replicator',
MASTER\_PASSWORD='password',
MASTER\_LOG\_FILE='mysql-bin.00000X',  -- Value from Server 2
MASTER\_LOG\_POS=1234;                 -- Value from Server 2
START SLAVE;

• Correct Unison File Sync

Since Unison is bidirectional, you usually don't need to change the command if the config is on Server 2. It will detect Server 2 has "New files" and Server 1 is empty/old, and it will push them automatically.

\# Unlock Server 1
ssh user@server1\_ip "sudo chown -R user:user /var/www/html/nextcloud/data"

\# Run Sync (Pushes S2 data to S1)
unison default

\# Lock Server 1
ssh user@server1\_ip "sudo chown -R www-data:www-data /var/www/html/nextcloud/data"

Normal chain is S1 → S2 → S3. Server 2 dies. You need S1 to sync directly to S3. When S2 returns, S3 updates S2.

• Bypass Server 2 (S2 is Down)

1. Create a "Bypass Profile" on Server 3:

nano ~/.unison/bypass.prf

Paste this:

\# Sync Local (S3) with Server 1 (Skipping S2)
root = /var/www/html/nextcloud/data
root = ssh://user@server1\_ip//var/www/html/nextcloud/data
auto = true
batch = true
prefer = newer
perms = 0

2. Run the Bypass Sync: Run this on Server 3 whenever S2 is down.

\# 1. Unlock Server 1
ssh user@server1\_ip "sudo chown -R user:user /var/www/html/nextcloud/data"

\# 2. Sync S3 <-> S1
unison bypass

\# 3. Lock Server 1
ssh user@server1\_ip "sudo chown -R www-data:www-data /var/www/html/nextcloud/data"

• Server 2 is Back (Restore & Fill Gaps)

1. Sync S3 → S2 (Run on Server 3): We create a temporary profile to push data back to the recovered Server 2.

nano ~/.unison/restore\_s2.prf

\# Sync Local (S3) to Server 2
root = /var/www/html/nextcloud/data
root = ssh://user@server2\_ip//var/www/html/nextcloud/data
auto = true
batch = true
prefer = newer
perms = 0

2. Run the Restore Sync:

\# 1. Unlock Server 2 (The recovered server)
ssh user@server2\_ip "sudo chown -R user:user /var/www/html/nextcloud/data"

\# 2. Sync S3 -> S2
unison restore\_s2

\# 3. Lock Server 2
ssh user@server2\_ip "sudo chown -R www-data:www-data /var/www/html/nextcloud/data"

3. Resume Normal Operations: Now that S2 is up-to-date, you can go back to your original setup (S1 syncing to S2, and S2 syncing to S3).

• step 1: Verify Server 2 is "Clean"

Run on Server 2:

ls -l /var/www/html/nextcloud/data/

• Step 2: Resume Server 1 → Server 2 Sync

1. Unlock Server 2
   Run on Server 1

ssh user@server2_ip "sudo chown -R user:user /var/www/html/nextcloud/data"

2. ssh user@server2_ip "sudo chown -R user:user /var/www/html/nextcloud/data"

unison default

3. Lock Server 2:

ssh user@server2_ip "sudo chown -R www-data:www-data /var/www/html/nextcloud/data"

• Step 3: Resume Server 2 → Server 3 Sync

Now that S2 is updated by S1, it passes those updates down to S3.
Run on Server 2: (Assuming you have a profile named sync_to_s3 that points to S3).

Unlock Server 3:

ssh user@server3_ip "sudo chown -R user:user /var/www/html/nextcloud/data"

Run the Standard Sync:

unison sync_to_s3

Lock Server 3:

ssh user@server3_ip "sudo chown -R www-data:www-data /var/www/html/nextcloud/data"

Modern authentication systems are moving beyond passwords. With the rise of passwordless authentication, One-Time Passwords (OTPs) delivered over email or SMS are becoming a trusted standard for secure and seamless user logins.

However, implementing an OTP-based login mechanism that is scalable, reactive, and audit-compliant requires more than a simple verification service. It demands an architecture that supports asynchronous workflows, event traceability, and reactive scalability — all while keeping the system maintainable and extendable.

In this post, we’ll walk through the conceptual design of a Reactive OTP Login System built using Spring Boot, CQRS (Command Query Responsibility Segregation), and Event Sourcing.
We’ll focus purely on the architecture and system flow — without diving into code — to illustrate how such a system achieves high throughput, clean separation of concerns, and full auditability.

Architectural Overview

At its core, this system adopts a Reactive CQRS + Event Sourcing design:

• Commands modify the system state (e.g., logging in a user).
• Queries fetch or compute data without altering state (e.g., generating OTP for a user).
• Events record every state transition as an immutable fact.
• Reactive Streams (Mono/Flux) ensure non-blocking, backpressure-aware execution.

Step 1: Requesting an Email OTP

The OTP generation process begins when a user initiates a login using their email.

Conceptual Flow

1. The client sends a request to /api/v1/user/request/emailloginotp/{email}.
2. The Query Controller constructs a RequestEmailLoginOTPQuery, encapsulating the user’s email and tenant metadata.
3. The Query Dispatcher routes the query to the appropriate Query Handler.
4. The Query Handler verifies whether the user exists and is active using a reactive repository.
5. If valid, it invokes EmailLoginOTPService to generate a unique OTP.
6. It then emits an EmailOTPSentEvent, which is published to Kafka for asynchronous notification delivery and audit tracking.
7. The API responds with a confirmation that the OTP request was processed successfully.

Step 2: Validating the Email OTP (Login Process)

Once the user receives the OTP, they can authenticate using it.

Conceptual Flow

1. The client submits a POST request to /api/v1/user/validate/emailloginotp with email and otp.
2. The Command Controller validates the OTP through the EmailLoginOTPService.
3. On success, it dispatches a LogInWithEmailOTPCommand to the Command Handler.
4. The Command Handler performs several key actions:
   • Rehydrates the user’s aggregate state from the Event Store.
   • Raises a LoggedInWithEmailOTPEvent to represent successful login.
   • Persists this event back to the Event Store.
5. The Event Handler listens for the event, updating the read projection (user table) to reflect login status.
6. The JWT Token Provider issues a new access token for the authenticated session.
7. The client receives a success response along with the token.

Event Sourcing Lifecycle

Event Sourcing lies at the heart of this system.
Every change in user state — from OTP sent to login success — is captured as a domain event and stored immutably in the Event Store.

Conceptual Event Chain

Replaying these events allows the system to rebuild state from history, ensuring full traceability and fault recovery without traditional database state dependencies.

Security and Compliance Considerations

Security is baked into every stage of the pipeline:

• OTP expiration, uniqueness, and rate limiting are handled by the EmailLoginOTPService.
• JWT tokens provide stateless, secure session management.
• Audit events ensure all critical actions are logged for compliance.
• Tenant-aware scoping enforces strict data isolation in multi-tenant setups.

By combining event logs with JWT-based access, the system achieves both security and observability.

Conclusion

Building an OTP-based authentication system using Reactive, CQRS, and Event Sourcing principles enables:

Scalable, non-blocking performance under heavy traffic
Strict auditability with event logs
Fault tolerance through event replay
Extensibility for future login channels or audit pipelines
Seamless user experience with real-time responsiveness

In essence, this architecture transforms a simple OTP mechanism into a production-grade authentication framework — one that is reactive by nature, event-driven by design, and compliant by default.

Enterprise applications that export Excel reports with embedded documents face a critical security challenge. The straightforward implementation exposes internal system identifiers:

https://app.example.com/api/document/12345/view?tenantId=67890

This reveals:

• Internal document IDs (12345)
• Tenant identifiers (67890)
• API structure and endpoints

Once Excel files are distributed, these identifiers persist indefinitely, creating ongoing security exposure even if the URLs require authentication.

The challenge intensifies when requirements include:

• Embedding images directly in Excel cells
• Providing download links for full-resolution access
• Supporting non-image documents (PDFs, DOCX) as clickable links

Solution: Short URL Redirection

Replace direct URLs with temporary, opaque redirect tokens:

Before:

https://app.example.com/api/document/12345/view?tenantId=67890

After:

https://app.example.com/api/shorturl/7k9x-m2p4

The short URL provides:

• Complete opacity (no exposed identifiers)
• Automatic expiration (configurable timeframe)
• Full auditability (access tracking)
• Universal compatibility (images and documents)

Architecture

Phase 1: Report Generation

Token Generation:

For each document in the export:

1. Generate cryptographically secure random token (e.g., 7k9x-m2p4)
2. Store mapping in database:

short_code:    7k9x-m2p4
original_url:  /api/document/12345/view?tenantId=67890
expires_at:    2025-11-06 14:30:00 UTC
created_by:    user@example.com

Content Handling:

Images:

• Fetch image via secure internal URL (server-side)
• Embed binary data directly into Excel cell
• Attach short URL as clickable hyperlink
• Result: Thumbnail preview with download link

Non-Images:

• Insert short URL as clickable hyperlink only
• Result: Text link for download/viewing

Excel Generation:

Use server-side libraries (Apache POI, OpenPyXL, EPPlus) to:

• Embed image binary data in cells
• Configure hyperlinks to short URLs
• Ensure zero internal identifiers in output

Phase 2: Document Access

User clicks link in Excel:

1. Request: Browser opens GET /api/shorturl/7k9x-m2p4

2. Validation: Public endpoint checks:

   • Token exists in database
   • Token not expired
   • Log access attempt

3. Redirect: Return HTTP 302:

   Location: https://app.example.com/api/document/12345/view?tenantId=67890
   

4. Authentication: Browser follows redirect with existing session, normal authentication applies

User experience: Click → Document opens

System process: Validate → Redirect → Authenticate → Deliver

Technical Implementation

Database Schema

Security Configuration

Redirect Endpoint:

• Path: /api/shorturl/**
• Authentication: None (public access)
• Rate limiting: Required (prevents enumeration)
• Validation: Token existence and expiration only

Token Specification:

• Length: Minimum 12 alphanumeric characters
• Entropy: Cryptographically secure random generation
• Character set: URL-safe (a-z, A-Z, 0-9)
• Collision handling: Database unique constraint with retry

Expiration Policy

Security Benefits

1. Information Protection

• Internal IDs completely hidden
• API structure remains confidential
• Zero architectural details exposed

2. Temporal Controls

• Automatic expiration reduces long-term risk
• Distributed files lose access over time
• No indefinite credential exposure

3. Audit Capability

• Track every access attempt
• Record timestamp, IP, user identity
• Enable anomaly detection and compliance reporting

4. Access Management

• Revoke tokens immediately if needed
• Extend expiration programmatically
• Tenant-level and user-level controls

Performance Considerations

Token Generation:

• Batch create during report generation
• ~1ms per token generation
• Minimal database overhead

Lookup Performance:

• O(1) with proper indexing
• Cache active tokens (optional)
• Typical response time: <10ms

Cleanup:

• Schedule periodic deletion of expired tokens
• Run during off-peak hours
• Archive audit data before deletion

Image Processing:

• Server-side fetch and embed: ~50-100ms per image
• Memory efficient with streaming
• No browser limitations

Example Workflow

Scenario: Report with 30 images, 20 PDFs

Generation:

1. Generate 50 short URLs: ~50ms
2. Fetch and embed 30 images: ~2-3 seconds
3. Build Excel file: ~500ms
4. Total: ~3-4 seconds

Usage:

• 5 users, 7-day period
• 150 total accesses across 50 documents
• Complete audit trail maintained
• Zero ID exposure
• Automatic expiration after policy period

Implementation Checklist

Required Components:

• Short URL mapping database table with proper indexes
• Token generation service (cryptographically secure)
• Public redirect endpoint (unauthenticated)
• Token validation logic (existence + expiration)
• Audit logging mechanism
• Scheduled cleanup job for expired tokens

Security Requirements:

• Rate limiting on redirect endpoint
• Cryptographic random token generation
• Proper expiration policy configuration
• HTTP 302 redirect (not 301 permanent)
• Error handling (404 for invalid/expired tokens)

Server-Side Excel Library:

• Java: Apache POI
• Python: OpenPyXL
• .NET: EPPlus

Why Server-Side:
Browser-based libraries (xlsx-js-style, etc.) cannot embed images in Excel cells. Server-side libraries provide full binary embedding capability.

Conclusion

The short URL redirection pattern solves document embedding security through architectural indirection. By replacing direct URLs with temporary tokens, systems achieve:

• Complete identifier masking (no IDs exposed)
• Automatic expiration (temporal security)
• Full auditability (compliance ready)
• Seamless UX (transparent to users)

This approach is applicable beyond Excel exports—anywhere temporary, auditable access to secure resources is required without exposing internal architecture.

Key Takeaway: Never expose internal identifiers in exported files. Use opaque, expiring tokens as an indirection layer between distributed content and secure resources.

Technical Stack Considerations:

This pattern integrates with existing authentication infrastructure. The redirect endpoint bypasses authentication (public), while the target URL enforces normal security. Token validation provides the security boundary, relying on cryptographic randomness and expiration rather than session state.

Broader Applications: PDF reports, email notifications, third-party integrations, mobile apps, automated distribution systems—any context requiring temporary resource access without persistent authentication.

• mongod - start mongo db server instance
• mongo - start mongo db command prompt to execute commands
• show dbs - show databases
• mongoimport -d [DATABASE_NAME] -c [COLLECTIONS] --file [FILE_NAME] - import into database and collection from file
• mongoexport -d [DATABASE_NEM] -c [COLLECTIONS] --out [FILE_NAME] - export db in json
• mongodump - binary export
• mongorestore - restore binary export
• bsondump
• mongostat
• use [DB_NAME]- change/switch DB. There is NO command to create DB
• db - set variable as DB (after user [DB_NAME])
• db.[COLLECTIONS] - e.g. db.links. Don't have to create collections (similar to DB)
• db.[COLLECTIONS].count() - to check number of documents. e.g. db.links.count()
• db.[COLLECTIONS].insert({[JSON_DATA]}) - e.g. db.links.insert({title: "google search", url:"www.google.com", comment:"top search engine", tags:["default","main page"], saved_on: new Date()})
• db.[COLLECTIONS].save({[JSON_DATA]}) - e.g. db.links.save({title: "yahoo search", url: "www.yahoo.com", saved_on: new Date()})
• db.[COLLECTIONS].find() - e.g. db.links.find(). Query the database to find the documents

Examples

• show collections - show collections for db
• db.users.insert({"name":"username"}) - insert collection user with data
• db.users.count() - show count of collections
• db.users.find() - find all data from collection
• db.users.find().explain() - explain execution planner for query to find data
• db.users.find().explain("executionStats") - more information on explain
• db.users.createIndex({number:1}) - to create an index on collection
• db.users.update({"name":"username"}, $set: {"first_name":"Name"})" - $set update record
• db.users.update({"name":"username"}, {$addToSet: {"hobbies":"running"}})" - $addToSet update array with new value
• db.users.remove({"name":"username"}) - remove record
• db.users.drop() - drop entire users collection

Notes

• bson: binary JSON
• Collection: Like an RDBMS table; but collection has no schemas.
• Document: Like an RDBMS record or row. There are bson documents.
• Field: Like an RDBMS column; {key: value}

The react-native-document-picker library is a React Native module that allows users to select documents (or files) from their device storage. This can include various types of files, such as images, videos, PDFs, audio files, and other types of documents, depending on the platform (iOS or Android).

The primary use case for this library is to give users the ability to pick files from their local storage or cloud services (like iCloud, Google Drive, etc.) within a React Native app.

Key Features of react-native-document-picker:

1. File Selection:
   • Allows users to pick various types of files (documents, images, audio, etc.) from their device storage.
   • Works across iOS and Android, providing a consistent API to access documents.
2. File Type Filtering:
   • You can specify the types of files you want users to select (e.g., only PDFs, only images, only audio files, etc.).
   • The library provides predefined constants for file types (e.g., DocumentPicker.types.images, DocumentPicker.types.audio, DocumentPicker.types.pdf), but you can also specify custom types.
3. Multiple File Selection:
   • You can allow the user to select multiple files at once (in supported platforms).
4. File Metadata:
   • After selecting a file, the library provides metadata about the file, such as its URI, name, size, type, and more, which you can use in your app.
5. Cross-platform:
   • Works on both iOS and Android devices, though there are some differences in behavior between the platforms, especially regarding the supported file types and the appearance of the file picker.

Basic Usage Example:

Here’s a simple example of how to use the react-native-document-picker library to allow a user to pick an audio file:

Import and Use the Library:Below is an example of how to use react-native-document-picker to allow the user to pick an audio file:

import React, { useState } from 'react';
import { View, Button, Text, Alert } from 'react-native';
import DocumentPicker from 'react-native-document-picker';

const FilePickerExample = () => {
  const [fileInfo, setFileInfo] = useState(null);

  // Function to pick an audio file
  const handlePickFile = async () => {
    try {
      // Pick an audio file
      const res = await DocumentPicker.pick({
        type: [DocumentPicker.types.audio],  // Filter for audio files
      });

      setFileInfo(res);  // Set the file metadata

      // Alert with file information
      Alert.alert('File Selected', `File: ${res.name}, Size: ${res.size} bytes`);

      console.log(res);  // Log the file metadata (URI, type, name, etc.)
    } catch (err) {
      if (DocumentPicker.isCancel(err)) {
        console.log('User canceled the picker');
      } else {
        console.error('Error picking file:', err);
      }
    }
  };

  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <Button title="Pick an Audio File" onPress={handlePickFile} />
      {fileInfo && (
        <Text style={{ marginTop: 20 }}>
          File: {fileInfo.name} (Size: {fileInfo.size} bytes)
        </Text>
      )}
    </View>
  );
};

export default FilePickerExample;

Install the library:If you haven’t already, install the library by running:

npm install react-native-document-picker

Or if you're using yarn:

yarn add react-native-document-picker

File Metadata Example:

When a file is selected, the DocumentPicker.pick() method returns an object containing metadata about the file. Here is an example of the metadata you might get:

{
  uri: 'file:///storage/emulated/0/Download/song.mp3',
  type: 'audio/mp3',  // The MIME type of the file
  name: 'song.mp3',   // The file name
  size: 1234567,      // The size of the file in bytes
  fileCopyUri: 'content://com.android.providers.media.documents/document/...',
}

File Types:

react-native-document-picker supports many file types, and you can filter what type of files users can pick. Here are some of the predefined types available:

All Files (Generic for any file type):

DocumentPicker.types.allFiles

Spreadsheets (Excel files):

DocumentPicker.types.xls

Plain Text:

DocumentPicker.types.plainText

PDF Documents:

DocumentPicker.types.pdf

Audio:

DocumentPicker.types.audio

Images:

DocumentPicker.types.images

You can also combine multiple types. For example, to allow both images and audio:

type: [DocumentPicker.types.images, DocumentPicker.types.audio]

Key Methods:

• pick(): The main method used to open the file picker and select files. You can pass an object with options to specify file types and whether multiple files can be selected.
• pickMultiple(): Allows users to pick multiple files at once (iOS only).
• isCancel(): A utility method to check if the user canceled the file picking action.

Platform Differences:

• iOS: The library provides a native file picker. You can pick files from the local file system, including cloud services like iCloud Drive.
• Android: The library typically uses the device's file system picker, which may vary depending on the Android version and manufacturer. The file picker might not always show cloud storage options unless explicitly configured by the app.

Use Cases:

1. Allow users to upload documents, images, or audio files from their device to your app (e.g., for profile pictures, document submissions, etc.).
2. Cloud storage integration: Some Android versions may allow cloud storage access via the file picker, but for full cloud file support, you'll typically need to integrate with a specific cloud API (e.g., Google Drive, iCloud).
3. Handling PDFs or media files: If you need to open or process PDFs or media files (audio, video, etc.), this library helps by allowing users to select these files from their device.

Summary:

• What it does: react-native-document-picker enables users to select files from their local storage (including documents, images, and audio files) and provides metadata about the selected file.
• Why it's useful: It simplifies the process of file selection in React Native apps, providing a consistent interface across iOS and Android.

Let me know if you need more information or examples!

• which git
• git --version
• vi /etc/gitconfig
• vi ~/.gitconfig : user level git config file
• vi [PROJECT_PATH]/.git/config : project level git config file
• git config --system : system level configuration
• git config --global : user level configuration
• git config : project level configuration
• git config --global user.name "[NAME]"
• git config --list : list of config properties
• git config --global core.excludefile ~/.gitignore_global : global config for gitignore
• git config --global alias.[shortcut] [git-command] : shortcut for git command
• git --help
• git init : initialize repository
• ls -la .git : shows git config files
• git add . : add all uncommitted changes from project. dot (.) is current directory
• git commit -m "message" : commit changes with message
• git commit -am "message" : shorthand for git add . and git commit -m "message" (grabs everything. not tracked(new) and deleted files are not included)
• git commit --amend -m "message" : this command is a convenient way to fix up the most recent commit.
• git log : check git commit log
• git log -2 : restrict show commit log to last two
• git log --since=2016-01-12 : show commits after this date
• git log --until=2016-01-12 : show commits till this date
• git log --author="Kaustubh" : show commits for specified author
• git log --grep="st" : show commits having specified text
• git log --online : shows all logs in one line
• git log --online -[number] : restrict log for given number
• git log [SHA]..[SHA] : shows log between two mentioned commits
• git log [file] : shows details about file
• git log -p : more details about commit. Like code insertion etc
• git log --stat --summary
• git log --format=oneline : this is similar to `git log --oneline"
• git log --format=[oneline / short / medium / fuller / email / raw]
• git log --graph
• git log --oneline --graph --all --decorate
• git status : difference between working directory, the staging index and teh repository
• git status -s
• git reset HEAD [file] : to unstage file
• git reset HEAD
• git reset --soft
• git reset --mixed : default
• git reset --hard
• git reset --hard [SHA] : reverted to the specified SHA version
• git diff : shows difference between the repository where HEAD is pointed at Vs working directory
• git diff [file]
• git diff --staged : shows difference between the staging index Vs working directory
• git diff --cached : similar to git diff --staged
• git diff --color-words [file] : shows only different words
• git diff [SHA] : difference between working directory and directory at that point of time
• git diff [SHA] [file]
• git diff [SHA]..[SHA] : difference between two commits
• git diff [SHA]..[SHA] [file]
• git diff -b : is same as git diff --ignore-space-change
• git diff -w : is same as git diff --ignore-all-space
• git diff [branch-1]..[branch-2]
• git diff [branch-1]..[branch-2]^ : compare with previous commit of branch-2
• git rm [file] : remove uncommitted file. similar to git add. use git commit -m to commit and remove file from repository.
• git rm --cached [file] : remove from caching (or staging index)
• git mv [orig_file] [newname_file] : rename file
• git checkout -- [file] : to discard changes in working directory. "--" indicates from current branch only.
• git checkout [SHA-key] -- [file] : revert to that SHA version
• git revert [SHA] : revert and commit
• git revert -n [SHA] : revert and not committed
• git clean -n : test run of git clean
• git clean -f : final run of git clean
• git ls-tree HEAD
• git ls-tree [branch-name]
• git ls-tree [branch-name] [folder-path]
• git ls-tree [branch-name]^ [folder-path] : earlier commit
• git ls-tree [SHA]
• git show [SHA]
• git branch : list branch names in working directory
• git branch [branch-name] : creates new branch
• git branch -d [branch-name] : delete branch (before this make sure you are not working on this branch)
• git branch -D [branch-name] : force delete branch
• git branch -m [branch-new-name] : rename branch
• git branch --merged :To see which branches are already merged into the branch you’re on
• git branch --no-merged : To see all the branches that contain work you haven’t yet merged in
• git branch -r : shows remote branches
• git branch -a : shows local and remote branches
• git branch [local-branch-name] [remote-branch-name] : creates new branch and tracking is set to the remote branch
• git checkout [branch-name] : change working directory to specified branch name
• git checkout -b [branch-name] : create and checkout at the same time for new branch
• git checkout -b [local-branch-name] [remote-branch-name] : creates and checkout new branch and tracking is set to the remote branch
• git merge [branch-name] : merge specified branch to current working branch
• git merge --no-ff [branch-name] : no fast forward. create new commit
• git merge -ff-only [branch-name] : do merge only for fast forward else abort
• git merge --abort : abort the current merge
• git stash save "message" : stash current changes
• git stash list : shows list of items are in stash
• git stash show stash@{NUMBER} : shows the details of that number
• git stash show -p stash@{NUMBER} : shows the details of that number (more descriptive with -p option)
• git stash pop : checkout changes are removes the stash
• git stash apply : only checkout changes. keeps in the stash as well
• git stash drop stash@{NUMBER} : delete the specified stash
• git stash clear : clears the stash list
• git remote : alias for remote branch
• git remote add [alias] [remote-url] : add alias for remote url
• git remote -v : more details about remote branch
• git push -u [remote-alias] [branch-name] : push code changes to remote repository. -u option to track remote branch
• git push : push current commits of the same branch to the origin (remote) branch
• git push origin :[remote-branch-name] : deletes the branch from remote
• git push origin --delete [remote-branch-name] : similar to git push origin :[remote-branch-name]
• git clone [git-remote-url] : creates with default folder
• git clone [git-remote-url] [folder-name] : creates folder to clone remote repository
• git fetch origin : sync (fetch) remote branch with local branch
• git fetch --all : sync (fetch) all remote branches with local branches
• git pull === git fetch + git merge

Git flow Commands

• git flow init -d : initialise git flow
• git flow feature start [feature-branch-name] : creates new feature branch
• git flow feature publish [feature-branch-name] : publish feature branch to remote repository
• git flow feature finish [feature-branch-name] : it deletes as well.

Notes

• SHA or SHA1 : Secure Hash Algorithm (1) https://en.wikipedia.org/wiki/SHA-1
• toggle between long commits : forward (f) or backward (b). space bar or enter to see more details
• toggle fold long lines : minus sign (-) + shift + S + return. wrap it around instead of lines being truncated.
• to return to long lines (unwrap) : minus sign (-) + S + return
• cat .git/master : points to where HEAD (SHA) is located
• cat .git/refs/heads/master : points to where HEAD (SHA) is located
• project/.gitignore : file to specify which files or directory to ignore
• .gitkeep : use this file to track empty folder
• remote url details can be found at .git/config file

Git cherry-pick

• Cherry picking in git means to choose a commit from one branch and apply it onto another.
• This is in contrast with other ways such as merge and rebase which normally apply many commits onto another branch.
  1. Make sure you are on the branch you want to apply the commit to.
     git checkout master
  2. Execute the following:
     git cherry-pick <commit-hash>

Git Windows command

• git add --chmod=+x [FILE] : To mark file executable

Contents

https://www.linkedin.com/learning/git-essential-training-2023/get-started-with-git

• Introduction

  • Introduction
  • How to use the exercise files

• Welcome

  • What you should know before watching this course
  • Using the exercise files

1. What is Git?

   • Understanding version control
   • The history of Git
   • About distributed version control
   • Who should use Git?

2. Installing Git

   • Installing Git on a Mac
   • Installing Git on Windows
   • Installing Git on Linux
   • Configuring Git
   • Exploring Git auto-completion
   • Using Git help

3. Getting Started

   • Initializing a repository
   • Understanding where Git files are stored
   • Performing your first commit
   • Writing commit messages
   • Viewing the commit log

4. Git Concepts and Architecture

   • Exploring the three-trees architecture
   • The Git workflow
   • Using hash values (SHA-1)
   • Working with the HEAD pointer

5. Making Changes to Files

   • Adding files
   • Editing files
   • Viewing changes with diff
   • Viewing only staged changes
   • Deleting files
   • Moving and renaming files

6. Using Git with a Real Project

   • Introducing the Explore California web site
   • Initializing Git
   • Editing the support phone number
   • Editing the backpack file name and links

7. Undoing Changes

   • Undoing working directory changes
   • Unstaging files
   • Amending commits
   • Retrieving old versions
   • Reverting a commit
   • Using reset to undo commits
   • Demonstrating a soft reset
   • Demonstrating a mixed reset
   • Demonstrating a hard reset
   • Removing untracked files

8. Ignoring Files

   • Using .gitignore files
   • Understanding what to ignore
   • Ignoring files globally
   • Ignoring tracked files
   • Tracking empty directories

9. Navigating the Commit Tree

   • Referencing commits
   • Exploring tree listings
   • Getting more from the commit log
   • Viewing commits
   • Comparing commits

10. Branching

    • Branching overview
    • Viewing and creating branches
    • Switching branches
    • Creating and switching branches
    • Switching branches with uncommitted changes
    • Comparing branches
    • Renaming branches
    • Deleting branches
    • Configuring the command prompt to show the branch

11. Merging Branches

    • Merging code
    • Using fast-forward merge vs. true merge
    • Merging conflicts
    • Resolving merge conflicts
    • Exploring strategies to reduce merge conflicts

12. Stashing Changes

    • Saving changes in the stash
    • Viewing stashed changes
    • Retrieving stashed changes
    • Deleting stashed changes

13. Remotes

    • Using local and remote repositories
    • Setting up a GitHub account
    • Adding a remote repository
    • Creating a remote branch
    • Cloning a remote repository
    • Tracking remote branches
    • Pushing changes to a remote repository
    • Fetching changes from a remote repository
    • Merging in fetched changes
    • Checking out remote branches
    • Pushing to an updated remote branch
    • Deleting a remote branch
    • Enabling collaboration
    • A collaboration workflow

14. Tools and Next Steps

    • Setting up aliases for common commands
    • Using SSH keys for remote login
    • Exploring integrated development environments
    • Exploring graphical user interfaces
    • Understanding Git hosting

15. Conclusion

Basic commands

• su: login as super user (e.g. root)
• pwd: current directory
• ls: list files
• ls -l: list files with detail info
• bunzip2 [FILE_NAME]: decompress file at same location
• cp [FILE_1] [FILE_2]: copy file1 to a file called file2
• mv [FILE_1] [FILE_2]: (move) rename file1 to the name file2
• mv [FILE_1] /[FOLDER_NAME]: move file1 to the [FOLDER_NAME] directory
• rm *: deletes everything in a subdirectory (http://cmgm.stanford.edu/classes/unix/rm.html)
• rm -r *: deletes everything in directory
• rm test.txt: removes only file with a name "test.txt" on the end
• tail -500 FILE_NAME | less: see last 500 lines of files
• cat [FILE_NAME]: view file

Size

• df -k: disk size
• df -g: disk size
• df -h: disk size
• du -s [FOLDER_NAME]: folder size info
• du -sh ./: current directory size
• du -sh -- *(D) | sort -k1n: order parent folder by size in ascending order
• ls -l | grep ^- | sort -nr -k 5: order files as per size

Basic network commands

• ifconfig: similar to ipconfig (display network interface parameters)
• hostname: get machine's name
• /etc/init.d/network restart: restart network

Install

• rpm -ivh: install rpm bin file

Init file

• /etc/init.d/chkconfig <SERVICE_NAME> off: off service at startup with super user (http://www.aboutlinux.info/2006/04/enabling-and-disabling-services-during_01.html)
• /etc/init.d/chkconfig <SERVICE_NAME> on: start service at startup with super user (http://www.aboutlinux.info/2006/04/enabling-and-disabling-services-during_01.html)

Terminal

• tty: to check terminal
• ps -ef | grep java: check the java processes
• kill -9 <process_id>: <process_id> is returned by prev command.

User

• startx: start GUI
• useradd <user>: create new user
• passwd <user>: change password for user
• groupadd <groupname>: create new group
• usermod -g <groupname> <user>: Assign a user to a primary group
• usermod -G <groupname> <user>: Assign a user to secondary groups
• whoami: current user
• sudo loginctl enable-linger: Keep a user service alive after logout

vi Editor

• vi [FILE_NAME]: Open or edit a file.
• Esc: Switch to Command mode.
• oo / o: insert new line after current line
• OO / O: insert new line before curren line
• i: Switch to Insert mode.
• [ESC] i ENTER: insert into file to location
• :w: Save and continue editing
• :wq or ZZ: Save and quit/exit vi
• :x: to file save
• :q!: Quit vi and do not save changes
• yy: Yank (copy) a line of text
• p: Paste a line of yanked text below the current line
• o: Open a new line under the current line
• O: Open a new line above the current line
• A: Append to the end of the line
• a: Append after the cursor’s current position
• I: Insert text at the beginning of the current line
• b: Go to the beginning of the word
• e: Go to the end of the word
• x: Delete a single character
• dd: Delete an entire line
• [X]dd: Delete X number of lines
• [X]yy: Yank X number of lines
• G: Go to the last line in a file
• [X]G: Go to line X in a file
• gg: Go to the first line in a file
• :num: Display the current line’s line number
• h: Move left one character
• l: Move right one character
• j: Move down one line
• k: Move up one line

Set ENV

• vi ~/.bash_profile: env variable setup file
• source ~/.bash_profile: export env variables to system
• export JAVA_HOME=/root/java/jdk1.7.0_45
• export MAVEN_HOME=/root/java/apache-maven-3.1.1
• export ANT_HOME=/root/java/apache-ant-1.9.2
• export PATH=$PATH:${JAVA_HOME}/bin:${MAVEN_HOME}/bin:${ANT_HOME}/bin

Increase swap size

• dd if=/dev/zero of=/.swapfile bs=1M count=2048
• mkswap -v1 /.swapfile
• swapon /.swapfile

Miscellaneous

• ubuntu jdk setup: http://www.mkyong.com/java/how-to-install-java-jdk-on-ubuntu-linux/
• clear temp directory: http://forums.opensuse.org/english/get-technical-help-here/how-faq-forums/unreviewed-how-faq/412640-clear-temp-files-boot.html
• sync; echo 3 > /proc/sys/vm/drop_caches: clear buffer cache
• /tmp/VMwareDnD: VM ware DragNDrop files - verify and delete

ETL (Extract, Transform, Load) is a fundamental process in databases and data warehousing used to move and process data from one system to another. It consists of three main steps:

1. Extract – Retrieve data from multiple sources (e.g., databases, APIs, files).
2. Transform – Clean, filter, and modify the data to fit the target system’s structure and requirements.
3. Load – Store the transformed data into the target database or data warehouse.

ETL is widely used for data migration, integration, and analytics. For example, moving data from MongoDB to PostgreSQL is ETL process that ensures structured storage and efficient querying.

Change Data Capture(CDC)

The ETL processor supports real-time Change Data Capture (CDC) to keep data synchronized between MongoDB and PostgreSQL With CDC:

• Watchers monitor MongoDB collections for real-time changes.
• Changes (inserts, updates, replacements, and deletes) are automatically captured and replicated to PostgreSQL.
• Each ETL job can have its own CDC configuration, ensuring flexibility.
• CDC complements batch ETL, providing both real-time and scheduled data synchronization.

Methods for Implementing CDC

1) Apache NiFi

Apache NiFi is a powerful data flow automation tool designed for ETL processes and real-time data streaming. Originally developed by the NSA and later open-sourced by the Apache Software Foundation, NiFi offers:

• An intuitive drag-and-drop interface for building complex data pipelines.
• Support for multiple data sources and destinations, making integration seamless.
• Real-time data ingestion and transformation, ideal for high-volume workloads.

2) Custom Jobs

Custom ETL Jobs automate data transfer between different databases, ensuring seamless integration. These jobs:

• Migrate data from MongoDB to PostgreSQL on a scheduled basis (e.g., daily).
• Define source and target databases to structure data efficiently.
• Process data incrementally based on a specific field (e.g., creationDate).
• Handle data in batches (e.g., 500 records at a time for optimal performance).
• Leverage CDC to track and update changes, ensuring data consistency with minimal manual intervention.

Firebase Cloud Messaging (FCM) is a service that allows you to send notifications and messages to users across platforms like iOS, Android, and the web.This guide will walk you through how to set up Firebase Push Notifications in a React Native app for Android.

Prerequisites

• A React Native project setup (if you don't have one, you can create it by running npx react-native init MyProject).
• Node.js installed on your machine.
• Firebase account and Firebase project setup in the Firebase Console.

Step 1: Create a Firebase Project:

1. Go to Firebase Console.
2. Click on Add Project and follow the steps to create a new project.
3. Go to your Firebase Console and select your project.
4. In the left-hand sidebar, navigate to Project settings (gear icon at the top).
5. In the Project Settings, under the General tab, you'll see the Your apps section.
6. There should be an option to Download google-services.json right next to your Android app listing. Just click that, and it’ll download the file for you.
7. Once downloaded, move the google-services.json file into the app folder of your Android project (usually located at app/ in your project structure).

MyProject/
  ├── android/
  │    ├── app/
  │    │    ├── google-services.json  <-- place it here
  │    │    ├── src/
  │    │    └── ...
  ├── ios/
  ├── lib/
  └── ...

Step 2: Install Required Dependencies:

To use Firebase Cloud Messaging in your React Native app, install these packages via ``npm``
npm install @react-native-firebase/app @react-native-firebase/messaging @notifee/react-native

• @react-native-firebase/app: This is the core library that connects your React Native app with Firebase.
• @react-native-firebase/messaging: This library allows you to interact with Firebase Cloud Messaging (FCM) for push notifications.
• @notifee/react-native: Notifee enables developers to rapidly build rich notifications with a simple API interface, whilst taking care of complex problems such as scheduling, background tasks, device API compatibility & more.

Step 3: Set Up and Configure Each Library According to Official Documentation:

a. Setup @react-native-firebase/app (Firebase Core SDK):
`npm install @react-native-firebase/app`

1. Modify android/build.gradle

buildscript {
  dependencies {
    // ... other dependencies
    // NOTE: if you are on react-native 0.71 or below, you must not update
    //       the google-services plugin past version 4.3.15 as it requires gradle >= 7.3.0
    classpath 'com.google.gms:google-services:4.4.2'
    // Add me --- /\
  }
}

3. Modify android/app/build.gradle

apply plugin: 'com.android.application'
apply plugin: 'com.google.gms.google-services' // <- Add this line

4. rebuilding

# Android apps
npx react-native run-android

Document file to learn more about this library.

b. Setup @react-native-firebase/messaging:

You can refer to the official documentation for setting up messaging.

c. Setup @notifee/react-native:

Document file to learn more about this library.

Step 4: Get FCM Device Token:

Import the Firebase Messaging Library: You need to import @react-native-firebase/messaging to retrieve the FCM token.

import messaging from '@react-native-firebase/messaging';

async function getDeviceToken() {
  try {
    // Get the FCM token
    const token = await messaging().getToken();
    console.log('FCM Device Token:', token);
    return token;
  } catch (error) {
    console.error('Error fetching FCM token:', error);
  }
}

// Call the function to retrieve the token
getDeviceToken();

Step 5: Save the FCM Token to Firestore or Your Backend:

To send the FCM token to your backend server, follow these steps:

1. Set up the backend server (using Node.js or any other backend of your choice).
2. Send the token from the React Native app to your backend, which will save the token in your database.

Step 6: Send a Test Push Notification from Firebase Console:

1. Go to Firebase Console:

• Navigate to the Firebase Console.
• Select your project.

2. Open the Cloud Messaging Section:
   

3. Compose the Message:

4. Target the Notification:

• Under Target, select Single Device.
• Enter the FCM Token: In the "Token" field, paste the device token that you retrieved in the previous step.
  • If you’ve saved the token in Firestore, retrieve it from there, or use the token logged in the console.
    

5. Send the Notification:

• After filling in the details, click on Send Test Message.
• You should see a confirmation message stating that the notification was sent successfully.
  

Conclusion

Setting up Firebase Push Notifications in a React Native app for Android is a straightforward process if you follow the steps carefully. By integrating the required libraries, configuring Firebase, and obtaining the FCM device token, you can enable seamless push notifications for your users.