DEV Community: Alex Booker

Next.js form validation on the client and server with Zod

Alex Booker — Wed, 01 Jan 2025 14:33:47 +0000

Building robust forms in Next.js is thirsty work!

Not only must you validate forms on the server, you must validate them on the client as well.

On the client, to ensure the user has a smooth experience, fields should be revalidated when their value changes, but only if the field has been "touched" or the form previously-submitted.

If JavaScript is disabled, the form ought to regress gracefully. Dynamic form validation won't be possible, but errors should still render alongside their respective fields and preserve their values between requests to the server.

You want to do all this without writing a bunch of duplicate code and, in this case, without a form library like React Hook Form.

Here's how a senior developer would do it utilising Zod ⬇️

Zod allows you to define the shape of a valid for submission. Provided you do so in a separate file, you can reference the definition from either the server or a client component, eliminating the possibility of duplicate code.

import { z } from "zod"

export const signUpFormSchema = z.object({
  email: z.string().email({ message: "Please enter a valid email." }).trim(),
  password: z
    .string()
    .min(8, { message: "Be at least 8 characters long" })
    .regex(/[a-zA-Z]/, { message: "Contain at least one letter." })
    .regex(/[0-9]/, { message: "Contain at least one number." })
    .regex(/[^a-zA-Z0-9]/, {
      message: "Contain at least one special character."
    })
    .trim()
})

export type SignUpActionState = {
  form?: {
    email?: string
    password?: string
  }
  errors?: {
    email?: string[]
    password?: string[]
  }
}

To validate the form on the server, import and and validate against the schema when the sever action is submitted:

"use server"

import { redirect } from "next/navigation"
import { SignUpActionState, signUpFormSchema } from "./schema"

export async function signUpAction(
  _prev: SignUpActionState,
  formData: FormData
): Promise<SignUpActionState> {
  const form = Object.fromEntries(formData)
  const validationResult = signUpFormSchema.safeParse(form)
  if (!validationResult.success) {
    return {
      form,
      errors: validationResult.error.flatten().fieldErrors
    }
  }

  redirect("/")
}

On the client, in a client component denoted with "use client", create your form:

ℹ️ Info
`<ValidatedInput />` isn't defined yet - take a moment to understand the form first

"use client"

import { useActionState, useState } from "react"
import { signUpAction } from "./action"
import { signUpFormSchema } from "./schema"
import { ValidatedInput } from "@/components/ui/validated-input"

export default function SignUpForm() {
  const [wasSubmitted, setWasSubmitted] = useState(false)

  const [state, action, isPending] = useActionState(signUpAction, {})

  const handleSubmit = (event: React.FormEvent<HTMLFormElement>) => {
    setWasSubmitted(true)
    const formData = new FormData(event.currentTarget)
    const data = Object.fromEntries(formData)
    const validationResult = signUpFormSchema.safeParse(data)
    if (!validationResult.success) {
      event.preventDefault()
    }
  }

  return (
    <form onSubmit={handleSubmit} action={action} noValidate>
      <div>
        <label htmlFor="email">Email:</label>
        <ValidatedInput
          type="email"
          name="email"
          wasSubmitted={wasSubmitted}
          fieldSchema={signUpFormSchema.shape["email"]}
          defaultValue={state.form?.email}
          errors={state.errors?.email}
        />
      </div>
      <div>
        <label htmlFor="password">Password:</label>
        <ValidatedInput
          type="password"
          name="password"
          fieldSchema={signUpFormSchema.shape["password"]}
          wasSubmitted={wasSubmitted}
          defaultValue={state.form?.password}
          errors={state.errors?.password}
        />
      </div>
      <div>
        <button type="submit" disabled={isPending}>
          Continue
        </button>
      </div>
    </form>
  )
}

When the form is submitted, onSubmit validates the form before indirectly invoking the server action.

The form component above is not concerned about rendering errors - that is the responsibility of <ValidatedInput />:

<ValidatedInput
  type="password"
  name="password"
  fieldSchema={signUpFormSchema.shape["password"]}
  wasSubmitted={wasSubmitted}
  defaultValue={state.form?.password}
  errors={state.errors?.password}
/>

Note how we extract the fieldSchema from signUpFormSchema using signUpFormSchema.shape. By passing the field schema in this way, <ValidatedInput /> remains flexible and reusable across your different forms.

Here's <ValidatedInput /> in full:

import { useState, useCallback } from "react"
import { Input } from "./input"

const ValidatedInput = ({
  name,
  wasSubmitted,
  errors,
  fieldSchema,
  ...props
}) => {
  const [value, setValue] = useState("")
  const [touched, setTouched] = useState(false)

  const getErrors = useCallback(() => {
    const validationResult = fieldSchema.safeParse(value)
    return validationResult.success
      ? []
      : validationResult.error.flatten().formErrors
  }, [fieldSchema, value])

  const fieldErrors = errors || getErrors()
  const shouldRenderErrors = errors || wasSubmitted || touched

  const handleBlur = () => setTouched(true)
  const handleChange = (e) => setValue(e.currentTarget.value)

  return (
    <>
      <Input
        id={name}
        name={name}
        onBlur={handleBlur}
        onChange={handleChange}
        className={fieldErrors.length > 0 ? "border-red-500" : ""}
        {...props}
      />
      {shouldRenderErrors && (
        <span className="text-sm text-red-500">{fieldErrors}</span>
      )}
    </>
  )
}
export { ValidatedInput }

It's based on Kent's FastInput.

Learn useActionState quickly with an example (Next.js 15)

Alex Booker — Sat, 16 Nov 2024 17:42:08 +0000

When using a form, the useActionState manages state by automatically updating a state variable with the value returned from the server action. This is particularly helpful for rendering input field validation errors, as shown in the example below using Zod.

form.tsx:

"use client";

import { useActionState } from "react";
import { signUp } from "../actions";

export default function SignUp() {
  const [state, action] = useActionState(signUp, {});

  return (
    <form action={action}>
      <div>
        <label htmlFor="username">Username:</label>
        <input
          type="text"
          id="username"
          name="username"
          defaultValue={state.username}
          required
        />
        {state.errors?.username && (
          <p className="text-sm text-red-500">{state.errors.username}</p>
        )}
      </div>

      <div>
        <label htmlFor="password">Password:</label>
        <input
          type="password"
          id="password"
          name="password"
          defaultValue={state.password}
        />
        {state.errors?.password && (
          <p className="text-sm text-red-500">{state.errors.password}</p>
        )}
      </div>
      <input type="submit" value="Sign Up" />
    </form>
  );
}

actions.ts:

"use server";

import { z } from "zod";

const SignUpSchema = z.object({
  username: z.string(),
  password: z
    .string()
    .min(8, { message: "Be at least 8 characters long" })
    .regex(/[a-zA-Z]/, { message: "Contain at least one letter." })
    .regex(/[0-9]/, { message: "Contain at least one number." })
    .regex(/[^a-zA-Z0-9]/, {
      message: "Contain at least one special character.",
    })
    .trim(),
});

export type SignUpActionState = {
  username?: string;
  password?: string;
  errors?: {
    username?: string[];
    password?: string[];
  };
};

export async function signUp(
  _prevState: SignUpActionState,
  form: FormData
): Promise<SignUpActionState> {
  const username = form.get("username") as string;
  const password = form.get("password") as string;

  const validatedFields = SignUpSchema.safeParse({
    username,
    password,
  });

  if (!validatedFields.success) {
    return {
      username,
      password,
      errors: validatedFields.error.flatten().fieldErrors,
    };
  }

  // process validated form inputs here

  return { username, password };
}

useActionState also returns an isPending property (example) that indicates whether the server action's promise is still resolving.

Reference isPending to temporarily disable form elements, such as a submit button, to prevent users from clicking it multiple times in quick succession before the ongoing action has completed.

useActionState vs useFormAction and useFormStatus

If you’re familiar with useFormAction and useFormStatus, you’ll find useActionState quite similar.

Essentially, it combines the functionality of both hooks and is renamed to reflect that server actions aren't just for forms (you can also use useActionState with buttons and other elements.)

Keep in mind that useFormStatus is deprecated as of Next.js 15 and you should import useActionState moving forward.

5 Best Instant Messaging APIs

Alex Booker — Fri, 09 Feb 2024 12:57:54 +0000

Looking for the perfect instant messaging solution can be a daunting task.

You need a provider that not only supports all the necessary instant messaging features but also offers delivery and scaling guarantees to ensure a smooth chat operation as your business grows.

While it might be tempting to start with a simple solution and see how your needs evolve, underestimating the importance of finding the right provider can be a costly mistake. Switching solutions later requires significant time, resources, and money, not to mention meticulous testing to avoid disruption to your business, which can lead to reputational damage and lost revenue. You need to get it right the first time, and this post is here to help you do exactly that.

We've narrowed it down to just the 5 best instant messaging APIs and SDKs, taking into consideration factors like features, scalability, and price. This way, you can make an informed decision about which provider will work best for your project.

What are instant messaging APIs and SDKs?

Fundamentally, instant messaging APIs and SDKs enable developers to build instant messaging more quickly by managing the infrastructure necessary to send and receive messages in realtime, plus must-have chat features like typing indicators, online indicators, and read receipts.

If you’re wondering how an API and SDK differ in this context, it has to do with how developers interface with said infrastructure.

An API gives developers direct access to the infrastructure through endpoints to send and receive messages, subscribe to typing indicators, and more. Equipped with the nuts and bolts, developers can now implement a chat UI with total flexibility.

An SDK, on the other hand, offers a complete set of development tools, usually including prebuilt chat UI components. By assembling chat “building blocks”, developers can save time up front.

Remember that APIs and SDKs aren’t mutually exclusive, and some providers offer both.

What should you look for in an instant messaging solution?

Instant messaging apps like WhatsApp and Slack have set the bar for instant messaging experiences, and it’s important to find a provider that enables you to deliver the same quality experience.

These are the ten foundational features you have to be able to deliver using your chosen solution, and that you should consider during your evaluation process.

Low Latency: If messages take too long to send or load, users won’t have a smooth user experience and will take the conversation elsewhere. That could be another channel (for example, a customer might pick up the phone and start their support request from scratch) or, if the experience is consistently laggy, users might even switch to another app.
The ability to scale: As your user volume grows, the load on the server also increases. If the server can’t handle this increased load, messaging features can become unresponsive, causing a poor user experience.
Reliability: Even a short downtime or an occasional error can be frustrating for users. This is unfortunate, but for businesses that rely on chat applications for customer support or sales, downtime can result in lost revenue or missed opportunities.
Guaranteed delivery: Messages should be delivered exactly once and in the correct order, even in the face of network issues. Otherwise, messages might come flying in out of order, and more than once, making it almost impossible to discern what is trying to be communicated.
Elasticity: Instant messaging app usage can be unpredictable. Applications may experience sudden spikes in usage during peak hours or events, or during product launches and marketing campaigns. If the server can’t scale its resources up dynamically in response to changes in user demand, chat features may become unresponsive.
Rich features: Your users will expect typing indicators, online status indicators, read receipts, push notifications, and more. If users can’t accomplish what they need to with your chat, they might switch to another app where they can.
Integrations: Instant messaging solutions need to integrate with the other tools in your tech stack. Dedicated integrations between technologies can help keep engineering requirements to a minimum.
Data governance: The way data is stored, processed, and disposed of needs to meet regulatory requirements, wherever you operate.
Chat moderation: Messaging experiences need to be safe for both end users and chat operators. The process of monitoring and controlling user-generated messages helps ensure compliance with your terms of use.
Frontend UI: Customizable themed components including colors and fonts help to keep your chat solution a cohesive part of your customer experience.

Another key consideration when evaluating a live chat solution is, of course, cost.

Most instant messaging API providers base their pricing on the number of monthly active users (MAUs). Some also account for additional factors like the number of messages and concurrent users.

While it might be hard to predict your precise usage up front, you should evaluate how a given provider’s pricing model might scale for your project. For example, some pricing models get gradually more expensive as you grow, while others hit an inflection point.

Now that we’ve covered the fundamentals, let’s look at the 5 best instant messaging APIs on the market.

The 5 best instant messaging APIs and SDKs

1. Ably

Ably is a realtime experience infrastructure used by companies like HubSpot, I7Live, and Riff to build feature-rich and reliable chat.

With the Ably API, you get the nuts and bolts needed to implement chat your way. For example, publish and subscribe functions to send and receive messages in a 1:1 or group setting, as well as additional data like which users are typing. Ably also provides other essential features, including presence to see who’s online, message history, and push notifications, and they all work cross-platform, enabling you to deliver a consistent experience across the web, Android, and iOS.

Whether it's a fundamental feature like threads, a contact book that needs to integrate with your database, or even live stream chat with donations, Ably's flexibility extends beyond customization options, allowing you to create engaging chat experiences beyond what's typically possible. Further, because you’re building on the Ably platform, you’ll benefit from low latency, guaranteed message ordering, and an assuring 99.999% average uptime SLA.

Although the nuts and bolts provided by Ably are perfect for chat, they’re not limited to chat alone. That’s great news because once you get started with Ably, you can use the same foundations to build other realtime features, including notifications, and realtime collaboration.

2. Twilio

Twilio is a communication platform with a suite of products designed to help developers code communication features like SMS, email, video, and - you guessed it - instant messaging.

Their chat product is called Conversations API and it’s unique because it’s specifically designed to enable omni-channel messaging.

Suppose your project revolves around connecting members from your team with customers. With Conversations API, the customer can start a conversation in-app then continue it on WhatsApp, for example. Twilio helps connect the dots, creating a seamless omni-channel experience on both sides.

Although Conversations API could be adapted to enable your users to chat together, that isn’t really the intended use case. As a result, Conversations API offers a limited chat feature set compared to some alternative solutions. For example, you can’t use Twilio to implement public group chat, and they don't support @user and @channel mentions or reactions.

3. Firebase

Firebase is an app development platform backed by Google that famously replaces the need for a backend. It accomplishes this by providing developers with a variety of services, including authentication, push notifications, and a database called Cloud Firestore that can be adapted to store and broadcast chat messages in realtime.

Firebase can be an attractive option because it manages all of your backend services in one place. These services are meant to gel well together, and it should therefore be smooth to implement user management, roles and permissions, chat history, and even push notifications under the roof of one platform. Of course, this might not be so compelling if you already have a backend and user management system. In that case, you’ll probably want to assess how you’ll keep Firebase and your systems in sync instead.

Remember, since Firebase is a general-purpose platform, it doesn’t have a specific notion of instant messaging. While implementing basic messaging might be fairly straightforward, expect to invest a significant amount of upfront development to get features like typing indicators, read receipts, and presence indicators to work, especially without a hitch at scale.

4. Sendbird

Sendbird Chat enables developers to implement chat and instant messaging by providing an SDK with ready-made chat UI components. They cover all the essential features you might expect, including voice and video, which makes it possible to deliver a comprehensive experience.

This out-of-the-box experience enables developers to “turn on” chat quickly, albeit at a recurring monthly premium. A common concern about Sendbird is that, beyond a certain scale, their pricing becomes somewhat opaque. This can make it hard to calculate precisely how much you’ll pay, especially if you’re dealing with a high number of users and traffic spikes.

Under the hood, Sendbird manages the chat infrastructure necessary to send and receive messages in realtime while ensuring that messages are stored securely and compliant with relevant standards like SOC 2 and HIPAA.

It should be noted that although Sendbird touts eight available data centers, each app must reside in a single data center, creating a single point of failure. Moreover, this can negatively impact latency, unless your users happen to be connecting from the same geographical region.

5. Stream (formerly GetStream)

Stream provides APIs and chat UI components that developers can use to implement instant messaging into their web and mobile applications.

They make it possible to build chat experiences with rich features like typing indicators, user presence, threaded conversations, push notifications, message & user moderation, reactions, plus @user and @channel mentions. In other words, everything you need for a modern chat experience.

All the infrastructure is managed for you. However, all traffic is processed and stored in a single data center. This can have a negative implication on latency and creates a single point of congestion and failure. This might explain why Stream only offers a 99.95% SLA unless you pay more for an enterprise plan.

It’s worth noting that instant messaging often goes hand-in-hand with other realtime use cases, such as multiplayer collaboration (think of a product like Figma, where you can edit your design collaboratively and chat with other users in realtime). However, Stream is very much a chat-centric solution. If you’re looking to build other realtime experiences alongside your messaging functionality, Stream can’t help – you will have to use different technologies, which brings additional complexity and increased costs to your project.

Which is the best instant messaging solution for your use case?

Like everything in software, the answer is “it depends” - on the features you need, how you envision your users engaging with your app, and on if you want to save time up front with a turn key solution at the cost of flexibility later. It’s critical to try and answer these questions early on so you don’t end up locked-in with a vendor, or with a solution that is great for chat but forces you to source another solution to implement other realtime features like presence indicators, multiplayer collaboration (a la Figma), collaborative whiteboarding, and collaborative text editing.

Although we might be biased, if you are looking for a solution that can support you now - as you integrate chat - and as you scale, and introduce new features, we recommend trying Ably for free (no credit card required). Our free plan includes:

