DEV Community: Vitor Norton

I tried to fork GSD, or: it's for vibe coders, not real devs

Vitor Norton — Mon, 15 Jun 2026 15:48:58 +0000

As a senior engineer I deep dive into spec-driven AI development: the architecture, the maintenance math, a 250-fork graveyard, a rejected GitHub issue, and how I chose between GSD, GitHub Spec Kit, and OpenSpec.

TL;DR

I genuinely like GSD. Its research, planning, and roadmap/phase model are some of the best I've used. It still doesn't fit how I work.

My problem was never a missing setting. It was the category of tool: GSD is an autonomous orchestrator. I'm a senior engineer who wants a human-in-the-loop assistant.

I considered forking it into a "lite" version. The maintenance math says a divergent fork is the worst available option, and a scan of all 250 forks confirms it: not one is a successful start point to me.

I'm switching to GitHub Spec Kit, with OpenSpec as a close runner-up. This is the entire reasoning, including the parts that argue against me.

Loving a tool that doesn't fit you

There's a specific kind of frustration that doesn't get written about much: when a tool is good, you can see the craft in it, and it still fights you on every project.

That's GSD for me. GSD ("Git. Ship. Done.") is a spec-driven, context-engineering framework for AI coding agents. It drives an agent through a disciplined loop (discuss → plan → execute → verify → ship) running the heavy research and planning work in fresh-context subagents so your main session never rots. The phase/roadmap model is excellent. The research step is excellent. I like the ceremony. For me it's a comprehension gate, the thing that forces the agent (and me) to actually understand the work before touching code.

And yet, every time I ran it on a real project, it worked against the way I work. I'm a senior engineer. My job is to be helped, not replaced. GSD is built to take the wheel.

I almost did the obvious engineer thing: fork it, file off the parts I don't like, ship my own "GSD lite". This post is what I found when I actually did the homework first, and why I'm doing something else entirely.

What GSD actually is, under the hood

Before you can reason about forking or replacing a tool, you have to know how it's wired. So I read the repo.

GSD is three layers stacked on top of each other:

Layer	What it is	Do I care about it?	Cost to maintain in a fork
Markdown "brain"	`commands/` → `workflows/` → `agents/` → `references/` → `templates/`: the prompts that drive the whole loop	Yes, this is what I love	High, these are the most-churned files upstream
CJS tooling + installer	`gsd-tools.cjs` • ~104 library modules, plus a ~10,700-line multi-runtime installer and a set of hooks	Almost none	Medium/high, and it's work that gives me nothing
Config	`.planning/config.json`	This is where the cheap wins live	~Zero

Two facts fall out of this that matter for any customization decision:

The workflows aren't standalone prompts. They call gsd-tools constantly, to load context, update state, and commit. So "just lift the good prompts into my own tool" isn't a copy-paste. The prompts assume a 104-module CLI sitting next to them. Lifting the brain means lifting the whole nervous system.

Most of GSD's complexity is infrastructure I'd never touch. The installer alone supports 16+ runtimes (Claude Code, Codex, Gemini CLI, Cursor, Windsurf, Copilot, and more). There are 33 agents, ~67 skills, 11 hooks, a capability registry, and a supply-chain gate against hallucinated packages. It's impressive engineering. It's also 90% surface area I don't need but would inherit the moment I forked.

There's a name for what GSD is, and it's the crux of this entire post: GSD is an autonomous orchestrator. It spawns subagents, commits per task, and advances on its own. The human approves at checkpoints. That's by design, and its made for a different operator than me.

The one hard "no": atomic per-task commits

If I strip my complaints down to the irreducible core, it's this: GSD commits automatically, one commit per task, as it executes. Here's the literal guidance from its git-integration.md:

| Task completed | YES | Atomic unit of work (1 commit per task) |

# How GSD stages and commits during execution
git add src/api/auth.ts src/types/user.ts
git commit -m "feat(08-02): create user registration endpoint"

The workflow I actually want is human-in-the-loop:

the agent does the work, locally, uncommitted
it stops. I validate on my machine
I give the order: now test it, run the checks, do the code review, open the PR
the commit happens under my command, late, not per task, not automatically

This is not a niche preference. The 2026 consensus on agentic workflows says the same thing in plain terms: "code review is the step most agentic workflows quietly drop," and the healthy pattern is "a human reviews the plan before execution begins, not after." GSD's auto-commit removes exactly the control points a senior engineer needs.

Plus, I cannot touch the code. If I change one line, if I do anything, it will just mess the entire commit history and it would spend a few minutes (and lots of tokens) to understand that: “yeah, I can do my one code, thank you”.

So I opened an issue…

I filed issue #745: add a config option to defer all commits during execution, leave the working tree dirty, and let me review the whole phase as one diff before anything lands.

The maintainer's response was fast and unambiguous:

"this is how its designed, not interested in changing the design at this time. the commits are there to protect against loss of context or other. this would be a redesign of how it works, not an enhancement."

I want to be fair here, because this is the part that actually clarified everything: the maintainer is right, from inside GSD's design. If your tool is an autonomous agent that may lose its context window mid-run, then committing every task is a feature, a crash-recovery and context-recovery mechanism. My request wasn't a tweak to that design. It was a request for a different philosophy. We don't disagree about quality. We disagree about who holds the wheel.

But the practical consequence is sharp: I can't upstream my way out of this. The thing I most want to change is precisely what the maintainer defends as the core of the design, and will keep elaborating with every release, rightfully so. Any customization I keep would be fighting an actively-maintained opposite opinion.

The subtler tax: it looks like collaboration, right up until it isn't

Auto-commit is the complaint I can point at. The one that actually cost me is harder to name, because it wears the disguise of good work.

Here's the shape of it. I had a tiny, one-off task on a small personal repo: pull a handful of scattered notes into a single file. Twenty minutes by hand. I ran it through the proper loop anyway: discuss → plan → execute. Roughly two hours later it handed me a polished, completely wrong deliverable: a reusable, unit-tested tool for what was a one-time edit. Something I never asked for, never wanted, and now had to unwind.

The maddening part is where it went wrong. The discuss step is the part I like most, the comprehension gate, the thing that's supposed to catch exactly this. And it didn't. Not because discussion is bad, but because it has a grain: it latches onto one reading of what you said and drives hard in that direction, confidently, past the point where it still makes sense. It keeps asking sharp questions (which feels like rigor) while quietly walking off the edge of the scope you actually gave it. By the time the drift is visible it's already downstream in a plan, then in code, and you're the one paying to reel it back.

And the whole time it looks productive. It's debating. It's planning. It's spinning up research. Every signal says "this is going well," so you trust it, and the bill only arrives at the end, as hours spent generating something that misses the nuance you could never get it to hold. That's the real failure mode of a highly-opinionated orchestrator: the opinions are load-bearing, and when your intent doesn't match them the tool can't bend. It can only drift, eloquently.

And this isn't one unlucky run. On a recent 70-phase project I had to redo or restructure at least 50 of them. The ones that survived only did because I'd front-loaded a lot of time organizing the code and kept each phase small and tightly scoped, and even then, every ~5 phases I had to stop and fix things in the code by hand so the next 5 wouldn't wander off. The review-and-re-prompt loop isn't the exception. It's the steady state. A huge share of my time on these projects goes to catching the tool before it commits to the wrong idea.

The maintenance math I did next

If you can't upstream it, your options are fork, patch, config, or build from scratch. I worked through all four.

Config can turn things off. It can't reshape the flow. GSD's config.json is genuinely deep. You can lean it out a lot:

{
  "mode": "interactive",
  "granularity": "coarse",
  "workflow": {
    "research": false,
    "plan_check": false,
    "verifier": false,
    "discuss_mode": "assumptions"
  },
  "planning": { "commit_docs": false },
  "parallelization": false
}

