DEV Community: Saif Jlassi

I'm building a scripting language for whiteboard animations

Saif Jlassi — Sat, 19 Sep 2026 10:24:50 +0000

I started Strokeline with one dumb, simple idea:

What if you could describe an animation the same way you describe a webpage — with text — and something else just... drew it?

Not AI-generated video.

Not a drag-and-drop editor where you fight with alignment guides for twenty minutes.

A script.

You write:

CIRCLE browser
RECTANGLE server
ARROW browser -> server

Hit run, and a hand-drawn whiteboard animation plays.

The twist — and really the whole point — is that the scripting language is simple enough that you can ask ChatGPT, Claude, or another AI to write it for you.

Something like:

Explain how DNS works in 45 seconds.

goes in.

A script comes out.

You paste it in.

You hit run.

And hopefully...

an animation comes out.

Simple idea.

Turns out "simple idea" and "simple to build" have almost nothing to do with each other.

The bug that ate 4GB of RAM

Somewhere in week one, my test suite died.

Not failed.

Died.

Vitest ran out of memory and took the whole process down with it.

It took a while to track down, but here's what was happening.

My parser had a recovery mechanism.

If it hit a broken line, it was supposed to skip ahead to the next recognizable keyword and keep going instead of crashing on the first typo.

Good idea in theory.

The bug was that one specific keyword — TEXT, if you're curious — could be interpreted in two different ways.

It could be a property:

CREATE server AS RECTANGLE
  TEXT "SERVER"
END

But it was also being treated as a statement boundary that the error-recovery logic could search for.

Under the wrong conditions, the parser would "recover" to a position it had never actually left.

So it did this:

parse
  ↓
error
  ↓
recover
  ↓
same position
  ↓
error
  ↓
recover
  ↓
same position
  ↓
...

Forever.

Every iteration created another diagnostic object.

Eventually:

4GB of RAM.

Then the OS gave up.

The actual fix was three lines.

Finding those three lines was not.

The screen that just went black

Once the parser was solid, I started building the actual editor.

The basic idea is pretty simple:

┌─────────────────────┬──────────────────────────┐
│                     │                          │
│    SCRIPT EDITOR    │      ANIMATION           │
│                     │                          │
│  CREATE browser...  │       ✏️ ○ ───────→ □   │
│                     │                          │
│                     │                          │
└─────────────────────┴──────────────────────────┘

Type on the left.

Watch it animate on the right.

I pasted in a two-scene test script to check everything worked end to end.

Black screen.

Console full of red text.

Maximum update depth exceeded.

Great.

This one wasn't the parser at all.

It was React and my state manager, Zustand, getting into a fight neither of them could win.

Somewhere in the code that renders the scene tabs, a piece of derived data — basically:

"Give me the list of scenes."

— was being recalculated on every render.

That meant it was a new array every time, even when nothing had actually changed.

React compares objects and arrays by reference.

So:

new array
   ↓
"Something changed"
   ↓
re-render
   ↓
calculate scenes
   ↓
new array
   ↓
"Something changed"
   ↓
re-render
   ↓
...

Forever.

It only showed up with two or more scenes.

One scene?

Totally fine.

Two scenes?

Welcome to hell.

That's the kind of bug that makes you paranoid about every other component in your codebase doing the exact same thing quietly, waiting for the right input.

Text that vanishes the moment it finishes appearing

This one's my favorite because it's so specific that it's almost funny.

I finally got the "hand-drawn" reveal working.

Text types itself onto the canvas character by character.

Shapes trace their own outlines like a pen is drawing them.

It was genuinely satisfying to watch.

Except...

A few seconds after any text finished typing, it would just...

disappear.

Not fade.

Not glitch.

Gone.

Like it was never there.

I had two separate rendering paths.

One for:

still animating

where the text was drawn live every frame.

And another for:

finished

where I could reuse a cached image instead of asking an expensive hand-drawn rendering library to redo the same work sixty times a second for something that wasn't moving.

Smart idea.

Better performance.

Except the code calculating how large that cached image needed to be was using a rough guess:

text.length * fontSize * 0.55

I am not proud of that line.

It also assumed the text started from a point instead of being centered on that point, which is how it actually gets drawn.

So everything looked perfectly fine while the animation was running.

Then the animation finished.

The renderer switched to:

"just show the cached version"

And suddenly the cached version had the wrong dimensions and the wrong position.

Half the text disappeared silently.

Every.

Single.

Time.

The animation itself was working.

The cache was working.

The transition between the two was the problem.

None of these bugs were exotic

That's probably the part I find most interesting.

There was no mysterious AI behavior.

No obscure browser API.

No impossible-to-reproduce hardware issue.

Just normal software bugs.

Different bugs.

Different systems.

Different symptoms.

But underneath, they all had something in common:

the program believed something was true when it wasn't.

The parser thought it had recovered.

It hadn't.

React thought the data had changed.

It hadn't.

The renderer thought the cached text had the correct dimensions.

It didn't.

Three completely different corners of the codebase.

Three completely different disguises.

Same fundamental problem.

Why I'm telling you this instead of just shipping quietly

Because I think there's a specific kind of satisfaction in watching something like this get built in public.

Not just the polished announcement at the end.

The bugs too.

The broken builds.

The weird rendering problems.

The moments where you stare at a console error wondering how something this stupid could possibly be happening.

The whole premise of Strokeline is:

text
  ↓
program
  ↓
animation

And building the thing that makes that possible has turned out to be a pretty good example of exactly that process.

You write something you believe is correct.

Then reality — the browser, the state manager, the parser, the rendering pipeline — tells you:

"No."

And you investigate why.

The part I'm most excited about

The interesting thing about a scripting language for animations isn't really the shapes.

Drawing a circle isn't difficult.

Drawing an arrow isn't difficult.

Even animating them isn't particularly difficult.

The interesting part is creating a language that is:

simple enough for humans to understand
structured enough for a renderer to execute
predictable enough for an AI to generate
expressive enough to create real explanations

For example, I want something like this to be enough to explain a basic HTTP request:

SCENE 1 "HTTP Request"

  CREATE browser AS CIRCLE
    POSITION 400 500
    RADIUS 100
    LABEL "Browser"
    DRAW 1s
  END

  CREATE server AS RECTANGLE
    POSITION 1400 500
    WIDTH 300
    HEIGHT 220
    TEXT "SERVER"
    DRAW 1s
  END

  ARROW browser -> server
    LABEL "HTTP Request"
    DRAW 1s
  END

END SCENE

That's the direction I'm aiming for.

Not a giant animation framework that requires a 400-page manual.

Something closer to:

HTML, but for explaining things visually.

And yes, AI is a big part of this

This is where Strokeline gets particularly interesting to me.

You don't necessarily need to learn the scripting language.

You could simply ask:

Explain how a database index works in 60 seconds.

Use three scenes.

Start with a slow query.

Then show the index.

Finish by comparing indexed and non-indexed lookups.

The AI generates the script.

Strokeline validates it.

The renderer executes it.

And you get an animation.

That means the language becomes a kind of intermediate representation for visual explanations.

The AI doesn't have to generate pixels.

It generates instructions.

The renderer handles the pixels.

That's a much more interesting problem to me.

The project is still early

The core loop works now:

Write script
    ↓
Parse script
    ↓
Build scene
    ↓
Render animation
    ↓
Play / scrub / inspect

I've also been working on things like:

camera movement
scene management
animation timing
hand-drawn rendering
text measurement
caching
error recovery
script validation

And yes...

bugs.

A lot of bugs.

But that's part of building it.

If you're the kind of person who reads:

"AI generates a whiteboard animation script and my platform just... plays it."

and immediately thinks:

"Wait, how does the timeline handle scrubbing backward in the middle of an animation without breaking everything?"

You're exactly who I'm building this for.

And I'd genuinely love to hear what you'd worry about first.

What's next?

I'm still figuring out what Strokeline ultimately becomes.

Right now, I'm focused on getting the fundamentals right:

language → parser → timeline → renderer → animation

