Real-Time Team Collaboration Platform

A Team Collaboration Platform is not just a task manager that refreshes more often. In a normal CRUD app, one user creates or edits data and the interface updates after a request finishes. In a real-time collaboration app, multiple users can change the same workspace at the same time. Task updates, comments, assignments, presence changes, and board activity must be broadcast to other connected clients almost immediately.

A common mistake is building the first version as a local CRUD app and then trying to “add WebSockets” at the end. This usually creates messy architecture because the components already assume that all changes come from the current user. Real-time apps need to handle two kinds of updates from the beginning: local user actions and remote events from other users.

The better approach is to design the app around events. A user action creates an event such as task.created, task.updated, comment.added, or presence.changed. The same reducer or store action should be able to process both local optimistic updates and confirmed remote events. This keeps the UI consistent across all connected clients.

Problematic approach:

          async function updateTask(taskId: string, title: string) {
            const response = await fetch(`/api/tasks/${taskId}`, {
              method: "PATCH",
              body: JSON.stringify({ title })
            });

            const updatedTask = await response.json();

            tasks = tasks.map((task) => {
              return task.id === taskId ? updatedTask : task;
            });
          }

This updates only the current browser. Other users will not see the change unless they refresh or poll the API.

Better event model:

          type CollaborationEvent =
            | {
                type: "task.updated";
                eventId: string;
                boardId: string;
                userId: string;
                payload: {
                  taskId: string;
                  changes: Partial<Task>;
                };
                createdAt: string;
              }
            | {
                type: "comment.added";
                eventId: string;
                boardId: string;
                userId: string;
                payload: {
                  taskId: string;
                  comment: Comment;
                };
                createdAt: string;
              }
            | {
                type: "presence.changed";
                eventId: string;
                boardId: string;
                userId: string;
                payload: {
                  status: "online" | "away" | "offline";
                };
                createdAt: string;
              };

Shared event handler:

          function applyCollaborationEvent(event: CollaborationEvent) {
            switch (event.type) {
              case "task.updated":
                updateTaskInStore(event.payload.taskId, event.payload.changes);
                break;

              case "comment.added":
                addCommentToTask(event.payload.taskId, event.payload.comment);
                break;

              case "presence.changed":
                updateUserPresence(event.userId, event.payload.status);
                break;
            }
          }

Pay attention to: Real-time collaboration should be event-driven from the start. Design local actions and remote updates to pass through the same predictable state layer.

WebSocket connections are long-lived side effects. They need connection setup, cleanup, reconnect handling, message parsing, error handling, and event dispatching. A common mistake is putting this logic directly inside visual components such as Board.svelte, TaskCard.svelte, or CommentsPanel.svelte. The component then becomes responsible for rendering, state updates, networking, and lifecycle behavior at the same time.

This makes the platform difficult to scale. If several components open their own WebSocket connections, users may accidentally create duplicate subscriptions. If one component unmounts, it may close a connection that another part of the app still needs. If reconnection logic is copied across components, bugs become harder to fix.

A better approach is to isolate WebSocket communication inside a service or Svelte store. Components should call functions like sendEvent, joinBoard, or leaveBoard. They should subscribe to reactive stores for connection status, presence, tasks, and comments. This keeps presentation clean and networking reusable.

Problematic approach:

          <script lang="ts">
            import { onMount } from "svelte";

            let socket: WebSocket;
            let tasks = [];

            onMount(() => {
              socket = new WebSocket("wss://example.com/boards/123");

              socket.onmessage = (message) => {
                const event = JSON.parse(message.data);

                if (event.type === "task.updated") {
                  tasks = tasks.map((task) => {
                    return task.id === event.taskId ? event.task : task;
                  });
                }
              };
            });
          </script>

This component owns too much. It opens the connection, parses events, updates board data, and renders the UI.