6M monthly messages
200 peak concurrent channels
200 peak concurrent connections

As a realtime Platform as a Service (PaaS), Ably gives you the infrastructure and tooling to build featureful in-app chat with no scale ceiling, low latency, predictable pricing, and 99.999% SLA. The best part? A new realtime feature doesn't require you to rebuild your entire back end or code against a brand-new API.

Whether it's a fundamental shift in how your product works, such as implementing multiplayer collaboration, or you want to enhance the experience through a feature such as in-app messaging, Ably makes it easy to get started thanks to integrations with almost every popular programming language and a free developer account.

Essential guide to WebSocket authentication

Alex Booker — Wed, 13 Dec 2023 14:15:46 +0000

Authenticating WebSocket connections from the browser is a lot trickier than it should be.

Cookie authentication isn’t suitable for every app, and the WebSocket browser API makes it impossible to set an Authorization header with a token.

It’s actually all a bit of a mess!

That is the last thing you want to hear when it comes to security, so I’ve done the research to present this tidy list of methods to send credentials from the browser.

The challenge with WebSocket authentication

Even though WebSocket and HTTP are completely separate protocols, every WebSocket connection begins with a HTTP handshake.

The WebSocket specification does not prescribe any particular way to authenticate a WebSocket connection once it’s established but suggests you authenticate the HTTP handshake before establishing the connection:

This protocol doesn’t prescribe any particular way that servers can authenticate clients during the WebSocket handshake. The WebSocket server can use any client authentication mechanism available to a generic HTTP server, such as cookies or HTTP authentication.

HTTP has dedicated fields for authentication (like the Authorization header), and you likely have a standard way to authenticate HTTP requests already so this makes a lot of sense on the surface!

Surprisingly, though, the WebSocket browser API doesn’t allow you to set arbitrary headers with the HTTP handshake like Authorization. 😱

HTTP cookie authentication is an option, but, as you will see in this post, it’s not always suitable, and potentially even vulnerable to CSRF.

In this post, I’ll outline your options to work around this remarkable limitation of modern browsers to securely and reliably send credentials to the server.

Authentication methods for securing WebSocket connections

Send access token in the query parameter

One of the simplest methods to pass credentials from the client to a WebSocket server is to pass the access token via the URL like this:

wss://website.com?token=your_token_here

Then, on the server, you can authenticate the request.

Here’s an example with Node:

import { createServer } from 'http'
import { WebSocketServer } from 'ws'
import { parse } from 'url'

const PORT = 8000
const server = createServer()
// noSever: Tells WebSocketServer not to create an HTTP server 
// but to instead handle upgrade requests from the existing 
// server (above).
const wsServer = new WebSocketServer({ noServer: true })

const authenticate = request => {
    const { token } = parse(request.url, true).query
    // TODO: Actually authenticate token
    if (token === "abc") {
        return true
    }
}

server.on('upgrade', (request, socket, head) => {

    const authed = authenticate(request)

    if (!authed) {
        // \r\n\r\n: These are control characters used in HTTP to
        // denote the end of the HTTP headers section.
        socket.write('HTTP/1.1 401 Unauthorized\r\n\r\n')
        socket.destroy()
        return
    }

    wsServer.handleUpgrade(request, socket, head, connection => {
        // Manually emit the 'connection' event on a WebSocket 
        // server (we subscribe to this event below).
        wsServer.emit('connection', connection, request)
    })
})

wsServer.on('connection', connection => {
    console.log('connection')

    connection.on('message', bytes => {
        // %s: Convert the bytes (buffer) into a string using
        // utf-8 encoding.
        console.log('received %s', bytes)
    })
})

server.listen(PORT, () => console.log(`Server started on port ${PORT}`))

If the token is valid, you move ahead with the upgrade. Otherwise, send a standard 401 “Unauthorized” response code and close the underlying socket.

This approach is easy to reason about and it only takes a few lines of code to implement on the client.

The downside we need to explore is the security implication of encoding the token in the query string in this way.

Some developers on public forums will argue this isn’t so bad:

When you use TLS (WSS), query strings are encrypted in transit.
Compared to HTTP, WebSocket URLs aren’t really exposed to the user. Users can't bookmark or copy-and-paste them. This minimizes the risk of accidental sharing.

However, it is important to acknowledge query parameters will still show up in plaintext on the server where they will likely get logged.

Even if your code doesn’t, the framework or cloud host likely will.

This is precarious because logs leak can error messages, for example (accidental information disclosure).

Should a malicious actor attain access to the logs, they would have access to all the data and functionality that the user behind the WebSocket connection has.

In the next section, let’s explore an evolution of this method that’s more secure, albeit more work to implement.

Send an ephemeral access token in the query parameter

As we covered in the section above, sending your main access token in the query parameter is not sufficiently secure because it might be logged in plaintext on the server.

To dramatically reduce the risk, we could use the main access token to request an ephemeral single-use token from an authentication service then send that short-lived token the query parameter.

This way, by the time the token is logged on the server, it will likely be useless since it will either have already been used or expired.

The basic flow can be illustrated like this:

While inherently more secure than sending the main access token, you now need to implement a custom and stateful authentication service specifically for WebSockets, which is a pretty significant downside considering we first started exploring sending the token in the query parameter because of its convenience!

Send access token over WebSocket

Another option to authenticate a WebSocket connection is to send credentials in the first message post-connection.

The server must then validate the token before allowing the client to do anything else.

Here’s a contrived server implementation I wrote with Node to illustrate the model:

import { WebSocketServer } from 'ws'
import { createServer } from 'http'
import { randomUUID } from 'crypto'

const server = createServer()
const wsServer = new WebSocketServer({ server })

const PORT = 8000
const connections = {}

const authenticate = token => {
    // TODO: Actually authenticate token
    if (token === "abc") {
        return true
    }
}

const handleMessage = (bytes, uuid) => {
  const message = JSON.parse(bytes.toString())
  const connection = connections[uuid]

  if (message.type === "authenticate") {
    connection.authenticated = authenticate(message.token)
    return
  }

  if (connection.authenticated) {
    // Process the message
  } else {
    connection.terminate()
  }
}

const handleClose = uuid => delete connections[uuid]

wsServer.on('connection', (connection, request) => {
  const uuid = randomUUID()
  connections[uuid] = connection

  connection.on('message', message => handleMessage(message, uuid))
  connection.on('close', () => handleClose(uuid))
});

server.listen(PORT, () => console.log(`Server started on port ${PORT}`))

If the token is invalid, the server terminates the connection. Otherwise, the it tracks the connection as “authenticated” and processes subsequent messages.

When implemented correctly, this method is completely secure, however, it involves defining your own custom authentication mechanism protocol securely and correctly.

Sending credentials over WebSockets in this way has some other downsides:

Implementing a custom stateful protocol will increase complexity. The example above looks simple but in reality you now need to manage session lifetimes, handle synchronization issues when you scale, and deal with potential inconsistencies. Should something go wrong, your users might not be able to login or, worse yet, you might introduce a security vulnerability.
You become vulnerable to DOS attacks. With this method, anyone can open a WebSocket connection. An attacker might open a bunch of WebSocket connections and refuse to authenticate, tying up server resources like memory indefinitely, potentially overloading your server until it becomes sluggish. To counteract this, you’ll need to implement rigorous timeouts, further contributing to the complexity compared to HTTP-based authentication methods.

Send credentials in a HTTP cookie

The WebSocket handshake is done with a standard HTTP request and response cycle, which supports cookies, allowing you to authenticate the request.

Authentication using cookies has been widely adopted since the early days of the internet. It's a reliable method that offers security you can trust. However, there are some limitations you should be aware of:

Not suitable if your WebSocket server is hosted on a different domain. If your WebSocket server is on a different domain than your web app, the browser will not send the authentication cookies to the WebSocket server, which makes the authentication fail.
Vulnerable to CSRF. The browser does not enforce a Same-Origin Policy for the WebSocket handshake like it would an ordinary HTTP request. A malicious website badwebsite.com could open a connection to yourwebsite.com and the browser will happily send along the authentication cookie, creating an opportunity for badwebsite.com to send and receive messages on the user’s behalf, unbeknown to them. To circumvent this, it’s pivotal the server checks the Origin header of the request before allowing it. Alternatively, you may choose to implement a CSRF token.

Send credentials with the Sec-WebSocket-Protocol header

While the WebSocket browser API doesn’t let you set arbitrary headers like Authorization, it does allow you to set a value for the Sec-WebSocket-Protocol header, creating an opportunity to smuggle the token in the request header!

In vanilla JavaScript, the client WebSocket code might look like this:

const ws  = new WebSocket(
  "wss://example.com/path", 
  ["Authorization", "your_token_here"]
)

And with a library like React useWebSocket, something like this:

const { sendMessage, lastMessage } = useWebSocket("wss://example.com/path", {
  protocols: ["Authorization", "your_token_here"]
})

The Sec-WebSocket-Protocol header is designed to negotiate a subprotocol not carry authentication information but some developers including me and those behind Kubernetes are asking “why not?"

You might be wondering what the downside of this neat workaround is. Every option in this list so far has a downside, and setting Sec-WebSocket-Protocol is no exception:

The token might get logged in plaintext on the server. Because Sec-WebSocket-Protocol is not designed to carry authentication tokens, they may end up in log files unintentionally as part of standard logging of WebSocket protocol negotiation, thus causing potential security risks.
You might experience unexpected behavior. It’s also important to acknowledge that such use of Sec-WebSocket-Protocol isn't standardized, meaning libraries, tooling, and middleware might not handle this kind of logic gracefully. For simple apps, this is unlikely to cause a problem, however, in a sufficiently complex system with multiple components, this could cause unexpected behavior including security issues.

Send credentials with basic access authentication

Some posts out there suggest an outdated trick whereby you encode the username and password in the WebSocket URL:

const ws = new WebSocket("wss://username:password@example.com")

Under the hood, the browser will pull these out to add a basic auhtenticaiton access header.

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ==

Apart from the fact that basic authentication is limited to a username and password (and you probably want to send a token), this method has always suffered from inconsistent browser support and is now totally deprecated.

Don’t use it. I’m only including a brief note about it here for completeness.

Forget about WebSocket authentication (mostly) with Ably

So far we’ve weighed the benefits and limitations of each approach however, you could just use a library that handles it all for you under the hood.

With Ably, authentication is a solved problem.

Ably is a realtime infrastructure API that makes it trivial to add realtime features to your apps compared to if you used WebSockets directly.

Apart from being easy to get started with, Ably handles authentication for you in a secure way, allowing you to focus on the features that really matter to your users.

Instead of deliberating the best authentication mechanism and burdening all that responsibility even if you’re not a security expert, Ably provides you with “white spots” to fill in with code that connects to your database to authenticate the user.

The token management part, including refresh tokens and permissions, is all handled for you.

Learn more about how Ably can help you build impressive realtime features at scale here or create a free account and play around for yourself.

Conclusion

In this post, we explored several methods to send credentials from the web browser to a WebSocket server.

It would have been nice if I could recommend one go-to method but, as will now be evident to you, each method has advantages and disadvantages that must be considered relative to your project.

Here’s a quick summary for future reference:

Query parameter: Sending the credentials in a query parameter is dead easy, but it introduces a risk of the credentials being logged in plaintext on the server, and that could be risky! A homemade authentication service that issues ephemeral tokens for use in the query parameter would improve the security greatly, however, for many, that is a bridge too far.
WebSocket connection: Sending the credentials over the WebSocket connection is worth considering, however, you usually end up implementing your own authentication protocol that is finicky to maintain, potentially vulnerable to DOS attacks, and doesn’t play well with anything else.
Cookies: Cookie authentication is attractive due to its reliability and ease of implementation. However, it may not be compatible with your system design.
Sec-WebSocket-Protocol: Smuggling the token in the Sec-WebSocket-Protocol is a stroke of genius, and, if it’s good enough for Kubernetes, it might be good enough for you! At the same time, misusing the header in this way might lead to unexpected behavior. User BatteryAcid on StackOverflow summed it up pretty well when they wrote - "I implemented this and it works - just feels weird. thanks" 😂

Of course, if this all sounds like a headache, you might consider Ably. Apart from solving the authentication problem, Ably provides additional features you’d need to implement on top of WebSockets like Presence and message queues, and provides production guarantees that will be time-consuming or costly to achieve on your own like 99.999% uptime guarantee, exactly-once delivery, and guaranteed message ordering.

What is WebTransport and can it replace WebSockets?

Alex Booker — Mon, 27 Nov 2023 11:03:18 +0000

WebTransport is a new specification that could offer an alternative to WebSockets.

For applications that need low latency, event-driven communication between endpoints, WebSockets has been the go-to choice, but WebTransport may change that.

In this article, you’ll learn what WebTransport offers and how it differs from WebSockets. You’ll also learn when—and if—you should make the switch.

WebSockets vs WebTransport, at a glance

WebSockets is a technology that enables bidirectional, full-duplex communication between client and server over a persistent, single-socket connection. This allows for low-latency, realtime updates, and the creation of richer communication and gaming applications. Previously, the web was dependent on requests and responses, which aren’t dynamic enough for those kinds of apps.

The newer WebTransport offers secure, multiplexed, realtime transport and already has APIs for sending data both reliably and unreliably.

In a reliable data transfer, the sender is notified of the success or failure of the data transmission, and failed transmissions are usually resent until they succeed, after which the next data packet is sent. In unreliable transfer, there’s no confirmation of transmission success, and packets that aren’t received simply don’t get delivered. Unreliable transfer is often used for things like streaming videos, where speed is a concern, and minor data loss, such as a few frames of video, is acceptable. Because WebTransport uses both of these methods, there are many use cases for it, such as bidirectional data streaming for multiplayer gaming, interactive live streams, and data transfer for sensors and internet of things devices.

While WebSockets creates a single stream per connection, WebTransport allows you to create multiple streams over a single connection. It avoids the head-of-line blocking delays that WebSockets suffers from, and is less resource intensive when creating connections. While WebSockets starts as a HTTP/1.1 protocol, WebTransport works on top of several different protocols, including some that WebSockets don't support.

It works with HTTP/3, the upcoming version of the transport protocol used by the World Wide Web. HTTP/3 uses the QUIC protocol for transport layer data exchange, which has several advantages. QUIC can prevent head-of-line blocking delays, improving network performance in many situations. This is a limitation of WebSockets.

With WebTransport, you can also use features like promises and the await keyword for asynchronous functions. The API runs in Web Workers, too, enabling multithreading.

Here’s an example of an async function from the WebTransport Working Group’s documentation.

async function sendData(url, data) {
    const wt = new WebTransport(url);
    const writable = await wt.createUnidirectionalStream();
    const writer = writable.getWriter();
    await writer.write(data);
    await writer.close();
}

The WebTransport working group is still hammering out the details of the specification, so more features and capabilities may come.

4 WebTransport use cases

There are many potential use cases for WebTransport. Let’s look at four where it shines.

1. Encrypted streaming

WebTransport’s streams API allows you to create connections for sending ordered data. As WebTransport uses the QUIC protocol, these connections are less resource intensive to open and close than with TCP used by WebSockets.

You can also do things like offer streaming media more securely. WebTransport has several security measures in place, such as requiring use of the Origin header as well as specific opt-in via a transport parameter.

2. Communication

WebTransport can send multiple types of data over the same connection. That means you can send and receive video information unreliably while sending text or file data reliably.

This feature allows you to do more with each connection, leading to richer communication between a greater number of simultaneous users. It means that you can send different types of content on different channels, so something like a large image could be sent over a different connection than other data, which would mean that the image can’t block chat communication.

You can also create bidirectional streams that allow either the server or client to initiate communication, so if you’re implementing a messaging system, data exchange can happen quickly.

3. Multiplayer gameplay

WebTransport works with the HTTP/2, HTTP/3, and QUIC protocols. It can receive data out of order over HTTP and can request data itself or listen to data that is pushed by the server. It can do this both reliably and unreliably.

With WebTransport’s bidirectional streams, data pushed by the server has very low latency, which is a big advantage for game development. It means less delay between user input and the response, which can be critical in action games, such as shooting, driving, or fighting.

It can also improve response times for cloud gaming services, where the server handles rendering and gameplay and streams video to a thin client, which passes back user input to the server.

4. Sensor data

Many Internet of Things (IOT) devices log data that needs to be transferred to a server, and a potential use of WebTransport is having a low-latency method for transferring this. IOT devices often send small amounts of data regularly. Consuming fewer resources has advantages for both the battery life of the devices and with regard to network congestion.

As the IOT grows, the large number of devices in use consuming an ever-increasing number of connections could become a problem, so the more lightweight those devices are, the better.

Can you use WebTransport?

Now let’s look at what specific features and capabilities WebTransport offers. The specification is still at the public draft stage but is fully usable.

In addition to the QUIC protocol, there’s an API that lets browsers control streams and datagrams. The API is HTTPS only, enforcing security.

QUIC

QUIC is a transport protocol designed to replace TCP and improve web performance. It uses UDP, and HTTP/3 is designed to take advantage of it. When using HTTP/3 over QUIC, it’s faster to establish connections, and congestion control feedback is available to help avoid problems. As mentioned previously, QUIC also prevents head-of-line blocking.