But no key reshapes the flow. You can't tell config "merge discuss into plan," "change how discussion works," or "commit my way." Reshaping behavior means editing the workflow Markdown, the hottest files in the repo. Which lands you in the maintenance trap.

The fork-vs-patch comparison is less flattering to patches than people think:

	Fork (tracking upstream)	Patch repo
Conflict frequency	Same, breaks when upstream edits your lines	Same
Conflict resolution	`git merge` is 3-way (knows the ancestor) → resolves better	`git apply` is 2-way → rejects more on moved code
Real advantage	"I own the tree"	Legibility: your delta is a small, separate artifact
As a public product	Installs cleanly	Bad UX: two-step install, version-coupled rejects hit your users

The only overlay pattern that survives upstream churn cleanly is additive files marked merge=ours: you only ever add files, never edit existing ones, so a periodic sync never conflicts. That's powerful, but it has a hard limit: it works for things you can add (your config, a launcher, your own skills, a host-side wrapper) and never for behavior edits. My change is a behavior edit. So it's stuck in the expensive lane no matter what.

The conclusion that reframed my whole decision: for a public tool that re-opinionates the flow, a fork is the worst quadrant. It makes you maintain 90% infrastructure you don't want and fight merge conflicts on exactly the files you customized.

The fork graveyard

I didn't want to argue this from theory, so I looked at the evidence: every fork of the repo.

250 forks. Not one is a successful divergent "lite." The breakdown:

The vast majority are stale snapshots carrying an old name the upstream itself used: untouched personal copies, not projects.
A few are README rebrands or translations, one commit of real work.
One is a runtime adapter with zero commits on its main branch despite an ambitious description.
The only serious one is an integration wrapper, and it's the most instructive object in the whole study.

That serious fork belongs to a company embedding GSD into a product. Their entire diff against upstream is this:

added     .gitattributes              (merge=ours rules)
added     scripts/sync-upstream.sh
added     NOTICE / CONTRIBUTING-UPSTREAM.md
modified  README.md                   (their banner only)

Their README states the strategy outright: "GSD itself runs unmodified." They wrap it host-side via the Claude Agent SDK and intercept the approval checkpoints in their own orchestrator. And their .gitattributes is the merge=ours trick in the wild:

# Keep "ours" on merge with upstream so periodic
# sync-upstream.sh runs don't conflict on files we maintain.
NOTICE                    merge=ours
scripts/sync-upstream.sh  merge=ours
.gitattributes            merge=ours

The reframe that changed everything

Here's the thing I wish I'd understood on day one. When you line GSD up against the rest of the field, a split appears that has nothing to do with features:

Autonomous orchestrators (GSD, BMAD): they take the wheel. Spawn subagents, commit on their own, advance on their own. The human approves occasionally.
Spec/planning layers (GitHub Spec Kit, OpenSpec, Agent OS, Taskmaster): they hand you structure and hold the door. They generate spec/plan/tasks, and execution runs through your normal agent, where you're already in the loop and commits are yours by default.

The landscape

Spec-driven development exploded in 2026. A community map tracks 30+ frameworks. Mapped against what I, as a senior engineer, actually care about:

Tool	Category	Commit / HIL	Keeps ideas open?	Research/planning depth	Cost to me
GSD	Autonomous orchestrator	Auto-commit + auto-advance	Locks requirements early	High (4 parallel researchers + plan-check + verifier)	Fork = high
OpenSpec	Spec layer	You drive; no auto-commit	Yes, per-change proposals	Lean	Adopt = low
Spec Kit	Spec layer	Human review each phase	Yes, per-feature	Medium (`/clarify` • `/plan`)	Adopt = low
Agent OS	Standards layer	"Complements, doesn't replace"	Encodes your standards	Low	Adopt = low
BMAD	Multi-agent orchestrator	Approves docs, but heavy	PRD + arch + epics locked	High	Adopt = medium; ceremony enormous
Taskmaster	Task layer	You drive	Incremental	Low	Adopt = low

The two that fit a senior engineer who likes ceremony but wants the wheel are GitHub Spec Kit and OpenSpec. So I went deep on both.

Spec Kit vs OpenSpec, for real

The difference between them is conceptual, not a matter of commands. In one line each:

Spec Kit = "specify the feature, then build it." The unit is the feature. You start from a constitution (project principles). Each feature flows spec → plan → tasks → implement, on its own git branch.
OpenSpec = "propose a change as a delta to a living spec." The unit is the change. There's a specs/ folder (current truth) and a changes/ folder (proposals). Each proposal folds into specs/ only when you apply and archive it.

That's feature-centric vs change-centric, and nearly everything else derives from it.

Axis	GitHub Spec Kit	OpenSpec
Mental model	Spec the feature → build	Delta change over a living spec
Structure	`constitution.md` • `specs/<feature>/{spec,plan,tasks}.md`	`specs/` (truth) + `changes/<name>/{proposal,specs,design,tasks}.md`
Git	Creates a branch per feature (`001-...`)	You manage git; the "change" is the review unit
Ceremony	Higher (constitution, `/clarify`, checklists)	Deliberately lean ("no personas, fluid")
Greenfield vs brownfield	Both, greenfield-leaning	Brownfield-first
Encode "my way"	Constitution every spec inherits	Conventions in agent files (lighter)
Commit behavior	Yours (scaffolds a branch, no per-task auto-commit)	Yours
Ecosystem	GitHub-backed, 105 extensions, 22 presets, 200+ contributors	Fission-AI, ~54k★, healthy but smaller

The same task through both, to feel it, "add dark mode to an existing app":

# Spec Kit
/speckit.specify   → branch 002-dark-mode + spec.md  (you review)
/speckit.plan      → plan.md + research.md            (you review)
/speckit.tasks     → tasks.md
/speckit.implement → builds; you commit

# OpenSpec
/opsx:propose dark mode → changes/add-dark-mode/ (proposal + tasks)  (you review)
/opsx:apply             → implements; you validate locally
/opsx:archive           → the delta folds into specs/

In both, the commit and the PR are mine.

About benchmarks (and why they lie a little)

You'll see a benchmark passed around: one CRM dashboard built three ways: OpenSpec ~12 min, Spec Kit ~90 min, BMAD ~5.5 h. Useful for order-of-magnitude, but it's one task and one reviewer. So I ran my own measurement against something real.

The method is simple and reproducible: read the git commit timestamps. On a real production project,, I took three consecutive GSD phases, each wiring one external integration, and measured wall-clock from the first to the last commit of each phase.

Phase	Span (first → last commit)	Duration	Plans
A	small, single adapter	~31 min	1
B	larger, 4 plans / 3 waves	~44 min	4
C	medium (+ a mid-phase re-scope)	~50 min	~3

Average ~40 minutes per phase. But the revealing part is the breakdown. In the most complete phase, code generation itself was the small part. The bulk was discuss + plan + research + verify. In another, the pure execution was about 3 minutes for three plans. The rest was context-gathering and a scope decision I made.

The takeaway: GSD's wall-clock isn't the machine grinding. It's the ceremony, the part I actually value.

That reframes "is it slow?" entirely. On a rough scale it lands between OpenSpec and BMAD, but who cares, because the time goes where I want it to. The real lesson for choosing a replacement: a tool with similar ceremony (Spec Kit) will feel about the same. A leaner tool (OpenSpec) is faster mostly because it cuts the comprehension gate I like. Speed was never my axis.

The verdict

For my posture (a senior engineer, existing projects, a backlog in triage, someone who likes ceremony as a comprehension gate, whose only hard "no" is atomic per-task commits), I'm going with GitHub Spec Kit. Mapping it to what I actually weighed:

My criterion	Winner	Why
Ceremony as a comprehension gate	Spec Kit	Heavier on purpose, OpenSpec strips it by philosophy
Research + planning depth	Spec Kit	`/clarify` • `/plan` → `research.md`, `data-model.md`, `contracts/`
Branch-per-feature	Spec Kit	Native; OpenSpec leaves git to you
Roadmap / phases	Spec Kit	Not built in, but the extension ecosystem can add whole phases
No atomic commits (my one "no")	Tie	Neither auto-commits per task
Encode my own standards	Spec Kit	`constitution.md` is the native lever
One standard, longevity	Spec Kit	GitHub-backed, MIT, biggest ecosystem
Brownfield + in-tool triage	OpenSpec	But I already triage in Notion, so it's partly redundant for me

OpenSpec is the runner-up, and an excellent tool: leaner, brownfield-first, with a genuinely elegant change-as-delta model. The only thing that should flip my decision is a hands-on test where Spec Kit's ceremony feels like friction instead of comprehension on my existing repos. That's the test I'll run next.

Sources & further reading

GSD: open-gsd/gsd-core · original gsd-build/get-shit-done · issue #745
GitHub Spec Kit · Spec Kit docs
OpenSpec (Fission-AI)
BMAD-METHOD · Agent OS · claude-task-master
Spec-Driven Development: a map of 30+ frameworks (2026)
BMAD vs Spec Kit vs OpenSpec (Reenbit)
9 Best Spec-Driven Tools 2026 (MarkTechPost)

Realtime meets AI: How we used gaming to showcase our new library, now open source!

Vitor Norton — Mon, 11 Nov 2024 14:09:31 +0000

We're excited to announce that we're open sourcing the code we used to create an interactive experience that synchronized data for over 3,000 users at major tech events, demonstrating the power and scalability of our newly released Realtime library.

Multiplayer Infinite Craft

One key part of this was making the Super, which was based on Infinite Craft, multiplayer. The game consists of combining different elements to create new ones, fostering creativity.

Users would start with the essential elements: "Fire", "Water", "Earth", "Wind", "Coffee", "JavaScript", and "Developer". After combining "Fire" and "JavaScript", an AI would analyze the combination and create "Firebase".

Because these events would gather a huge number of people (sometimes 3.5k people), we couldn't synchronize every new element among everyone. This was mainly because the gameplay would not be fun; instead, it would be confusing and stressful. By the end of these events, that would add up to 16k elements. Can you imagine how to display 16k non-structured elements on a mobile screen?

We took a different approach by making it a bit of a race. Everyone would play with a single instance, but in case they found a first discovery (meaning no one before had tried this combination), new points were added to the user, and everyone at the event would get a push notification. With more points, there was a greater chance to win a big prize at the end of the day.

Adding Real-time

We had build with a Next.js project, using our @superviz/realtime package, which offers a WebSocket infrastructure, that is based on a Publisher/Subscriber (PubSub) design pattern. This allowed for efficient event-driven communication between different instances of the application.

For this, we had created two different channels, the default and the game. The default channel was the communication of the whole experience, it would tell if an activation has awarded points to the user, and would sync across other parts of the system (mostly syncing user dada). We had a dedicated channel for the game, that would notify every one that was listening to the new.element event.

When someone combined two elements, it would send a request to our API. The API would analyze if the user was valid and if the element combination already existed in our database. If neither of these conditions were met, it would send a prompt to OpenAI to create the element. Before returning the result, we would update the database and publish several events.

await Promise.all([
  defaultChannel.publish("activation.game.update", {
    userId: user.id,
    points: quantity,
  }),

  gameChannel.publish("new.element", {
    element,
    user,
    points: quantity,
  }),
]);

On the frontend of the game, we would listen to the new.event and add a push notification using toast. Like so:

const handleGameUpdate = (message) => {
  const userFromMessage = message.data.user;
  const element = message.data.element;

  if (userFromMessage.email ===
    JSON.parse(localStorage.getItem(USERDATA_KEY) as string))
    return;

  toast(`${userFromMessage?.name} just discovered ${element.name.toUpperCase()} and has more chance of winnin!`);
};

useEffect(() => {
  gameChannel.subscribe("new.element", handleGameUpdate);
}, []);

But the application magic happened on the dashboard and with the other event being dispatched.

A playful dashboard

On our stand, we had a giant TV to display the dashboard. It was designed to be both informative and mesmerizing , displaying real-time updates of player activities and discoveries. It was a visual representation of every single participant activity. Not only kept participants informed of their scores but also fueled friendly competition and excitement throughout the event.

The dashboard was inspired by the popular multiplayer game Agar.io. Much like how players in Agar.io grow by consuming smaller cells, our dashboard represented each participant as a dynamic entity that expanded as they gained points.

The design concept revolved around creating a visually engaging and intuitive representation of real-time data. Each participant was depicted as a circular entity, with concentric rings expanding outward to indicate their score and level of engagement. This organic, cell-like visualization not only made the data easy to interpret at a glance but also added an element of gamification to the event experience. We also would add transparency to those users that was offline to showcase our recent released presence feature.

Behind the scene

To make this happen, this page would listen to every single event, and that was plenty! This is the list of the listening events the page was subscribed:

defaultChannel.subscribe("activation.start", handleActivationStart);
defaultChannel.subscribe("activation.complete", handleActivationComplete);
defaultChannel.subscribe("activation.game.update", handleGameUpdate);
gameChannel.subscribe("new.element", handleGameUpdate);

defaultChannel.presence.subscribe("presence.leave", (message) =>
  handleParticipantStatusChange(message.id, false)
);
defaultChannel.presence.subscribe("presence.joined-room", (message) =>
  handleParticipantStatusChange(message.id, true)
);
defaultChannel.presence.subscribe("presence.update", (message) =>
  handleParticipantUpdate(message)
);

Let's break down those events our dashboard listens to and explore how each contributes to creating a dynamic, real-time experience:

Activation events: The dashboard listens for activation.start and activation.complete events, which add a progress ring when an activation starts and add a complete ring when it finishes. The rings were added based on the order that the person would participate in the activations, providing a real-time visual story of their journey through the event.

The activation.game.update event was responsable to showcase real-time progress in the game. It updates the player's score, which is visually represented by expanding the ring around their entity on the dashboard.

Game updates: It subscribes to new.element events from the game channel, which would display a toast notification with the new element created. This feature gathered people around the screen to see what others were creating in real-time, creating a sense of community and shared excitement.

We had seen the creation of beautiful elements, like “Real-time communication”, “Web sockets”, “Collaboration environment”, “Remote work” and funny ones like “Intergalactic coffee”!

Presence events: The code subscribes to various presence-related events, which play a crucial role in maintaining an up-to-date representation of participant activity. These events include:

presence.leave: Triggered when a participant goes offline, causing their representation to become semi-transparent on the dashboard.
presence.joined-room: presence.joined-room: Fired when a participant comes online. For new participants, a new cell would enter the screen. For returning participants, it would restore the brightness of their existing cell. This effect allows participants and organizers to easily spot who is currently active in the event.

This real-time updating creates a dynamic, engaging experience for all participants, showcasing the power and versatility of the Realtime library in handling multiple simultaneous events and updates.

Hackathon AI meets Realtime

We recently hosted an Super Hackathon 2.0, with the challenge: AI meets Realtime challenge, pushing the boundaries of innovation by combining artificial intelligence with real-time communication technologies.

Participants were given the freedom to create anything they could imagine, much like our Super! (But we couldn’t participate of our own hackathon with this project 😢)

The hackathon saw an impressive projects that leveraged our Realtime library alongside various AI technologies. The creativity and innovation displayed by the participants were truly remarkable. If you're curious about the winning projects and want to explore how they combined AI with real-time capabilities, we invite you to read our detailed blog post about the hackathon winners. It's a great source of inspiration and showcases the potential of our Realtime library when paired with AI.

After many request, it’s open source

The overwhelming enthusiasm for our game didn't end with the events. Participants were eager to continue playing, explore without limitations, people were legitimately addicted to the gameplay. We heard your requests loud and clear!

Now that our new Realtime library is officially released, we're excited to announce that we're making the code for this project open source! This allows you to not only continue playing but also gain a better understanding of how everything works behind the scenes.