Better WebSocket service:

          type ConnectionStatus =
            | "idle"
            | "connecting"
            | "connected"
            | "reconnecting"
            | "disconnected"
            | "error";

          function createCollaborationSocket() {
            let socket: WebSocket | null = null;

            const connectionStatus = writable<ConnectionStatus>("idle");

            function connect(boardId: string) {
              connectionStatus.set("connecting");

              socket = new WebSocket(`wss://example.com/boards/${boardId}`);

              socket.addEventListener("open", () => {
                connectionStatus.set("connected");
              });

              socket.addEventListener("message", (message) => {
                const event = parseCollaborationEvent(message.data);

                if (event) {
                  applyCollaborationEvent(event);
                }
              });

              socket.addEventListener("close", () => {
                connectionStatus.set("disconnected");
              });

              socket.addEventListener("error", () => {
                connectionStatus.set("error");
              });
            }

            function sendEvent(event: CollaborationEvent) {
              if (!socket || socket.readyState !== WebSocket.OPEN) {
                return false;
              }

              socket.send(JSON.stringify(event));
              return true;
            }

            function disconnect() {
              socket?.close();
              socket = null;
              connectionStatus.set("idle");
            }

            return {
              connectionStatus,
              connect,
              sendEvent,
              disconnect
            };
          }

          export const collaborationSocket = createCollaborationSocket();

Component usage:

          <script lang="ts">
            import { onMount } from "svelte";
            import { collaborationSocket } from "$lib/realtime/collaborationSocket";

            export let boardId: string;

            onMount(() => {
              collaborationSocket.connect(boardId);

              return () => {
                collaborationSocket.disconnect();
              };
            });
          </script>

          <ConnectionBanner status={$collaborationSocket.connectionStatus} />

Pay attention to: Keep WebSocket lifecycle logic outside visual components. Components should render state and call actions, while services and stores manage real-time communication.

Optimistic UI makes collaboration apps feel fast. When a user moves a task, edits a title, or posts a comment, the app can update the interface immediately instead of waiting for the server. The mistake is assuming every optimistic update will always succeed. In real applications, the request can fail, the user may lose connection, the server may reject the action, or another user may change the same task first.

A safe optimistic update needs a pending state and a reconciliation strategy. The UI should know which actions are waiting for server confirmation. If the server confirms the action, the pending marker can be removed. If the server rejects it, the app should roll back the local change or show a clear conflict state.

This is important for trust. If the app shows that a comment was posted but the server never saved it, users may believe their teammate saw something that was actually lost. Collaboration tools must be honest about pending, synced, and failed states.

Problematic approach:

          function renameTask(taskId: string, title: string) {
            updateTaskInStore(taskId, { title });

            collaborationSocket.sendEvent({
              type: "task.updated",
              taskId,
              title
            });
          }

This updates the UI immediately but does not track whether the server accepted the change.

Better optimistic action model:

          type PendingAction = {
            actionId: string;
            type: CollaborationEvent["type"];
            rollback: () => void;
            createdAt: string;
          };

          const pendingActions = writable<Record<string, PendingAction>>({});

          function addPendingAction(action: PendingAction) {
            pendingActions.update((actions) => {
              return {
                ...actions,
                [action.actionId]: action
              };
            });
          }

          function removePendingAction(actionId: string) {
            pendingActions.update((actions) => {
              const nextActions = { ...actions };
              delete nextActions[actionId];

              return nextActions;
            });
          }

Optimistic task rename:

          function renameTaskOptimistically(taskId: string, nextTitle: string) {
            const previousTask = getTaskSnapshot(taskId);
            const actionId = crypto.randomUUID();

            updateTaskInStore(taskId, {
              title: nextTitle,
              syncStatus: "pending"
            });

            addPendingAction({
              actionId,
              type: "task.updated",
              createdAt: new Date().toISOString(),
              rollback: () => {
                updateTaskInStore(taskId, previousTask);
              }
            });

            const sent = collaborationSocket.sendEvent({
              type: "task.updated",
              eventId: actionId,
              boardId: previousTask.boardId,
              userId: currentUser.id,
              payload: {
                taskId,
                changes: {
                  title: nextTitle
                }
              },
              createdAt: new Date().toISOString()
            });

            if (!sent) {
              rollbackPendingAction(actionId);
            }
          }

