DEV Community: Harun Al Rasyid

Building Cursor Powered App: A Devlog Series, Powered by Cursor (Part 4) – Authentication Logic

Harun Al Rasyid — Sat, 09 Aug 2025 05:47:14 +0000

In the last few episodes of this devlog saga, we laid down the basics. From crafting our pkg utilities to sketching out the core architecture.

Now it's time to work on one of the most important parts of any app: Authentication.

Yes, that magical system that decides whether you're a trusted user or just some stranger.

And, get ready for another temporary hardcoded user. Promise, it's just for testing. (I know, we said the same thing about any other config in previous part :D).

In this post, we'll walk through the authentication domain, use cases, and how we wire them together using dependency injection.

While the implementation uses a hardcoded user for now (since the database setup comes later), all the token mechanics are already production-style.

The Authentication Domain

At its core, the authentication domain has just two main players: Credential and Session.

You give us your credentials, we give you a session. Simple as that. At least in theory.

The authentication domain is basically the brain of our login system.
It's where we keep all the logic for:

Validating login credentials (right now for our VIP hardcoded user membership).
Generating JWT tokens.
Handling refresh logic.
Revoking tokens so they can't be reused.

The cool part? It doesn't care about HTTP, JSON, or any of that transport stuff. It's just pure business logic.

And, before your forgot that this is a Cursor-powered application, let's kick things off the right way, by stating the Cursor Rule:

### Credential
Represents the input required for user authentication (login).

- **Fields:**
  - Email: type `user.Email` (referenced from user package), validated as `required,email`
  - Password: type `user.Password` (referenced from user package), validated as `required,password`
- **Best Practices:**
  - Do not store credentials; use only for authentication input
  - Always validate both fields before processing
- **Method:**
  - `Verify(ctx context.Context, matchedUser *user.User) error`: Checks if the provided password matches the user's stored ciphertext. Returns nil if matched, otherwise returns InvalidCredential. Uses the Password's validation and matching logic.

## Session Object
Represents the output of a successful authentication (login), containing issued tokens.

- **Fields:**
  - AccessToken: type `token.Token` (referenced from token package)
  - RefreshToken: type `token.Token` (referenced from token package)
- **Best Practices:**
  - AccessToken is used for short-lived API access
  - RefreshToken is used to obtain new access tokens
  - Consider implementing refresh token rotation for enhanced security
  - Do not expose sensitive token details in logs or user-facing messages

## Token Subject Constants
- **AccessTokenSubject**: Constant string value representing the subject for access tokens (e.g., "access_token").
- **RefreshTokenSubject**: Constant string value representing the subject for refresh tokens (e.g., "refresh_token").
- **Usage**: These constants should be used as the `Subject` field in token claims to distinguish between access and refresh tokens throughout the authentication flow.

We generate two tokens: an access_token and a refresh_token, and store their metadata in Redis.
This metadata is the Session Object, and it's what lets us fully control a token's lifecycle.

Field	Description
`access_token`	A short-lived token (valid for 2 hours) used for most API requests.
`refresh_token`	A longer-lived token (valid for 48 hours), inactive for the first 2 hours.

These tokens are not just random strings. They are stored in Redis along with metadata records in redis.

Field	Description
`exp`	Expiration timestamp.
`nbf`	"Not before” timestamp, ensuring the refresh token can't be used too early.
`jti`	Unique token ID, similar to a JWT claim.
`user_id`	The ID of the authenticated user.
`link_id`	A link between an access token and its refresh token (used for revocation).

Storage keys in Redis:

access:<jti> → metadata
refresh:<jti> → metadata

Why this matters:
The Session Object is the source of truth for authentication. It allows us to:

Enforce expiration and "not before" rules.
Implement revocation instantly (kill a token in Redis, and it's dead on the next request).
Revoke both tokens at once via link_id.
Avoid trusting client-side tokens blindly. Every token is validated against Redis.

Use Cases

We (I and cursor) have implemented three core authentication flows.

1. Login Endpoint

The login flow takes in email and password (right now, it's checked against a hardcoded user. Don't judge, it's just a demo).

If you pass the vibe check, you get:

An access token (valid for 2 hours)
A refresh token (valid for 48 hours, but time-locked for the first 2 hours via nbf).

Why the lock? Because we don't want people refreshing too soon, like your PM who asks "are we done yet?" five minutes after the task was delivered.

2. Refresh Token Endpoint

The refresh endpoint accepts a refresh_token and:

Validates that nbf ≤ current time.
Issues a new pair of tokens (access + refresh).
Revokes the old refresh token (single-use only, like that one time lunch coupon you forgot to redeem).

By revoking the old refresh token, we ensure attackers can't reuse a stolen refresh token.

3. Logout Endpoint

The logout flow accepts the Authorization: Bearer <access_token> header and:

Revokes the access token.
Uses link_id to find and revoke the associated refresh token.

This prevents both access and refresh tokens from being used again.

Dependency Injection

We use Google Wire (https://github.com/google/wire) to handle dependency injection in the authentication module.
The snippet below defines a UseCaseSet

var UseCaseSet = wire.NewSet(
    provider.ConfigSet,
    // Configuration
    provider.ProvideRedisClient,
    provider.ProvideRedisAdapter,

    // Repositories
    provider.ProvideUserRepository,
    provider.ProvideTokenGenerator,

    // Use Cases
    provider.ProvideAuthUseCase,

    // Container
    provider.ProvideContainer,
)

func InitializeContainer() provider.Container {
    panic(wire.Build(UseCaseSet))
}

This approach:

Removes manual dependency wiring.
Makes components easier to test (swap in mocks).
Avoids accidental "hidden"”" dependencies.
Keeps our codebase modular.

In short, UseCaseSet is the blueprint, Wire is the builder, and Container is the final assembled product.

Links, if you're curious

What's Next?

Now that authentication is in place, it's time to bring it to life in the presentation layer.
Here, our APIs will finally be able to greet the outside world. And yes, we'll even make it shake hands politely with Swagger docs.

Building Cursor Powered App: A Devlog Series, Powered by Cursor (Part 3) - Laying the Foundation with Packages

Harun Al Rasyid — Fri, 01 Aug 2025 10:58:40 +0000

Hey! Before we dive into login screens and token refresh logic, I want to take a step back and shine a light on something that rarely gets the attention it deserves: the supporting packages.

They don't flash UI.
They don't talk HTTP. But they are everything that makes the rest of the app possible.

But first, a confession.
I did something bold. Brave. Maybe even a little impulsive.

I subscribed to Cursor Pro

Yes, I paid actual money. And I have zero regrets.

Why? Because coding with Cursor feels less like using a tool and more like pairing with a genius friend who never gets tired, judges my bad naming only silently, and finishes my half-baked ideas without drama X)).

It's not just about giving it prompts. It's about building vibes. You teach Cursor your coding rituals, your quirks, your "I know it's ugly but it works" logic. And wow! it adapts. It's like a teammate that reads your mind, writes tests, and never asks for coffee breaks.

The Foundation: Packages

Before we get fancy with login forms and token flows, let's appreciate the "boring yet essential" stuff: the packages. The heroes of app that quietly hold everything together without complaining.

Redis Adapter

This package wraps Redis operations. I didn't reinvent the wheel, just made it easier to test, swap, and inject (like a good dependency should). The idea is simple: don't scatter redisClient.Set(...) all over your app.

# Redis Adapter Rule

The `redis` package provides an adapter that wraps the `github.com/go-redis/redis/v8` library, offering a simplified and type-safe API for common Redis operations.

## Purpose
- Abstract away direct usage of the go-redis client
- Provide a reusable, testable, and idiomatic interface for Redis operations
- Enable easy mocking and extension for testing and future enhancements

Token Provider

This one powers the generation, validation, and parsing. Both access and refresh tokens. I use a TokenSubject enum to keep things clean (AccessTokenSubject, RefreshTokenSubject, etc).

I also introduced something fun: LinkedToken. It embeds the refresh token ID inside the access token's claim. This way, revoking both tokens becomes possible even when all you have is the access token, neat, right?

Error

In this app, I separate internal errors (think: Redis down, token parsing failed) from business errors (like "wrong credentials").

How?

Internal errors are wrapped with my beloved stackerror package. They bubble up with stack traces and observability in mind.
Business errors are returned as value objects and interpreted at the presentation layer.

This separation lets me write usecases that don't care about HTTP status codes, they just speak in errors, and the HTTP handler translates.
It's like a translator for angry backend logic.

Bonus: Cursor Rule Files Are a Superpower

With Cursor, I rely heavily on .mdc files to establish patterns and expectations.

For example:

# Convention
All packages under /pkg must expose clear interfaces and avoid coupling with HTTP or Echo

# Rule
Business errors are never returned as HTTP errors from usecases

It's not just prompting, it's like training your AI teammate on your architectural beliefs.

That's it for today!
Authentication is coming next, but I hope showing the invisible infrastructure was helpful. If you've ever wondered how to structure pkg in a scalable Go backend, or want to make AI pair programming less chaotic, this is where I started.

Links, if you're curious

mtsg Repo

Next Up

We're diving into the juicy stuff: the authentication business module.
Think clean usecases, no HTTP nonsense, and logic that could survive a framework apocalypse.

We'll answer questions like:

What actually happens during a login?

How do refresh tokens work with Redis?

Can you TOTP your way into greatness?

Stay tuned, the domain is strong with this one

Building Cursor Powered App: A Devlog Series, Powered by Cursor (Part 2) - Defining the Domain

Harun Al Rasyid — Mon, 14 Jul 2025 13:27:07 +0000

After struggling with docs in Part 1, I finally touched some code.

This was the start of the actual domain modeling process: defining the core business entities of the app:

Tenant: represents a customer account (company/org)
User: belongs to a tenant and interacts with the system
Project: something users can create and manage under their tenant

Each model is defined in its own file inside internal/domain/, keeping things modular and easy to scale.

Why Start with Domain?

Because the domain layer is the heart of the app.
And, let's be honest. It makes me look like I know what I'm doing

Directory Layout

I’m keeping the structure… well, not exactly simple.

But trust me, I'm pretending I know what I'm doing

internal/
└── domain/
    ├── tenant/
    ├── user/
    └── project/

Each entity gets its own package. It might look like overkill now, but it will pay off as things grow.

What's next

Domain Rules

To keep my domain layer consistent (and to future-proof my sanity), I started writing some generic domain rules in .mdc files.

Here’s what I’ve got so far:

entity.mdc, defines how entities should be structured (fields, IDs, invariants)
generic-types.mdc, documents reusable components like Identity, Enumerated String types.
unit-test.mdc, outlines rules for generating unit tests for domain entities

These arent just notes. They act as Cursor-aware prompts or codegen contracts.

Its a bit like meta-programming: I describe the rules, and Cursor helps generate code that follows them.

So yes, I am basically writing documentation for an AI to read X))

