DEV Community: Sushant Rahate

I Built a Daily JavaScript Quote Bot with GitHub Actions (No Server Required)

Sushant Rahate — Sun, 01 Mar 2026 19:54:16 +0000

This is a submission for the DEV Weekend Challenge: Community

👉 Check it out in action: https://t.me/jsdailybyte

The Community

JS Daily Byte was built for a Telegram Channel of developers who want to stay sharp on JavaScript fundamentals.

We didn’t need another course.
We didn’t need long threads.

We just needed one clear JavaScript concept, delivered daily.

Simple. Focused. Practical.

What I Built

JS Daily Byte is a fully automated Telegram bot powered by GitHub Actions.

Every day at 13:00 UTC, it:

Reads a quotes.json file
Picks a deterministic quote based on the current date
Formats it safely for Telegram
Sends it to the JS Daily Byte channel

No servers.
No hosting.
No cron jobs on a VPS.
No backend deployment.

Just GitHub + Telegram API.

Example message:

🟡 JS Daily Byte

“Every JavaScript program runs inside an execution context with two 
phases: memory creation and code execution.”

Demo

🔗 Telegram Channel:
https://t.me/jsdailybyte

(Every day a new JavaScript concept drops automatically.)

Code

The entire project is open on GitHub:

👉 https://github.com/sushantrahate/js-daily-byte

Key files:

quotes.json - Stores all JavaScript concepts in a simple array format.
.github/workflows/js-daily-byte.yml - GitHub Action that runs daily and handles the entire automation flow.

How I Built It

The stack is intentionally minimal:

GitHub Actions → daily scheduler (cron at 13:00 UTC)
Node.js (inline script) → reads JSON + generates deterministic index
Telegram Bot API → sends formatted message
Secrets → bot token + chat ID stored securely

Why GitHub Actions?

Because:

It’s free
It’s reliable
It removes infrastructure complexity

The workflow:

Loads the quotes array from quotes.json
Generates a deterministic index using the current UTC date
Selects the corresponding quote
Escapes HTML to ensure Telegram-safe formatting
Sends the formatted message to the Telegram channel via the Bot API using curl.

No database.
No server.
No maintenance.

The entire setup takes under 30 minutes.
Perfect for a small but meaningful weekend hack. 😉

Build Your Own in 5 Steps

Create a Telegram bot (via @ BotFather)
- Open Telegram and search @ BotFather
- Run /newbot
- Set a name (example: JS Byte Bot) and a username ending with bot
- Copy the API token BotFather gives you (this becomes TG_BOT_TOKEN)
Create a Telegram channel and add the bot
- Create a channel (example: JS Daily Byte)
- Add your bot to the channel
- Make the bot an admin so it can post messages
Get your Telegram chat_id
- Send a message in the channel (or mention the bot like @ YourBot hi)
- Open this URL in a browser: https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates
- Copy the chat.id value (usually starts with -100...) This becomes TG_CHAT_ID
Add your quotes
- Create quotes.json in the repo root
- Store quotes as a simple array of strings, like: ["quote 1", "quote 2", "quote 3"]
Add the GitHub Actions workflow
- Create .github/workflows/js-daily-byte.yml
- Add a scheduled cron job (example: 0 13 * * * for 13:00 UTC)
- Workflow will:
  - read quotes.json
  - pick the quote for the day
  - send it using Telegram Bot API via curl
Add GitHub Secrets (required)
- Repo → Settings → Secrets and variables → Actions → New repository secret
- Add:
  - TG_BOT_TOKEN = your BotFather token
  - TG_CHAT_ID = your channel chat id

After that, the bot runs daily automatically. You can also trigger it anytime from the Actions tab using workflow_dispatch.

That’s it.

Final Thoughts

JavaScript fundamentals aren’t difficult because they’re complex.
They’re difficult because we forget them.

JS Daily Byte keeps these concepts fresh - one small reminder at a time.

You can find more of my work at: https://sushantrahate.com/

Happy coding! 😄

I Built a 100/100 Google Lighthouse Portfolio website - By Keeping It Boring

Sushant Rahate — Sun, 28 Dec 2025 16:11:40 +0000

Like most developers, I once believed a portfolio had to be flashy.
More animations • More motion • More “wow”
And somehow… a Lighthouse score of 62 😅

So this time, I did the opposite.