Server confirmation:

          function handleServerConfirmation(actionId: string, taskId: string) {
            removePendingAction(actionId);

            updateTaskInStore(taskId, {
              syncStatus: "synced"
            });
          }

          function rollbackPendingAction(actionId: string) {
            pendingActions.update((actions) => {
              const action = actions[actionId];

              if (action) {
                action.rollback();
              }

              const nextActions = { ...actions };
              delete nextActions[actionId];

              return nextActions;
            });
          }

Pay attention to: Optimistic UI is not just “update first.” Track pending actions, confirm successful updates, and rollback or mark conflicts when synchronization fails.

Presence is one of the features that makes a collaboration platform feel alive. Users want to know who is online, who is viewing the same board, and sometimes who is editing a specific task. A common mistake is storing presence as a simple array of usernames. This breaks when the same user opens two tabs, reconnects after a network drop, or switches between boards.

Presence should be modeled separately from user profiles. A user profile describes a person. A presence session describes one active connection from that person. The same user can have multiple sessions. If you treat username as the presence ID, you may accidentally mark a user offline when only one of their tabs disconnects.

A stronger model tracks session ID, user ID, board ID, status, last seen time, and optional activity such as currently viewed task or editing field. This allows the UI to show accurate presence indicators and clean up stale sessions safely.

Problematic approach:

          let onlineUsers = ["Ana", "Nina", "Devon"];

          function removeUser(username: string) {
            onlineUsers = onlineUsers.filter((user) => user !== username);
          }

This cannot distinguish between one user and one connection. It also loses useful details such as board context and last activity time.

Better presence model:

          type PresenceStatus = "online" | "away" | "offline";

          type PresenceSession = {
            sessionId: string;
            userId: string;
            boardId: string;
            status: PresenceStatus;
            lastSeenAt: string;
            activity?: {
              type: "viewing-board" | "editing-task" | "writing-comment";
              taskId?: string;
            };
          };

          type UserProfile = {
            id: string;
            name: string;
            avatarUrl?: string;
          };

Presence store:

          const presenceSessions = writable<Record<string, PresenceSession>>({});

          function upsertPresenceSession(session: PresenceSession) {
            presenceSessions.update((sessions) => {
              return {
                ...sessions,
                [session.sessionId]: session
              };
            });
          }

          function removePresenceSession(sessionId: string) {
            presenceSessions.update((sessions) => {
              const nextSessions = { ...sessions };
              delete nextSessions[sessionId];

              return nextSessions;
            });
          }

Derived online collaborators:

          const onlineCollaboratorIds = derived(presenceSessions, ($sessions) => {
            const userIds = new Set<string>();

            Object.values($sessions).forEach((session) => {
              if (session.status === "online") {
                userIds.add(session.userId);
              }
            });

            return [...userIds];
          });

Pay attention to: Presence is connection state, not just a list of names. Model sessions separately from users so reconnects, multiple tabs, and board switching remain accurate.

Real-time systems often receive duplicate events or events in an unexpected order. A client may reconnect and receive missed events. A server may retry delivery. Two users may edit related data at nearly the same time. A common mistake is applying every incoming event blindly. This can duplicate comments, move a task twice, or overwrite newer data with older data.

A collaboration platform should make event handling idempotent where possible. Each event should have a unique eventId. The client should keep a short record of processed event IDs and ignore duplicates. For entities such as tasks and comments, timestamps or version numbers can help decide whether an incoming update is newer than the local version.

This does not mean building a perfect distributed database. But even a portfolio project should show awareness of real-time consistency problems. Idempotent event handling makes the app more stable and demonstrates stronger engineering judgment.