Once that foundation is solid, there are a lot of directions this could go.

More animation primitives.

Better camera control.

Reusable components.

Timeline editing.

AI-assisted script generation.

Maybe eventually collaborative editing.

But for now?

I'm happy that I can type a few lines of text and watch the browser turn them into something that actually moves.

Especially after spending several hours debugging why the text was disappearing.

More soon.

Probably with more bugs to tell you about.

Lakron : A Minimal, Encrypted, Realtime Life Scheduler with Supabase

Saif Jlassi — Wed, 25 Jun 2025 12:59:16 +0000

Lakron: A Minimal, Encrypted, Realtime Life Scheduler with Supabase

Lakron is a minimal, smart life scheduler that keeps your data private and in sync. Every task is encrypted before it leaves your browser, and realtime sync means your schedule is always up to date everywhere.

How Encryption Works

Every task you create is encrypted in the browser using a key derived from your password and a salt. Only you can decrypt your data—nobody else, not even the database admin.

// TaskProvider.tsx
const generateKey = useMemo(() => {
  if (!currentProfile?.password) return ''
  return CryptoJS.PBKDF2(currentProfile.password, ENCRYPTION_SALT, { keySize: 256 / 32 }).toString()
}, [currentProfile?.password])

When saving or loading a task, the title and description are encrypted/decrypted with this key:

// supabase.ts
function encrypt(text, key) {
  return CryptoJS.AES.encrypt(text, key).toString()
}
function decrypt(cipher, key) {
  return CryptoJS.AES.decrypt(cipher, key).toString(CryptoJS.enc.Utf8)
}

How to Clone and Run Lakron

Clone the repo:

   git clone https://github.com/laakri/lakron.git
   cd lakron

Install dependencies:

   npm install

Create a .env file in the root with your Supabase project keys. Use your own values, never share your real keys publicly!

   VITE_ENCRYPTION_KEY=your-random-salt
   VITE_SUPABASE_URL=https://your-project.supabase.co
   VITE_SUPABASE_KEY=your-service-role-key
   VITE_SUPABASE_ANON_KEY=your-anon-key

Start the dev server:

   npm run dev

Enable Realtime on the Tasks Table

Lakron uses Supabase Realtime to sync tasks instantly across devices.

To enable this, turn on Realtime for the tasks table in your Supabase dashboard:

Go to your Supabase project
Click on "Database" → "Replication"
Find the tasks table and enable Realtime

SQL to Create the Tables (All in One Block)

If you need to create the profiles and tasks tables from scratch, here’s the full SQL:

-- Create profiles table
CREATE TABLE IF NOT EXISTS profiles (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) UNIQUE NOT NULL,
  password VARCHAR(255) NOT NULL,
  created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

-- Create tasks table
CREATE TABLE IF NOT EXISTS tasks (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  title VARCHAR(255) NOT NULL,
  time VARCHAR(10) NOT NULL,
  date DATE NOT NULL,
  completed BOOLEAN DEFAULT FALSE,
  type VARCHAR(10) CHECK (type IN ('task', 'event')) DEFAULT 'task',
  description TEXT,
  profile_id INTEGER REFERENCES profiles(id) ON DELETE CASCADE,
  created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
  priority INTEGER NOT NULL DEFAULT 2,
  recurring BOOLEAN NOT NULL DEFAULT false,
  recurrence_rule TEXT,
  "completedDates" TEXT[]
);

-- Add constraint to ensure recurrence_rule values are valid
ALTER TABLE tasks
  ADD CONSTRAINT IF NOT EXISTS check_recurrence_rule
  CHECK (
    recurrence_rule IN ('daily', 'weekly', 'monthly', 'yearly', 'custom')
    OR recurrence_rule IS NULL
  );