👉 Portfolio: https://sushantrahate.com

(Open it alongside this post if you want context.)

PageSpeed Insights: https://pagespeed.web.dev/analysis/https-sushantrahate-com/vkyra56xl5?form_factor=desktop

The Real Goal

I didn’t want my portfolio to entertain people.

I wanted it to respect their time.

It should load in milliseconds
And the moment it appears, the viewer should feel: “Okay. I know who this person is.”

The first screen is the first impression.
If that moment is unclear, everything after it is noise.

So the first screen explains - without asking you to scroll:

who I am
what I do
what I’m building

No telling. Only proof.

“Talk is cheap. Show me the code.” - Linus Torvalds

My Constraints (Intentionally Self-Imposed)

Before writing a single line of code, I set strict rules:

⚡ 100% Google Lighthouse performance
🧠 Only essential information
🚫 No heavy frameworks
🚫 No animations to wait for
🚫 No component libraries
🚫 No guessing
🚫 No effort required from the viewer
✅ Fast even on slow networks

The Layout: Compact by Design

Once I knew what to show, I focused on how.
I chose a bento grid layout - compact, high-signal information density.

People don’t read websites line by line.
They scan, usually in a Z-pattern:
top-left → top-right
then diagonally down
then left → right again

So I placed sections deliberately to match that flow.

1. Starting With the Human

The page begins with who I am.

I mention JavaScript, not a long list of frameworks (tools change, fundamentals don’t)
I mention backend and security (that’s how I think when building systems)
I end with a small personal line - husband, dad to remind there’s a human behind the code

No fluff. Just context.

2. What I’m Actually Building

At the top, I show what I care about right now:

MatriProfile - my live SaaS

👉 https://matriprofile.com

A modern, multilingual, privacy-first marriage biodata generator -
built end-to-end by me.

Shipping a real product teaches more than any tutorial or side project ever will:
product thinking, user behavior, trade-offs, and long-term maintenance.

3. Proof Over Promises

I first heard this line in The Social Network, and it stuck:

“Talk is cheap. Show me the code.”
Instead of listing skills, I show repositories.

One of them:
👉 https://github.com/sushantrahate/express-typescript-prisma-postgresql
⭐ It has 27 GitHub stars - but more importantly, it has intent.

It’s a production-ready backend starter focused on:

clean architecture
TypeScript discipline
real-world backend patterns

4. Writing for Clarity

I also link to articles I’ve written.
Because writing exposes understanding.
If I can explain authentication, access control, or backend trade-offs in simple words,
it means I’ve wrestled with those concepts long enough to earn clarity.

Finally, social links sit at the bottom.

The Tech Stack

HTML
Tailwind CSS
Vanilla JavaScript

JavaScript is loaded with defer, so it never blocks rendering.

<script src="./script.js" defer></script>

Fetching GitHub stars is handled carefully:

The API call runs only after the page has fully loaded
First paint stays untouched

Closing Thought

A portfolio doesn’t need to explain everything.
It just needs to make the right impression - fast
and give the viewer clear paths to go deeper if they want to.

Mine isn’t a big portfolio.
It’s simple, clean, and intentional.

And sometimes, boring is exactly what works.

GitHub URL: https://github.com/sushantrahate/portfolio

I hope this guide helps you. Happy coding! 😄
I’d love to connect - whether for work, collaboration, or just to talk systems.

Node.js Authentication: Best Practices and Key Strategies

Sushant Rahate — Mon, 11 Nov 2024 08:41:06 +0000

This article showcases secure login strategies for Node.js, implementing multiple security techniques to safeguard user credentials, sessions, and account access.

Key Security Features

1. Password Hashing with Salt

Passwords are hashed using a strong hashing algorithm (e.g., bcrypt) along with a random salt for each password. This ensures that even if the hashed password is compromised, it cannot easily be reversed into the original password.

Why its important:

Prevents plain-text password storage.
Salting makes it difficult for attackers to use precomputed hash tables (rainbow tables) to guess passwords.

Implementation:

import bcrypt from 'bcrypt';

const hashPassword = async (password: string): Promise<string> => {
  const saltRounds = 10;
  const salt = await bcrypt.genSalt(saltRounds);
  return await bcrypt.hash(password, salt);
};

// Create and save the user in the database
const newUser = new User({ username, password: hashPassword });
await newUser.save();

