DEV Community: Saif Jlassi

How We Made PNG Export More Responsive in Strokeline

Saif Jlassi — Fri, 09 Oct 2026 11:57:51 +0000

Exporting a scene as a PNG sounds simple: draw it to a canvas and download the
result. But a large scene can turn that single click into a long stretch of
main-thread work—and make the rest of the page feel frozen.

We recently made Strokeline's PNG snapshot export more responsive. Here's what
the export actually does, why we changed it, and what the change does (and
doesn't) guarantee.

First, what does a PNG snapshot contain?

Strokeline's PNG export captures one scene at the current playhead time. It
is not a video render: it resolves the timeline at that instant, draws the
resulting scene to a canvas, then downloads a PNG.

The lifecycle is roughly:

Compile and validate the current script.
Select the active scene and clamp the playhead time to that scene's duration.
Preload images and the handwritten font.
Resolve the timeline into the state for that time.
Draw the scene to a canvas.
Encode the canvas as a PNG Blob and download it.

The problem: one uninterrupted render

Previously, the snapshot path drew all visible scene nodes in one synchronous
pass. While that pass was running, the browser had fewer opportunities to
respond to input or paint UI updates. Dense scenes could therefore make the
export feel like it had stalled the page.

The first improvement is to render in batches of four nodes. Between batches
the renderer yields using requestAnimationFrame (or a timer fallback), so the
browser gets a chance to update the page. It also reports progress and checks
whether the user cancelled before continuing.

In simplified form, the asynchronous drawing loop is:

const batchSize = Math.max(1, Math.floor(options.batchSize ?? 12))
const totalNodes = Math.max(1, args[1].nodes.length)
const steps = drawSceneSteps(args, batchSize)

while (true) {
  if (options.signal?.aborted) {
    throw new DOMException("The export was cancelled.", "AbortError")
  }

  const step = steps.next()
  if (step.done) break

  options.onProgress?.(Math.min(0.98, step.value / totalNodes))
  await new Promise<void>((resolve) => {
    if (typeof requestAnimationFrame === "function") {
      requestAnimationFrame(() => resolve())
    } else {
      setTimeout(resolve, 0)
    }
  })
}

The PNG exporter sets the batch size to four. This is cooperative scheduling,
not parallel rendering: the work still happens on the browser's main thread.
Yielding between batches gives the browser opportunities to respond, but one
especially expensive node can still take noticeable time to draw.

Put a limit on output pixels

Canvas memory use grows with the number of output pixels. Strokeline now exports
at 1× scale by default, caps the PNG at 4 million pixels, and also limits
either output dimension to 8192 pixels. It preserves the canvas aspect ratio
when it needs to scale down a large output.

For example:

Canvas size	Pixel count	PNG output
1920 × 1080	2.07 MP	1920 × 1080
8000 × 5000	40 MP	2529 × 1581 (about 4 MP)

The cap is a practical limit, not a universal browser guarantee. Devices and
browsers have different memory and canvas constraints, and a scene with costly
shapes can still take time to draw.

Download a Blob instead of a base64 data URL

After drawing, the exporter uses canvas.toBlob() and downloads the resulting
PNG Blob. This avoids creating a large base64-encoded string as an intermediate
representation. The final image still has to be encoded and stored, but it
avoids that extra string allocation.

const blob = await new Promise<Blob | null>((resolve) =>
  canvas.toBlob(resolve, "image/png")
)
if (!blob) throw new Error("The browser could not encode the PNG snapshot.")
download(blob, `strokeline-${timestamp()}.png`)

Progress and cancellation

The export menu reflects the drawing progress. Its cancellation signal is
checked between batches, so a cancel request takes effect at a batch boundary.
It can't interrupt an individual shape while that shape's renderer is running.

That boundary is intentional: it keeps the drawing loop straightforward while
giving long exports a way to stop without waiting for every remaining node.

What changed

PNG snapshots render four nodes per batch and yield between batches.
Progress is updated during rendering, and cancellation is checked at batch boundaries.
Output is 1×, with a 4 MP pixel cap and an 8192 px maximum dimension.
PNG data is encoded with toBlob() rather than an intermediate base64 URL.

The implementation is in the
Strokeline repository, primarily in
web/src/export/exporters.ts, web/src/export/pngSizing.ts, and
web/src/renderer/draw.ts.

If a large export still makes your browser unresponsive, the scene, device, and
browser all matter. The batching and pixel cap reduce common sources of load;
they don't make canvas rendering free.

From Correct to Polished: What Changed in Strokeline

Saif Jlassi — Wed, 30 Sep 2026 13:34:08 +0000

In my last post, I described Strokeline as working, but not pro yet.

At that point, I had a clear list of things I wanted to improve: better motion, better rendering, better text placement, more reliable export, and eventually a better authoring experience.

That post was mostly a plan.

This one is about what actually happened.

A lot of the work ended up being less about adding visual effects and more about fixing the fundamentals underneath them: geometry, timing, rendering consistency, and giving both humans and AI a reliable way to write valid Strokeline scripts.

The biggest lesson so far is pretty simple:

Polish is mostly engineering.

The renderer became diagram-aware

One of the biggest changes was making the renderer understand more about what it is actually drawing.

Tables are a good example.

Previously, getting a table on screen was not enough. The text needed to sit comfortably inside the cells, columns needed to give longer content room before wrapping, and the table needed to look like one coherent object.

Tables now have better padding, automatic column widening before wrapping, rounded corners, header styling, soft shadows, and optional divider sections between attributes and operations.

That same idea applies to shapes.

Shapes now support rounded corners and better centered, auto-fitting labels. I also added a DIAMOND shape for flowcharts.

But arrows were probably the more interesting problem.

An arrow shouldn't simply draw a line from coordinate A to coordinate B. It needs to understand the shapes it connects.

The renderer now clips arrows to the actual shape boundary, spreads anchors when multiple arrows connect to the same side, and uses straighter lines with rounded elbows.

That makes a surprisingly large difference.

Then came UML-specific details: hollow triangles, hollow and filled diamonds, open arrowheads, multiplicities, and labels on both ends of relationships.

For example, a relationship can now carry information like:

SOURCELABEL "1"
TARGETLABEL "*"

Those labels also get automatic background plates so they remain readable over the diagram.

Self-message loops are supported too, which matters for sequence diagrams where an object can send a message back to itself.

The important part is that these aren't isolated visual additions.

Arrow geometry depends on knowing the shape boundary. Label placement depends on knowing the arrow geometry. Readability depends on knowing where the label lands. Multiple arrows depend on knowing which side of the shape they share.

Fixing one piece exposed problems in the next.

That's what I mean by the renderer becoming diagram-aware. It isn't just drawing primitives anymore. More of the rendering logic understands the relationships between those primitives.

Preview and export have to agree

Another lesson was that a preview that looks good is not enough.

If the preview and exported video use different rendering paths, eventually they disagree.

Strokeline now renders with a crisp high-resolution 2x canvas, and exports use the same renderer and visual rules as the preview.

Video export is also deterministic rather than depending only on real-time screen capture.

That matters because an animation editor should not effectively say:

"It looked right while you were watching it, hopefully the recording looks the same."

GIF export gave me a particularly good example of this.

I had a bug where exported GIF frames could come out black or empty. The underlying problem wasn't the animation itself. The frames were being handled at the wrong stage of the rendering/downsampling process.

The fix was to render each frame at the logical canvas size first and then downsample it.

That sounds like a small implementation detail.

It wasn't small from the user's perspective.

A perfect-looking preview followed by an empty GIF is simply a broken export.

Sequence-diagram frames and use-case boundaries also received cleanup, while camera motion and easing became smoother and more stable. Tables and arrows now have smoother reveal animations as well.

I'm still treating preview/export consistency as an area that needs testing. In particular, I haven't verified the stronger claim from the previous post that old scripts remain pixel-identical, so that's still an open item rather than something I'm going to pretend is solved.

Narration changed the architecture of timing

In the previous post, I deliberately said I was skipping voice-over and subtitles for the time being.

That didn't last.

Once narration became part of the product, it became obvious that captions, speech, and animation timing can't really be treated as separate systems.

Consider a SAY line.

It has a duration declared by the script, but the text itself also has a natural reading time. If I only use the declared duration, a long sentence can finish visually before there is enough time to read or hear it.

Strokeline now schedules a SAY using whichever is longer: its declared duration or a text-based estimate.

That timing then needs to drive the caption.

And the caption needs to represent the entire spoken text. Long captions now advance through the full text instead of getting stuck showing only the first couple of wrapped lines.

Then there is generated audio.

The audio needs to line up with that same timeline. If the caption says one thing while the generated narration is at another point, the system feels broken even if both pieces work individually.

So generated audio is now synchronized with the actual caption timeline.

Seeking and playback timing were also improved, making audio less likely to skip or end abruptly. Pausing the preview now pauses the narration state as well.

This is still ongoing work. I'm not claiming that every browser audio edge case is solved.

But the architectural lesson is clear:

If two things describe the same moment in the animation, they need to share the same timing model.

AI needs a source of truth

Another part of Strokeline that changed wasn't the renderer at all.

It was how scripts get written.

Because Strokeline is text-based, it's natural to ask an AI to generate a .wbs file.

That also creates a very predictable problem: an AI can confidently invent syntax.

It might produce YAML. Or JSON. Or Mermaid. Or PlantUML. Or some imaginary hybrid that looks reasonable but has nothing to do with the actual Strokeline parser.

That's not useful.

So I built a public Strokeline skill repository:

Strokeline-Skills

The skill contains the actual core instructions, syntax references, diagnostics, layout guidance, quality checks, bad/good examples, patterns, and complete example scripts.

The important part is that the examples are validated against the real parser/compiler/validator.

The workspace's Copy AI Prompt now tells assistants to use this skill before generating or editing Strokeline scripts.

That gives an AI something much better than a vague description of the product: an actual source of truth.

The skill also documents details that are easy for an AI to get subtly wrong.

For example, CANVAS takes width and then height. POSITION represents the center point of an object. Vertical layouts need to respect safe areas.

These details sound obvious once you know them.

They're exactly the kind of details an AI will happily get wrong if nobody gives it authoritative instructions.

The goal isn't to make AI magically understand Strokeline.

The goal is to give it enough real information that the output has a chance of being executable on the first pass.

A small UI cleanup

I also cleaned up the surrounding workspace.

The landing page now has a darker shadcn-style design with stronger hierarchy, refined cards, spacing, and motion.

Inside the workspace, menus such as Scenes now appear above the preview instead of getting clipped behind it.

It's not the main story, but the editor shouldn't get in the way of the thing you're actually building.

What's still unfinished

Strokeline is in a much better place than when I wrote the previous post, but there are still plenty of open problems.

I haven't finished proving compatibility with existing scripts at the pixel level. Audio behavior still needs continued work across different browser conditions. And the renderer still has plenty of room for refinement as more complicated diagrams expose new geometry and timing cases.

I'm also deliberately not calling every item from the original roadmap finished just because related work happened. Some of those ideas still need proper implementation and validation.

Right now, my focus is on making the existing pipeline more reliable and predictable rather than piling on effects.

The pattern I've started to see is that every layer affects the next one.

Better geometry improves animation.

Better timing improves narration.

A shared renderer improves export.

A real syntax reference improves AI-generated scripts.

And when those foundations are right, visual polish becomes much easier to build on top of them.

That's a much more useful definition of "polished" than adding more effects.

What would you want a scriptable diagram animation tool to get right before anything else: rendering, animation, narration, export, or AI authoring?

Strokeline studio: https://strokeline.glassisaif.workers.dev/

Strokeline AI skill repo: https://github.com/laakri/Strokeline-Skills

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