Problematic approach:

          function handleIncomingComment(event) {
            comments.update((items) => {
              return [...items, event.payload.comment];
            });
          }

If the same event arrives twice, the comment appears twice.

Better processed-event tracking:

          const processedEventIds = new Set<string>();

          function shouldProcessEvent(event: CollaborationEvent): boolean {
            if (processedEventIds.has(event.eventId)) {
              return false;
            }

            processedEventIds.add(event.eventId);

            if (processedEventIds.size > 500) {
              const oldestEventId = processedEventIds.values().next().value;
              processedEventIds.delete(oldestEventId);
            }

            return true;
          }

Safe event application:

          function handleIncomingEvent(event: CollaborationEvent) {
            if (!shouldProcessEvent(event)) {
              return;
            }

            applyCollaborationEvent(event);
          }

Version-aware task update:

          type Task = {
            id: string;
            title: string;
            description: string;
            version: number;
            updatedAt: string;
          };

          function applyTaskUpdate(taskId: string, changes: Partial<Task>, version: number) {
            tasks.update((currentTasks) => {
              const existingTask = currentTasks[taskId];

              if (!existingTask || version <= existingTask.version) {
                return currentTasks;
              }

              return {
                ...currentTasks,
                [taskId]: {
                  ...existingTask,
                  ...changes,
                  version
                }
              };
            });
          }

Pay attention to: Incoming real-time events are not always clean. Track processed event IDs, avoid duplicate application, and use version or timestamp checks for important shared entities.

A team collaboration app needs identity. Users create tasks, assign teammates, write comments, join boards, and see presence indicators. If authentication is treated as decoration, the app becomes unrealistic. A common mistake is adding a fake current user object inside the frontend and allowing every action everywhere. That may be enough for a small demo, but it does not represent how collaboration platforms work.

Even if the first version uses a simple auth starter or mock session, the architecture should respect user identity and permissions. Board access should be checked before loading shared data. Task actions should include userId. Comments should record authorship. Presence should be tied to a real session. Admin-only actions such as deleting boards or inviting members should be clearly separated from normal member actions.

In SvelteKit, this usually means thinking about protected routes, server-side session checks, route guards, form actions, and environment variables. The visual UI should not be the only protection layer. A hidden button is not the same as permission enforcement.

Problematic approach:

          const currentUser = {
            id: "demo-user",
            name: "Demo User",
            role: "admin"
          };

          function deleteBoard(boardId: string) {
            boardsStore.remove(boardId);
          }

This makes every user an admin and does not model access control.

Better identity model:

          type TeamRole = "owner" | "admin" | "member" | "viewer";

          type CollaborationUser = {
            id: string;
            name: string;
            email: string;
            avatarUrl?: string;
          };

          type BoardMembership = {
            boardId: string;
            userId: string;
            role: TeamRole;
          };

          function canDeleteBoard(role: TeamRole): boolean {
            return role === "owner" || role === "admin";
          }

          function canEditTask(role: TeamRole): boolean {
            return role === "owner" || role === "admin" || role === "member";
          }

Permission-aware UI:

          {#if canEditTask(currentMembership.role)}
            <button
              type="button"
              on:click={() => openTaskEditor(task.id)}
            >
              Edit task
            </button>
          {/if}

          {#if canDeleteBoard(currentMembership.role)}
            <button
              type="button"
              class="danger"
              on:click={() => confirmBoardDelete(board.id)}
            >
              Delete board
            </button>
          {/if}

Event with identity:

          const event: CollaborationEvent = {
            type: "task.updated",
            eventId: crypto.randomUUID(),
            boardId: board.id,
            userId: currentUser.id,
            payload: {
              taskId: task.id,
              changes: {
                title: nextTitle
              }
            },
            createdAt: new Date().toISOString()
          };

Pay attention to: Team software needs identity and permissions. Model users, roles, memberships, session state, and permission checks early instead of treating them as optional decoration.