// Login API
const { username, password } = req.body;

const user = users.find((u) => u.username === username);
if (!user) return res.status(400).send('User not found');

const isPasswordValid = await bcrypt.compare(password, user.password);
if (!isPasswordValid) return res.status(400).send('Incorrect password');

2. Token-Based Authentication

JWT (JSON Web Token) is used for token-based authentication, allowing stateless authentication between the client and server. Users receive a JWT upon login, which is then sent with every subsequent request in the Authorization header.

Why its important:

Stateless: No need for session storage on the server.
Secure token can carry claims (user ID, roles) without exposing sensitive information.

Implementation:

import jwt from 'jsonwebtoken';

const generateToken = (userId: string) => {
  return jwt.sign({ userId }, process.env.JWT_SECRET, { expiresIn: '1h' });
};

3. Refresh Tokens

A refresh token is used to obtain new access tokens without requiring the user to log in again. This ensures a smooth experience for users without compromising security.

Here Is Repo for JWT Authentication With Refresh Token as HTTP-only Cookie

Why its important:

Minimizes exposure by using short-lived access tokens.
Refresh tokens are stored more securely (e.g., in a database or HTTP-only cookie).

Implementation:

const generateRefreshToken = (userId: string) => {
  return jwt.sign({ userId }, process.env.REFRESH_SECRET, { expiresIn: '7d' });
};

4. HTTP-Only Cookies

Store sensitive tokens such as refresh tokens in HTTP-only cookies. This prevents JavaScript from accessing the tokens, protecting them from XSS (Cross-Site Scripting) attacks.

Why its important:

Shields tokens from being stolen by malicious scripts.
Reduces the risk of token exposure through client-side code.

Implementation:

res.cookie('refreshToken', refreshToken, {
  httpOnly: true,
  secure: process.env.NODE_ENV === 'production',
  sameSite: 'strict',
});

5. JWT Blacklisting

JWT tokens do not have built-in revocation. To invalidate tokens (e.g., on logout), JWT blacklisting is used. A database or Redis is used to store invalidated tokens until they expire.

Why its important:

Prevents previously issued tokens from being used after logout or account compromise.

Implementation:

const blacklistToken = async (token: string) => {
  await redisClient.set(token, 'blacklisted', 'EX', tokenExpirationTime);
};

6. Single Session at a Time

Ensure that only one session is active for a user at any given time. When a new session is created, invalidate previous tokens or sessions.

Why its important:

Prevents concurrent logins from multiple devices or locations, enhancing account security.

Implementation:

// Schema for User table:
sessionId: { type: String, unique: true }

//login API
const newSessionId = generateAccessToken(user);
user.sessionId = newSessionId;
await user.save();

// Auth API
const decodedToken: any = jwt.verify(token, process.env.ACCESS_TOKEN_SECRET!); // Replace with your JWT secret key
const sessionIdFromToken = decodedToken.sessionId;

if (user.sessionId !== sessionIdFromToken) {
      return res.status(403).json({ message: 'Session invalidated. You are logged in elsewhere.' });
    }

7. Ideal Time Session Expiration

Sessions expire after a period of inactivity. Implement a session expiration timer to automatically log out users who are inactive for a predefined time.

Why its important:

Reduces the risk of an unauthorized person accessing the session if the user forgets to log out.

Implementation:

const sessionExpirationTime = 15 * 60 * 1000; // 15 minutes
const IDLE_TIMEOUT = 15 * 60 * 1000;

// User Schema
lastActivity: { type: Date, default: Date.now }, // Track last activity timestamp

// in auth middleware
const now = new Date();
const idleTime = now - new Date(user.lastActivity);

if (idleTime > IDLE_TIMEOUT) {
  // Token is still valid, but session is idle for too long
  return res.status(401).json({ message: 'Session expired due to inactivity' });
}

// Else Update last activity timestamp if within idle timeout
user.lastActivity = now;
await user.save();

8. Account Lockout Mechanism

Prevent brute force attacks by locking out accounts after several failed login attempts. Implement time-based lockout, where accounts are temporarily locked after repeated failures.

Why its important:

Mitigates brute force attacks by limiting login attempts.

Implementation:

// Schema
failedLoginAttempts: { type: Number, default: 0 },
lockoutUntil: { type: Date, default: null }, // Track lockout time