-- Optional: Standardize existing recurrence_rule values (safe to run even if table is empty)
UPDATE tasks SET recurrence_rule = 'daily' WHERE recurrence_rule = 'daily';
UPDATE tasks SET recurrence_rule = 'weekly' WHERE recurrence_rule = 'weekly';
UPDATE tasks SET recurrence_rule = 'monthly' WHERE recurrence_rule = 'monthly';
UPDATE tasks SET recurrence_rule = 'yearly' WHERE recurrence_rule = 'yearly';
UPDATE tasks SET recurrence_rule = 'custom'
  WHERE recurrence_rule IS NOT NULL
    AND recurrence_rule NOT IN ('daily', 'weekly', 'monthly', 'yearly');

Realtime Sync

Supabase’s realtime channels keep tasks in sync across tabs and devices. The provider subscribes to changes for the current profile, so if you add or complete a task on your phone, it updates instantly on your laptop.

// TaskProvider.tsx
const unsubscribe = dbOperations.subscribeToTasks(currentProfile.id, (payload) => {
  // handle INSERT, UPDATE, DELETE
})

Deployment

Deploying Lakron is as smooth as using it. The whole process is automated with GitHub Actions, so every push to the main branch triggers a build and deploy.

The workflow does three things:

Installs dependencies and builds the frontend
Copies the built static files to the server using SCP over SSH
Reloads the Caddy server so your changes go live instantly

Here’s the gist of the deployment workflow:

# .github/workflows/deploy.yml
- name: Install dependencies and build
  run: |
    npm ci
    npm run build

- name: Deploy dist to server
  uses: appleboy/scp-action@v0.1.7
  with:
    host: ${{ secrets.SERVER_HOST }}
    username: ${{ secrets.SERVER_USER }}
    key: ${{ secrets.SERVER_SSH_KEY }}
    source: "dist/*"
    target: "/home/youruser/lakron/dist"

- name: Reload Caddy
  uses: appleboy/ssh-action@v1.0.0
  with:
    host: ${{ secrets.SERVER_HOST }}
    username: ${{ secrets.SERVER_USER }}
    key: ${{ secrets.SERVER_SSH_KEY }}
    script: |
      sudo systemctl reload caddy

You just need to add your server’s SSH key and connection info as GitHub secrets.

Caddy serves the static files from the dist directory, so as soon as the workflow finishes, your latest version is live.

No manual uploads, no downtime, just push and your encrypted, realtime scheduler is up to date for everyone.

Clone, set your env, run the SQL, enable realtime, and you’ve got a fully encrypted, realtime, minimal life scheduler.

Building a Secure Multi-Device Authentication System: The SyncBridge Story #1🔐

Saif Jlassi — Mon, 23 Dec 2024 18:04:21 +0000

Ever wondered how apps like WhatsApp Web handle secure device pairing? Or how Netflix manages to keep track of all your devices? Today, I'm diving deep into how I built SyncBridge's authentication system, handling everything from QR code login to token refresh mechanisms. Buckle up - it's gonna be a fun ride! 🚀

The Challenge 🎯

Building SyncBridge's auth system wasn't just about letting users log in. I needed to:

Track multiple devices per user
Handle secure device pairing
Manage token refresh without compromising security
Implement email verification
Monitor suspicious activities

The Architecture 🏗️

Here's what I came up with:

The Secret Sauce 🌟

What makes this system special? Three key ingredients:

Device-Specific Tokens: Each device gets its own unique identifier and refresh token. If one device is compromised, others stay safe.
Rotating Refresh Tokens: Every time a refresh token is used, it's invalidated and a new one is issued. This means if someone steals your refresh token, they have exactly one shot at using it.
Security Event Tracking: Every login, token refresh, and device pairing is monitored. Suspicious patterns? We catch them before they become problems.

Let's Get Technical 🛠️

Token Management: The Dance of Access and Refresh 💃

Remember the last time you stayed logged into an app for weeks without entering your password? That's the magic of refresh tokens. But here's how we made it more secure in SyncBridge:

The Two-Token Tango 🎭

Why This Matters 🤔

Here's what makes our token system special:

Single-Use Refresh Tokens

// When refreshing tokens
const deviceAuth = this.deviceAuthRepository.create({
device_id: device.device_id,
refresh_token: refreshToken,
expires_at: new Date(Date.now() + 7 24 60 60 1000), // 7 days
is_valid: true,
});