It doesn’t require as much header information, which allows lightweight communication—without the overhead of HTTP. It’s also hardware independent, with support required only at the application level.

QUIC is already widely supported in browsers and applications. Currently 7.7% of websites use it, but the figure is increasing steadily.

If you want to experiment with QUIC in Chrome and many other Chromium-based browsers, you can activate it in the settings.

Type chrome://flags in the URL bar, then find the Experimental QUIC protocol setting and enable it, as in the screenshot below. (For Chromium-based browsers, simply replace chrome://flags with [browser name]://flags.)

Other protocols

WebTransport can also run on top of either HTTP/2 or HTTP/3 without QUIC. It can also use HTTP/2 as a fallback, allowing you to take advantage of the benefits of WebTransport, regardless of the network.

HTTP/2 compatibility could potentially let you run it on older setups that don’t support HTTP/3 and lets you take advantage of features like resource prioritization.

Datagrams

WebTransport works primarily with datagrams and streams. A datagram is a self-contained packet of data that can arrive in any particular order. Datagrams are sent unreliably. Unreliable data can be sent at high speed, and the connection can cope if some data is dropped. The WebTransport specification allows you to limit the datagram size using the maxDatagramSize attribute.

WebTransport objects have a datagrams object that can be accessed via its readable and writable attributes. Datagrams can be queued, and you can also create promises to wait for datagram transmission.

The WebTransport objects also include state data, indicating whether they are connecting, connected, closed, or failed. They also include promises indicating if the object is ready or closed.

Streams

Streams allow you to send ordered, reliable data. You can establish a stream and have the server push this content to the client. It allows low-latency, real-time communication.

In the API, WebTransport objects have slots for further objects representing different types of stream. These include SendStream, ReceiveStream, and Bidirectional Stream objects, all defined in the working draft of the specification.

WebTransport also allows multistream data to be sent in a partially reliable manner. Sent like this, data is not guaranteed to arrive in the right order overall but is ordered by the status of other related streams. This works well when sending video frames.

With streams, you can also pipe received data into a handler, such as a TextDecoderStream that converts it into a format readily usable by your application.

SendStream

SendStream objects are a kind of WritableStream used for outgoing data. They store stream objects, but a SendStream object also contains a promise, which defines an action it will take, such as being closed or aborted.

SendStream objects also include a slot to attach them to the HTTP/3 transport layer.

ReceiveStream

ReceiveStream objects are a kind of ReadableStream that handles incoming data.

The ReceiveStream object is structured similarly to the SendStream objects, with a stream slot and transport slot. It doesn’t, however, include promises.

Bidirectional stream

The bidirectional stream combines the send and receive streams into a single object, which allows you to manage two-way communication in one place. Objects have a readable and writable property, corresponding to the ReceiveStream and SendStream objects discussed above.

These properties let them work with data sent in either direction. You read the incoming stream and write to the outgoing stream.

Unidirectional streams

You can also create unidirectional streams. IncomingUnidirectionalStreams are ReadableStreams consisting of multiple ReceiveStreams. You can call createUnidirectionalStream() to create an outgoing equivalent.

Could WebTransport replace WebSockets?

The WebTransport specification is still in flux, but its future looks bright. As it continues to take shape, we’re sure to see more developers adopt it and utilize the new features it brings.

Early adopters stand to reap big rewards but also take the biggest risks as it isn’t clear how fully the specification will deliver on its promises. We don’t know how well browsers will support it, how likely developers are to adopt it, or how it will evolve.

WebTransport has advantages in some use cases, such as low-latency scenarios and reusing connections for multiple purposes. It isn’t a silver bullet, though, and there are scenarios where WebSockets will still be the best choice—or at least a perfectly good one.

As a new specification, WebTransport is still nascent, so it will be harder to get working until other tools are updated to work with it. For now, that means keeping eyes and minds open and being ready to adapt.

WebSockets still offer a great deal of functionality, and as an established standard, are fully supported by all modern browsers. WebTransport should offer modest performance improvements and incremental gains, but will also likely create new engineering challenges that will have to be addressed to build production-ready systems.

Does Ably support WebTransport?

At Ably where we offer a realtime communication API used by developers to build experiences like chat, multiplayer collaboration, and other live updates in your web and mobile applications at scale. Under the hood, we build on lower-level communication protocols to enable features like online presence, message history, queues, and more. Most developers use Ably with WebSocket transport, but we also support HTTP, SSE, and MQTT. Our community sometimes wonders - is Ably currently exploring WebTransport? And the answer is yes, but until the future of WebTransport is more certain, we’re focused on WebSockets.

If you are looking to implement reliable realtime messaging in your application, I encourage you to give Ably a try!

Conclusion

WebTransport is already a viable alternative to WebSockets, with several advantages. The lack of head of line blocking, slightly lower latency, and versatility of the multi-protocol approach offer benefits in many scenarios.

As the technology is not fully defined yet, the tooling is less developed, and will be for a while. On the other hand, the API is usable, and the opportunity is there to be the quickest to market with products that benefit from its strengths.

It’s too early to predict what WebTransport will be used for, but the first teams to use it have every chance to build something groundbreaking.

Though there’s no urgent need to switch, developers should keep an eye on it for future projects and be ready to use it if it’s the best fit.

The complete guide to WebSockets with React

Alex Booker — Tue, 31 Oct 2023 12:04:12 +0000

In this post, you’ll learn more than you ever thought you needed to know about WebSockets with React, including how to build a smooth realtime cursor experience from scratch:

Jump into the tutorial which uses React on the front and Node on the back or start with some general guidance when it comes to WebSockets with React below.

What are WebSockets?

WebSockets are a communication protocol that enable bidirectional communication between applications.

They are a great choice when two-way communication is needed such as chat and multiplayer collaboration.

Additionally, WebSockets are well-suited when you need to push fresh data from the server as soon as it’s available - like live sports score updates, updates on a package delivery, or perhaps realtime chart data.

Because they are full-duplex, information can flow in both directions simultaneously, making WebSockets an attractive option for high throughput scenarios like an online multiplayer game as well.

Wondering how WebSockets compare to alternative realtime transports like Server-Sent Events (EventSource)? I wrote all about that here.

How WebSockets work

Unlike HTTP where requests are short-lived, WebSockets enable realtime communication using a long-lived stateful connection.

Once the connection is established, it remains open until either side closes the connection.

Because these connections are long-lived you don’t want to open more than necessary as not to cause memory problems. And since one WebSocket connection has plenty of bandwidth, it’s common practice to use one connection for all your messages (a technique called multiplexing).

This leads to some interesting questions like “where should I put my connection in React?” and “how do I clean up the connection?”, both of which I will answer in this post.

WebSockets and React

WebSockets have a Web API accessible in all major web browsers, and since React is “just JavaScript” you can access it without any additional modules or React-specific code:

const socket = new WebSocket("ws://localhost:8080")

// Connection opened
socket.addEventListener("open", event => {
  socket.send("Connection established")
});

// Listen for messages
socket.addEventListener("message", event => {
  console.log("Message from server ", event.data)
});

There is no specific React library needed to get started with WebSockets, however, you might benefit from one.

The simple and minimal WebSocket API gives you flexibility, but that also means additional work to arrive at a production-ready WebSocket solution.

When you use the WebSocket API directly, here are just some of the things you should be prepared to code yourself:

Authentication and authorization.
Robust disconnect detection by implementing a heartbeat.
Seamless automatic reconnection.
Recovering missed messages the user missed while temporarily disconnected.

Instead of reinventing the wheel, it’s usually more productive to use a general WebSocket library that provides the features listed above out of the box - this allows you to focus on building features unique to your application instead of generic realtime messaging code.

Best React WebSocket libraries

Before we look at some WebSocket libraries, it’s helpful to distinguish React and JavaScript in this context.

Since React is “just JavaScript”, you might not necessarily need a React-specific WebSocket library.

That being said, it would definitely be a plus if the WebSocket library had idiomatic React functions available such as ready-made React hooks!

There’s a bunch of WebSocket libraries out there (many of them outdated) so we previously wrote a post showing you only the best WebSocket libraries for React.

Here’s the summary:

React useWebSocket: A thin layer on top of the WebSocket API that features automatic reconnection and a fallback to Server-Sent Events (as long as you’ve coded support on your server). This library is specifically made for React, so it’s very natural to utilise the useWebSocket hook and all its options. The downside is that useWebSocket might not have all the features and reliability guarantees you need in production. Learn more.
Socket.IO: A JavaScript realtime messaging library based on WebSockets with an optional fallback to HTTP long polling in case the WebSocket connection can’t be established. Socket.IO has more features than useWebSocket, but it’s not specific to React, and there’s still work to do to ensure good performance and reliability in production. Learn more.
React useWebSocket with Socket.IO: useWebSocket actually works with Socket.IO, meaning you might be able to use them together in your React project. I haven’t tested this extensively, but it looks promising!
Ably: A realtime infrastructure platform featuring first-class React client support. With useWebSocket or Socket.IO, you need to host your own WebSocket server. That sounds simple enough, but it’s actually a big burden to manage your own WebSocket backend. With Ably, you create an account, and all the messages route through the Ably global infrastructure with the lowest possible latency. Instead of worrying about uptime or if your messages will be delivered exactly-once and in the correct order, you can just plug into the React hook and focus on building the features that actually matter to your users. Learn more.

React WebSocket best practices

When using WebSockets with React, they become an important channel for new information to flow. Ideally, any component that needs to should be able to send and receive data using the shared connection.

At the same time, you don’t want to create a mess by prop drilling, or introduce brittleness by making the WebSocket accessible to every component. When you do that, you violate encapsulation, meaning any component can alter the WebSocket object, potentially causing unexpected behavior elsewhere in the code.

When I was learning about WebSockets in React, this caused me a bit of anxiety! I went looking for a definitive best practice but, as it happens, there isn’t a universal “right” answer. It depends on what you’re building and the specific shape of your application.

In the next section, I’ll share what I wish I had - a tour of the options to structure your WebSocket React code, with some considerations for and against (plus, some best practices).

Where do I put the WebSocket in React?

Should you put the connection in a component, use context, create a hook, or something else entirely?

Here’s what you need to know.

Use the useWebSocket hook

While there are advantages to managing the connection yourself, for most of us, all of our “WebSockets-with-React” answers are but an npm install away.

useWebSocket is an open source module with 1.2K stars (so you know it’s popular), and it provides a well-thought-out hook to establish a WebSocket connection and manage the connection lifecycle.

Here is an example of it in action:

import useWebSocket, { ReadyState } from "react-use-websocket"

export const Home = () => {
  const WS_URL = "ws://127.0.0.1:800"
  const { sendJsonMessage, lastJsonMessage, readyState } = useWebSocket(
    WS_URL,
    {
      share: false,
      shouldReconnect: () => true,
    },
  )

  // Run when the connection state (readyState) changes
  useEffect(() => {
    console.log("Connection state changed")
    if (readyState === ReadyState.OPEN) {
      sendJsonMessage({
        event: "subscribe",
        data: {
          channel: "general-chatroom",
        },
      })
    }
  }, [readyState])

  // Run when a new WebSocket message is received (lastJsonMessage)
  useEffect(() => {
    console.log(`Got a new message: ${lastJsonMessage}`)
  }, [lastJsonMessage])

  return <Chat lastJsonMessage={lastJsonMessage} />
}

Apart from providing an idiomatic abstraction, useWebSocket also has some handy options like share.

When set to true, useWebSocket will share the connection to the same endpoint no matter where you call the hook.

This makes it straightforward to reuse the connection from different instances of the component and generally access the WebSocket anywhere you need.

Note - there is no need to cleanup the WebSocket connection since useWebsocket does that for you when the component unmounts. Very handy!

In the top-level component

In the previous section, we looked at how a third-party module called useWebSocket can help.

In case you don’t want to depend on a library, next let's explore how to manage the WebSocket instance directly with idiomatic React code.

For simple applications, it’s perfectly appropriate to open the WebSocket connection directly in the top-level component and utilize useRef (useMemo will also work) to hold on to the connection instance between renders:

export const Home = () => {
  const connection = useRef(null)

  useEffect(() => {
    const socket = new WebSocket("ws://127.0.0.1:800")

    // Connection opened
    socket.addEventListener("open", (event) => {
      socket.send("Connection established")
    })

    // Listen for messages
    socket.addEventListener("message", (event) => {
      console.log("Message from server ", event.data)
    })

    connection.current = ws

    return () => connection.close()
  }, [])

  return <Chat />
}

As a best practice, subscribe to the WebSocket events from the top-level component, update top-level state in response to new events, and pass the state down as a prop.

While it might be tempting to pass the WebSocket object down as a prop so you can attach event handlers or call send directly, that could become hairy compared to managing your WebSocket connection in one place.

In the likely event a child component needs to send data, you can pass a callback function.

Context API

If you have a lot of components in your component hierarchy and many of them need access to the WebSocket, passing props from the top-level component can become really unwieldy really quickly.

Context is a React feature specifically invented to solve this problem.

It provides a way to share data through the component tree without having to pass props down manually from parent to child component and is perfect for state that’s considered “global” in the application, such as the current authenticated user, theme, preferred language, or - you guessed it - a WebSocket connection.

Here is an example of a WebSocket Context provider, borrowed from Kian Musser who wrote a very good post on the subject:

export const WebsocketContext = createContext(false, null, () => {})
//                                            ready, value, send

// Make sure to put WebsocketProvider higher up in
// the component tree than any consumer.
export const WebsocketProvider = ({ children }) => {
  const [isReady, setIsReady] = useState(false)
  const [val, setVal] = useState(null)

  const ws = useRef(null)

  useEffect(() => {
    const socket = new WebSocket("wss://echo.websocket.events/")

    socket.onopen = () => setIsReady(true)
    socket.onclose = () => setIsReady(false)
    socket.onmessage = (event) => setVal(event.data)

    ws.current = socket

    return () => {
      socket.close()
    }
  }, [])

  const ret = [isReady, val, ws.current?.send.bind(ws.current)]

  return (
    <WebsocketContext.Provider value={ret}>
      {children}
    </WebsocketContext.Provider>
  )
}

And a consumer:

// Very similar to the WsHook component above.
export const WsConsumer = () => {
  const [ready, val, send] = useContext(WebsocketContext); // use it just like a hook

  useEffect(() => {
    if (ready) {
      send("test message");
    }
  }, [ready, send]); // make sure to include send in dependency array

  return (
    <div>
      Ready: {JSON.stringify(ready)}, Value: {val}
    </div>
  );
};

In a custom hook

Hooks in React are what you make of them.

At a minimum, a custom WebSocket hook would provide an idiomatic way to abstract your WebSocket-related code in a single place.

As mentioned earlier, WebSocket is a simple and minimal API and there’s always more work to do on top to achieve a minimum-viable production implementation.

For example, you’ll need a way to detect disconnections and automatically reconnect. Additionally, you may want to associate some state with the connection, like a list of users currently connected (presence).

It would make a lot of sense to abstract that code away in a hook instead of convoluting your components and risking messy code duplication.

Here’s an example from Kian's post:

export const useWs = ({ url }) => {
  const [isReady, setIsReady] = useState(false)
  const [val, setVal] = useState(null)

  const ws = useRef(null)

  useEffect(() => {
    const socket = new WebSocket(url)

    socket.onopen = () => setIsReady(true)
    socket.onclose = () => setIsReady(false)
    socket.onmessage = (event) => setVal(event.data)

    ws.current = socket

    return () => {
      socket.close()
    }
  }, [])

  // bind is needed to make sure `send` references correct `this`
  return [isReady, val, ws.current?.send.bind(ws.current)]
}

And the usage:

export const WsComponent = () => {
  const [ready, val, send] = useWs("wss://echo.websocket.events/")

  useEffect(() => {
    if (ready) {
      send("test message")
    }
  }, [ready, send]) // make sure to include send in dependency array

  return (
    <div>
      Ready: {JSON.stringify(ready)}, Value: {val}
    </div>
  )
}

While hooks are an idiomatic and clean way to share logic between components, they don’t solve the problem where you need to access the WebSocket connection throughout your application. You’d still need to lean on props (or Context) for that.

Alternatively, you could take a page from useWebSocket and implement the singleton pattern, such that the hook only maintains a single connection, regardless of how many times it’s instantiated.

How to use WebSockets with React and Node

We’ve covered the theory behind WebSockets. The aim now is to bring it all together by showing you concrete examples of the fundamentals in action.

What you’ll build

In this tutorial, you will learn how to build a live cursors experience with WebSockets and React:

You will learn how to:

Open a WebSocket connection using useWebSocket.
Send and receive messages.
Implement a “who’s online” feature (presence).
Broadcast messages to every connected client.

Remember, the fundamental ideas in this post can be adapted to work for chat, online updates, or even a full-blown realtime collaborative experience.

If you want to jump ahead and grab the code, please go ahead! It's all on GitHub. Maybe leave a star on the way by?

Implementing the WebSocket server in Node

Every WebSocket application has two components - the server and the client.

Since the client won’t be able to do much until it has a server to connect to, let’s build the server first!