const MAX_ATTEMPTS = 3;
const LOCK_TIME = 15 * 60 \_ 1000; // 15 minutes
// Example for MongoDB with Mongoose
const handleFailedLogin = async (email: string) => {
  const user = await User.findOne({ email });
  if (!user) return false;

  if (user.lockoutUntil && user.lockoutUntil > new Date()) {
    return true; // Account is still locked
  }

  user.failedLoginAttempts += 1;

  if (user.failedLoginAttempts >= MAX_ATTEMPTS) {
    user.lockoutUntil = new Date(Date.now() + LOCK_TIME); // Lock for 30 mins
  }

  await user.save();
  return user.lockoutUntil && user.lockoutUntil > new Date(); // Return if account is locked
};

// Reset login attempts if the login is successful

9. Secure Password Reset Procedures

Users can reset their passwords through a secure process. Use a time-limited, one-time token (OTP) sent to the user's email for the reset process. Ensure the reset token expires after a short period.

Why its important:

Provides users a secure way to recover accounts without compromising security.

Implementation:

// User Schema
resetPasswordToken: String,
resetPasswordExpires: Date,

/* Use crypto.randomBytes() to generate a secure hex instead of Math.random(), Math.random() hex are easier for attackers to guess or brute force. */
const generateResetToken = () => {
  return crypto.randomBytes(20).toString('hex');
};

const token = generateResetToken();
user.resetPasswordExpires = Date.now() + 3600000; // 1 hour from now

10. Password Expiration and Restricting Past 3 Passwords

Here's how this works:

Password History:

The system stores the last three hashed passwords in a user's password history.
When a user attempts to set a new password, the system compares the new password against these previous passwords to prevent reuse.

Password Expiration:
- The system tracks how long a user has been using their current password.
- After a set period (e.g., 1 month), the system sends a notification prompting the user to change their password.
- If the password is not updated within a given grace period, access may be restricted until a new password is set.

// Schema
passwordHistory: [{ type: String }], // Array to store past 3 password hashes
passwordUpdatedAt: { type: Date, default: Date.now }, // When the password was last updated

// You can Check Expiration on Login or have a corn job to find and notify users via email.

11 . Implementing Strong Password Policies

Strong password policies help prevent unauthorized access and minimize the risk of brute-force attacks, dictionary attacks, and credential stuffing.

Implementation:

import validator from 'validator';

const password = 'User@1234';
if (
  !validator.isStrongPassword(password, {
    minLength: 8,
    minLowercase: 1,
    minUppercase: 1,
    minNumbers: 1,
    minSymbols: 1,
  })
) {
  throw new Error('Password does not meet complexity requirements.');
}

12. User-Specific Token Revocation

User-specific token revocation is the process of invalidating a single user’s tokens without affecting others.

It’s useful in cases like:

Suspicious activity detected on an account
A user requests token revocation for security
The account is disabled or suspended
A token is stolen or leaked

How it Works:

Token Structure:

Tokens (e.g., JWTs) contain user data and a tokenVersion. The tokenVersion is stored in the database to track the validity of tokens for each user.

Token Verification:

When a request is made, the server decodes the token and compares the tokenVersion in the token with the version stored in the database. If they match, the token is valid; if not, the token is invalidated.

Token Revocation:

To revoke all tokens for a user, simply increment the tokenVersion in the database. All tokens with the previous version are automatically invalidated.

Implementation:

// Schema: token_version INT DEFAULT 1

// JWT Creation
const createToken = (user) => {
  const payload = { userId: user.id, tokenVersion: user.tokenVersion };
  return jwt.sign(payload, SECRET_KEY, { expiresIn: '1h' });
};

// Token Validation
if (user.tokenVersion !== decoded.tokenVersion) {
  throw new Error('Invalid token: version mismatch');
}

// To revoke, increment tokenVersion
user.tokenVersion++;

13. Cross-Origin Resource Sharing (CORS) Configuration

Configure CORS to restrict which origins are allowed to access the API. Only trusted domains should be allowed to send requests to your server.

Why its important:

Prevents unauthorized sites from making requests to your server.
Protects against CSRF (Cross-Site Request Forgery) attacks.

Implementation:

import cors from 'cors';

app.use(
  cors({
    origin: 'https://your-frontend-domain.com',
    credentials: true,
  })
);