You can find the repository on our GitHub page. We encourage you to clone it, experiment with it, and maybe even contribute your own improvements or variations.

Happy coding and crafting!

SuperViz Hackathon 2.0: AI meets RealTime

Vitor Norton — Wed, 02 Oct 2024 17:39:02 +0000

A couple of months after our first hackathon, we are ready to announce: The Super Hackathon 2.0!

Get ready to participate in our Super Hackathon 2.0 this October to showcase your innovative real-time AI communication solutions! Hosted by SuperViz, this exciting hackathon is the perfect opportunity for developers to unleash their creativity and push the boundaries of using AI with real-time technology.

With $5,000 in prizes up for grabs, we challenge you to integrate AI with SuperViz's real-time platform, pushing the boundaries of interactive communication.

You can utilize any language model, such as GPT, Gemini, LLaMA, or Claude, to create innovative tools that elevate the real-time experience, making communication smarter and more efficient. How will you combine AI with real-time data to create meaningful improvements in collaboration and productivity?

Event Details:

Date: October 18-27, 2024
Prizes:
- Fist Place: $3,500
- Second Place: $1,000
- Third Place: $500
Platform: Online

We will have workshops, feedback sessions, and make sure you have all the resources you need to create the best solution to compete!

Ready to join? Visit the Super Hackathon 2.0 website to register and stay updated. Let's create something amazing!

How to implement real-time mouse pointers into a web-application using SuperViz React SDK

Vitor Norton — Wed, 28 Aug 2024 16:23:49 +0000

In this tutorial, we will guide you through adding real-time mouse pointers to a web application using the SuperViz React SDK. Real-time mouse pointers are essential for collaborative applications, allowing users to see each other's cursor movements and interactions on a shared screen. This feature enhances communication and collaboration, making it easier for participants to follow along with each other's actions.

We'll demonstrate how to use SuperViz to implement real-time mouse pointers in a React application. Although we’ll use a <canvas> element for rendering shared content, the real-time mouse pointers component is versatile and can be used with other HTML elements as well. This flexibility allows developers to integrate real-time pointers in a variety of web application contexts, providing a dynamic and interactive experience similar to collaborative platforms like Google Docs or Figma. Let's get started!

Prerequisite

To follow this tutorial, you will need a SuperViz account and a developer token. If you already have an account and a developer token, you can move on to the next step.

Create an Account

To create an account, go to https://dashboard.superviz.com/register and sign up using either Google or an email/password. Note that if you choose email/password, you will receive a confirmation link that you'll need to click to verify your account.

Retrieving a Developer Token

To use the SDK, you’ll need a developer token, which is essential for associating SDK requests with your account. You can retrieve both development and production SuperViz tokens from the the dashboard.

Copy and save the developer token, as you will need it in the next steps of this tutorial.

Step 1: Set Up Your React Application

To begin, you'll need to set up a new React project where we will integrate the SuperViz SDK for real-time mouse pointers.

1. Create a New React Project

First, create a new React application using Create React App with TypeScript.

npm create vite@latest mouse-pointers-demo -- --template react-ts
cd mouse-pointers-demo

2. Install SuperViz SDK

Next, install SuperViz, which will enable us to add real-time mouse pointer features to our application.

npm install @superviz/react-sdk uuid

@superviz/react-sdk: SDK for integrating real-time collaboration features, including mouse pointers.
uuid: A library for generating unique identifiers, useful for creating unique participant IDs.

3. Configure Tailwind

In this tutorial, we'll use the Tailwind CSS framework. First, install the Tailwind package.

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

We then need to configure the template path. Open tailwind.config.js in the root of the project and insert the following code.