You can implement a WebSocket server in almost any programming language but since React uses JavaScript, we will use Node and the ws module.

Start by creating a new folder called react-websockets-tutorial and a subfolder called server:

mkdir react-websockets-tutorial
cd react-websockets-tutorial
mkdir server
cd server

Making sure you’re inside the server subfolder, run npm init followed by npm install:

npm init -y
npm install –-save ws uuid

npm init creates a package.json file while npm install ws uuid download the modules we’ll need to reference from the code.

After that, create index.js and paste the whole server code. I’ll explain it all below.

const { WebSocketServer } = require("ws")
const http = require("http")
const uuidv4 = require("uuid").v4
const url = require("url")

const server = http.createServer()
const wsServer = new WebSocketServer({ server })

const port = 8000
const connections = {}
const users = {}

const handleMessage = (bytes, uuid) => {
  const message = JSON.parse(bytes.toString())
  const user = users[uuid]
  user.state = message
  broadcast()

  console.log(
    `${user.username} updated their updated state: ${JSON.stringify(
      user.state,
    )}`,
  )
}

const handleClose = (uuid) => {
  console.log(`${users[uuid].username} disconnected`)
  delete connections[uuid]
  delete users[uuid]
  broadcast()
}

const broadcast = () => {
  Object.keys(connections).forEach((uuid) => {
    const connection = connections[uuid]
    const message = JSON.stringify(users)
    connection.send(message)
  })
}

wsServer.on("connection", (connection, request) => {
  const { username } = url.parse(request.url, true).query
  console.log(`${username} connected`)
  const uuid = uuidv4()
  connections[uuid] = connection
  users[uuid] = {
    username,
    state: {},
  }
  connection.on("message", (message) => handleMessage(message, uuid))
  connection.on("close", () => handleClose(uuid))
})

server.listen(port, () => {
  console.log(`WebSocket server is running on port ${port}`)
})

Congratulations! 🎉 If you now run node index.js, you will be running a fully-functioning WebSocket server:

It’s not that useful to run the server without a client and, of course, you’re here to understand the code (not just paste it!), but I think it’s worth pointing out how quickly we can get up and running.

Let’s break down the code from bottom to top.

First, we create a HTTP server and a WebSocket server before listening for incoming connections:

// Normally these constants live at the top of the file but I pasted them here for context :)
const server = http.createServer()
const wsServer = new WebSocketServer({ server })

server.listen(port, () => {
  console.log(`WebSocket server is running on port ${port}`);
})

Even though WebSocket is a separate protocol from HTTP, the WebSocket upgrade handshake happens over HTTP, meaning we need both.

Next, we add an event handler for incoming connections.

Here, things get much more interesting:

wsServer.on('connection', (connection, request) => {
  const { username }  = url.parse(request.url, true).query
  const uuid = uuidv4()
  connections[uuid] = connection
  users[uuid] = {
    username
  }
  connection.on('message', message => handleMessage(message, uuid));
  connection.on('close', () => handleClose(uuid));
});

In the client code, we will eventually connect to the server using a URL like "ws://localhost:8080?username=Alex".

Step one is to extract the { username } from the query string so we know who is connecting.

Next, we generate a universally unique identifier (UUID) by which to reference the user.

We use a UUID as a key instead of the username in case two users with the same username connect.

So far, so good!

The next two lines require a bit more explanation:

 connections[uuid] = connection
 users[uuid] = {
   username,
   state: { }
}

First, we add the connection to the connections dictionary.

This will be handy when we want to send a message to all connected clients since we can now loop over connections and call connection.send on each.

Next, we create and add a user to the users dictionary. Here, we associate information with the user, such as their username.

Additionally, we initialize an empty state object which we will later populate with information about the user’s status or attributes.

For the realtime cursor experience we’re building, we will eventually update the user’s state with their cursor position, but this pattern I call presence can be adapted to associate any information with the user.

For example, if you are building a chat application, you could add a typingStatus and onlineStatus (personally, I look forward to being "out for lunch 🍔").

You might be wondering - why create both a connections and a users dictionary?

We could maintain just a connections dictionary then associate the user with the connection.

On the surface, it looks simpler:

connection.user = { 
  username,
  state: { } 
}
connections[uuid] = connection

This is valid, but I see connection state and user presence information as discrete concepts and choose to represent them that way in code.

From a practical perspective, in a moment, we will JSON.stringify (serialize) and broadcast the users object to all connected clients. If we tried to serialize the connections object, we’d get a really unfocused string with metadata about the ws connection.

Speaking of the broadcast function, here it is:

const broadcast = () => {
  Object
    .keys(connections)
    .forEach(uuid => {
      const connection = connections[uuid]
      const message = JSON.stringify(users)
      connection.send(message)
    })
}

broadcast enumerates the connection dictionary and sends each client an up-to-date view of who’s connected and their state.

With just one call to broadcast, connected clients will receive a list of who’s connected (making it possible to build a “who’s online list”), as well as state about each user.

Most importantly - the client will see a snapshot of every user's cursor position so that, in turn, it can render a visual cursor.

Still working our way up the server index.js file, let’s look at the event handlers next:

const handleMessage = (bytes, uuid) => {
  const message = JSON.parse(bytes.toString())
  users[uuid].state = message
  broadcast()
}

const handleClose = uuid => {
  delete connections[uuid]
  delete users[uuid]
  broadcast()
}

handleClose at the bottom deletes the connection and user before broadcasting the users object to all clients (excluding the one that just closed since we deleted it).

Since the user will have been deleted from users, the client will basically get the message that someone disconnected.

In an ideal world, we might broadcast a named event like “user_gone” with information about the disconnected user.

For the purposes of this tutorial, however, we will leave it up to the client to spot the difference between the previous users object and the new one to detect who exactly disconnected.

Note that handleMessage is run every time a message is received from the client. The only message the server is expecting in this example code is a state update message.

Whenever the client wants to update the user’s state (for example, the cursor position), it sends a message to the server.

In this handler, the server overwrites user.state with whatever message object it received.

As your application evolves, you will surely want to handle different types of messages and I reccomend you validate inputs to avoid WebSocket security issues.

Understanding the WebSocket server

Even though the server code is short, there’s quite a lot going on.

In the following video I quickly recap how the server works by sending and subscribing to data using an API platform Postman.

They make it possible to send and receive messages over a WebSocket connection.

By thoroughly understanding the shape of the WebSocket endpoint, it will become a lot easier to understand what needs doing on the client in the next section.

Implementing the WebSocket client in React with useWebSocket

Now the server is up and running, we can shift our attention to the React client where we’ll solve some interesting challenges around how to structure the WebSocket code, smoothly render the cursors over the network (spoiler - we are going to animate them!), and strike a balance between frequency of cursor updates and network efficiency.

First things first, cd back to the project root and scaffold a React application called “client” with vite:

cd ..
npm create vite@latest client --template react
cd client

Making sure you’re inside the ./client subfolder, run npm install:

npm install react-use-websocket lodash.throttle perfect-cursors

For the purposes of a tutorial, it makes sense to install everything up front.

The function of each module will become clearer as we progress through the tutorial but here’s a quick summary so you know what to expect:

React-use-websocket: A React hook for WebSocket communication (click here and jump up the page if you want more information).
Lodash.throttle: Used to invoke a function at most once every X milliseconds.
Perfect-cursors: Plots a smooth curve between two or more cursor positions using spline interpolation. We can then animates the cursor along said curve to prevent the cursor jumping between throttled updates.

Creating the login screen

When a user opens the app, we first want to identify them by a username:

In a new file called components/Login.jsx:

import { useState } from "react"

export function Login({ onSubmit }) {
  const [username, setUsername] = useState("")
  return (
    <>
      <h1>Welcome</h1>
      <p>What should people call you?</p>
      <form
        onSubmit={(e) => {
          e.preventDefault()
          onSubmit(username)
        }}
      >
        <input
          type="text"
          value={username}
          placeholder="username"
          onChange={(e) => setUsername(e.target.value)}
        />
        <input type="submit" />
      </form>
    </>
  )
}

Next, create a placeholder file called Home.jsx:

export function Home() {
}

Then paste the following in ./index.js:

import React, { useState } from "react"
import ReactDOM from "react-dom/client"
import { Home } from "./components/Home"
import { Login } from "./components/Login"

const App = () => {
  const [username, setUsername] = useState("")

  return username ? (
    <Home username={username} />
  ) : (
    <Login onSubmit={setUsername} />
  )
}

const root = ReactDOM.createRoot(document.getElementById("root"))
root.render(<App />)

As a reminder, index.is is the entry-point for our clien - it’s the first code that runs, and we’ll use this opportunity to determine which screen to show used based on the application’s state.

Here, we check if the username has been set. If it hasn’t, we return (render) the Login component. Otherwise, we render the Home component and pass the username as a prop.

In the next step, we’ll use this username prop to identify the user to the server when establishing the WebSocket connection.

Sending cursor positions over WebSockets

When it comes to rendering realtime cursors, we can divide the problem in two parts:

Sending the cursor positions.
Receiving the cursor positions and efficiently rendering a cursor for each user.

In this section, we’ll focus on the first part of the problem - connecting to the WebSocket server and sending the cursor position when it moves.

Let’s start with a code dump before explaining it line by line.

In Home.jsx (the empty placeholder component we defined before), replace the entire contents with the following:

import useWebSocket from "react-use-websocket"
import React, { useEffect, useRef } from "react"
import throttle from "lodash.throttle"

export function Home({ username }) {
  const WS_URL = `ws://127.0.0.1:8000`

  const { sendJsonMessage } = useWebSocket(WS_URL, {
    queryParams: { username },
    share: true,
  })

  const THROTTLE = 50
  const sendJsonMessageThrottled = useRef(throttle(sendJsonMessage, THROTTLE))

  useEffect(() => {
    sendJsonMessage({
      x: 0,
      y: 0,
    })

    window.addEventListener("mousemove", (e) => {
      sendJsonMessageThrottled.current({
        x: e.clientX,
        y: e.clientY,
      })
    })
  }, [])

  return <h1>Home</h1>
}

First, we import the useWebSocket hook and call it with the WebSocket server’s address - in this case, "ws://127.0.0.1:8000".

Tip - make sure the WebSocket server is running in the background and double-check the port in the server the console output matches the one here (8000).

Additionally, we pass a queryParams option with the username. In a nutshell, useWebSocket will take the username property and append the value to the WebSocket server URL like this "ws://127.0.0.1:8000?username=Alex".

If you recall, the server has been coded to extract the username query parameter to identify the user.

We also pass share: true as an option to useWebSocket.

This isn’t strictly necessary for this project, however, I include to illustrate a key feature of useWebSocket that will probably be of use in your project.

When share is set to true, you can call useWebSocket(WS_URL) anywhere in your React application and - if useWebSocket already has a connection to that specific URL, it will share the connection between instances instead of opening a new one.

This is true if you create multiple instances of the same component (potentially simplifying the code since you can just call useWebSocket and not worry about managing the connection yourself), or, if you need to access the connection from a completely separate component (another screen, for example).

As you can see, setting up the WebSocket connection with useWebSocket is easy enough.

The unique code in this component lies within the useEffect hook.

Here, we call useEffect with an empty [], which effectively says “call me once when the component first mounts only”:

 const THROTTLE = 50
    const sendJsonMessageThrottled = useRef(throttle(sendJsonMessage, THROTTLE))

    useEffect(() => {
      sendJsonMessage({
        x: 0, y: 0
    })

    window.addEventListener('mousemove', e => {
      sendJsonMessageThrottled.current({
        x: e.clientX,
        y: e.clientY
      })
    })
  }, [])

In the above snippet, we listen to the mouse movement and send the cursor X and Y position to the server.

In a perfect world, cursor updates would happen with zero latency and arrive at the same rate as the user’s monitor.

In practice, however, it makes more sense to “throttle” the updates to roughly one every 50-80 milliseconds.

Why 50-80 milliseconds?

Even briefly wiggling the cursor on the screen could potentially fire hundreds of events in a few milliseconds (maybe thousands if you have a high mouse sensitivity), and that would put undue strain on the server, especially coming from tens, hundreds, or thousands of users.

At Ably, we built a tool called Spaces to specifically help enable realtime collaborative features like realtime cursors (user presence too). Our thorough user experience testing revealed 50-80 milliseconds is the sweet spot between performance and efficiency.

This isn't a post about Spaces (I just think realtime cursors are cool) but we apply that learning here by creating a custom function called sendJsonMessageThrottled.

sendJsonMessageThrottled will only allow the message to be sent maximally once per every 50 milliseconds and it achieves this by using the lodash throttle function.

A key point about sendJsonMessageThrottled is that we hold a reference to the throttled function using useRef.

If not for useRef (useCallback would work as well by the way), we would be calling throttle every time the renders (this happens many times per second). This isn’t only quite inefficient, but it would break the throttle function because we would also be starting the internal 50ms timer from scratch every render.

With the server running in the background, it should now be possible to open the client, “login”, and observe the cursor position being received and logged in the WebSocket server console every 50 milliseconds or so. As you can see, the updates are still plenty frequent even though they're throttled:

Feel free to open multiple tabs and watch the messages print in the console - it’s quite fun!

The next step is, of course, to subscribe to the server broadcasts and render the cursors, but herein lies a problem we must address in the next section.

Rendering cursors with perfect-cursors

Sending a cursor update every time the cursor twitches isn’t sustainable, so we throttle the update by 50 milliseconds.

This is frequent enough that the cursor is basically realtime, but it also means the cursor might appear to jump or twitch when rendered due to the 50 millisecond gap.

Enter perfect-cursors.

Perfect-cursors is a handy library by Steve Ruiz, who is the creator of an online whiteboard called tldraw. I mention this because tldraw actually uses perfect-cursors under the hood, which is a testament to its production-readiness!

Perfect-cursors is a hook that can blend the cursors between two points.

Ordinarily, if you move your cursor from [0, 0] to [0, 500], it would appear to jump across the screen.

With perfect-cursors, it becomes possible to gently animate the cursor from [0, 0] to [0, 500] basically giving the illusion that the cursor is updated in true realtime.

In this section, we’ll quickly scaffold perfect-cursors before going back to Home.jsx to import and use it.

We already "npm installed" perfect-cursors at the beginning of this section so no need to worry about that!

Start by creating a file called components/Cursor.jsx:

// Source: https://github.com/steveruizok/perfect-cursors

import * as React from "react"
import { usePerfectCursor } from "../hooks/usePerfectCursor"

export function Cursor({ userId, point }) {
  const rCursor = React.useRef(null)

  const animateCursor = React.useCallback((point) => {
    const elm = rCursor.current
    if (!elm) return
    elm.style.setProperty(
      "transform",
      `translate(${point[0]}px, ${point[1]}px)`,
    )
  }, [])

  const onPointMove = usePerfectCursor(animateCursor)

  React.useLayoutEffect(() => onPointMove(point), [onPointMove, point])

  return (
    <svg
      ref={rCursor}
      style={{
        position: "absolute",
        top: -15,
        left: -15,
        width: 35,
        height: 35,
      }}
      xmlns="http://www.w3.org/2000/svg"
      viewBox="0 0 35 35"
      fill="none"
      fillRule="evenodd"
    >
      <g fill="rgba(0,0,0,.2)" transform="translate(1,1)">
        <path d="m12 24.4219v-16.015l11.591 11.619h-6.781l-.411.124z" />
        <path d="m21.0845 25.0962-3.605 1.535-4.682-11.089 3.686-1.553z" />
      </g>
      <g fill="white">
        <path d="m12 24.4219v-16.015l11.591 11.619h-6.781l-.411.124z" />
        <path d="m21.0845 25.0962-3.605 1.535-4.682-11.089 3.686-1.553z" />
      </g>
      <g fill={"red"}>
        <path d="m19.751 24.4155-1.844.774-3.1-7.374 1.841-.775z" />
        <path d="m13 10.814v11.188l2.969-2.866.428-.139h4.768z" />
      </g>
    </svg>
  )
}

Then a file called hooks/useCursor.jsx:

// Source: https://github.com/steveruizok/perfect-cursors

import { PerfectCursor } from "perfect-cursors"
import * as React from "react"

export function usePerfectCursor(cb, point) {
  const [pc] = React.useState(() => new PerfectCursor(cb))

  React.useLayoutEffect(() => {
    if (point) pc.addPoint(point)
    return () => pc.dispose()
  }, [pc])

  const onPointChange = React.useCallback((point) => pc.addPoint(point), [pc])

  return onPointChange
}

For more information on perfect-cursors, you can check out the official documentation over on GitHub.

Now Cursor.jsx is set up, we can reference it from our Home component.

Receiving cursor positions over WebSockets

Okay, time to receive cursor updates from the server and render them!

Replace the entirety of Home.jsx with:

import { Cursor } from "./Cursor"
import useWebSocket from "react-use-websocket"
import React, { useEffect, useRef } from "react"
import throttle from "lodash.throttle"

const renderCursors = (users) => {
  return Object.keys(users).map((uuid) => {
    const user = users[uuid]
    return (
      <Cursor key={uuid} userId={uuid} point={[user.state.x, user.state.y]} />
    )
  })
}