Also read Role-Based Access Control with Feature-Centric Approach

Check out my GitHub profile: https://github.com/sushantrahate

I hope this guide helps you. Happy coding! 😄

Role-Based Access Control (RBAC) with Feature-Centric Approach

Sushant Rahate — Sat, 09 Nov 2024 19:01:50 +0000

In this article, we’ll explore how to set up a Role-Based Access Control (RBAC) system where features are a central part. We'll go through defining modules, associating features, assigning roles with specific features, and finally assigning roles to users. This example uses JSON data to keep things simple and adaptable, allowing for scalable access control without requiring any changes for new roles on the frontend

Live Demo

1. Define Modules and Features

Modules group similar features together. Each module can contain multiple features representing actions that users can perform.

JSON Structure for Modules and Features:

{
  "modules": [
    {
      "id": 1,
      "name": "Users",
      "features": [
        "view-users",
        "edit-users"
      ]
    },
    {
      "id": 2,
      "name": "Reports",
      "features": [
        "view-reports",
        "edit-reports"
      ]
    }
  ]
}

Modules: Represents a specific area of the application, like "Users" or "Reports."
Features: Actions within each module, such as view-users and edit-users for the Users module.

2. Create Roles and Assign Features

Next, create roles that define sets of features. Each role will have a list of permissions that grant access to specific features within the modules.

JSON Structure for Roles and Permissions:

{
  "roles": [
    {
      "id": 1,
      "name": "Admin",
      "permissions": [
        "view-users",
        "edit-users",
        "view-reports",
        "edit-reports"
      ]
    },
    {
      "id": 2,
      "name": "Viewer",
      "permissions": [
        "view-users",
        "view-reports"
      ]
    }
  ]
}

Roles: Represent groups with specific access rights, like "Admin" and "Viewer."
Permissions: Specify which features each role has access to, allowing for flexible permission settings.

By defining roles, you can manage access control efficiently without modifying each user's permissions.

3. Assign Roles to Users

After creating roles, assign them to users. Each user will inherit the permissions granted by their role.

JSON Structure for Users and Role Assignments:

{
  "users": [
    {
      "id": 1,
      "name": "Sushant",
      "roleId": 1
    },
    {
      "id": 2,
      "name": "Raghav",
      "roleId": 2
    }
  ]
}

Users: Represent individuals who will access the application.
RoleId: Links each user to a specific role, determining their feature access.

With this structure, you can easily update roles to grant or restrict access for multiple users simultaneously.

4. Setting Up Access Control Logic in the Frontend

On the frontend, access to each feature is checked based on the user's role. Here’s how to securely handle user access based on their assigned role.

Fetch Role Permissions: When a user logs in, retrieve their role's permissions from the backend.
Store Permissions Locally: For session-based access control, store permissions in a secure format (such as JWT or session storage).
Conditional Rendering: For each section or feature, check if the user has permission to view or edit it.

Example Access Check in JavaScript:

const userPermissions = ["view-users", "edit-users"]; // Loaded from backend based on role

if (userPermissions.includes("view-users")) {
  // Render the user view section
}

if (userPermissions.includes("edit-users")) {
  // Render the user edit section
}

Using a role-based check in the frontend ensures that users only see features they’re permitted to access.

Backend Validation

While this example focuses on the frontend, validating user roles and permissions should also happen on the backend. Backend validation should re-check feature access on every request, helping to prevent any unauthorized data or feature access

Pros and Cons

Pros

Fine-Grained Access Control: This approach allows you to control user access on a feature-by-feature basis, which is more flexible than traditional role-based access control.
Scalability: New features and modules can easily be added to the system, and roles can be adjusted without significant backend changes.
Improved Security: By combining frontend validation and strict backend checks, this system helps prevent unauthorized access to restricted features.

Cons

Complexity: Feature-based access control can become complex, especially as the number of modules, features, and roles increases. Proper planning and documentation are essential to prevent it from becoming difficult to manage.

Conclusion

Role-Based Access Control (RBAC) with a feature-centric approach offers a scalable and efficient way to manage user permissions. By defining modules and features, setting up roles, and assigning or updating features to roles, you can easily create and manage custom roles without requiring any new changes in the frontend.

Check out my GitHub profile: https://github.com/sushantrahate

I hope this guide helps you. Happy coding! 😄