Entity

Once I had my entity.mdc rule in place, I started defining specific entity contracts. Beginning with tenant.mdc.

Here’s how it works: instead of jumping straight into code, I describe the entity and its behavior in Markdown, like this:

# Tenant

This rule describes the **tenant** entity and its behavior.

## Entity

### Tenant

- ID: Identity of Tenant – New Identity
- Name: string – constructor input
- Status: Enumerated string of "active", "inactive", default("active")

This isn't just documentation — Cursor uses it to generate consistent, valid Go code that follows my conventions.

It reads the structure, applies the meta-rules from entity.mdc, and gives me a complete Go struct, constructor, and even basic validation.

So in a way, I am designing the system in plain text first, and letting AI turn it into working code.

And honestly? I amm starting to feel like it writes Go better than I do X)).

Links, if you're curious

Next Up

Now that the domain layer is in place, I'm going to focus on session management and authentication.

I'll be storing sessions in Redis (instead of using JWTs) so I can invalidate them easily — a pattern I've used and loved in past projects.

Building Cursor Powered App: A Devlog Series, Powered by Cursor (Part 1)

Harun Al Rasyid — Sat, 12 Jul 2025 07:29:42 +0000

A few days ago, I found myself curious about this whole "vibe coding" movement. You know, using AI-powered tools like Cursor or Copilot to speed up the flow of coding, especially in solo or creative projects.

I wasn’t chasing productivity or building a startup — I just wanted to see how it feels to build something serious but personal, with AI as a pair.

So I asked ChatGPT (yes, I even ask AI for the idea) for ideas that would:

Simulated the real world project
Stay safely outside of my current job’s non-compete zone

That’s when it suggested:

"How about building a cleanly architected, multi-tenant SaaS backend in Go?"

Boom!! A project name idea was invented:

Multi-Tenant SaaS Backend

I even had no idea what that meant. X))

Still, I thought hard about the project and figured I’d better start by abbreviating the name: MTSB.

How smart am I.

And instead of hiding it away, I decided to document every step — one post per task, like a devlog journal.

This is the first post in what might become a very long devlog series — one post per issue or PR. Basically a public journal of code, architecture, struggle, and vibes.

So be ready. It could be millions of posts. Or like, five.

Day 1 — Setting the Foundation with Docs

Before writing a single line of code, I decided to start with something most devs (myself included) usually skip or leave half-baked:

Documentation.

Why? Because it’s a great way to:

Clarify what I’m actually building
Lay out the structure before getting lost in implementation details
Make the repo portfolio-ready from Day 1
Make me looks like professional dev :D

What I Wrote (or not written by me)

README.md – basic overview, goals, tech stack, and structure
docs/architecture.md – Clean Architecture overview with Mermaid diagrams
docs/data-model.md – sketches of key entities and relationships
docs/tenant.md – a deeper look at the "tenant" concept and how it fits into the app
docs/user-journey.md – a rough user flow from signup to project creation

Looks smart isn't it? Unfortunately not. I didn’t write the docs alone. I used Cursor to keep the flow tight and fast. Combined with ChatGPT, it felt less like "writing docs" and more like sketching out a blueprint with a buddy who types faster and doesn’t complain.

Cursor helped:

Suggest Markdown layout
Autocomplete repetitive sections
Keep my thoughts structured and clean

It was honestly the most painless documentation session I’ve ever had.

What I Learned

Starting with documentation forces you to think before you build. Sounds obvious… but it’s so easy to skip.
Defining architecture early sets the tone. Even if it changes later, you’ve at least set a direction.
You don’t need to over-engineer docs. A few .md (or more precisely .mdc) files can go a long way when done with intention.
You even don't need to write article like this from scratch. Credit to chatGPT.

Links, If You're Curious

Up Next: Domain Modeling

In next session, I’ll start building the core domain layer.

That means defining types like Tenant, User, Project, and laying the foundation for the actual business logic — all while keeping it clean, testable, and cursor-powered.

Thanks for reading! Stay tuned for more journal entries — and if you’re building something similar, let’s connect!

Revisiting My Old Neural Network Project in Go

Harun Al Rasyid — Tue, 01 Jul 2025 08:17:15 +0000

A few years ago, I built a minimal neural network toolkit in Go: Rolade – a minimal neural network library written in Go.

It was messy, naïve, and mostly forgotten in my GitHub. The goal was to better understand the internals of forward and backpropagation by implementing everything manually, without relying on external ML libraries. The code worked, but it was very basic and lacked in performance.

Now, I’m revisiting this project to refactor the code and improve the overall design. Here’s a summary of what I’ve improved:

What Was Already Working

Modular organization

The codebase already had a good separation of concerns: activation functions, loss, optimizers, and network logic were neatly organized into their own modules. This made it relatively easy to extend the library with new features.

The Improvement : Parallel Training

To improve training efficiency, I implemented parallel batch training.

Training data is split into multiple batches, each processed in a separate goroutine using sync.WaitGroup.
I used sync.Mutex to safely collect training errors and weight deltas from all batches.
After all batches are processed, the deltas are merged using a custom mergeDeltas() function and applied once at the end of the epoch.

Lessons Learned

Race Condition. Initial versions caused data races when multiple goroutines accessed or modified shared weight structures.

Fix: Delay all updates until after parallel computation finishes.

Locking Can Kill Parallelism. Putting locks around weight updates inside each batch makes the process sequential. It removes the benefit of parallelism.

Fix: Do all mutation after goroutines have joined.

Unstable Training Without Averaging. Summing raw deltas led to unstable error gradient.

Fix: Add delta average in mergeDeltas() to stabilize learning.

🚀 Final Result

Training speed increased (especially for datasets like Iris).
Accuracy was retained.

🧩 Source: github.com/harungurubudi/rolade