export function Home({ username }) {
  const WS_URL = `ws://127.0.0.1:8000`
  const { sendJsonMessage, lastJsonMessage } = useWebSocket(WS_URL, {
    share: true,
    queryParams: { username },
  })

  const THROTTLE = 50
  const sendJsonMessageThrottled = useRef(throttle(sendJsonMessage, THROTTLE))

  useEffect(() => {
    sendJsonMessage({
      x: 0,
      y: 0,
    })
    window.addEventListener("mousemove", (e) => {
      sendJsonMessageThrottled.current({
        x: e.clientX,
        y: e.clientY,
      })
    })
  }, [])

  if (lastJsonMessage) {
    return <>{renderCursors(lastJsonMessage)}</>
  }
}

Since we are replacing the entire file, note - this snippet contains all the same code to send updates that we discussed above. Additionally, we import the Cursor component, subscribe to updates, and render a cursor for each connected user.

Let’s break it down.

const { sendJsonMessage, lastJsonMessage } = useWebSocket(WS_URL, {
  share: true,
  queryParams: { username },
})

Subscribing to realtime updates with useWebSocket is easy enough. We just need to reference lastJsonMessage, as shown above.

Every time useWebSocket receives an update, it updates lastJsonMessage.

This behaves like a state variable returned by useState, meaning every time lastJsonMessage changes, the component will render, allowing us to reference the newest lastJsonMessage value and execute some rendering logic.

In the following snippet we check if lastJsonMessage has been set yet (it won’t be until the first WebSocket update is received), and, if it is, we call renderCursors:

if (lastJsonMessage) {
  return <>{renderCursors(lastJsonMessage)}</>
}

const renderCursors = (users) => {
  return Object.keys(users).map((uuid) => {
    const user = users[uuid]
    return (
      <Cursor 
        key={uuid} 
        userId={uuid}
        point={[user.state.x, user.state.y]}  
      />
    )
  })
}

As a reminder, every time a user joins, leaves, or updates their cursor position, the server broadcasts a dictionary (object) of users and their state.

renderCursors takes this object, enumerates it, and returns a <Cursor /> component for each user, which are then subsequently rendered on the screen.

Rendering a “who’s online” list

As a final touch, let’s leverage the list of users to render a crude “who’s online list”.

With some UI work, it could look something like this but we will keep it simple and render just plaintext as this tutorial draws to a close:

First, open Home.jsx and create a function called renderUsersList. I suggest pasting it below renderCursors, like so:

// do not paste
const renderCursors = users => {
   // do not paste
}

// paste this *below* renderCursors
const renderUsersList = users => {
  return (
    <ul>
      {Object.keys(users).map(uuid => {
        return <li key={uuid}>{JSON.stringify(users[uuid])}</li>
      })}
    </ul>
  )
}

In the same Home.jsx file, replace:

if (lastJsonMessage) {
  return <>{renderCursors(lastJsonMessage)}</>
}

With:

if (lastJsonMessage) {
  return (
    <>
      {renderUsersList(lastJsonMessage)}
      {renderCursors(lastJsonMessage)}
    </>
  )
}

Now when you run the application and connect from multiple tabs (or computers), you should see a textual representation of who’s currently connected and their state.

Note how if you disconnect, the user is removed from the list, making it trivial to build a “who’s online list”.

Conclusion

In this post, you learned how to go realtime with React and WebSockets.

Rather than jump straight into the tutorial, we started with a focus on the fundamentals. This way, no matter what specific shape your application takes, you can feel confident about the best way to manage the WebSocket connection in React.

Realtime cursors are a fun example, and they do a good job illustrating how WebSockets and React make light work of intensive realtime updates, such as a cursor position, which updates very frequently.

Don’t forget - the key learnings in this post can be applied to all manner of realtime use cases such as chat, notifications, and graphs!

Looking to add a realtime experience to your React application?

In this post, we built a fullstack JavaScript WebSocket application that works great on localhost or with a small set of users.

Ensuring WebSocket connections work reliably with low latency and high uptime in demanding production environments is a much harder task, but it doesn’t have to be - you can let Ably handle the backend WebSocket infrastructure for you.

With Ably, WebSocket messages are routed through the Ably global infrastructure to ensure the lowest possible roundtrip latency and the highest percentile of uptime (Ably can legitimately offer a 99.999% uptime SLA).

The best part?

The Ably JavaScript SDK makes working with Ably from React just as easy as useWebSocket does, except it also supports, presence and history - and provides quality of service guarantees client-side libraries cannot like guaranteed message ordering and exactly-once semantics:

const { channel, ably } = useChannel("your-channel-name", (message) => {
  console.log(message)
})

channel.publish("test-message", { text: "message text" })
const { presenceData, updateStatus } = usePresence(
  "your-channel-name",
  "initial state",
)
updateStatus("out for lunch")

Create a free account (no credit card required) or learn how to send and receive realtime messages and display users' presence status with Ably and React here.

WebSocket security: 9 common vulnerabilities & prevention methods

Alex Booker — Mon, 25 Sep 2023 13:46:47 +0000

The WebSocket communication protocol is used for a range of purposes, including transmitting sensitive information and running actions with elevated privileges. This makes it an increasingly attractive attack vector for malicious actors.

The best defense against common WebSocket vulnerabilities is to be aware of them and implement the proper controls to reduce exposure.

In this post, we’ll look at the most common WebSocket security vulnerabilities and how to prevent them through a combination of modern security approaches and testing tools.

For each security vulnerability, I'm going to outline:

What it is
The impact
And how to prevent against an attack (I'll show you best practices and some tools)

Along the way, I'll also link to in-depth posts that I think you'll find helpful.

Let's start with a fundamental one a lot of developers get wrong - broken authentication.

Broken authentication

WebSockets don’t prescribe any particular way for servers to authenticate clients, putting the responsibility on us, the developers, to devise and implement a mechanism to confirm our user’s identity and securely manage their session.

The lack of a standard way to authenticate incoming WebSocket connections leaves room to make critical security mistakes.

Impact of broken authentication

The impact of a WebSocket authentication vulnerability is severe. Once an attacker has bypassed authentication, they have access to all the data and functionality that the compromised account has.

Prevention of broken authentication

Preventing broken authentication involves authenticating the handshake before establishing the WebSocket connection, either with a cookie or token

When using cookie authentication, the browser automatically sends cookies to the server with the WebSocket handshake. Just beware of Cross-Site WebSocket Hijacking (more on that in the section below).

Token authentication is a bit more tricky.

Browsers don’t allow arbitrary headers with the WebSocket connection request, meaning you need to find another medium to send the token to the server.

It can be tempting to send the authentication token in the query string, however, this should be approached with extreme caution. Query strings form part of the URL, which is plaintext and may appear in logs and be used in an attack.

One possible solution is to use your long-lived authentication token to make a HTTP request for an ephemeral one-time token from your authentication service. Send this one-time token with the WebSocket connection in the query string then discontinue it on the server-side. This way, if the token is logged somehow or shared accidentally, it's no longer usable.

If you'd like to learn more about how to implement a token-based authentication flow, Senior Software Engineer Jimmie Potts has a concise post on the subject.

Broken access control

In the previous section, we looked at authentication, which confirms the client is who they say they are. Access control, on the other hand, involves granting or denying access to specific resources or actions based on the authenticated identity.

Suppose Lord Voldemort authenticates with a password. Surely he shouldn’t be authorized to subscribe to Harry Potter and the gang’s WebSocket channel.

Impact of broken access control

Broken access control is the most commonly encountered and often a critical security vulnerability. It happens when a user can in fact access some resource or perform some action that they are not supposed to be able to access. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data, or performing a business function outside the user's limits.

Prevention of broken access control

Unless a resource is intended to be publicly available, deny access by default.
Explicitly declare the access that is allowed for each resource.
Thoroughly audit and test access controls to ensure they’re working as designed.

While the design and management of access control is a complex and dynamic problem, most issues can be solved with the above best practices.

Many developers rely on obfuscation for WebSocket security, but security through obscurity is not security at all.

WebSocket URLs are normally tucked away in code and the paths themselves often contain identifiers that seem random and impossible to predict, creating a false sense of security.

Today, it's trivial for a malicious actor to use a WebSocket traffic inspectors like Burp or even Chrome’s WebSocket inspector to recognise and exploit a pattern, making it more important than ever to double-check every resource is behind an access rule.

Insecure Direct Object References (IDOR)

Insecure Direct Object References (IDOR) is a subcategory of access control vulnerabilities. It's one of the most common access control weaknesses, so we wanted to call it out directly.

An IDOR vulnerability allows a malicious actor to exploit a WebSocket application by manipulating a "direct object reference" in the WebSocket request, such as a file name or query parameter.

In an IDOR attack, the request succeeds due to missing access control checks, which fail to verify whether a user should be allowed to access specific data.

To give an example - in a post entitled IDOR via WebSockets, Security Engineer Shuaib Oladigbolu describes how they managed to comment as another user simply by tampering with the authorID parameter in the WebSocket comment request - sometimes it's that easy for an attacker to cause problems.

Impact of IDOR

IDOR vulnerabilities are among the most commonly-reported and are trivial to execute. They can result in unauthorized data exposure, leakage of personally identifiable information, and even create the potential for data manipulation or deletion.

Prevention of IDOR

Implement access control checks for each object that users try to access.
Use complex identifiers like GUIDs instead of predictable incremental IDs as a defense-in-depth measure (but remember that access control is crucial even with these identifiers).

For more information on IDOR, The Open Web Application Security Project (OWASP) has a handy IDOR prevention cheat sheet - they are a non-profit dedicated to application security and have many educational resources dedicated to the security subjects described on this page.

Injection attacks (SQL Injection, XSS, etc.)

Injection is an attacker’s attempt to send data to an application, with the intention of exploiting vulnerabilities in the application's processing. It's one of the most common vulnerabilities with HTTP, and it applies to WebSockets as well, which are often used to transmit sensitive information and run actions with elevated privileges.

Common types of injection attacks include SQL injection, where attackers manipulate database queries, and cross-site scripting (XSS), where malicious scripts are injected into web pages viewed by other users.

Impact of injection attacks

Injections are among the oldest and most dangerous attacks aimed at web applications in general and often arise in relation to WebSockets. They can lead to unauthorized access, data loss, denial of service, or even full system compromise if not properly mitigated.

Prevention of injection attacks

Escape special characters in user inputs before incorporating them into queries or commands. This prevents them from being interpreted as code.
Treat all user-supplied input as untrusted. Validate all inputs on the server, and use an allowlist of acceptable inputs.
Examine and remove unwanted key characters, such as HTML tags that are deemed to be unsafe. Keep the safe data and remove any potentially unsafe characters.
Most instances of SQL injection can be prevented by using parameterized queries (also known as prepared statements) instead of string concatenation within the query.

Denial of Service (DoS)

A Denial of Service (DoS) attack exploits vulnerabilities in your WebSocket implementation to crash the WebSocket server, making it inaccessible for your genuine users.

DoS attacks accomplish this by flooding the WebSocket server with traffic, or sending it information that causes a crash.

A DoS attack can be compared to a phone system being flooded with constant, non-stop calls from prank callers, jamming the lines and preventing legitimate callers from getting through, thus disrupting trade and losing the business money.

Impact of DoS

A successful DoS results in sluggish behavior or a total system crash. In both instances, the DoS attack deprives genuine users of the service they expected.

Though DoS attacks don't typically result in unauthorized access to sensitive data, they can have a devastating impact on critical services, leading to direct financial loss and reputational damage.

Prevention of DoS

Only allow authenticated users to open a WebSocket connection to prevent an attacker from flooding the WebSocket server with a large number of connection requests.
Ensure that your authentication mechanism is efficient so that DoS attacks using an invalid token can be quickly and cheaply refused.
Limit the number of requests that can be made to the WebSocket server from the same IP address over a specific time period.
Limit the number of connections allowed to the WebSocket server to circumvent a resource exhaustion attack.
Limit message size to a reasonable number to prevent message size attacks.

DoS is not a specific attack but rather, a category of attacks. It would be outside the scope of this post to list every type of DoS however, I can highly recommend this post on DoS via WebSockets by CQR. They go into more detail about the above vulnerabilities and touch on a few others as well - for example, a pesky type of DoS called a WebSocket SYN Flood DoS.

Distributed Denial of Service (DDoS)

An additional type of DoS attack is the Distributed Denial of Service (DDoS) attacks.

DDoS attacks are more sophisticated and impactful than DoS attacks. They involve a coordinated effort from multiple sources - often compromised computers or devices forming a botnet. These sources simultaneously DoS the WebSocket server, making it even more challenging to defend against or mitigate.

Impact of DDoS

The most immediate and obvious impact of a DDoS is that your WebSocket server becomes overwhelmed and crashes. Suppose you’re building a chat experience or realtime collaborative experience over WebSockets - if your WebSocket server is compromised, your entire website may as well be down. As your service becomes intermittent, users may lose faith in the experience and use another service altogether.

Since the attack is distributed, connections will likely come from all around the world. It will be hard to distinguish malicious and genuine connections due to the fact the botnet is composed of compromised systems that otherwise seem like genuine users. This makes a DDoS difficult to mitigate, resulting in intermittent disruptions to the service, often leading to reputational damage or straight up financial loss.

Prevention of DDoS

Ensure your server is not vulnerable to DoS attacks (see section above).
Use a hosted WebSocket infrastructure like ours at Ably - our near-limitless scale means we can mitigate huge increases in traffic and defend against DDoS attacks - so you benefit from our scale as attacks have no effect on your own servers.
Proxy WebSocket connections through a content delivery network (CDN) that offer DDoS protection services that can detect and mitigate attacks in realtime.
Distribute WebSocket connections across multiple servers and data centers, making it harder for attackers to overwhelm a single server.
Have a plan in place for responding to a DDoS attack, including procedures for notifying stakeholders, isolating affected systems, and restoring services.

For more information on how DDoS attacks work in the real world (and some guidance on how to mitigate them), CloudFlare has an in-depth post on the subject. As it happens, CloudFlare is a CDN that offers DDoS protection. We use them at Ably.

Cross-site WebSocket hijacking

Cross-site WebSocket hijacking (also known as cross-origin WebSocket hijacking) is a security vulnerability that occurs when a malicious actor makes an unauthorized WebSocket connection to a different origin (site) than the one the user is currently on.

It arises when the WebSocket handshake request relies solely on HTTP cookies for authentication and isn't relevant to you if you're using token-based authentication.

Modern browsers ordinarily prevent cross-origin resource sharing (CORS) with a same-origin policy - while this applies to HTTP, counterintuitively, this does not apply to WebSocket connections, introducing a potentially surprising attack vector - unless you happen to know better. Good job you're reading this post!

Impact of cross-site WebSocket hijacking

The implication of a cross-site WebSocket hijacking vulnerability depends on the scope of the attack and the hacker's ability to leverage it.

At a minimum, a successful cross-site WebSocket hijacking attack enables malicious actors to abuse the established WebSocket connection to perform actions on the user's behalf without their consent, potentially compromising their data or executing unintended actions. In many cases, the user won't know they've been exploited until it's too late, making it hard to react and defend their own data.

In a serious case of cross-site WebSocket hijacking, an attacker managed to execute arbitrary JavaScript in a subdomain of the domain where the WebSocket communication was occurring.

Prevention of cross-site WebSocket hijacking

On the server side, validate the origin of incoming WebSocket connections. Only allow connections from trusted domains by checking the Origin header. Reject connections from unexpected or unauthorized origins.
Introduce a session-individual token (like a CSRF token) into the user's session, which is then included in the WebSocket connection request sent to the server. This token is not known to malicious actors, making it difficult for them to forge requests.

Sensitive information disclosure over a network

When transmitting sensitive information from one client to another over WebSockets, it must traverse the network. Malicious actors may exploit vulnerabilities to eavesdrop on the communication and steal personally identifiable information, such as account details, sensitive health data, private communications, and intellectual property.

Broadly speaking, this is known as a man-in-the-middle attack and is the equivalent of a mailman opening your bank statement, writing down your account details, and then resealing the envelope and delivering it to your door - you might not know you've been hacked until it's too late!

Impact of sensitive information disclosure over a network

The most immediate impact of a data leak is the violation of privacy for your users whose personal information has been exposed. At a minimum, users will lose faith in your ability to secure their information, leading to reputational damage and potentially loss of business as well. Depending on the nature of the breach, you may incur legal consequences and regulatory fines also.

The severity of the impact can vary based on the nature of the data exposed, and the motivation of the attackers. By intercepting or manipulating sensitive data, a malicious actor could steal intellectual property or even use data obtained from the breach to carry out a secondary attack, possibly causing wider operational disruptions.

Prevention of sensitive information disclosure over a network

Always use the WebSocket Secure (wss) protocol instead of WebSocket (ws) to ensure data exchanged between the client and server is encrypted using SSL (TLS), making it difficult for attacks to intercept or decipher.
Ensure that the SSL certificate used for security the WebSocket connection is valid and issued by a trusted certificate authority.
Regularly review the information sent over WebSockets to determine if a justifiable business need exists for transmitting each item present. Any items deemed unnecessary should be removed.

Using vulnerable or outdated WebSocket libraries

When building with WebSockets, it’s common to use a library like Socket.IO to help you get up and running more quickly. These libraries tend to implement features you probably need - like automatic reconnection and message acknowledgements, as well as provide patterns for grouping connections by “rooms” or “topics” (pub/sub) to make routing messages simple. They are very convenient!

However, before depending on a WebSocket library, do some research, and possibly some auditing.

Using a third-party WebSocket library can save time upfront, but it’s not without risk of introducing a vulnerability.

For example, according to Snyk, websockets@9.1 introduces a DOS vulnerability before being patched in websockets@10.

Here's one more example of a Regular Expression Denial of Service (ReDoS) vulnerability introduced by the third-party ws package, which has since been solved.

Newer WebSocket libraries (or newer WebSocket library versions) may be more susceptible to vulnerabilities due to the fact they haven’t yet been battle-tested.

Additionally, watch out for older or unmaintained WebSocket libraries. Often, libraries with known vulnerabilities don’t get fixed due to a lack of maintainers.

Impact of using vulnerable or outdated WebSocket libraries

A vulnerable or outdated dependency may be susceptible to any of the common WebSocket vulnerabilities described in this post.

Malicious actors can exploit these vulnerabilities to gain access to sensitive data or take control of the application entirely.

Prevention of using vulnerable or outdated WebSocket libraries

Use a commercial WebSocket-based API like Ably, which is actively maintained by a dedicated team, frequently undergoes penetration testing, and has a respectable vulnerability disclosure policy (bug bounty).
Carefully inspect any open source dependency you add to your WebSocket server, as it may have an outstanding vulnerability.
Keep open source dependencies updated to ensure you have the latest security patches, reducing the risk of an exploit.
Optionally use an integration such as Snyk to continuously perform security scanning on your open source dependencies and detect potential vulnerabilities.

WebSocket security FAQ

To wrap up this post, let's cover some of the most commonly-asked questions about WebSocket security.

Do WebSockets need SSL?

Yes, it's highly recommended to use SSL encryption with WebSockets (wss) to prevent eavesdropping and tampering by malicious actors. Using SSL also helps to maintain the integrity and confidentiality of the communication and prevents various security vulnerabilities that can arise when data is transmitted over an unencrypted connection.

How secure are WebSockets?

WebSockets are very secure when used over an encrypted SSL connection (wss) and you follow the WebSocket security best practices described in this post. Secure authentication, authorization, and input validation are crucial for preventing unauthorized access and attacks. Regular updates to libraries and ongoing testing contribute to overall security.

How do you test WebSocket security?

Comprehensive WebSocket security testing requires a deep understanding of the WebSocket protocol and practical experience in both manual and automated security testing techniques. Open tools like STEWS can detect known WebSocket vulnerabilities while commercial security tools like Burp Suite exist to intercept and manipulate WebSocket frames with ease, however they won't catch everything. Perform manual testing and fuzzing to identify unexpected behavior or vulnerabilities that automated tools might miss.

If you lack experience in WebSocket security testing, consider consulting with security experts or penetration testers who specialize in this area, as the consequences of poor WebSockets security can be dire.

5 best chat APIs and messaging SDKs in 2024

Alex Booker — Fri, 14 Jul 2023 11:51:35 +0000

Looking for the perfect chat solution can be a daunting task.

You need a provider that not only supports all the necessary chat features but also offers delivery and scaling guarantees to ensure a smooth chat operation as your business grows.

We've narrowed it down to just the 5 best chat APIs and messaging SDKs, taking into consideration factors like features, scalability, and price. This way, you can make an informed decision about which provider will work best for your project.

What are chat messaging APIs and SDKs?

Fundamentally, chat APIs and SDKs enable developers to build chat more quickly by managing the infrastructure necessary to send and receive messages in realtime, plus must-have chat features like typing indicators, online indicators, and read receipts.

If you’re wondering how an API and SDK differ in this context, it has to do with how developers interface with said infrastructure.

An SDK, on the other hand, offers a complete set of development tools, usually including prebuilt chat UI components. By assembling chat “building blocks”, developers can save time up front.

Remember that APIs and SDKs aren’t mutually exclusive, and some providers offer both.

What should you look for in a live chat solution?

Chat apps like WhatsApp and Slack have set the bar for live chat experiences, and it’s important to find a chat provider that enables you to deliver the same quality experience.

These are the ten foundational features you have to be able to deliver using your chosen solution, and that you should consider during your evaluation process.

Low Latency: If messages take too long to send or load, users won’t have a smooth user experience and will take the conversation elsewhere. That could be another channel (for example, a customer might pick up the phone and start their support request from scratch) or, if the experience is consistently laggy, users might even switch to another app.
The ability to scale: As your user volume grows, the load on the server also increases. If the server can’t handle this increased load, chat features can become unresponsive, causing a poor user experience.
Reliability: Even a short downtime or an occasional error can be frustrating for users. This is unfortunate, but for businesses that rely on chat applications for customer support or sales, downtime can result in lost revenue or missed opportunities.
Guaranteed delivery: Messages should be delivered exactly once and in the correct order, even in the face of network issues. Otherwise, messages might come flying in out of order, and more than once, making it almost impossible to discern what is trying to be communicated.
Elasticity: Chat app usage can be unpredictable. Applications may experience sudden spikes in usage during peak hours or events, or during product launches and marketing campaigns. If the server can’t scale its resources up dynamically in response to changes in user demand, chat features may become unresponsive.
Rich features: Your users will expect typing indicators, online status indicators, read receipts, push notifications, and more. If users can’t accomplish what they need to with your chat, they might switch to another app where they can. For a comprehensive guide to the features needed, see our ultimate list of live chat features (complete with examples).
Integrations: Live chat solutions need to integrate with the other tools in your tech stack. Dedicated integrations between technologies can help keep engineering requirements to a minimum.
Data governance: The way data is stored, processed, and disposed of needs to meet regulatory requirements, wherever you operate.
Chat moderation: Chat experiences need to be safe for both end users and chat operators. The process of monitoring and controlling user-generated messages helps ensure compliance with your terms of use.
Frontend UI: Customizable themed components including colors and fonts help to keep your chat solution a cohesive part of your customer experience.

Another key consideration when evaluating a live chat solution is, of course, cost.

Most chat API providers base their pricing on the number of monthly active users (MAUs). Some also account for additional factors like the number of messages and concurrent users.

Now that we’ve covered the fundamentals, let’s look at the 5 best chat APIs on the market.

The 5 best chat API and messaging SDKs

1. Ably

Ably is a realtime experience infrastructure used by companies like HubSpot, I7Live, and Riff to build feature-rich and reliable chat.

2. Twilio

Twilio is a communication platform with a suite of products designed to help developers code communication features like SMS, email, video, and - you guessed it - chat.

Their chat product is called Conversations API and it’s unique because it’s specifically designed to enable omni-channel messaging.

3. Firebase

Remember, since Firebase is a general-purpose platform, it doesn’t have a specific notion of chat. While implementing basic chat might be fairly straightforward, expect to invest a significant amount of upfront development to get features like typing indicators, read receipts, and presence indicators to work, especially without a hitch at scale.

4. Sendbird

Sendbird Chat enables developers to implement chat by providing an SDK with ready-made chat UI components. They cover all the essential features you might expect, including voice and video, which makes it possible to deliver a comprehensive chat experience.

5. Stream (formerly GetStream)

Stream provides APIs and chat UI components that developers can use to implement live chat into their web and mobile applications.

All the infrastructure is managed for you. However, all chat traffic is processed and stored in a single data center. This can have a negative implication on latency and creates a single point of congestion and failure. This might explain why Stream only offers a 99.95% SLA unless you pay more for an enterprise plan.

It’s worth noting that chat often goes hand-in-hand with other realtime use cases, such as multiplayer collaboration (think of a product like Figma, where you can edit your design collaboratively and chat with other users in realtime). However, Stream is very much a chat-centric solution. If you’re looking to build other realtime experiences alongside chat, Stream can’t help – you will have to use different technologies, which brings additional complexity and increased costs to your project.

Which is the best chat solution for your use case?

30 inspiring web developer portfolio examples you have never seen before

Alex Booker — Mon, 20 Feb 2023 22:40:04 +0000

There are many decisions that a recruiter makes while evaluating your application for your first junior developer role.

Do you have the personality and capacity to confront technical challenges? Do you have a genuine passion for coding and the dedication to improve despite not having professional experience?

Your secret weapon to convince them?

An amazing web developer portfolio.

A web developer portfolio is a showcase of who you are. It shows recruiters that you have the right skills, enthusiasm, and desire to complete technical challenges. It's your opportunity both to impress them and standout from another dozen of candidates in the hiring process.

If you're ready to create your web developer portfolio and yet you don't know how to turn it into something beautiful, this article is the only resource you will ever need.

I've gone through dozens of forums, portfolio directories and design websites to find the most stunning, yet unseen portfolios for you to take examples from.

Let's dive deep into them now and find out what makes them great.

Do I really need a web developer portfolio?

No. A web developer portfolio is not a requirement to be hired for a junior position. However, missing one means missing a tremendous opportunity to prove to recruiters your skills and dedication to the role despite your lack of professional experience.

Without one, you're limited to your words during the interview process, and as always, showing your skills is better than telling them.

What Should I Know Before Creating My Web Developer Portfolio?

Before diving into creating your own web developer portfolio, keep in mind the following fundamentals:

Display only your best work: don't mind using your first program where you used a while loop. Your portfolio is a place to show complete, meaningful projects. Also remember: you don't need a dozen of significant projects. Usually, two to four is a perfect balance.
Use your name as the domain's name: this is the absolute best way to make sure you're found during the interview process when recruiters search for you on Google.
Include a contact form: to make sure recruiters can easily contact you.
Add honorable mentions: if somebody mentions your work in a publication or praises you online for it, mention it in the portfolio. There's no better way of selling yourself than social proof.
Do not use tutorial projects: your portfolio should be a place for originality, so don't use projects from Udemy courses or YouTube tutorials. It might surprise you how many devs do and how easily recruiters will spot that.

⚠️ Important note: while a great web developer portfolio can help you a long way in your career search, a bad one will for sure damage your image in the eyes of recruiters. So always strive for a website that is looking beautiful, both on mobile and desktop, which you maintain regularly. You never want recruiters to click on your portfolio only to find a 404-page error.

Our Top 30 Stunning Web Developer Portfolio Examples

Let's know deep dive into our favorite portfolio examples for you to take inspiration from.

Our top 30 stunning web developer portfolio examples

Let's know deep dive into our favourite portfolio examples for you to take inspiration from.

Safet Pojskic

I love the simplicity of Safet's portfolio. He follows a classic structure of an introductory line + nice photo of himself. He also placed a contact button as a call to action, which is very smart as it directs website's visitors to their next step when interacting with him.

After listing his skills, he also gives recruiters the opportunity to download an updated version of his CV with a button click.

I really enjoyed the particle animation they used for the background of the portfolio, adding a sense of dynamic to a spotless color palette, using simply black, red and white.

Tip: if you want to implement particles effect in your portfolio too, you can use Anime.js as Safet did.

Ben Scott

Ben's description of himself is uncomplicated. His portfolio is very similar to Safet's one in terms of background effects and palette colors. I loved his choice of displaying his skills as images and, most of all, all his projects list a live link to test the final result, allowing recruiters to visualize his work without having to pull down the project from GitHub.

Tip: want to create a dynamic lightning background like Ben? He usedHTML's canvas API for that.

Brice Clain

Brice's portfolio feels alive thanks to the animation he placed across the whole page. Visiting this website feels like having a conversation with him, where he explains the history behind each one of his projects and how they came to life. A really memorable experience for the eyes.

Tip: Anime.js is the library behind his typewriting effects on the text.

Iuri De Paula

The first time I visited Iuri's portfolio, I realized how a beautiful web design mixed with storytelling can make for a masterpiece website. His portfolio is an award-winning experience, where he guides you step-by-step through his career via stunning graphics and scrolling effects.

Tip: want to create a portfolio just like Iuri? The code for his website is open-source, and you can find ithere.

Uroš Ignjatović

Despite Uroš portfolio's simplicity, he did an amazing job of creating an elegant website with a traditional black and white color palette and an amazing font choice.

Tip: the font used for this website is called "Segoe UI".

Bruno Figueiredo

Bruno's portfolio is a visually appealing website. This is possible thanks to a pleasant choice of the color purple, a great illustration to welcome visitors, and various nice scroll effects spread across the page.

Tip: if you want to adopt this website's scroll animations, you can use a library called AOS.

Hakim El Hattab

If you want your portfolio to be uncomplicated, you can opt for the approach used by Hakim. He composed this website with a simple description of himself plus links to his work, making it for an easy yet effective way of displaying who he is to potential employers.

Jeremy Thomas

While this is not exactly a developer portfolio aimed at getting hired for the first time, it still uses a lot of great ideas you can integrate into your design. First, Jeremy lists the company he worked with, which fits perfectly in with the principle of using, when available, social proof to impress visitors.

In addition, his case study section is a magnificent example of presenting yourself as a professional. He lists every challenge he faced for each client, the solutions he adopted, and why. An approach you can use for your portfolio too.

✅Pro Idea: Don't just show your project, talk about them. Create case studies around your work, explain your challenges, choices you made and the tradeoffs you had to come up with, it will impress recruiters and give you a huge help during the interview process.

Adam Hartwig

I loved this site from the first moment I laid my eyes on it. The lively color palettes welcomes its visitors into a memorable experience, where nothing is trivial, from the animations to the way its author Adam uses them to describe his skills. I'm sure he had fun creating this portfolio, and that reflects perfectly into this piece of work.

Tip: Textillate.js is the text animations library you can use to animate your texts like Adam did.

Timothèe Roussilhe

This website is very simple, yet memorable thanks to a choice of colors that add an artistic aura to Timothèe's portfolio, making it very stylish and notable in the panorama of dev portfolios.

✅Pro Idea: not sure about which color palette to use for your website? Check out this free color palette generator here.

Adam Greenough

Adam's portfolio is simple. He uses a beautiful color and a moving background to make the website look more lively. He has some amazing projects listed, and I really appreciated his listed coding blog posts, which increase Adam's credibility as a professional.

Tip: Vanta.js is the library used for the background effects.

✅Pro Idea: if you ever wrote technical blog posts during your path to learn coding, add them to your website. Recruiters love to see this kind of community engagement and efforts. Actually, I landed my last dev job also thanks to my contribution online on Medium!

Andy Patrick

As a UX designer, Andy uses a very creative approach to narrating his story, with an airplane landing through the various stages of his career, making this portfolio remarkable thanks to this minor detail, despite his simplicity in other sections.

Tip: to create loading effects as cool as Andy's portfolio, Loading.io is an impressive library I discovered for this purpose.

✅Pro Idea: sometimes a memorable animation is everything needed to make a portfolio easy to remember.

Sean Halpin

This portfolio is my favorite on the entire list. The palette of pastel colors is delightful, the "Bogart" font makes the whole page look slick, and the above the folder content has the genius touch of an eye animation looking at the text, directing the user's eye where Sean wants.

The author describes his work with amazing case studies, where he shows the entire process of creating a project, including his personal notes and sketches. A true masterpiece thanks to his care for details and overall look.

Tip: You can also create a moving eyeball in CSS using this tutorial.

Gilles Vermeulen

Despite Gille's portfolio comprising a single series of scrolling images and descriptions, he went big on creativity, with this animated character head opening to reveal all his cool projects and a background effect. A very witty approach to showcase his work in a fun way.

✅Pro Idea: never be afraid of showing personality on your portfolio, whether that's via a witty copy or an image of yourself.

Raoul Gaillard

What impressed me the most about Raoul's website is his elegance in using colors, and the way he presents every detail beautifully thanks to amazing parallax effects, 3D images and a 3D matrix's background that will make you feel as if the website is constantly moving.

Tip: Here's an amazing guide on creating 3D-looking images with CSS. Here you can find a guide to the 3D matrix in HTML for the background effects used by Raoul.

Sean Wilson

Sean's portfolio is a minimalist website. Yet, what makes it worthy of notice is his use of great copy to catch his visitors. Instead of simply presenting himself, he targets the specific audience of people in need of a website's redesign, explaining how he can help them and why he's the solution to their problem. A great example of how a well-thought copy can increase your portfolio's effectiveness.

Eli.wtf

Eli describes himself as a developer who loves creating weird websites, and his portfolio is a perfect example of that. The website has a high visual impact thanks to an initial moving skull animation, with quirky animations leading you from one page to another.

He also lists the conferences he took part in as a speaker for added credibility, besides an amazing use cases section where he describes how his clients benefited from his work. Truly an amusing experience as a website.

Tip: the animations on the website were made using HTML's canvas API. I found also a CodePen explaining to you how to create a moving head animation like his, here.

Lucas Bebber

This portfolio is proof of how simplicity, when accompanied by great visuals can make for an amazing portfolio. The initial image of moving mountains make the whole project feel alive, and it welcomes users to the projects created by Lucas and live demo links to try them.

Tip: here's a tutorial on creating moving mountains like Lucas did.

Samsy.ninja

Samsy's portfolio opens with a stunning effect of moving lines and a minimalistic color palette made of gray colors. I loved his approach to transitioning between sections by creating a zoom-in effect, rather than a classic scroll. Plus, every use case he lists has videos attached to it, making the experience a delight for the eyes.

Damien Seguin

Damien describes himself as a creative developer, and that shines clearly through his portfolio. This website speaks volumes about the artistic personality of the author, showcasing his work in an easy yet remarkable way, with beautiful use cases built around his projects and great images to give the whole thing a retro, artsy look.

Luigi de Rosa

Luigi adopted quite an unusual color palette for his portfolio, making the result truly distinctive. Bubbles animations also helped the entire website to achieve an impressive and admirable ultimate effect.

Tip: The bubbles on this website were realized using translate3D in CSS.

Danilo Figueiredo

Danilo chose a text only approach to welcome users into his portfolio, which I found quite effective thanks to a great font choice (SF pro). I also appreciated his idea of mentioning the tech stack he used for each one of his use cases.

Riccardo Zanutta

This portfolio feels rich thanks to many small details: the rotating background matrix scattered with geometric figures, the beautiful and colored loading states, the detailed case studies (which list also the color preferences adopted for the clients), plus an experiments section which is a great idea to display creativity and willingness to try, the very essence of a developer.

Tip: I found no specific info about the effects implementation on this website, but matrix3D should do the trick.

Prashant Sani

I find the most beautiful thing about this portfolio is its synthwave palette, which is helped by amazing animations to display texts and loading states, plus motivational quotes placed carefully to reflect the personality of Prashant and his work.

Tip: The images on this website were realized using translate3D in CSS.

Matt Farley

Matt's portfolio has a very simple above the folder content, with a witty description of himself and a nice illustration as a profile pic. I enjoyed how he described his skills using a table rather than classing images. He also lists the companies he worked with and specifies his coding experiments, which adds for added respect for him for showing he's a truly passionate developer.

✅Pro Idea: got some extra cool experiments you tried you could mention on your portfolio? Do it. Always show creativity and inventive .

Rob Owen

Rob's portfolio palette makes the entire website feel light and lively. What I appreciated the most about his work was the way he described himself and his work policy, opening up to his personality and adding charisma to the character. His projects section is amazing thanks to relevant projects he created, like Syntwave 84, the popular Visual Studio Code extension.

Tip: try Befunky to turn your website into drawing illustrations.

Michael Pumo

Michael set up a great color palette for his website, adding a unique touch to it thanks to a scrolling effect which shows you his project while keeping his description of himself always highlighted. In addition, I really appreciated his choice of images for his projects, which he accompanies with reviews and logos from his clients to show his expertise.

Tip: If you're interested in checking out the source code for this portfolio, check it out here.

Omar Moquete

Omar's portfolio is easy in its structure, yet very polished and with an amazing animation of an IDE greeting visitors, which is what made this creation memorable for me.

Tip: If you're interested in how he realized his project, you can visit his open source portfolio project here.

Ahmed Zougari

Ahmed's portfolio feels smooth, with a description of himself and a great photo. What makes it standout is his choice of the font "Fingerprint", which makes the entire website feel playful and minimalistic, thanks also to a classic black and white palette.

Alex Michailidis

What I loved the most about interacting with Alex's award-winning portfolio was its storytelling. You can follow through with it and click on each one of his experiences to get a full description of what he did. Plus, this website gave me nostalgic feelings, with its color palette reminding me of a Linux terminal, really a well-done creation.

Tip: Anime.js is the library behind this website's animations.

The key takeaways from these portfolios

Top portfolios always have a beautiful above the folder content, with a description of the author plus their image or illustration, and a nice background.
Slick animations placed around portfolios make them memorable.
Aim for a minimalistic color palette to make your web developer portfolio look neat and elegant.
Most portfolios are usually a Single Page Application, with the possibility of scrolling to view through the different sections.
Most portfolios list around four projects.
Build case studies around your portfolio, explain which challenges you faced and how you went about solving them.
Remember to always list your skills, but never use percentages to describe your knowledge of a programming language. More info about this common error here.
Add testimonials if you have them available.

Conclusion

Creating your web developer portfolio is a serious task, but it all becomes worth it once you have a beautiful website showcasing your personality and skills to potential recruiters, becoming your secret trick to standing out during the hiring process.

P.S: do you need a free video guide on how to create your web developer portfolio? We have created one for you here.

11 reasons why you should become a web developer (that aren’t just the high salary)

Alex Booker — Tue, 14 Feb 2023 01:56:54 +0000

Interested in becoming a web developer, but not sure if web development is a good career?

The world of web development can seem intimidating when you're just starting out. Throw post-pandemic economic uncertainty into the mix, and it's understandable if you have concerns about switching careers.

Some feel that the only thing that makes becoming a developer worth it is the high salary. But in reality, web development can be a hugely rewarding, flexible, and varied career path in its own right.

Of course, what you're paid will always be a major consideration when it comes to your career (good news then that despite the economic downturn, web development salaries have continued to rise!). But there's so much more to web development than the salary.

In this post, we've rounded up some of the lesser-known benefits that make web development a career worth considering. Feel free to jump down the page if there's something that catches your eye! 👇

High demand means plenty of choice when it comes to roles 🌎
You can choose a career that aligns with your values ✅
Satisfying work, tangible results 💪🏻
Opportunities for growth in almost any direction 🚀
You can express your creativity 🎨
Lots of opportunities to collaborate and pick up new skills 🤝🏻
The community spirit! 🍻
You can work from anywhere 💻
The flexibility of freelancing 🕺🏻
It can be really (really!) fun 🎉
BONUS - It's well paid 💰

High demand means plenty of choice when it comes to roles 🌎

Across almost every industry, web developers are in high demand. In the US alone, the number of people employed as developers is forecast to grow 23% by 2031 — much faster than other occupations.

Don't get us wrong: it's not always easy to get your foot in the door as a developer. Securing that first opportunity requires hard graft, and you'll need to really put in the hours to get your skills up to scratch. But once you've got a year or so of experience under your belt, you're likely to have a lot more choice available to you than at the same point in another profession.

Here are just a few examples of where a training as a web developer could take you:

Creating mobile apps for an international game developer 👾

Scrimba student Anthony Moreno worked and credited on a Call of Duty title!

Building banking interfaces at the cutting edge of FinTech 📈
Developing new learning platforms for schools and universities 🎓

With so many companies looking for talent, web developers often have lots of freedom to try out different industries and types of organization. Many senior developers, for example, choose to hone their skills at large companies before moving to startups where they can really influence the direction of the product.

You can choose a career that aligns with your values ✅

Web development is a hugely transferable skill. There aren't many organizations that don't have a web presence of some kind. So no matter where you start out, if there's an industry you really care about — for example, conservation or education - it's likely you'll be able to move into that area once you get some experience.

And one of the things that make web development so great to work in is the fact that so many of the best developers started out in completely different careers. The relatively low barrier to entry of frontend web development in particular means that it's entirely possible to retrain and start a new career, even after 10, 15 or 20 years in another role.

👉 Need proof? Check out our recent podcast with Michael Robards, a career changer who became a software developer for Coca-Cola at 51!

If you're in a career at the moment that you don't find fulfilling, web development might be the skill you can use to unlock a role in an area that really matters to you. And your previous experience will definitely come in handy! Skills such as:

project management
problem solving
data analytics
design
team management
customer research

... and more are all extremely transferable to a career in web development.

Long-term job satisfaction is all about balance — for example, between work you care about and work that pays you enough for the lifestyle you want. With such high demand for talent, becoming a web developer gives you enough choice to find the role with the right balance for you.

Satisfying work, tangible results 💪

We won't lie — the feeling of being able to say 'I made that!' never gets old. From solving FizzBuzz for the first time to building websites that handle millions of visits a day, a career in web development is full of the satisfaction that comes with cracking complex problems.

And you don't need to train for years before you can start making cool stuff! Once you pick up the basics of frontend development, it won't be long before you can make things like:

Websites and blogs 💻
Games and puzzles 🎲
Calculators and forms 🔢

If you become a web developer, you'll be making tangible products that people use every day — which isn't something you can say about every job out there.

Of course, the flip side of that is the frustration that comes with struggling to get something to work (or the stress of potentially breaking something that people rely on!). If you're easily frustrated or not a fan of problem-solving, web development might not be the role for you. But if enjoy figuring out puzzles and having the autonomy to work things out for yourself, it can be a seriously rewarding career.

Opportunities for growth in almost any direction 🚀

One thing that's sometimes unclear to people before they make the move into web development is what their career progression might look like.

A standard progression over the course of a career might be something broadly along the lines of: Junior Developer → Senior Developer → Tech Lead → Chief Technical Officer (CTO).

💡 Bear in mind that terminology varies between organizations, and 'Tech Lead' in one company might be 'Principal Developer' in another. Most companies also have several levels to each role, for example 'Level 2 Senior Developer.

But this path is by no means the only one available. Once you become a web developer, a wide range of careers open up to you (including setting up on your own as a freelancer!).

If you love working with and coaching people, you might move into team leadership or mentoring.
If you like getting to grips with customer problems and researching their ideal solutions, you might want to become a Technical Product Manager.
If you want to craft entire systems from scratch, you could expand your skillset into full stack development (👉 find out more about frontend vs backend vs full stack development here)
You could even move across to a lucrative role in technical writing, crafting documentation for complex systems.

Dream of becoming a technical expert who sets the direction of an entire organization? Or want to work closely with customers as an all-in-one consultant? Whatever you want from your career, a solid grounding in frontend web development will set you on the right path to achieve it.

You can express your creativity 🎨

Creativity might not be the first word that many people associate with web development. But it's a much more creative career than the stereotypes would have you believe.

If you become a web developer, you'll be entering a career where there's no one 'right' way to solve a problem. Creating good software requires ingenuity, imagination, and a healthy dose of flair.

Web developers work closely with user experience (UX) and user interface (UI) designers to bring a design on a page to life. Developers use programming languages like HTML, CSS and JavaScript to add style, functionality, animation, and more to web interfaces, making them as engaging and user-friendly as possible.

The best developers are often highly creative thinkers, always thinking of new ways to approach their craft. In fact, more and more web designers are teaching themselves to code, and vice versa. Having both skills in your arsenal means you can design and build products from scratch, opening up a wealth of creative possibilities.

Lots of opportunity to collaborate and pick up new skills 🤝

One of the best reasons to become a web developer is the opportunity it gives you to work cross-functionally with different stakeholders across your organization.

In your day-to-day as a web developer, you're likely to work with:

A product manager responsible for the vision and direction of what you're building, making sure it meets the needs of the business and of customers.
A UX designer responsible for crafting the overall experience of using your product or software.
A UI designer responsible for designing the interactive elements of your product (such as buttons and menus) that you then build.

Web developers work collaboratively with these roles to craft products that run smoothly, are user-friendly, and fit the overall aims of the organization.

Outside of your immediate team, you're also likely to have close contact with customer-facing roles like Customer Success Manager or Integrations Manager. You might be helping to troubleshoot a customer problem, or gathering feedback on your latest release.

You might also work closely with the product marketing team to help them showcase what you've built!

If you're looking for a career with plenty of variety and exposure to lots of different business functions, web development could be a really great fit.

The community spirit! 🍻

The global web development community is one of the most vocal, supportive, and fast-growing communities in tech! There are countless Slack groups and Discord servers across the globe that bring web developers together to chat, solve problems and help each other out.

👉 Check out our roundup of the top 9 web developer communities to join to find out more!

It can be a bit counter-intuitive if you come to web development from an academic background, or any environment where googling the answer is considered 'cheating' — but web development thrives on crowdsourced knowledge and sharing solutions to common problems.

From the moment you take the first step on your journey to becoming a web developer, you'll be part of a community of helpful folks around the world who can keep you motivated, inspired, and continuously learning.

You can work from anywhere 💻

Working from home is no longer just an occasional luxury for most people — in fact, 25% of all professional jobs in the US are now fully remote. Most career paths now have some provision for hybrid working, either requiring a certain number of in-office days per week or leaving it completely up to the individual to decide.

The digital-first nature of web development means that it's particularly well-suited to remote working. Even as a Junior Developer, you'll have the opportunity to work from home from anywhere in the world.

The abundance of remote-first opportunities makes web development a great career path for a huge range of people, including:

👩‍👧‍👦 Parents who want the flexibility to work from home
👨‍💻 Neurodivergent folk who have a preferred work setup that meets their needs
✈️ Digital nomads who want to take their work with them on their travels

But if a fully remote career isn't on your agenda, don't worry — the demand for in-office tech teams isn't going anywhere either. There are loads of benefits to having a physical workspace, including a better tech setup (second screen, anyone?) and the opportunity to hang out with colleagues you don't work closely with every day.

Whether you prefer remote, hybrid, or in-office working, the high demand for web developers means that once your career gets going, you'll be able to find the right fit for your style of working.

The flexibility of freelancing 🕺

Not everyone who becomes a web developer wants to work a 9-5. The good news is, freelance web developers are highly sought-after: demand grew by over 40% on freelance platform Upwork in the year to 2022.

Of course, freelancing isn't for everyone. Being employed by a company secures you perks, sick pay, a pension, and all sorts of other useful stuff. But if you want the freedom and flexibility that comes with freelancing — or want to earn some extra money on the side of your day job — becoming a web developer is a great start.

We recently interviewed designer, developer and Scrimba teacher Gary Simon about how he grew his freelance business from $3k a month to $100k a year. To future-proof yourself as a freelancer, Gary says, it's all about continuous learning. Whether it's staying active on developer communities or refreshing yourself on how to rank highly for your services on Google, success as a freelancer requires a constant commitment to learning new things.

💡 If you want to hear more from web developers who made it work as a freelancer, check out these episodes of the Scrimba podcast 👇

️🎙️ Get started freelancing on Upwork with no experience
🎙️ Becoming a six figure freelancer with Gary Simon

It can be really (really!) fun 🎉

Web development can be hard work — it wouldn't be so well-paid if it wasn't! — but for most developers, there's absolutely no shortage of fun and exciting moments to keep you engaged.

Web development is evolving at an incredibly fast pace, which means you never stop learning. From the increased accessibility of AI to exciting new developments in PWA (progressive web application) technology, there's constantly something new to discover and add to your practice.

It's definitely the case that no two days are the same for a web developer. This is a career that requires constant testing and innovation to adapt to fast-changing technology and consumer behavior. And that means there are plenty of opportunities to have fun as you build (and break!) brand-new systems on a day-to-day basis.

A career in development is a uniquely rewarding mix of good pay, good perks, and enjoyable, varied projects to work on (which might be why nearly 24,000 students have taken Scrimba's Frontend Developer Career Path to date!).

BONUS - It's well paid 💰

Okay, we said we wouldn't mention salaries — but this one bears repeating. Starter salaries for web developers are good (often great), and there's potential for it to be an incredibly high-earning career.

We take a deep-dive into salary data in our in-depth guide to becoming a developer in 2023, but to give you a quick idea:

Average web developer salary in the USA 🇺🇸: $53,628-$107,028
Average web developer salary in the UK 🇬🇧: £25,690-£49,434
Average web developer salary in Australia 🇦🇺: A$57,500-A$100,000

And those are just national averages: if you're, say, a Senior Developer working in London, you're likely to be earning a whole lot more.

👉 Curious to know why web development is such a high-earning career? We recently took a deep-dive into web development salaries on the blog, but at a high level it boils down to: high demand, a technical skillset, and significant levels of responsibility.

What next?

2023 is a great year to become a web developer. It's a growing field, there are more remote opportunities than ever before, and salaries are the best they've ever been.

If you want to find out more about how to become a web developer in 2023, we'd recommend checking out our complete guide. In there, you'll find loads more information on web development as a career and how to get started.

And if you're ready to jump in and start learning, our Frontend Development Career Path is designed and created by industry-leading developers to transform beginners into hireable web developers. You'll learn everything from the basics of web dev to advanced interview techniques, all for the fraction of the price of a coding bootcamp.

6 Reasons to learn and use React in 2023

Alex Booker — Sat, 11 Feb 2023 02:09:26 +0000

When Meta (then Facebook) announced React in 2013, it took web developers by storm.

Ten years later, it's natural to wonder: Should I learn React in 2023?

The answer is yes, absolutely!

React is still launching new features all the time and has the weight of Meta and their brilliant, dedicated engineering team behind it.

The ecosystem (think add-on libraries and documentation) has reached a point of maturity, and in most places around the world, there are usually more React jobs than Angular, Vue, or Svelte.

Here are 6 more reasons React is still popular in 2023.

📍 React isn't going anywhere anytime soon
📍 React has great features
📍 React can power any app
📍 There are lots of React jobs
📍React is on the cutting-edge
📍It's "just" JavaScript

React isn't going anywhere anytime soon

When React came out in 2013, it popularised the idea of breaking down your app into components:

It was a bit unorthodox at the time (the best ideas usually are), but developers eventually warmed up the idea they could split the UI into independent, reusable pieces because working on each piece in isolation made them productive.

Working with components in this way meant teams could adopt React piece by piece. Instead of converting their whole application at once (which would put new features on pause and take a lot of time), developers could convert a component here, a component there, and reap the benefits of React incrementally.

When I wrote that "React took web developers by storm," this is exactly how! Year after year, bit by bit, apps incrementally converted to React.

Around the time React was born web apps were becoming more dynamic.

Components are great for managing this newfound complexity, so developers would often react for React when working on new projects as well.

This unique set of circumstances (and the influence of React's creators, Meta) allowed developers to adopt React in a unique way that a new framework or library would struggle to emulate today.

Ten years later, React is tried and true, and there hasn't really been a compelling reason for developers, their teams, or companies to use a new frontend library or framework.

If you learn React in 2023, you can bet it's not going anywhere soon!

ℹ️ Will Svelte take over?

You might have heard of a React competitor called Svelte. Is it a threat to React?

We compared Svelte and React and concluded Svelte is honestly really good! It allows you to achieve the same things as React, albeit in a more concise way. Here's why Svelte doesn't hold a candle to React.

Svelte is a bit better, but it's not so much better that teams will rewrite their apps and learn new technology. React also has more libraries, including React Native, which allows you to build and deploy native-feeling iOS and Android applications.

React has great features

React is fast, modular, and scalable. Without getting too technical, some of the top features include:

A slight learning curve (if you know JavaScript already)
Reusable components
Data binding
High-performance thanks to the vDOM 📈
Support for web and mobile apps with React Native
Dedicated tools like React Developer Tools for easy debugging

React also supports advanced features you might not need today but you'll be glad for later:

Server-side rendering
Efficient data-fetching
Caching
Error-handling
SEO-friendly
Dedicated deployment tools to make your live website as efficient as possible

React can power any app

If you learn React, you can build from basic apps to amazing dashboards. React can be used to create any type of web application, such as:

Social media platforms like Facebook and Instagram
E-commerce websites like Amazon and Etsy
Project management tools like Asana and Trello
Dashboards for data visualization and analytics like Google Analytics and Mixpanel
Gaming platforms like Angry Birds and Candy Crush
Video streaming websites like YouTube and Netflix

Companies using React:

There are lots of React jobs

According to the Stack Overflow Developer Survey for 2021, React was the most popular frontend JavaScript library, with 63.5% of respondents saying they had used it. It was also the fourth most popular technology overall, with 74.5% of respondents saying that they had worked with it 🤯

This shows that there is strong demand for developers who are proficient in React, and this demand will likely continue in the future.

You should also know the average salary for a React developer in the United States is $92,419 per year, according to data from Glassdoor. This is higher than the average salary for a developer with experience in other frontend technologies, such as Angular or Vue.

Overall, learning React is likely to be a valuable investment for frontend developers in 2023 and beyond.

React is on the cutting-edge

Even though React is ten years old, it's not exactly long in the tooth 🦷!

Every year, React releases updates to support the evolving demands of modern web developers.

React Native, a framework for building native mobile applications using React has gained popularity in recent years and is likely to power more and more mobile applications every year.

Moreover, new frameworks like Next.js by Vercel is built on React are gaining popularity. This trend heavily suggests continued interest and investment in the React ecosystem, which will likely contribute to its future growth and development ♻️!

It's "just" JavaScript

One thing that's nice about React is that it's "just" JavaScript, meaning if you already know the fundamentals of JavaScript, it might be easier to learn React than you think!

👀 Suggested reading: How much JavaScript do you need to know before learning React?

React uses JSX, a syntax extension for JavaScript, which allows you to write HTML-like code in your JavaScript.

If you already know HTML, this will make it much easier to learn React, as the syntax is familiar.

import React from 'react';
function Hola(props) {
    return <h1>Hola, {props.name}!</h1>
}

export default Hola;

In this example, the Hola component is a function that takes a props object as an argument and returns a JSX element.

Knowing JavaScript will give you a head start, but it's important to note that React is a large and complex library, and it can take time and practice to become proficient in it.

Give yourself the time you need to fully understand the concepts and build your skills.

👀 Suggested reading: How long to learn React?

The verdict

After considering the various technical and practical benefits of learning React, as well as the current state of the job market and the strong community of developers who use and support the library, we think it's safe to say React is a solid investment for any developer looking to expand their skills and advance their career.

If you are a developer who is interested in learning React, here's my best advice as a Senior React developer:

Start with the fundamentals Make sure you have a solid understanding of the core concepts of React, such as components, state, and props, before moving on to more advanced topics
Practice, practice, practice The best way to learn any new technology is to build things with it. Set aside time to work on projects and exercises, and don't be afraid to make mistakes and learn from them
Join the community React has a large and active community of developers who are always willing to help and share their knowledge. Consider joining forums, meetups, or online communities to connect with other React developers and learn from them
Keep learning React is a rapidly evolving library, and there is always more to learn. Make sure to keep up with the latest developments in the React ecosystem and continue to

There are many resources available for learning React, including online tutorials, video courses, and books. You are reading the Scrimba blog so of course we think you should try our free courses 😉:

Learn React for free is a beginner-level course that covers the fundamentals of React, including components, state, and props. This course comes with structured lessons, experienced instructors (it's the head of Scrimba, in fact!), and hands-on exercises.
Learn advanced React💰 is an intermediate-level course that covers more advanced topics in React, such as hooks, performance optimization, and testing. You need to make sure your existing knowledge is rock-hard, and this course paves a great way for that and takes them to the next level!

Some other popular options for learning React include :

The official React documentation is a comprehensive resource that covers all aspects of React, including core concepts, API references, and examples.
FreeCodeCamp's React course for 2022 is a free, self-paced online course that covers the fundamentals of React, including components, state, and props.
Fullstack React: The Complete Guide to ReactJS and Friends 💰: The Complete Guide to ReactJS and Friends is a paid book that covers the fundamentals of React and related technologies such as Redux and GraphQL.

Will AI like ChatGPT replace programmers?

Alex Booker — Tue, 07 Feb 2023 13:35:50 +0000

ChatGPT. Everyone's talking about it. There's tons of content where people interact with ChatGPT in amazingly creative and even frivolous ways.

ChatGPT can help you plan your day, write an essay, and even make you some money (at least according to so many Tiktok videos).

Developers have not been left behind. For example, joshsowin on Tiktok asked ChatGPT to code an analog clock, and A.I. Financial was able to create a predictive script for Bitcoin trading.

Before you get all giddy, the big question is: just like A$AP Blockie on TikTokasks, will AI take your coding job?

Part of your job as a JavaScript developer involves "CRUD" operations: Create, Read, Update, and Delete. It has to do with sending and retrieving user data.

"Will AI replace JavaScript developers?" or at least part of their job? Bearing in mind that CRUD operations are overly repetitive, and AI automates repetitive tasks?

Let's go on a journey to explore the question, "Will AI make programmers obsolete?" and more.

📍 Will AI replace JavaScript developers?
📍 How does AI write code?
📍 Examples of programming tasks AI is already doing well
📍 What limitations does AI have?
📍 Will learning to code be worth it in the near future?
📍 The verdict

So, will AI replace JavaScript developers?

There are two schools of thought here. There are people who see AI as another tool in developers' arsenals to help increase productivity.

On the other hand, the second school of thought is that AI will get so good that it will replace programmers. Hello ChatGPT?

Let's think about a scenario where a JavaScript developer needs to use a code generator or assistant like ChatGPT, AlphaCode, Co-Pilot, Codex, CodeQL, SonarQube, or Coverity.

Let's ask ChatGPT to generate code to connect our database to our endpoints.

ChatGPT prompts us back, asking for more information about our specific use case and the technology stack.

The assistant generates the code snippet, but you still have to tweak it to fit your particular use case, for example, by taking care of the specific versions of the tools you are using.

Depending on whether your code is in development or production, you might also want to make sure that sensitive information is hidden.

You could have gotten the same information from Stack Overflow. The only difference is that with ChatGPT, you don't get to read through several answers.

Let's further explore the question, "Will AI make programmers obsolete?"

How does AI write code?

If all this talk about AI writing its own code sounds complex or confusing, let's take a step back and have a look at the "behind the scenes" of how it all works.

Before we define AI, let's talk about programming. Programming is the process of writing instructions for a computer to follow so as to achieve a particular goal.

This set of instructions is known as a "program."

You can write a program for an e-commerce site like Amazon. For example. The instructions would be:

A customer logs in.
Goes through the item catalog.
Chooses an item.
Adds it to the cart.
Checks out.

For the above instructions to be carried out, a lot of things need to take place. The user details need to be confirmed, for example.

The instructions, therefore, need to be very specific.

AI, or artificial intelligence, can be seen as "advanced programming." In addition to writing instructions for a computer to follow, we also "teach" it some human intelligence. For example, we "teach" AI to identify cat images.

This happens through a very complex process known as machine learning (ML). In ML, there are models (which represent real-world concepts). Programmers train these models using real-world data.

For example, a programmer can train a machine learning model to identify cat images. To do so, the model has to "see" lots of cat images. Over time, the model will identify the patterns that help it distinguish between a cat and something that is not a cat (something called "unsupervised learning").

The same thing happens with code — a model goes through lots of code or is "trained" via large amounts of code. Over time, it begins to identify the patterns that "define" code. Eventually, it will be able to generate some code.

This is what happened with ChatGPT. ChatGPT is basically a machine learning model that was trained with a lot of data from the internet, including code. The model on which ChatGPT was trained is called GPT-3 (Generative Pre-trained Transformer 3).

It then used an ML concept called reinforcement learning, where models are "rewarded" for accuracy and consistency.

In addition, there were also human AI trainers that helped frame conversations between humans and an AI. The conversations were then "fed" into the models. This is referred to as Reinforcement Learning from Human Feedback (RLHF).

ChatGPT is currently available for free in the research phase.

Now that we know how AI writes code, will AI replace JavaScript developers? Let's keep going to find out.

Examples of programming tasks AI is already doing well

Now that AI is more advanced and there's more infrastructure to handle large data sets, will AI make programmers obsolete?

In this section, we look at some programming tasks that AI is doing well.

Coding competitions

Coding competitions attract lots of developers, and for good reason. They are a good way for programmers to bolster their problem-solving skills. This way, they end up becoming better at their craft.

Moreover, there are also enviable prizes to be won.

AlphaCode is an ML model built for coding competitions. This far, it has ranked among the top 54% in coding competitions on sites like Codeforces, where there are tens of thousands of participants.

Who knows, AI might soon change how hackathons — coding competitions where you get to build a solution within a very short period of time (between 2 and 3 days) — are done.

Debugging

Debugging is a necessary part of writing code. This is because developers need to deliver code that works according to a specified user story.

Remember our "list of instructions" for an e-commerce site? They can be rewritten into user stories, which are more customer-focused.

Instead of "a customer logs in," we can have something like "as Jaime, I would like to be able to log in to my account."

User stories and debugging are some coding best practices that every developer needs to learn in order to deliver a great product.

You can imagine what would happen if anyone was able to log in using Jaime's account. They could steal their credit card information, for example.

Let's not even get started with all the regulations around PII (personally identifiable information), like GDPR.

This is why debugging is important. It helps to identify aspects of your code you might have overlooked, for example, confirming Jaime's credentials before logging in.

The only downside to debugging is that it can get quite time-consuming. While writing tests (another programming best practice) helps with debugging, sometimes a developer can get absolutely "stuck."

They may not be able to identify an error or how to fix it. They spend hours on the internet and on sites like Stack Overflow trying to find out whether other people have experienced similar errors and how to solve them.

The good news is that with AI tools like ChatGPT and SonarQube (a code review tool), debugging becomes a faster process.

AI can therefore be used for pair programming, where it helps you write and debug code.

Let's look at a ChatGPT debugging example.

Image source: https://twitter.com/amasad/status/1598042665375105024/photo/1

A practical use case of the above example is where you might have just learned about the JavaScript setTimeout() method.

You may not understand the output (why it keeps printing "5"). Don't you have a for loop with a condition that checks the value of i every time, (if i < 5)?

Why does it print 5 in the first place, yet the loop should stop when the condition is no longer being met?

The setTimeout() method sets a timer to execute a piece of code when the timer expires.

As you can see, ChatGPT not only points out the bug or error but also suggests a way to fix it.

Note that ChatGPT was not built as a debugger. It is a model that is meant to generate language and code (since code is written in programming languages).

The fact that you can "push" it to debug code means that we already have a framework and blueprint for an AI that can eventually be built to specialize in debugging and generating code.

This would make debugging way faster and easier in the near future, saving developers copious amounts of time.

Code generation

As we have seen in the previous example, AI can help you debug code. In addition, it can generate code from prompts written in human language.

A ChatGPT code generation example

Let's ask ChatGPT to generate a code snippet that can help run the Fibonacci sequence. Its response:

The follow-up prompt was to ask ChatGPT to generate a code snippet for the Fibonacci sequence. It did so in Python.

As you can see, it generated a code snippet in Python and explained the code precisely — the different components, and expected output.

Next prompt: convert the code snippet from Python to Javascript.

Again, ChatGPT converted the code from Python to Javascript and explained it too, stating the expected output.

What limitations does AI have?

We have learned that AI can do some cool and phenomenal things. However, will AI replace web developers?

The good news is that it won't happen. At least not yet. This is because there are a few things AI has yet to figure out and some challenges it has yet to overcome. Let's explore them further.

Legal issues

When an AI uses data from the internet as part of its training data set, there are bound to be legal issues, especially with copyright, intellectual property, and licenses. For example, Codex's neural network (the OpenAI model Copilot is based on) was trained via billions of lines of code stored on GitHub in order to learn how to write code.

We don't know whether it only used code from public GitHub repositories or under free distribution licenses.

Recent research from MIT, on the other hand, shows that machine learning models trained with synthetic data can sometimes be more accurate than those trained with real-world data.

This could help with copyright issues. It would raise problems like working excellently in isolated cases (something referred to as "local maxima") but failing miserably at generalization.

For accurate results, a good ML model must be able to generalize data well.

Let's delve into accuracy when it comes to AI.

Accuracy

AI models like ChatGPT do give incorrect responses. In fact, in December 2022, answers from ChatGPT were temporarily banned from StackOverflow due to inaccuracy.

The AI does caution about its accuracy limitations, though.

The AI gives inconsistent responses as you tweak consecutive prompts. Besides, even when it's plainly wrong, it sounds really confident.

Another aspect that affects chatGPT's accuracy is the fact that it was trained with data until the beginning of 2022.

This makes it impossible to show current data. If you ask for current information, it says that it is unable to search the internet.

In addition, ChatGPT responses are inherently biased. It can, as a result, respond to harmful prompts or give inappropriate responses.

ChatGPT is also too wordy and uses the same phrases over and over, like saying again and again that it is a language model trained by OpenAI.

The company behind ChatGPT, OpenAI, on the other hand, is eager to address its model's limitations. This could hopefully resolve the inaccuracies and biases in the future.

The need for human input

While AI is doing a great job at code generation, it still needs input from humans to write code that actually works.

For example, when ChatGPT was asked to write a game in pure Javascript, HTML, and CSS, it did not give a complete response when asked to add the specified functions.

Moreover, it still needed more prompts to generate code that worked as expected.

So, will AI replace web developers? Not really.

Will learning to code be worth it in the near future?

Despite the advancements that we are seeing in AI, coding will still be an important skill in the near future.

Let's imagine for a moment that an AI like ChatGPT can write perfect code.

First, we'll still need humans who understand code to write appropriate prompts for AI to use. Secondly, a programmer needs to "verify" that the generated code actually works for their particular use case.

Thirdly, we need humans to think about other aspects of the software that is being built---the user experience and other constraints that may affect performance and scalability.

For example, programmers will need to make decisions on the best software combination to go with to ensure that it can handle traffic spikes.

In short, there are things AI cannot do yet, so learning to code is still a great idea. So, will AI replace JavaScript developers? Highly unlikely.

Code generation tools are "assistants." There's a reason why Github's code-generating tool is called Co-pilot. It is helping you "navigate" through your code, rather than taking over the pilot's seat.

As we mentioned, AI would work great for pair programming. You become the navigator, instructing it, and it generates code as the driver.

We cannot ignore the fact that AI is getting better at learning. Who knows? We might see a decrease in demand for coding skills.

We might actually be very wrong. There's a book called "Optimism Bias" by Tali Sharot, and it scientifically explains why humans are wired to misinterpret the reality of circumstances and how grossly inaccurate we can get with predicting our own futures.

So, AI might actually be coming for web development jobs 🤭

The verdict

So, will AI replace JavaScript developers? We have gone on a wild ride where we have explored some ways that people are imaginatively using AI, from making their lives and work easier to generating code.

We then dove deeper into questions around "Will AI make programmers obsolete?" We defined how AI generates code — the "behind the scenes" of how AI "writes" code.

We also looked at some examples of where AI is thriving as well as some of its limitations. Finally, we concluded that learning to code is still a valuable skill in the wake of AI advancements.

It is important to note that AI will keep getting better, and it might be a smart move to upskill and acquire advanced skills like DevOps in the future. Or stay alert for new jobs that will be created as a result of AI.