Device-Bound Tokens
Each refresh token is tied to a specific device. Try using it from another device? Not happening! 🚫
Concurrent Request Handling

if (isRefreshing) {
try {
const token = await new Promise((resolve, reject) => {
failedQueue.push({ resolve, reject });
});
// Handle concurrent requests during refresh
}
}

The Security Checklist ✅

✅ Access tokens expire in 15 minutes
✅ Refresh tokens are single-use
✅ Device fingerprinting for extra security
✅ Token rotation on every refresh
✅ Concurrent request queue management

QR Code Magic: Secure Device Pairing 📱

One of the coolest features we built is the QR code login system. You know when you open WhatsApp Web and scan that QR code? We built something similar, but with our own security twist!

How It Works 🔍

When you click "Add Device", here's what happens behind the scenes:

async generateLoginQR(userId: string): Promise<{ qrId: string; qrCode:string }> {
// Generate unique QR session ID
const qrId = uuidv4();
// Store QR session with Redis (5 minutes expiration)
await this.redis.set(
qr_login:${qrId},
JSON.stringify({
status: 'pending',
ownerId: userId,
createdAt: new Date().toISOString(),
}),
'EX',300
);

Security First! 🛡️

Here's how we keep the QR login secure:

Time-Limited Sessions: Each QR code expires in 5 minutes
One-Time Use: Once scanned, the QR code becomes invalid
Device Verification: We check if the scanning device is authorized
Real-time Status Updates: Using Redis for instant status changes

The User Experience 🎯

User opens SyncBridge on their computer
Clicks "Add Device" and gets a unique QR code
Scans with their phone (already logged in)
Both devices get notified of successful pairing
New device receives its own unique tokens

// Real-time QR status monitoring
const checkQRStatus = async (qrId: string) => {
const status = await redis.get(qr_login:${qrId});
if (status.authenticated) {
// Handle successful authentication
const { deviceId, tokens } = status;
await setupNewDevice(deviceId, tokens);
}
};

Email Verification: Double-Check Everything ✉️

Every new device pairing triggers an email notification:

This gives users instant visibility into their account activity and a chance to revoke access if something looks suspicious.

Security Monitoring: The Guardian Angel 👀

What happens after users log in? We keep watching! Here's our security monitoring system in action:

Event Tracking System 📊

async logSecurityEvent(params: {
user: User,
device: Device,
event_type: SecurityEventType,
severity: SecurityEventSeverity,
}) {
// Log and monitor security events
}

What We Track 🔍

🚪 Login attempts (successful and failed)
🔄 Token refresh patterns
📱 Device pairing activities
🌍 Geographic anomalies
⚠️ Suspicious IP changes

Putting It All Together 🎯

Here's what makes SyncBridge's authentication special:

Zero Trust Architecture
- Every request is verified
- No device is inherently trusted
- Continuous validation
User-First Security
- Clear email notifications
- Device management dashboard
- One-click device revocation
Future-Proof Design
- Scalable token management
- Extensible security events
- Ready for new auth methods

Final Thoughts 💭

Building a secure authentication system is like building a house - you need a solid foundation (token management), good locks (QR code pairing), and a reliable security system (event monitoring).

The best part? This is just the beginning. Next up: implementing biometric authentication and hardware key support! 🚀

Found this helpful? Follow me for more deep dives into web security and full-stack development!
LINKED IN : https://www.linkedin.com/in/seif-eddine-jlassi/
GITHUB REPO :https://github.com/laakri/SyncBridge

Building SyncBridge: When "Copy Here, Paste There" Gets an Upgrade 🚀

Saif Jlassi — Sat, 21 Dec 2024 19:23:54 +0000

Ever had that moment when you're reading an article on your phone, but want to continue on your laptop? Or found yourself copying text between devices like a digital juggler? Yeah, me too. That's why I built SyncBridge.

The "Aha!" Moment

Picture this: I'm coding on my desktop, reading docs on my tablet, and messaging on my phone. Copy, switch device, paste. Switch again. Copy again. At that moment, I thought, "This is madness. Why isn't this seamless?"

What's SyncBridge, Anyway?

Think of it as a digital bridge between all your devices. You're reading on your phone? Swipe up, continue on your laptop. Found a cool code snippet? It's already in your tablet's clipboard. Writing notes? They sync across devices before you even finish your thought.

The Secret Sauce 🌶️

What makes SyncBridge different isn't just sync – it's the experience. No more "send to device" buttons or manual syncing. It just works. Like magic, but with better error handling. 😉

The Cool Stuff Under the Hood:

Real-time sync that's faster than your coffee break
Smart device pairing (scan & go)
Automatic conflict resolution (no more "which version is newer?")
Battery-friendly background sync
End-to-end encryption (because your data is yours)

Current Status: The Foundation

Right now, I've laid down the architecture (shown above) and mapped out the core features. Think of it as building the highway before the cars start rolling. The diagrams show the planned user flows and technical architecture – the blueprint of what's coming.

What's Next?

This is just the beginning. I'm building SyncBridge in public, and I'll be sharing every major milestone, challenge, and "why didn't I think of this before?" moment. Next up: the real-time sync engine that makes everything feel instantaneous.

Join the Journey

Want to see how a "wouldn't it be cool if..." moment turns into a full-fledged product? Follow along! I'll be posting regular updates as SyncBridge grows from these architecture diagrams into your next favorite tool.

Building a Real-Time Auction Platform: Behind the Scenes

Saif Jlassi — Tue, 10 Dec 2024 17:28:00 +0000

As a developer, I recently built a sophisticated auction platform that combines the excitement of live bidding with modern social features. Today, I want to share the journey of creating the core auction experience, particularly focusing on real-time interactions.

The Auction Experience

Our auction platform offers a dynamic, interactive environment where users can:

Watch live auctions with real-time price updates
Participate in auction-specific chat rooms
See live viewer counts
Place bids with instant feedback
Track time remaining with precision countdowns
Interact with other bidders in real-time

Key Features

1. Live Bidding System

Real-time price updates across all connected users
Anti-sniping protection
Minimum increment enforcement
Instant bid validation

2. Social Integration

Live chat during auctions
Real-time viewer count
User presence indicators
Follow/unfollow sellers

3. Owner Controls

Real-time auction management
Chat moderation capabilities
Early ending option
Private auction management

The Real-Time Architecture

The heart of our platform is the real-time communication system. Here's how we implemented it:

WebSocket Implementation

We built a robust WebSocket architecture that handles:

1. Bidding Events

Instant price updates
Bid confirmations
Outbid notifications
Current price synchronization

2. Room Management

Auction room joining/leaving
Viewer count tracking
User presence management
Chat room coordination

3. State Synchronization

Auction status updates
Timer synchronization
Owner control changes
Chat state management

Challenges & Solutions

1. Race Conditions

Implemented server-side bid validation
Used atomic operations for price updates
Maintained bid order consistency

2. State Management

Centralized state management for consistency
Real-time data synchronization
Optimistic UI updates with rollback

3. Performance

Efficient WebSocket message handling
Minimal payload sizes
Smart reconnection handling

User Experience Considerations

1. Responsive Updates

Instant UI feedback for actions
Smooth animations for price changes
Real-time countdown synchronization

2. Error Handling

Graceful connection loss handling
Automatic reconnection
State recovery after disconnection

3. Security

Bid verification
User authentication
Rate limiting
Private auction access control

Technical Insights

The most challenging aspect was maintaining data consistency across all connected clients while ensuring a smooth user experience. We achieved this through:

1. Event-Driven Architecture

Centralized event handling
Predictable state updates
Clean separation of concerns

2. Real-Time Data Flow

Bidirectional communication
Event queuing
State reconciliation

3. Scalability Considerations

Horizontal scaling capability
Connection pooling
Load balancing ready

Lessons Learned

Always handle disconnections gracefully
Implement proper error boundaries
Use optimistic UI updates carefully
Maintain a consistent state across all clients
Consider latency in user experience design

This project showcases how modern web technologies can create engaging, real-time experiences. The combination of WebSocket communication, state management, and user experience design creates a platform that's both powerful and user-friendly.

#webdev #javascript #typescript #websockets #react

Building Glide: A Modern E-commerce Platform with Angular 17 and .NET 8

Saif Jlassi — Tue, 10 Dec 2024 16:40:29 +0000

Hey fellow developers! Today I'm excited to share my journey building Glide, a modern e-commerce platform that combines cutting-edge technologies with practical solutions. Whether you're a student looking to learn or a developer seeking insights, this post will walk you through the key aspects of building a full-stack e-commerce application.

The Vision Behind Glide

Every great project starts with a clear vision. For Glide, it was creating an e-commerce platform that not only processes transactions but delivers an exceptional user experience. The goal was to build something that both developers would appreciate for its clean architecture and users would love for its intuitive interface.

Tech Stack: Why These Choices Matter

The foundation of Glide rests on two powerful frameworks:

🔹 Frontend: Angular 17

Standalone components for better modularity
New control flow syntax for cleaner templates
Built-in SSR capabilities for better SEO
DaisyUI + Tailwind CSS for responsive design

🔹 Backend: .NET 8

Robust API architecture
JWT + Google OAuth integration
Entity Framework Core with MySQL
Real-time capabilities with SignalR

Key Features That Make Glide Stand Out

1. Authentication & Security

The authentication system combines traditional JWT tokens with Google OAuth, providing users with flexible login options while maintaining robust security. The implementation includes:

Secure token management
Role-based access control
Protected API endpoints
CORS policy implementation

2. Real-Time Features

Using SignalR, we've implemented:

Live notifications
Order status updates
Real-time cart synchronization
Instant messaging between users and support

3. Admin Dashboard

A comprehensive admin interface featuring:

Sales analytics with Chart.js
Inventory management
Order processing
User management

Development Insights & Best Practices

Frontend Architecture

Components are organized by feature
Services handle state management
Interceptors manage HTTP requests
Guards protect restricted routes

Backend Structure

Clean architecture principles
Repository pattern for data access
Middleware for request/response handling
Structured error handling

Challenges & Solutions

Performance Optimization
- Implemented lazy loading for routes
- Used Angular's built-in optimization tools
- Configured proper caching strategies
State Management
- Created service-based state management
- Implemented reactive patterns
- Used BehaviorSubjects for real-time updates

typescript

> // Authentication configuration
> builder.Services.AddAuthentication(options => {
>     options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
>     options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
> })
> .AddJwtBearer()
> .AddGoogle(options => {
>     options.Scope.Add("email");
>     options.Scope.Add("profile");
> });

Learning Outcomes

Building Glide taught valuable lessons about:

Modern web architecture
Security best practices
Performance optimization
User experience design
Real-time feature implementation

Tips for Students

Start Small
- Begin with core features
- Add complexity gradually
- Test thoroughly as you go
Focus on Fundamentals
- Master TypeScript/C# basics
- Understand HTTP protocols
- Learn authentication concepts
Best Practices
- Write clean, documented code
- Follow naming conventions
- Use version control effectively

Future Roadmap

Glide continues to evolve with planned features:

AI-powered product recommendations
Enhanced analytics dashboard
Mobile app development
Performance optimizations

Get Involved

The project is open source and welcomes contributions! Whether you're fixing bugs, adding features, or improving documentation, your input is valuable.

Resources for Learning

To build something similar, check out:

Angular Documentation
.NET 8 Documentation
JWT Authentication guides
SignalR tutorials
DaisyUI components

Connect & Contribute

I believe in learning together and sharing knowledge. If you're interested in:

Contributing to the project
Learning more about the implementation
Discussing web development
Sharing your own experiences

Feel free to reach out! You can find me on:

GitHub: [Your GitHub]
LinkedIn: [Your LinkedIn]
Twitter: [Your Twitter]

Remember, every developer started somewhere. Keep learning, keep building, and most importantly, enjoy the process!

WebDevelopment #Angular #DotNet #Programming #OpenSource #TechEducation