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
• who am i: current user

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.

Steps to solve this issue:

1. Android Build Configuration Updates

2. Updates to package.json Dependencies

3. Kotlin Version Update in @react-native/gradle-plugin:
   Another file that was modified is the patch file for @react-native/gradle-plugin:

To know more about this issue

• Common Project:
  For shared things that multiple projects can use (like tools, reusable code, or common settings).
  Example: Same DTOs, enums, or helper functions used everywhere.
• System Project:
  For things specific to one application (like custom logic, workflows, and configurations).
  Example: APIs, security settings, or how the app runs.

Before Migration (Example Project)

Example for “Model” entity

A)  Steps to Move in Common Project :

1) Create a new package: “tech.gyri.example.query.model”.

2) Move the “dto, entity, and repository” objects from the “query” package of the Example project to the newly created package “tech.gyri.example.model” in the Common project.

3) Add a new enum to the “CDCCollectionEnum” file and implement a corresponding function in the “CDCStreamWatcher” file.

4)  Add a new enum in the “application-common-properties” file.

Common Project (After Migration)

B)  Steps to Move in System Project :

1) Create the following packages in the System project:

• tech.gyri.example.command
• tech.gyri.example.framework
• tech.gyri.example.query
• tech.gyri.example.shared

2) Move the “model.command” objects from the Example project to the “tech.gyri.example.command.model” package in the System project.

3) In “tech.gyri.example.framework.common”, create a “cache” package and move the “RedisCacheConstants” file there. Additionally, create another package named “exception” and move the “ErrorCode” file into it.

4) Move the “model.query” objects from the Example project to the “tech.gyri.example.query.model” package in the System project. Within this package, move only the “api, exceptions, and infrastructure” sub-packages. Move the remaining sub-packages to the Common project.

5) Move the “shared.model.events” objects from the Example project to “tech.gyri.example.shared” in the System project.

6) Set the authority for the API in the “securityConfig” file within the System project. Add all APIs from the Example project to the System project.

7) Register command and query components in the main file of the System project.

8) Configure Consul in the application.properties file.

System Project (After Migration)

Updated Example Project (After Migration)

The process of moving entities from the Example project to the System and Common projects helps achieve a more organized and modular software architecture. By distinguishing between system-specific logic and shared components, the system becomes more maintainable and scalable.

To know more about CQRS pattern

In this blog, we will explore how to create a robust system for describe image into meaningful word descriptions using Kotlin and Spring Boot. This process integrates modern tools and frameworks like AI APIs (Gemini, ChatGPT), Redis caching, and reactive programming.

Step 1: The Controller

The controller exposes an API endpoint to accept requests for image descriptions. Here’s how it’s implemented:

• The endpoint accepts a POST request containing an image and account credentials.
• It validates the input and delegates the request to the query handler for further processing.

Step 2: The Query

The query encapsulates the data required to retrieve the image description.

• It ensures the necessary details like imageUrl and accountToken are provided.
• Structuring the data in a manner that is easily processed by the query handler.

Step 3: Query Handler

The query handler executes the core business logic. Its responsibilities include:

1. Cache Check:
   It checks if a cached description exists in Redis.
2. Database Retrieval:
   If no cached description is found, it retrieves the description from the database, if available.
3. API Call:
   If the description is neither in the cache nor the database, it calls the AI API to generate a new description.

Step 4: AI API Integration

The service interacts with the AI API to generate image descriptions.

Summary

This system shows how to use Kotlin, Spring Boot, and AI to turn image into word descriptions. By using caching and reactive programming, it works quickly and can handle a lot of requests. Whether you're creating an AI app or learning new tools, this setup is a great starting point.

Liquibase is a powerful database schema evolution tool that integrates excellent with Spring Boot projects. In this guide, we'll walk through the process of configuring Liquibase in a Spring Boot application using Kotlin and Gradle.

Step 1: Add Dependencies

dependencies {
implementation("org.springframework.boot:spring-boot-starter-data-jpa")
implementation("org.liquibase:liquibase-core")

// Add your PostgreSQL dependency
implementation("org.postgresql:postgresql")
}

Run `./gradlew build` to fetch the updated dependencies.

Step 2: Create Liquibase Configuration

create a `liquibase.properties` file in `src/main/resources` with your postgreSQL database connection details and Liquibase settings:

Step 3: Create Liquibase Change Log

In the `src/main/resources/db/changelog` directory, create a `db.changelog-master.xml` file. This file will contain your database changes sets:

<!-- db.changelog-master.xml -->

<databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
                            http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.1.xsd">

    <!-- Add your change sets here -->

</databaseChangeLog>

Step 4: Configure Liquibase in `application.properties`

Open your `application.properties` file and configure liquibase :

# application.properties

spring.liquibase.change-log=classpath:db/changelog/db.changelog-master.xml

Step 5: Run Your Application

Exceute the following Gradle command to run your Spring Boot application:

./gradlew bootRun

Liquibase will automatically apply the database changes during the application startup.

Congratulations! You've successfully configured Liquibase in your Spring Boot project , with PostgreSQL as the database. Customize the database connection properties and change sets based on your project requirements.

NOTE: Adjust the PostgreSQL connection details according to your setup.