/** @type {import('tailwindcss').Config} */
export default {
  content: [
    "./index.html",
    "./src/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

Then we need to add the tailwind directives to the global CSS file the src/index.css.

@tailwind base;
@tailwind components;
@tailwind utilities;

4. Set Up Environment Variables

Create a .env file in your project root and add your SuperViz developer key. This key will be used to authenticate your application with SuperViz services.

VITE_SUPERVIZ_API_KEY=YOUR_SUPERVIZ_DEVELOPER_KEY

Step 2: Implement the Main Application

In this step, we'll implement the main application logic to initialize SuperViz and handle real-time mouse pointers.

1. Implement the App Component

Open src/App.tsx and set up the main application component using the SuperVizRoomProvider to manage the collaborative environment.

import { SuperVizRoomProvider } from '@superviz/react-sdk'
import { v4 as generateId } from 'uuid'
import Room from './Room'

const developerKey = import.meta.env.VITE_SUPERVIZ_API_KEY;
const participantId = generateId()

export default function App() {
  return (
    <SuperVizRoomProvider
      developerKey={developerKey}
      group={{
        id: 'realtime-mouse-pointers',
        name: 'realtime-mouse-pointers',
      }}
      participant={{
        id: participantId,
        name: 'Participant',
      }}
      roomId='realtime-mouse-pointers'
    >
      <Room />
    </SuperVizRoomProvider>
  )
}

Explanation:

SuperVizRoomProvider: This component wraps the application to enable real-time features and provides configuration for group and participant details.
developerKey: Retrieves the developer key from environment variables to authenticate with SuperViz.
participantId: Generates a unique ID for each participant using the uuid library.
Room Component: Contains the logic for rendering the canvas and handling mouse pointers.

2. Implement the Room Component

Create a new file named src/Room.tsx and add the following implementation:

import { MousePointers } from "@superviz/react-sdk";

export default function Room() {
  return (
    <div className='w-full h-full bg-gray-200 flex items-center justify-center flex-col'>
      <header className='w-full p-5 bg-purple-400 flex items-center justify-between'>
        <h2 className='text-white text-2xl font-bold'>SuperViz Real-Time Mouse Pointers</h2>
      </header>
      <main className='flex-1 w-full h-full'>
        <div className='w-full h-full'>
          <canvas id="canvas" className='w-full h-full'></canvas>
        </div>

        <MousePointers elementId="canvas" />
      </main>
    </div>
  )
}

Explanation:

MousePointers Component: Displays the real-time location of each participant's mouse cursor on the canvas, allowing users to see where others are interacting.
elementId: Specifies the ID of the element (canvas) where the mouse pointers will be shown. The component can also be used with other HTML elements such as div or svg, offering flexibility in its application.
Canvas Element: A <canvas> element is used to render the shared content, with an ID that matches the elementId specified in MousePointers.

Step 3: Understanding the Project Structure

Here's a quick overview of how the project structure supports real-time mouse pointers:

App.tsx
- Initializes the SuperViz environment.
- Sets up participant information and room details.
- Renders the Room component within the SuperVizRoomProvider.
Room.tsx
- Contains the main UI elements, including the canvas.
- Integrates the MousePointers component to show real-time cursor movements.

Step 4: Running the Application

1. Start the React Application

To run your application, use the following command in your project directory:

npm run dev

This command will start the development server and open your application in the default web browser. You can interact with the canvas and see mouse pointers in real-time as other participants join the session.

2. Test the Application

Real-Time Mouse Pointers: Open the application in multiple browser windows or tabs to simulate multiple participants and verify that mouse movements are displayed in real-time for all users.
Collaborative Interaction: Test the responsiveness of the application by moving the mouse around the canvas and observing the pointers of other participants.

Summary

In this tutorial, we implemented real-time mouse pointers in a web application using SuperViz and React. We configured a React application to display mouse pointers for all participants, enabling seamless collaboration and interaction. This setup can be extended and customized to fit various scenarios where real-time collaboration and visual feedback are required.

Feel free to explore the full code and further examples in the GitHub repository for more details.

How to integrate Contextual Comments into Matterport SDK

Vitor Norton — Mon, 19 Aug 2024 15:12:36 +0000

In this tutorial, we will guide you through adding contextual comments to a Matterport SDK application using SuperViz. Contextual comments enable users to leave feedback directly within a 3D model, making it easier to collaborate on design reviews, walkthroughs, and virtual tours. This feature is particularly useful in scenarios where precise feedback within a spatial context is critical.

We'll demonstrate how to integrate SuperViz with Matterport, allowing participants to add and view comments within the 3D environment in real-time. By the end of this tutorial, you'll have a fully functional Matterport application with a robust commenting system that enhances collaboration and communication.

Let's get started!

Prerequisite

To follow this tutorial, you will need a SuperViz account and a developer token. If you already have an account and a developer token, you can move on to the next step.

Create an Account

Retrieving a Developer Token

Copy and save the developer token, as you will need it in the next steps of this tutorial.

Step 1: Set Up Your React Application

To begin, you'll need to set up a new React project where we will integrate SuperViz and the Matterport SDK.

1. Create a New React Project

First, create a new React application using Create React App with TypeScript.

npm create vite@latest matterport-comments -- --template react-ts
cd matterport-comments

2. Install Required Libraries

Next, install the necessary libraries for our project:

npm install @superviz/sdk @superviz/matterport-plugin uuid

@superviz/sdk: For integrating real-time collaboration features, including comments.
@superviz/matterport-plugin: Plugin for adding SuperViz interaction features to a Matterport Viewer.
uuid: A library for generating unique identifiers, useful for creating unique participant IDs.

3. Set Up Environment Variables

Create a .env file in your project root and add your SuperViz developer key and Matterport application key. These credentials will be used to authenticate your application with SuperViz and Matterport services.

VITE_SUPERVIZ_API_KEY=YOUR_SUPERVIZ_DEVELOPER_KEY
VITE_MATTERPORT_KEY=YOUR_MATTERPORT_KEY

Step 2: Implement the Main Application

In this step, we'll implement the main application logic to initialize SuperViz and the Matterport Viewer, and handle real-time contextual comments.

1. Implement the App Component

Open src/App.tsx and set up the main application component using SuperViz to manage the collaborative environment.

import { v4 as generateId } from 'uuid';
import { useCallback, useEffect, useRef } from "react";
import SuperVizRoom, { Comments } from '@superviz/sdk';
import { MatterportPin } from '@superviz/matterport-plugin';
import type { MpSdk } from '@superviz/matterport-plugin/dist/common/types/matterport.types.d.ts';

Explanation:

Imports: Import necessary components from React, SuperViz, Matterport Plugin, and UUID for managing state, initializing SuperViz, and enabling contextual comments within the Matterport SDK.

2. Define Constants

Define constants for the API key, Matterport key, and room ID.

const apiKey = import.meta.env.VITE_SUPERVIZ_API_KEY as string;
const matterportKey = import.meta.env.VITE_MATTERPORT_KEY as string;

const ROOM_ID = 'matterport-comments';
const PLAYER_ID = generateId();

Explanation:

apiKey & matterportKey: Retrieves the SuperViz and Matterport API keys from environment variables.
ROOM_ID & PLAYER_ID: Defines the room ID for the SuperViz session and generates a unique player ID.

3. Create the App Component

Set up the main App component and initialize references for the Matterport SDK.

export default function App() {
  const matterportSDK = useRef<MpSdk | null>(null);

  useEffect(() => {
    initializeMatterport();
  }, []);
}

Explanation:

matterportSDK: A ref to store the Matterport SDK instance.
useEffect: Calls the initializeMatterport function once when the component mounts, setting up the Matterport Viewer.

4. Initialize SuperViz

Create a function to initialize SuperViz and integrate the contextual commenting system.

const initializeSuperViz = useCallback(async () => {
  const superviz = await SuperVizRoom(apiKey, {
    roomId: ROOM_ID,
    participant: {
      id: PLAYER_ID,
      name: 'player-name',
    },
    group: {
      id: 'matterport-comments',
      name: 'matterport-comments',
    }
  });

  const pinAdapter = new MatterportPin(matterportSDK.current!, document.getElementById('showcase')!);
  const comments = new Comments(pinAdapter, {
    buttonLocation: 'top-right',
  });
  superviz.addComponent(comments);
}, []);

Explanation:

initializeSuperViz: An asynchronous function that initializes SuperViz and adds the contextual comments component to the Matterport Viewer.
MatterportPin: Adapts the Matterport SDK to work with SuperViz's commenting system, allowing users to pin comments directly in the 3D space.

5. Initialize Matterport Viewer

Create a function to initialize the Matterport Viewer with the necessary credentials and configurations.

const initializeMatterport = useCallback(async () => {
  const showcase = document.getElementById('showcase') as MatterportIframe;
  const showcaseWindow = showcase.contentWindow as MatterportIframe['window'];
  const source = \`/vendor/matterport/showcase.html?&play=1&qs=1&applicationKey=\${matterportKey}&m=Zh14WDtkjdC\`;
  showcase.setAttribute('src', source);

  await new Promise((resolve) => {
    showcase.addEventListener('load', async () => {
      matterportSDK.current = await showcaseWindow?.MP_SDK.connect(showcaseWindow, matterportKey);
      resolve(matterportSDK.current);
    });
  });

  initializeSuperViz();
}, [initializeSuperViz]);

Explanation:

initializeMatterport: Loads the Matterport Viewer in an iframe, connects the Matterport SDK, and then initializes SuperViz for real-time collaboration and commenting.

Step 3: Render the Application

Finally, return the JSX structure for rendering the Matterport Viewer and the SuperViz-powered interface.

return (
  <div className='w-full h-full bg-gray-200 flex items-center justify-center flex-col'>
    <header className='w-full p-5 bg-purple-400 flex items-center justify-between'>
      <h2 className='text-white text-2xl font-bold'>SuperViz Matterport Comments</h2>
    </header>
    <main className='w-full h-full flex items-center justify-center relative'>
      <iframe id='showcase' className='w-full h-full' />
    </main>
  </div>
);

Explanation:

Viewer Container: The showcase iframe is where the Matterport Viewer will be rendered, filling the entire screen. This is where users will interact with the 3D space and collaborate in real time with contextual comments.

Step 4: Understanding the Project Structure

Here's a quick overview of how the project structure supports adding contextual comments to a Matterport SDK application:

App.tsx
- Initializes SuperViz.
- Sets up the Matterport Viewer with real-time commenting features.
- Handles the loading of 3D spaces and integration of collaborative tools.
Matterport Viewer
- Renders the 3D space, allowing users to navigate, inspect, and leave comments in a shared virtual environment.
SuperViz Components
- MatterportPin & Comments: Enables users to pin comments to specific locations in the 3D model, enhancing collaborative review sessions.

Step 5: Running the Application

1. Start the React Application

To run your application, use the following command in your project directory:

npm start

This command will start the development server and open your application in the default web browser. You can interact with the 3D space and see real-time comments from other participants.

2. Test the Application

Contextual Comments: Open the application in multiple browser windows or tabs to simulate multiple participants and verify that comments are updated in real-time.
Collaborative Interaction: Test the commenting feature by adding comments to the 3D model and observing how they appear for other participants.

Summary

In this tutorial, we integrated contextual comments into a Matterport SDK application using SuperViz. We configured a React application to handle 3D space navigation and commenting, enabling multiple users to collaborate seamlessly within a shared virtual environment. This setup can be extended and customized to fit various scenarios where real-time collaboration on 3D spaces is required.

Feel free to explore the full code and further examples in the GitHub repository for more details.

What is channels and the benefits of using it when working with events

Vitor Norton — Thu, 15 Aug 2024 12:15:02 +0000

Event handling is a critical aspect of any application development process. It allows applications to respond to user interactions or system occurrences by executing specific sets of code. There are various ways to manage these events, but one effective method is through the use of channels. Within this blog post, I will explore what channels are and the benefits they offer when working with events.

What are Channels?

Channels are a communication mechanism used in concurrent programming for passing data between different parts of a software system. They are essentially pipelines through which you can send and receive values with the channel operator.

Channels provide a way for different routines, threads, or processes to communicate and synchronize. The major concept is that data can flow from one end of the channel to another, enabling different parts of a system to communicate seamlessly.

Why Use Multiple Channels?

While it's possible to use just one channel in your application, there are several reasons for using multiple channels.

One of the main reasons is to keep your application organized and maintainable. Each channel can be dedicated to a specific type of event or interaction, making it easier to manage and debug the application. For example, one channel could handle user interface events, another could handle a chat application, and so on. This separation of concerns makes your application more modular and easier to understand.

Another reason to use multiple channels is to increase the efficiency of your application. Different channels can be processed in parallel, which can lead to performance improvements, especially in multi-core or multi-threaded environments. In contrast, if all events are sent through a single channel, they would have to be processed one after another, which could lead to bottlenecks and reduce the responsiveness of your application.

Lastly, using multiple channels can help prevent data loss. If a single channel is overwhelmed with too many events, it may start dropping events or crash altogether. By spreading the load across multiple channels, you can help ensure that all events are processed successfully.

However, it's important to note that using multiple channels also comes with its own challenges, such as coordinating between different channels and managing concurrency issues. Therefore, it's crucial to design your application carefully and choose the right number of channels based on your specific needs.

What It Looks Like

The code snippet provided below showcases an example of how channels can be used in a real-life setting.

import { Realtime } from "@superviz/sdk";

const realtime = new Realtime();

const uxChannel = realtime.connect('ux');
const chatChannel = realtime.connect('chat');

const buttonClicked = { id: "#buttonId" }
uxChannel.publish("handle.click", buttonClicked);

const connection = { message: "Olá mundo" }
chatChannel.publish("handle.newMessage", connection );

In this scenario, two separate channels are created for handling different types of events - one for User Experience (UX) events and another for chat events. These events are then published to their respective channels, demonstrating how tasks can be effectively segregated and managed using multiple channels.

Channels and SuperViz

We recently introduced the multi-channel feature to our Real-Time Data Engine. It has significantly improved how we handle events on our SuperViz platform.

Now, it is possible to dedicate different channels for different types of events, increasing the efficiency and organization of your application. In addition, the ability to process channels in parallel allows for better performance, especially in multi-core or multi-threaded environments.

Super Hackathon Invitation - Win $5.000

So, while you are here, let me invite you to participate in our upcoming Super Hackathon this August!

From Aug 9-31, you'll be challenge to transform your virtual interactions with SuperViz’s real-time communication and data synchronization platform and a chance to win a prize of $5,000.

Top design patterns for frontend

Vitor Norton — Thu, 08 Aug 2024 12:31:07 +0000

Over the past couple of month, I have shared some trending design patterns for frontend developers. These include patterns like Singleton, Facade, Observer, Publisher/Subscriber and more. Today, I want to summarize some of the key points and benefits of these patterns and how they can be used to improve your frontend development process.

What are Design Patterns

Design patterns are reusable solutions to common problems that occur in software design. They represent the best practices used by experienced object-oriented software developers. These patterns can speed up the development process by providing a proven way of resolving frequent issues.

Top Design Patterns

1. Singleton Pattern

The Singleton Pattern is a type of design pattern that restricts the creation of a class to only one instance. This is useful in scenarios where a single point of control or coordination is required. In other words, it ensures that a class has only one instance and provides a global point of access to it.

A real use of the Singleton Pattern is managing a configuration settings object in a large-scale application, like a web app. This ensures only one instance of the configuration object (holding settings like database strings and API keys) exists, providing a single access point and preventing conflicts.

Learn more about the Singleton Pattern and how to code it

2. Facade Pattern

The Facade Pattern provides a simplified interface to a larger body of code. It makes a software library easier to read and understand, and wraps a poorly designed collection of APIs with a single well-designed API.

In a complex e-commerce platform, the Facade Pattern unifies multiple third-party services for payment, shipping, and inventory into a single interface. This simplifies interactions, making tasks like order placement easier, and keeps the main application code cleaner and more understandable.

Learn more about the Facade Pattern and how to code it

3. Observer Pattern

The Observer Pattern allows an object (known as the subject) to notify other objects (known as observers) when its state changes. This is useful in scenarios where a change to one object requires changing others, and where the actual set of objects is expected to change dynamically.

Learn more about the Observer Pattern and how to code it

3. Publisher/Subscriber Pattern

The Publisher/Subscriber Pattern is a messaging pattern where senders of messages, known as publishers, don't program the messages to be sent directly to specific receivers, called subscribers. Instead, published messages are categorized into classes without the publishers knowing the subscribers' identities. It's an effective way to handle event-driven programming.

In the Publisher/Subscriber pattern, publishers don't communicate directly with subscribers. Instead, these messages are classified and sent to subscribers by the message bus. This can provide more flexibility and scalability in complex systems. To dive deeper into the difference between PubSub and Observer patterns and their differences, check out this detailed article.

Learn more about the Publisher/Subscriber ****Pattern and how to code it

Real-time Data Engine

Architecting software to sync data between different instances can be challenging, but not the core business focus. The solution is the Real-time Data Engine tools, specifically SuperViz. It provides real-time collaboration and communication for web apps. SuperViz allows an easy-to-integrate tool for developers for the creation of a room where an event published by one participant is broadcast to all others across different devices and networks, ensuring real-time updates and a seamless experience.

SuperViz provides the infrastructure necessary to build real-time, collaborative applications. This includes the ability to also catch these events on your backend using webhooks, and as well to publish an event with a simple HTTP request, to name a few features.

Learn more about Real-time Data Engine and how to use it

5. Adapter Pattern

The Adapter Pattern allows the interface of an existing class to be used as another interface. It is often used to make existing classes work with others without modifying their source code, which can be particularly useful when they are from different libraries or frameworks.

A real case scenario of the Adapter Pattern can be seen in integrating legacy systems with modern applications. For instance, suppose you have an old payment processing system with a proprietary API that doesn't conform to the modern RESTful API standards used by your new e-commerce platform. By using an Adapter, you can create a wrapper that translates the requests and responses between the old system and the new platform, allowing seamless communication without altering the legacy system's code.

Learn more about the Adapter Pattern and how to code it

6. Composite Pattern

The Composite Pattern allows you to compose objects into tree structures to represent part-whole hierarchies. It lets clients treat individual objects and compositions of objects uniformly, making it easier to work with complex structures or recursive algorithms.

The Composite Pattern is useful for developing a restaurant's ordering app menu system. A menu can include individual items like "Burger" or composite items like "Combo Meal" (burger and fries). This pattern allows the app to uniformly handle operations like displaying the menu, calculating prices, or applying discounts on both single items and combos, simplifying management and expansion as new items or combos are added.

Learn more about the Composite Pattern and how to code it

7. Builder Pattern

The Builder Pattern allows for the step-by-step construction of complex objects. It separates the construction of a complex object from its representation, enabling the same construction process to create different representations. This pattern is particularly useful when building objects with many optional parameters or when the creation process involves several steps.

A real case scenario for the Builder Pattern can be seen in the construction of a complex user interface component, such as a customizable dashboard. By using the Builder Pattern, developers can create a dashboard with various optional widgets like graphs, charts, and tables, each configured with specific parameters such as data sources, styles, and update intervals. This pattern allows developers to assemble the dashboard step-by-step, ensuring that each component is properly configured before the final dashboard is created, providing flexibility and control over the customization process.

Learn more about the Builder Pattern and how to code it

Conclusion

Using design patterns can enhance frontend development by offering organized solutions to common challenges, making your code easier to maintain and scale. Patterns like Singleton, Facade, Observer, Publisher/Subscriber, Adapter, Composite, and Builder ensure a strong, flexible application architecture. Experiment with these patterns to find the best fit for your workflow and project needs.

If you have any questions feel free to drop a comment below.

Super Hackathon Invitation - Win $5.000

So, while you are here, let me invite you to participate in our upcoming Super Hackathon this August!

From Aug 9-31, you'll be challenge to transform your virtual interactions with SuperViz’s real-time communication and data synchronization platform and a chance to win a prize of $5,000.

Design Pattern #7 - Builder Pattern

Vitor Norton — Fri, 02 Aug 2024 13:31:08 +0000

This article is the last one in our series on design patterns for frontend development. Throughout this series, we've looked at various patterns, like the Observer and PubSub pattern, that help developers write better code. The Builder Pattern, which we will talk about here, is another useful tool.

The Builder Pattern

The Builder Pattern is a creational design pattern that allows developers to construct complex objects step-by-step. It separates the construction of an object from its representation, enabling the same construction process to create different representations.

In JavaScript, this pattern is particularly useful when dealing with objects that require numerous optional parameters or when the construction process involves several steps. By using the Builder Pattern, developers can create more readable and maintainable code by chaining method calls to set properties and ultimately build the desired object in a controlled manner.

Real case scenario

Imagine a frontend developer tasked with creating a complex dashboard for a web application. The challenge is to allow users to customize their dashboard with various widgets such as charts, tables, and notifications. Each widget needs different settings such as data sources, display options, and refresh intervals. Managing all these options through a single constructor or multiple setters can become cumbersome and prone to mistakes.

The Builder Pattern provides an elegant solution by using a DashboardBuilder class, developers can chain method calls to set properties for each widget, ensuring that all necessary configurations are applied before the dashboard is built. This approach not only makes the code more readable and maintainable but also allows for flexibility in creating different types of dashboards with varying complexities.

Hands on

The code below exemplifies the discussed scenario. It shows how a frontend developer can use the Builder Pattern to create a this dashboard:

class DashboardBuilder {
  constructor() {
    this.widgets = [];
  }

  addChart(type, data) {
    this.widgets.push({ type: 'chart', chartType: type, data });
    return this;
  }

  addTable(data) {
    this.widgets.push({ type: 'table', data });
    return this;
  }

  addNotification(message) {
    this.widgets.push({ type: 'notification', message });
    return this;
  }

  build() {
    return new Dashboard(this);
  }
}

class Dashboard {
  constructor(builder) {
    this.widgets = builder.widgets;
  }

  render() {
    this.widgets.forEach(widget => {
      switch (widget.type) {
        case 'chart':
          console.log(`Rendering a ${widget.chartType} chart with data:`, widget.data);
          break;
        case 'table':
          console.log('Rendering a table with data:', widget.data);
          break;
        case 'notification':
          console.log('Showing notification:', widget.message);
          break;
        default:
          console.log('Unknown widget type');
      }
    });
  }
}

// Usage
const dashboard = new DashboardBuilder()
  .addChart('line', [1, 2, 3])
  .addTable({ header: ['Name', 'Age'], rows: [['Alice', 30], ['Bob', 25]] })
  .addNotification('Welcome to your dashboard!')
  .build();

dashboard.render();

This code demonstrates the implementation of the Builder Pattern for creating a customizable dashboard. Here's a breakdown of the main components:

1. DashboardBuilder class:

Manages the construction of the dashboard
Has methods to add different types of widgets (charts, tables, notifications)
Each method returns this to allow method chaining
The build() method creates and returns a new Dashboard instance

2. Dashboard class:

Represents the final product
Takes a DashboardBuilder instance in its constructor
Has a render() method to display the widgets

3. Usage example:

Creates a new dashboard with a line chart, a table, and a notification
Uses method chaining to add widgets in a readable manner
Calls build() to create the Dashboard instance
Finally, calls render() to display the dashboard

This pattern allows for flexible and readable creation of complex dashboard objects with various widgets and configurations.

Overall, the Builder Pattern is a powerful tool in software development, especially when dealing with complex object creation scenarios. It promotes cleaner code, reduces the likelihood of errors, and enhances the maintainability of the codebase.

If you have any questions feel free to drop a comment below. Also, make sure to check out the other articles in our frontend design patterns series!

Super Hackathon Invitation - Win $5.000

So, while you are here, let me invite you to participate in our upcoming Super Hackathon this August!

From Aug 9-31, you'll be challenge to transform your virtual interactions with SuperViz’s real-time communication and data synchronization platform and a chance to win a prize of $5,000.

Design Pattern #6 - Composite Pattern

Vitor Norton — Thu, 25 Jul 2024 13:09:17 +0000

In today’s article, which is part of our series about frontend design patterns, I will explain the Composite Pattern, explore real-world examples, and provide a hands-on JavaScript implementation. Let's dive in!

Composite Pattern is a structural design pattern that organizes objects into tree structures for representing whole-part hierarchies. It helps you handle individual objects and groups of objects in the same way. This pattern is handy for working with tree-like structures, like user interfaces or organizational hierarchies.

In JavaScript, the Composite Pattern can be implemented by creating a base component class that defines the common interface for both simple and composite objects. “Leaf” objects represent the end objects in the composition, while composite objects can contain other leaf or composite objects.

Real case scenario

A common challenge developers face is managing a complex UI with nested elements, such as menus with submenus or file systems with directories and files. Without a structured approach, the code can become difficult to manage and extend, leading to potential bugs and inefficiencies.

This is where the Composite Pattern comes into play. By treating individual UI elements and groups of elements uniformly, developers can simplify the management of nested components. For instance, consider a menu system where we have two types of components: MenuItem and Menu. MenuItem represents a single menu item, while Menu can contain multiple MenuItem objects and other Menu objects. Both MenuItem and Menu implement a common interface, allowing the main menu to treat them uniformly. This pattern not only makes the code more manageable but also enhances its extensibility.

Hands-on

To better understand the Composite Pattern, let's implement a simple example using JavaScript.

// Component interface
class MenuComponent {
  add(component) {}
  remove(component) {}
  getChild(index) {}
  display() {}
}

// Leaf object
class MenuItem extends MenuComponent {
  constructor(name) {
    super();
    this.name = name;
  }

  display() {
    console.log(this.name);
  }
}

// Composite object
class Menu extends MenuComponent {
  constructor(name) {
    super();
    this.name = name;
    this.children = [];
  }

  add(component) {
    this.children.push(component);
  }

  remove(component) {
    this.children = this.children.filter(child => child !== component);
  }

  getChild(index) {
    return this.children[index];
  }

  display() {
    console.log(this.name);
    this.children.forEach(child => child.display());
  }
}

// Client code
const mainMenu = new Menu('Main Menu');
const menuItem1 = new MenuItem('Item 1');
const menuItem2 = new MenuItem('Item 2');
const subMenu = new Menu('Sub Menu');
const subMenuItem1 = new MenuItem('Sub Item 1');

mainMenu.add(menuItem1);
mainMenu.add(menuItem2);
mainMenu.add(subMenu);
subMenu.add(subMenuItem1);

// Display the menu structure
mainMenu.display();

Let's break down the code:

MenuComponent: This is the base class, serving as an interface for both leaf and composite objects. It defines the common methods like add, remove, getChild, and display.

MenuItem: This class represents the leaf objects in the composite pattern. It extends MenuComponent and implements the display method to output its name.

Menu: This class represents composite objects that can contain children (both MenuItem and other Menu objects). It extends MenuComponent and implements methods to add, remove, retrieve, and display its children.

Client code: The example creates a menu structure with a main menu, menu items, and a sub-menu. It then adds items to the main menu and the sub-menu, and finally displays the entire structure.

Conclusion

By applying the Composite Pattern, you can manage complex UI components efficiently, handle organizational hierarchies, and structure data representations such as file systems. This pattern makes your codebase more maintainable and scalable, particularly in scenarios where you need to treat individual objects and compositions of objects uniformly.

If you have any questions feel free to drop a comment below. Also, make sure to check out the other articles in our frontend design patterns series!

Stay tuned for our next post coming next week!

Super Invitation - Win $5.000

So, while you are here, let me invite you to participate in our upcoming Super Hackathon this August!

From Aug 9-31, you'll be challenge to transform your virtual interactions with SuperViz’s real-time communication and data synchronization platform and a chance to win a prize of $5,000.

Announcing the SuperViz Hackathon

Vitor Norton — Thu, 18 Jul 2024 14:29:48 +0000

Join the Super Hackathon this August to showcase your innovative real-time communication solutions! Hosted by SuperViz, this exciting hackathon is the perfect opportunity for developers to unleash their creativity and push the boundaries of virtual interactions.

With a $5,000 prize up for grabs, we challenge you to use SuperViz's advanced SDK to create applications that boost user engagement and productivity. Whether it's building on an existing platform or developing something entirely new, your project will showcase your innovative ideas in real-time communication!

Event Details:

Event: SuperViz Super Hackathon
Date: August 9-25, 2024
Prize: $5,000
Platform: Online

Ready to join? Visit the Super Hackathon website to register and stay updated. Let's create something amazing!

Design Pattern #5 - Adapter Pattern

Vitor Norton — Thu, 11 Jul 2024 18:56:16 +0000

Over the past few weeks, I have shared some of the trending design patterns, like the PubSub and the Singleton ones. Today, I'm going to share one more article of this series, but please comment below and tell me which design pattern I should cover next!

The Adapter Pattern

The Adapter Pattern is a structural design pattern that allows objects with incompatible interfaces to collaborate. It's often used when you want to make existing classes work with others without modifying their source code. This pattern is particularly useful when the interface of an existing class does not match the one you need.

Real Case Scenario

Let's consider a real-life example. You've been tasked to integrate a third-party video player into your application. However, the video player functions differently and has a different method interface than what your application expects. In this case, you could use the Adapter Pattern to create a wrapper class around the video player, making the third-party code compatible with your existing application code.

Here is the code you'd use in this case:

// Adapter class
class VideoPlayerAdapter {
    constructor() {
        this.externalPlayer = new ThirdPartyVideoPlayer({
            // some configuration
        });
    }

    play() {
        const video = this.externalPlayer.getVideo();
        this.externalPlayer.playVideo(video, {
            // additional parameters
        });
    }
}

// Your application code
class Application {
    constructor() {
        this.videoPlayer = new VideoPlayerAdapter();
    }

    start() {
        // Play video using your application code
        this.videoPlayer.play();
    }
}

Let's break down the code above:

ThirdPartyVideoPlayer is a hypothetical external library that your application wants to use. However, its interface might not be compatible with your application.
VideoPlayerAdapter is the adapter class. It wraps around ThirdPartyVideoPlayer. The adapter's interface is compatible with your application. When the adapter's play() method is called, it internally calls the necessary methods on ThirdPartyVideoPlayer.
Application is your application code. It creates an instance of VideoPlayerAdapter and uses it as if it were a regular video player. When it calls the play() method on the adapter, the adapter translates that into the appropriate calls to ThirdPartyVideoPlayer.

This way, the Application class doesn't need to know anything about how ThirdPartyVideoPlayer works. If you ever need to replace ThirdPartyVideoPlayer with a different library, you only need to write a new adapter — the Application class can stay the same. This is the main benefit of the Adapter pattern: it decouples your application code from the specifics of third-party libraries.

Differences Between Adapter Pattern and Facade Pattern

While the Adapter Pattern and the Facade Pattern might seem similar, they serve different purposes and are used in different contexts:

Purpose:
- Adapter Pattern: The primary purpose of the Adapter Pattern is to make two incompatible interfaces compatible with each other. It allows an existing class with a different interface to be used as if it implemented a different interface.
- Facade Pattern: The main purpose of the Facade Pattern is to provide a simplified interface to a complex subsystem. It hides the complexities of the subsystem and provides a higher-level interface that makes the subsystem easier to use.
Usage:
- Adapter Pattern: It is used when you need to integrate a new class or library that does not match the existing class or interface in your application. The Adapter Pattern is about adapting a particular interface to an expected interface.
- Facade Pattern: It is used when you want to simplify interactions with a complex subsystem. The Facade provides a straightforward method for interacting with the system, hiding its complexity.
Design:
- Adapter Pattern: Typically involves creating a new class (the Adapter) that implements the interface expected by the client and translates calls to the adapted class.
- Facade Pattern: Involves creating a Facade class that provides simplified methods to the client, often aggregating multiple functionalities from the subsystem.

In summary, while both patterns provide a way to work with existing code, the Adapter Pattern focuses on interface compatibility, whereas the Facade Pattern focuses on simplifying the interaction with a complex system.

Super Invitation - Win $5.000

So, while you are here, let me invite you to participate in our upcoming Superthis August!

This remote event gives you the chance to showcase your skills and creativity by tackling the challenge to transform your virtual interactions with our real-time communication tools. With SuperViz, you stand a chance to win a prize of $5,000.

Pub/Sub pattern vs Observer Pattern: what's the difference?

Vitor Norton — Thu, 04 Jul 2024 13:53:12 +0000

Over the past few weeks, I've been delving into the trending design patterns in frontend development. I've covered the Singleton, the Facade, the Observer, and most recently, the Pub Sub Pattern Design.

The last two articles focused on the Pub/Sub and Observer patterns. While these two patterns share some conceptual similarities, I thought it would be interesting to explore their differences. Hence, this post.

Main difference

Both of these patterns have a concept of publishing something and subscribing to an observer, right? So what’s the difference?

The Observer pattern solves this by allowing the Client to attach itself as an Observer to the Store. When the iPhone arrives, the store notifies all attached Observers. While in the PubSub application, it publishes an event/data to an event broker, and then the subscribers listen for it. The publisher is unaware of its observers.

In our Client-Store scenario, the event broker of the PubSub application could be like a marketplace. It would need to keep track of product availability in the store. When a new iPhone arrives, the marketplace system would register this event and notify all subscribers (customers who expressed interest in the iPhone) by sending them an email or a push notification.

Observer patterns are mostly used when you want different parts of a single application to share data with each other, usually in real-time. In this case, the entity providing the data is aware of who is receiving it.

On the other hand, the Pub-Sub pattern allows data to be shared across multiple applications. This usually happens asynchronously but can be made synchronous using specific SDKs, like the SuperViz Real-time Data Engine. In this pattern, the one sharing the data doesn't know who's receiving it - they just put it out there for anyone interested.

The main difference is that the Pub-Sub pattern supports a more decoupled architecture, where the data sharers and receivers can work independently from each other. This is not the case in the Observer pattern.

Use Cases for Observer Patterns

Observer Patterns are often used in GUI development, where one part of the application (the button) needs to notify another part of the application (the click event handler) when a certain event (the button being clicked) occurs.

Use Cases for Publisher Subscriber Pattern

In the context of frontend development, Publisher Subscriber Patterns can be instrumental. For instance, in a complex web application, different components may need to exchange data in real-time, like in a chat application, tracking the GPS of a taxi, or even real-time stock market data updates. These are situations where different components need to stay updated without having a direct relationship with each other.

Let me know in the comments area if you have other scenarios where the Observer or the PubSub is helpful.

Real-time Data Engine

If you're building a web application that requires real-time data sharing and communication, SuperViz is an SDK tool worth considering. It offers a real-time collaboration and communication SDK and API, designed for developers building real-time web applications.

Using SuperViz, you can create a room with several participants. When publishing an event, it will be broadcasted to all the participants in the room who are accessing it through different devices and networks. This means that any updates made by one participant will be reflected in real time across all devices, providing a seamless and collaborative experience.

SuperViz provides the infrastructure necessary to build real-time, collaborative applications. This includes the ability to catch these events on your backend using webhooks, as well as to publish an event with a simple HTTP Request, to name a few features.

You can easily test it with our open-source sample codes that run with a glance.