DEV Community: The Gnar Company

React Server Components Example with Next.js

Royce Threadgill — Tue, 16 Apr 2024 19:17:12 +0000

React Server Components (oftentimes shortened to RSC) provide us with a fascinating new approach to building React applications.

That said, my experience while researching this article was far less rosy and far more expletive laden than I expected.

But now that I have been one acquainted with the RSC, I’d like to share my findings with you so that hopefully your learning journey won’t be quite as painful or confusing.

In this article, we’ll discuss a range of topics, including:

What are React Server Components?
Can you use React Server Components without Next.js?
How do React Server Components work in Next.js?
What are the advantages and disadvantages of React Server Components?
Are React Server Components production ready?

We’ll also go through a React Server Components example using the Next.js app router. That example will discuss RSC streaming behavior and client and server component nesting. If you’re only interested in the code example, just scroll to the bottom of the article.

Let’s begin!

What are React Server Components?

My favorite definition of RSC comes from Mark Dalgleish in his 2023 React Advanced conference talk, “Simplifying Server Components”. The way he puts it is that “server components are just virtual DOM over the network”.

What does this mean?

Let’s say we have a React component called Basic:

const Basic = () => {
  return (
    <main>
      <p>Hello, World</p>
    </main>
  );
};

On the server, that component would be serialized into what’s known as an RSC payload. That would look something like this in the Next.js server component implementation.

// ...complicated Next.js stuff up here
{
  children: [
    "__PAGE__",
    {},
    [
      "$L1",
      [
        "$",
        "main",
        null,
        {
          children: ["$", "p", null, { children: "Hello, World" }],
        },
      ],
      null,
    ],
  ];
}
// ...more complicated Next.js stuff down here

That RSC payload would then be streamed down to the client and rendered exactly like any other JSX.

ℹ️ Sidenote: This explanation gets at the core of React Server Components, but is a little simplified. If you want to learn more about what’s happening under the hood, I highly recommend watching to Daishi Kato’s “Exploring React Server Component Fundamentals” talk at React Day Berlin 2023.

Seems pretty simple, right? So why bother with this RSC payload nonsense? Why not just render the component to HTML and stream that down to the client?

Well, we can! Typically, we would call this server side rendering (SSR).

React Server Components vs SSR

We’ve actually been able to serialize React components to HTML for several years now.

You can find a solid definition of SSR in the Vite documentation:

SSR specifically refers to front-end frameworks (for example React, Preact, Vue, and Svelte) that support running the same application in Node.js, pre-rendering it to HTML, and finally hydrating it on the client.

Put simply, SSR pre-renders a React component to HTML, while RSC serializes a React component into an RSC payload.

Server components have a couple advantages over traditional SSR. For one, SSR requires a hydration step once the HTML has been sent to the client; the initially loaded page isn’t interactive until the entire JS bundle is downloaded and the entire page is hydrated.

By comparison, server components require no hydration step, allowing pages to load faster and become interactive more quickly.

The page loading issues raised by SSR can be mitigated by chunking your JavaScript bundle and streaming it to the client, but eventually the entire bundle needs to be downloaded. And that bundle tends to get larger as your application grows.

Server components, meanwhile, add no additional JavaScript to your bundle. As your application grows, your JavaScript bundle size does not grow with it (assuming you only use server components).

ℹ️ Sidenote: It’s important to note that RSC and SSR aren’t mutually exclusive. You can learn a bit more about this by reading “Making Sense of React Server Components” by Josh Comeau.

Server Components vs. Client Components

The Basic component above was a simple example. What happens when we add interactivity to our component?

Let’s say we add a Counter to our Basic component:

const Basic = () => {
  return (
    <main>
      <Counter />
      <p>Hello, World</p>
    </main>
  );
};

When we interact with the Counter, we would expect the value to increment. In other words, that component has state and must be declared as a client component in our React code.

How do we represent such a component in a format that can be generated on the server and sent to the client? The answer, as you may have guessed, lies in the RSC payload.

When a bundler supporting React Server Components detects a client component, it adds a reference to that component in the RSC payload – react.client.reference.

The bundler also generates a manifest that maps the reference ID to the actual client component, which determines what JavaScript must be sent to the client (meaning that, unlike server components, client components will contribute to your bundle size).

In Episode #311 of the Changelog podcast, Dan Abramov said (and I’m paraphrasing a bit here) the RSC payload resulting from such scenarios can be thought of as having a script tag in place of the client component.

ℹ️ Sidenote: If you’re interested in learning a bit more about how client components are serialized, take a look at “React Server Components, without a framework?” by Tim Pillard.

As the late Billy Mays would say, “But wait, there’s more!”

What happens when you nest a server component inside that client component? As wacky as it sounds, your bundler recognizes that as a server component and serializes it as such in the RSC payload.

Don’t worry, we’ll get more into server components vs client components in our code example. But first, let’s address the elephant in the room….

React Server Components Without Next.js…?

Daishi Kato, creator of Zustand and Jotai, says there are a few things we need to support RSC serialization:

Bundler capable of recognizing client components, generating a manifest, and resolving client references on the client
Server capable of accepting HTTP requests and responding with (dynamic) RSC payloads
Router capable of intelligently serving resources (e.g., don’t render client components that are not useful for a given route)
SSR that works in tandem with React Server Components, largely for initial page load performance

So while the RSC concept is fairly straightforward in theory, there are a number of moving parts necessary for implementing RSCs in practice.

Currently, Next.js is the only production framework that fully supports RSCs.

This isn’t an accident; when Meta introduced React Server Components, Dan Abramov explicitly stated that they collaborated with the Next.js team to develop the RSC webpack plugin.

That means you’re mostly limited to Next.js if you’d like to build an app with RSCs.

📣 Important: This article was originally written in March 2024. At the very end of that month, RedwoodJS announced full support for server components! While there still appear to be some implementation issues, RedwoodJS does now offer a viable alternative for implementing React Server Components in production.

But What If I Really Don’t Like Next.js?

If you’re really against using Next.js, your options are limited and largely experimental.

The moderators at Reactiflux pointed me toward Waku (also developed by Daishi Kato) as a potential alternative. However, Daishi explicitly recommends using the framework on non-production projects.

At Node Conference 2023, Jarred Sumner (creator of Bun) showed a demo of server components in Bun, so there is at least partial support in that ecosystem. The Bun repo provides bun-plugin-server-components as the official plugin for server components. And while I haven’t looked at it in-depth, Marz claims to be a “React Server Components Framework for Bun”.

In the Changelog Podcast episode referenced above, Dan Abramov alluded to Parcel working on RSC support as well. I couldn’t find much to back up that claim aside from a GitHub issue discussing directives and a social media post by Devon Govett (creator of Parcel), so I can’t say for sure if Parcel is currently a viable option for developing with RSCs.

And you can’t use React Server Components with Vite right now, but support is being worked on.

React Server Components Example with Next.js

Alright, with that out of the way, let’s get to the code example. Note that we’re using Tailwind for styling just to make the example a bit less ugly; Tailwind has no other bearing on the example.

For reference, here are our dependencies:

"dependencies": {
    "react": "^18",
    "react-dom": "^18",
    "next": "14.1.3"
  },
  "devDependencies": {
    "typescript": "^5",
    "@types/node": "^20",
    "@types/react": "^18",
    "@types/react-dom": "^18",
    "autoprefixer": "^10.0.1",
    "postcss": "^8",
    "tailwindcss": "^3.3.0",
    "eslint": "^8",
    "eslint-config-next": "14.1.3"
  }

We’re going to cover a few concepts here, but we’ll start with a React Server Components Suspense example to demonstrate how payload streaming is handled.

React Server Components and `Suspense`

React Suspense can intelligently display parts of the RSC payload as they are streamed down to the client. If the component is not yet available, Suspense will fall back to a loading state.

Let’s say we have a component Multiple, which has multiple server components that take varying amounts of time to load:

// src/app/multiple/page.tsx

const Multiple = () => {
  return (
    <main className="flex min-h-screen flex-col items-center justify-between p-24">
      <div className="flex w-1/2">
        <div className="flex flex-col gap-8">
          <h1 className="text-4xl">Multiple long loading things</h1>

          <Suspense fallback={<p>Loading...</p>}>
            <LongLoadingComponent />
          </Suspense>

          <Suspense fallback={<p>Loading...</p>}>
            <LongerLoadingComponent />
          </Suspense>

          <Suspense fallback={<p>Loading...</p>}>
            <LongestLoadingComponent />
          </Suspense>
        </div>
      </div>
    </main>
  );
};

export default Multiple;

Each server component is wrapped within a Suspense component, which falls back to “Loading…” text until the server component is available.

For the purposes of this example, we’ll mock each long running query with a Promise that resolves after a defined timeout. So each of the server components will look something like this:

const longLoadingFetch = async () => {
  const promise = new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve("Vegeta, what does the scouter say about his power level?");
    }, 2000);
  });

  return promise;
};

const LongLoadingComponent = async () => {
  const res = await longLoadingFetch();

  return (
    <div className="text-white border border-white p-4">{res as string}</div>
  );
};

export default LongLoadingComponent;

Each component will have a different timeout value and string to simulate different server components with different query durations.

Initially, each server component is unavailable and all display the “Loading…” text. Then the quickest component renders, then the second quickest, then the third quickest.

In Episode #718 of the Syntax podcast, Wes Bos pointed out a handy RSC Devtools Chrome extension that we can use to better understand what’s going on here.

We can see that we have three lazily loaded components, which lines up with what we would expect. If we click on the first node, we see the RSC payload and the rendered content.

Also note that the page header has already been rendered! The remainder of the RSC payload is streamed down to the client as it becomes available. Importantly, this means the long-running queries are not blocking page rendering.

ℹ️ Sidenote: If you’d like to learn more about how the RSC payload is streamed to the client, check out “Why React Server Components Are Breaking Builds to Win Tomorrow”.

But you may have noticed that this example only deals with server components. Let’s examine a more complex example that involves both client and server components.

Interleaving Client and Server Components

This is where the fun begins. In this example, we’ll be looking at how to implement some basic search functionality. Let’s take a look at the Search component:

// src/app/search/page.tsx

const Search = ({
  searchParams,
}: {
  searchParams?: { [key: string]: string | string[] | undefined };
}) => {
  return (
    <main className="flex min-h-screen flex-col items-center justify-between p-24">
      <div className="flex w-1/2">
        <div className="flex flex-col gap-8">
          <h1 className="text-4xl">Search example</h1>

          {/* client component */}
          <CounterProvider>

            {/* client component */}
            <SearcheableToDoList>

              {/* client component */}
              <SearchField />

              <Suspense fallback={<p>Loading...</p>}>

                {/* server component */}
                <ToDoList searchParams={searchParams}>

                  {/* client component */}
                  <CounterDisplay />
                </ToDoList>
              </Suspense>
            </SearcheableToDoList>
          </CounterProvider>
        </div>
      </div>
    </main>
  );
};

export default Search;

I’ve added comments to indicate where there are server and client components. Note that the searchParams value passed into the Search component is a Next-specific property containing the query parameters for the page.

Let’s briefly discuss what the individual components are doing:

CounterProvider is a client component providing a context to its children components; the context value is just counterVal and setCounterVal.
SearcheableToDoList is a client component wrapper that uses the above context to increment the counter value on clicking a button; it displays the counterVal, a button to increment the counter, and its children.
SearchField is a client component input that updates the URL query parameters
ToDoList is a server component that reads data from a data.json file, then filters that data based on the searchParams retrieved in the Search parent; it displays the resulting data and its children.
CounterDisplay is a client component that displays the counter value from the CounterProviderContext.

The Next.js documentation refers to this nested pattern as “interleaving” server and client components.

But how is it that we can nest a server component within our client components?

Recall that React Server Components are just serialized vDOM sent over the network. So as long as the content in the React tree is serializable, it can be handled without issue by your bundler.

In this case, the ToDoList server component is serializable specifically because it is a child of its client component wrapper. Children of a React component are really just props – and props are serializable!

Here’s what the rendered components look like.

There are a couple other little tidbits we can glean from the interleaved components.

You Can Still Use Contexts (Carefully)

In Next.js v13+, all components are server components by default and cannot use state hooks like useState, useEffect, or useContext.

Client components operate exactly the same as before and can use state hooks. For example:

"use client";

type CounterProviderValue = {
  counterVal: number;
  setCounterVal: Dispatch<SetStateAction<number>>;
};

export const CounterProviderContext: React.Context<CounterProviderValue> =
  createContext<CounterProviderValue>({
    counterVal: 0,
    setCounterVal: () => {},
  });

export const CounterProvider: React.FC<PropsWithChildren> = ({ children }) => {
  const [counterVal, setCounterVal] = useState(0);

  return (
    <CounterProviderContext.Provider value={{ counterVal, setCounterVal }}>
      {children}
    </CounterProviderContext.Provider>
  );
};

We declare CounterProvider as a client component with the use client directive at the top of the file. This directive is how the bundler identifies CounterProvider as a client component and treats it accordingly in the RSC payload.

We can use useState in CounterProvider only because we’ve declared it as a client component.

Similarly, we can access the counterVal and setCounterVal in child components, but only if those children are client components.

"use client";

const SearcheableToDoList: React.FC<PropsWithChildren> = ({ children }) => {
  const { counterVal, setCounterVal } = useContext(CounterProviderContext);

  return (
    <div className="flex flex-col gap-2">
      <div className="flex gap-2">
        <button
          className="bg-white text-black"
          onClick={() => setCounterVal(counterVal + 1)}
        >
          Counter
        </button>
        <CounterDisplay />
      </div>
      <div className="flex flex-col gap-2">{children}</div>
    </div>
  );
};

export default SearcheableToDoList;

Because SearcheableToDoList is a client component, we can access counterVal and setCounterVal via useContext.

The same can be said of CounterDisplay. As long as it is declared as a client component, we can use counterVal and setCounterVal. That’s true even when CounterDisplay is a child of the ToDoList server component.

"use client";

const CounterDisplay = () => {
  const { counterVal } = useContext(CounterProviderContext);

  return <span>Count is {counterVal}</span>;
};

export default CounterDisplay;

You Can Use Server Code in Server Components

Server components are rendered on the server, so we can use any server side code we'd like! For instance, we can read from the file system in ToDoList to return the list of filtered to-dos.

import { promises as fs } from "fs"; // import included for clarity

type ToDoListProps = PropsWithChildren & {
  searchParams?: { [key: string]: string | string[] | undefined };
};

type ToDo = {
  id: number;
  heading: string;
  body: string;
  isFavorite: boolean;
};

const fetchData = async (searchParams: {
  [key: string]: string | string[] | undefined;
}) => {
  const file = await fs.readFile(`${process.cwd()}/src/app/data.json`, "utf8");
  const parsedJson = JSON.parse(file);
  const { data } = parsedJson;

  const headingSearch = searchParams["heading"] as string;

  const res = (data as ToDo[]).filter((item) =>
    item.heading.includes(headingSearch)
  );

  return res;
};

const ToDoList: React.FC<ToDoListProps> = async ({
  searchParams,
  children,
}) => {
  const data = await fetchData(
    searchParams as { [key: string]: string | string[] }
  );

  return (
    <div className="flex gap-4">
      <div className="flex flex-col gap-4">
        {data.map((item: ToDo) => (
          <div key={item.id} className="border border-white p-4">
            <h2 className="text-2xl">{item.heading}</h2>
            <p>{item.body}</p>
          </div>
        ))}
      </div>
      <div>{children}</div>
    </div>
  );
};

export default ToDoList;

When SearchField updates the query parameters, the searchParams passed to Search are updated and passed to ToDoList. We then search the file system using fs.readFile and filter out the results based on the provided query parameters.

ℹ️ Sidenote: This works for our example, but there’s a bit of nuance here with Next.js caching behavior that may cause issues if you try something similar in production. Check out this GitHub discussion and the Next.js docs for more information.

After we’ve fetched our data and populated the component, the resulting RSC payload is streamed down to the client. Notably, this means that JavaScript used within your server component (including imports) does not get added to the bundle on your front-end!

For completeness, here’s the SearchField component code:

const SearchField = () => {
  const router = useRouter();
  const pathname = usePathname();

  const [searchText, setSearchText] = useState("");

  const searchTextTimeout: ReturnType<typeof setTimeout> = setTimeout(() => null, 500);
  const searchTextTimeoutRef = useRef<ReturnType<typeof setTimeout>>(searchTextTimeout);

  useEffect(() => {
    clearTimeout(searchTextTimeoutRef.current);

    // this is just a debounce so we don't update query params on every keystroke
    searchTextTimeoutRef.current = setTimeout(() => {
      router.push(
        !!searchText?.length ? `${pathname}/?heading=${searchText}` : pathname
      );
    }, 500);
  }, [searchText, searchTextTimeoutRef, router, pathname]);

  return (
    <div>
      <input
        className="text-black"
        onChange={(e) => setSearchText(e.target.value)}
      />
    </div>
  );
};

What Are the Advantages of React Server Components?

Using server components means your JavaScript bundle size will not scale with the size of your codebase. Couple this with the fact that server components don’t require hydration and you get a shortened time-to-interactive and a reduction in page load times.

That reduced bundle size means client machines don’t need to download as much JavaScript. Additionally, executing JavaScript on the server is often more efficient for the end-user than executing it on the client (especially for mobile devices). Both of these points lead to improved user experiences for Next.js v13 and up.

Another interesting point is that executing fetches on the server can allow developers to more easily leverage caching. Next.js already handles caching out-of-the-box and I’m curious to see if the wider adoption of RSC reduces the need to combine React with solutions like Apollo Server and Apollo Client. While there are other benefits to these tools, RSC could provide similar caching behavior without the need to invest in a GraphQL solution.

Combining React Server Components and Suspense (along with traditional SSR) should also go a long way toward improving interaction to next paint (INP) for Next.js applications.

📣 Important: As state above, RedwoodJS very recently added RSC support. That team also emphasized the overlap in functionality between RSC and GraphQL.

What are the Disadvantages of React Server Components?

The main disadvantage of React Server Components, in my mind, is the significant increase in complexity.

A portion of this complexity should fade as React developers get accustomed to the new patterns necessitated by RSC. But as currently implemented, I do think RSC reduces the overall ergonomics of React – especially on any page with multiple nested client/server components and contexts.

Another disadvantage lies with RSC support. Since Next.js is the only framework supporting React Server Components, you’re stuck with it for now. And since Next.js works best when deployed to Vercel, some might also argue that narrows your choice of hosting providers.

Outside of JavaScript frameworks, there is a known issue with CSS-in-JS libraries including emotion and styled-components. That problem isn’t insurmountable, but will complicate incremental adoption for large, established code bases. Poor server component support by other libraries will also have a similar effect.

Are React Server Components Production Ready?

My answer here would be a solid “yes, but…”.

If you’re using Next.js or plan to use Next.js, then React Server Components are production ready. There are definitely rough edges in the Next.js implementation, but I don’t think that’s a show stopper.

That being said, I suspect that greenfield projects will have an easier time adopting RSC since they can pick and choose compatible libraries. Established codebases may find it very time consuming to update their existing code to cooperate with RSCs, especially given the dearth of libraries supporting it.

ℹ️ Sidenote: If you want more insight on this, check out Are we RSC yet?.

If you are not using Next.js and do not plan to, I would personally advise against implementing RSC into production code until support has improved.

Open Questions About React Server Components

In writing this article, I began forming some questions that I don’t yet have the answer to. These include:

How much will the combination of React Forget and React Server Components improve React performance overall? Will they impact or compliment one another at all?
How will React Server Components work with Expo and React Native?
How does Turbopack fit into this? Will it bring RSC functionality to other frameworks?

If you know anything about these topics, please feel free to let me know! I’d love to learn from you.

Further Resources and Special Thanks

Thanks for sticking with me until the end of a long article! Here are a few additional resources I came across if you’d like to learn more about React Server Components:

I’d also like to extend my thanks to multiple people who provided feedback and pointed me toward resources while writing this article. Thank you for the help and I hope this was an enjoyable read!

Learn more about how The Gnar builds React applications

Creating Passkey Authentication in a Rails 7 Application

Royce Threadgill — Wed, 27 Mar 2024 17:39:10 +0000

If you're looking to allow your users to log into your Rails 7 app with passkeys, well searched.

This article is specifically about passkeys, which are a form of passwordless login that replaces passwords with secure, per-device keys (the eponymous passkeys) which are handled by the device's operating system.

As of this writing, up-to-date Windows, macOS, iOS, and Android all support passkeys. Linux users with the correct browser or browser extension can also use passkeys.

This widespread support is due to the standard called FIDO2, which covers two components: WebAuthn and CTAP2. WebAuthn handles communication between a relying party (your app) and a credential provider (we'll use Bitwarden's Passwordless.dev), while CTAP2 handles key management and communication between the browser and the operating system.

We won't need to worry about either of these standards, since using Bitwarden as a passkey provider means we can use their open-source library to handle the details.

Rails 7 Passkey Authentication Example

Now that we have a concept for what passkey auth is and how it works, let's implement it in a Rails app. You can find the repo for our example at https://github.com/JackVCurtis/devise-passkeys-example.

We are going to implement a passwordless strategy using Devise. For the uninitiated: Devise is an authentication gem commonly used in Rails applications. It provides several off-the-shelf strategies which abstract the core concepts typically encountered in conventional web authentication.

The core functionality of Devise focuses on the username/password authentication paradigm. Here we will add a custom strategy to Devise using passkeys rather than username/password.

As we mentioned earlier, Bitwarden (specifically Passwordless.dev) is a passkey provider which manages both sides of the passkey management flow (WebAuthn and CTAP2). The first step of our process is to create an account and an application with Passwordless.dev.

You will be given three values: An API URL, an API private key, and an API public key. Create a .env file and provide these values:



BITWARDEN_PASSWORDLESS_API_URL=
BITWARDEN_PASSWORDLESS_API_PRIVATE_KEY=
BITWARDEN_PASSWORDLESS_API_PUBLIC_KEY=

Set up your database and run the app locally:



rails db:create
rails db:migrate
rails s

Install Devise and associate it with a User model. I recommend removing the password field before running the migration; otherwise Devise will create an automatic presence validation on the password, which we will not be using.

The migration file that Devise generates, after we have removed the password field, should look something like this:



# frozen_string_literal: true

class DeviseCreateUsers < ActiveRecord::Migration[7.1]
  def change
    create_table :users, id: :uuid do |t|
   ## Passkey authenticatable
      t.string :email,              null: false, default: ""

   ## Rememberable
      t.datetime :remember_created_at

      ## Trackable
      t.integer  :sign_in_count, default: 0, null: false
      t.datetime :current_sign_in_at
      t.datetime :last_sign_in_at
      t.string   :current_sign_in_ip
      t.string   :last_sign_in_ip

      ## Confirmable
      t.string :unconfirmed_email
      t.string   :confirmation_token
      t.datetime :confirmed_at
      t.datetime :confirmation_sent_at

      t.timestamps null: false
    end

    add_index :users, :email,                unique: true
    add_index :users, :confirmation_token,   unique: true
  end
end

Install the Bitwarden Passwordless.dev JS client using your choice of package manager. The example uses import-maps.

Add our custom passkey Devise module and strategy under the lib/devise directory.

lib/devise/models/passkey_authenticatable.rb:



require Rails.root.join('lib/devise/strategies/passkey_authenticatable')

module Devise  
    module Models  
        module PasskeyAuthenticatable  
            extend ActiveSupport::Concern  
        end  
    end
end

lib/devise/strategies/passkey_authenticatable.rb:



module Devise
  module Strategies
    class PasskeyAuthenticatable &lt; Authenticatable
      def valid?
        params[:token]
      end

      def authenticate!
        token = params[:token]
        res = Excon.post(ENV['BITWARDEN_PASSWORDLESS_API_URL'] + '/signin/verify', 
          body: JSON.generate({
            token: token
          }),
          headers: {
            "ApiSecret" =&gt; ENV["BITWARDEN_PASSWORDLESS_API_PRIVATE_KEY"],
            "Content-Type" =&gt; "application/json"
          }
        )

      json = JSON.parse(res.body)
      if json["success"]
        success!(User.find(json["userId"]))
      else
        fail!(:invalid_login)
      end
    end
  end
end

Warden::Strategies.add(:passkey_authenticatable, Devise::Strategies::PasskeyAuthenticatable)

Generate the Devise controller for sessions and configure your routes.

config/routes.rb:



devise_for :users, controllers: {
  sessions: "users/sessions"
}

Replace app/controllers/users/sessions.rb with the following:



# frozen_string_literal: true

class Users::SessionsController < Devise::SessionsController
  before_action :configure_sign_in_params, only: [:create]

  protected

  def configure_sign_in_params
    devise_parameter_sanitizer.permit(:sign_in, keys: [:token])
  end
end

Create a Stimulus controller at app/javascript/controllers/passwordless_controller.js:



import { Controller } from "@hotwired/stimulus"
import { Client } from '@passwordlessdev/passwordless-client';


export default class extends Controller {
  static targets = [ "email" ]

  connect() {
    this.client = new Client({ apiKey: window.VAULT_ENV.BITWARDEN_PASSWORDLESS_API_PUBLIC_KEY });
    this.csrf_token = document.querySelector('meta[name="csrf-token"]').content
  }

  async register() {
    const email = this.emailTarget.value
    const { token: registerToken } = await fetch('/api/registrations', {
      method: 'post',
      headers: {
        'content-type': 'application/json'
      },
      body: JSON.stringify({
        email: email,
      })
    }).then(r => r.json())

    const { token, error } = await this.client.register(registerToken)

    if (token) {
      await this.verifyUser(token)
    }

    if (error) {
      console.log(error)
    }
  }

  async login() {
    // Generate a verification token for the user.
    const { token, error } = await this.client.signinWithAlias(this.emailTarget.value);

    if (token) {
      await this.verifyUser(token)
    }
  }

  async verifyUser(token) {
    const verifiedUser = await fetch('/users/sign_in', {
      method: 'post',
      headers: {
        'content-type': 'application/json'
      },
      body: JSON.stringify({
        token,
        authenticity_token: this.csrf_token
      })
    }).then((r) => r.json());

    if (verifiedUser.id) {
      window.location.reload()
    }
  }
}

And insert the controller in the HTML at app/views/users/new.html.erb:



<h1>Sign Up</h1>

<% if current_user %>
  <h2>You're logged in!</h2>

  <%= button_to(
          "Log Out",
          destroy_user_session_path,
          method: :delete
        ) %>
<% else %>
  <div data-controller="passwordless">
    <input data-passwordless-target="email" type="email">

    <button data-action="click->passwordless#register">
      Create Account
    </button>

    <button data-action="click->passwordless#login">
      Log In
    </button>
  </div>
<% end %>

Navigate to your new combined signup/login page and test it out!

Contributors:

Learn more about how The Gnar builds Ruby on Rails applications.

DevSecOps 101: What is DevSecOps?

Royce Threadgill — Sat, 27 Jan 2024 05:49:10 +0000

DevSecOps vs. DevOps

Though there is overlap between Development Security Operations (DevSecOps) and Development Operations (DevOps), they are two distinct topics.

So, what is the difference between DevOps and DevSecOps?

Let's first start by defining DevOps. Roughly speaking, I see DevOps as the practice of using automation to turn code (“development”) into deployments on real infrastructure (“operations”) automatically.

On the other hand, we can define Dev_Sec_Ops as the integration of security tooling into the CI/CD pipeline to enforce security at each stage of the development and release process.

If you have a CI/CD pipeline, you’re implementing DevOps. If you run Brakeman during CI/CD, you’re implementing DevSecOps.

DevSecOps as Company Culture

For a deeper dive, I really like this description of DevSecOps by Snyk. It's worth noting that Snyk’s DevSecOps definition along with the one from RedHat both use the word "culture" in characterizing the practice.

It's not a mistake or a hyperbole; embracing DevSecOps demands moving beyond the old "set it and forget it" mentality. You are probably already adopting DevSecOps at some level; you just may not be doing a satisfactory job yet.

Adopting DevSecOps means embracing the additional responsibility that software security requires. It means using - and understanding - the relevant DevSecOps tools for each stage of the security lifecycle.

It's a bit of a paradigm shift; many software devs still consider security outside of their job description, and fairly so. But as security moves more and more into the software development lifecycle (which is now fairly married to the deployment lifecycle), it is necessary that all parties involved in that lifecycle be conversant with the security implications of their work. Christophe Limpalair at Spacelift puts it nicely:

"...most people view security as an annoyance and as something that adds extra friction to the development and deployment process. Instead of accepting that and putting security on the back burner, DevSecOps brings security back to the forefront by saying “you know what, security is critical and must be part of our process, so let’s make it fit in as painlessly as possible."

It's an elephant, but once we break it down we should see that each bite is manageable.

The US Department of Defense (DoD) does a very nice job of visualizing the DevSecOps lifecycle:

Read more in the DoD Enterprise DevSecOps Strategy Guide.

There are many similar diagrams online, but I find the DoD's to be the most clear and consumable.

So what do each of these steps mean? Let's break them down a bit.

Plan: Threat Analysis

List all assets that need to be protected (user devices, servers, developer devices), the actors they need to be protected from (ransomware gangs, “hacktivists”, advanced persistent threats like North Korea’s Lazarus Group), and the vulnerabilities those actors could exploit (unauthorized data access, server access, cross-site scripting, compromised SSL certificates).

A threat analysis plan is often articulated in a threat analysis chart like this one from Network Analysis, Architecture, and Design.

Develop: Secure Coding; Security as Code

Ensure that developers know the best practices around their language and framework (Ruby on Rails, React Native, etc.). Automate your security tooling using infrastructure as code.

Learn more by reading Snyk’s article on secure coding practices and GitLab’s security-as-code guide.

Build: Static Application Security Testing (SAST)

Analyze your source code for any recognizable weaknesses with SAST tools. This is language- and framework-specific. SAST runs as part of your build pipeline. Examples:

Bundler Audit (ruby)
Brakeman (Ruby on Rails)
NPM Audit (JavaScript)
Sobelow (Phoenix Framework)

Test: Dynamic Application Security Testing (DAST)

Actively scan for exploitable weaknesses. DAST software runs against a test environment. This is language-agnostic testing, usually for web applications. ZAP is a good example of DAST software.

Test: Penetration ("Pen") Testing

Bring on dedicated specialists to attempt to hack a test environment with a variety of tools, and provide a report of vulnerabilities after doing so. There are many consulting firms which provide pen test services.

Snyk’s penetration testing guide is a good introduction to penetration testing concepts.

Release: Digitally Sign

Use cryptographic signatures to verify that source code is unmodified from the version published by the source domain/package maintainer. If someone were to manipulate the file containing your program to include malicious code, this would be detected by a signature verification tool.

Deliver: Secure Transfer

Ensure that your code is deployed via an encrypted and secure connection. Most cloud platforms will do this automatically.

If using containers, ensure that the container registry and container image is secure using tools like Clair.

Deploy: Security Config, Security Scan

Define and configure your infrastructure using infrastructure as code tools like AWS CDK.

Scan that infrastructure with a tool like Cloudsploit (Multicloud), KubiScan (Kubernetes), or Amazon Inspector (AWS). Like SAST tools, the tools you choose will be specific to your platform.

Operate: Security Patch

Continually patch your code to the latest version. Use tools like dependabot and bundler-audit.

Monitor: Security Audit, Security Monitor

Continuously assess the security of your application's data. This step is best considered after you understand what it is you are monitoring (see everything above). This sounds obvious, but plenty of devs hook up a monitoring system without really knowing what is being monitored.

In addition to monitoring the software processes, a security audit should also review the user processes, i.e. how users access and share data within and outside of the application.

Shout out to Wazuh as a comprehensive monitoring/dashboard tool, while AWS has Amazon Security Hub. For auditing there’s a wide range of options, but TechTarget’s security audit guide is a good place to start.

Conclusion

Investing in a legitimate DevSecOps strategy at your organization is certainly no small investment, in time or resources. But it is a very surmountable challenge.

If we break the process down as above and become comfortable with each step of the process, we can weave these security practices into the existing fabric of our software lifecycle.

And if there is any question about whether this venture is worth the time or resources it demands, I would point you to research into the savings a company will realize by investing in a DevSecOps strategy.

If you're interested in jumping into DevOps or DevSecOps, or if you are already on your way and would like some feedback, shoot us a line. We'd love to hear from you.

Contributors:

Learn more about how The Gnar builds software.

Gnarly Learnings from December 2023

Royce Threadgill — Thu, 11 Jan 2024 06:01:14 +0000

At The Gnar, we’re always reading, watching, and listening in order to keep our skills sharp and our perspectives fresh. Every month, we round up our learnings and publish them in a Gnarly Learnings blog post.

In December 2023, we learned about AI applications in finance roles, strategies for top converting landing pages, and Static Hermes. We also pondered how the combination of Rails and Hotwire can be used to replace some of the functionality previously provided only by React.

Business Applications of AI

McKinsey recently published a brief generative AI guide for CFOs on how and where to integrate gen AI solutions into finance roles.

The writers posit that generative AI can help automate tedious tasks, augment productivity, and accelerate data extraction, potentially increasing the velocity of innovation.

Gen AI can be an important tool for value creation. CFOs should strive to be gen AI enablers, not gatekeepers, and make sure that strategically critical initiatives rapidly and continually receive necessary resources.

Meg McFarlane recently published a Think With Google article discussing the benefits of AI-based advertising strategies.

In a single case study, they found a 36% increase in unique reach, 45% drop in cost, and 30% higher average impression frequency per user by switching YouTube ad strategy to lean more heavily on Google’s AI ad optimization.

Where in the past we’d have to do a lot of guesswork to determine the ideal rotation between in-stream and bumper ads, we now let the Google AI decide how often each ad was shown and to whom.

Ecommerce Web Design

In a February 2023 podcast, Logan Grasby discusses the design of top converting landing pages. He goes into detail about the anatomy of a landing page, discussing the purpose of each section and tips for improving marketing performance.

You can find a summarization of his key points starting around 25:30 in the podcast.

Russ Maschmeyer, product lead for spatial commerce at Shopify, discusses a suite of AI tools called Shopify Magic in a recent episode of Practical AI. The tools can help you with a variety of tasks, from generating product descriptions to generating product imagery.

Design

In December of 2023, we came across two sites – Addifico and ai-chat – that present their business and value proposition with eye-catching, interactive websites.

Mobile App Development

Hermes, the JavaScript engine built and maintained by Meta, is already fine-tuned for running fast React Native applications. But in the presentation “Static Hermes: The Next Generation of Hermes”, Tzvetan Mikov explains how JavaScript can be compiled to achieve huge leaps in performance.

[15:00] When we started compiling it to native initially, it was the same performance as Hermes…but now as you can see, it is 10x faster when compiled natively…plus we’re certain that there is more headroom. We can probably get to 20x times faster than Hermes.

Tzvetan reports 10x faster performance over traditional Hermes in one benchmark.

He also emphasizes that native compilation unlocks “the possibility of very efficient native platform integration”, estimating that call overhead could be between 15x and 18x lower than JSI when calling a native function. This “zero-cost FFI” ultimately opens up the possibility to implement platform integrations “entirely in JavaScript” with “practically no cost, just as if we were a C program”.

If you’re interested in learning more about Static Hermes, Tzvetan created a blog post discussing how to speed up a micro-benchmark by 300x using Static Hermes.

Gaurav Gautam also wrote a blog post about compiling TypeScript to native code, which Tzvetan discussed in a GitHub thread. That same GitHub thread yielded this remarkable result from the bunnymark benchmark:

Runtime	FPS	CPU	GPU	Memory
C	90	68%	84%	48 MB
Static Hermes	90	70%	84%	53 MB

Tech Insights

The tech world evolves incredibly fast, so it’s important to stay on top of new strategies for building applications.

It’s our belief that the Hotwire family of products, including the well-known Turbo and Stimulus, provide a compelling alternative to React for many types of applications.

Learn more by reading our blog post, “Ruby on Rails vs. React: Hotwire + Turbo Change the Equation”.

Gnarly Bytes

GraphQL: This OWASP Cheat Sheet for GraphQL is a great summary of best practices
Elixir: Notesclub is a collection of Elixir Livebooks
Artificial intelligence: Ollama provides a bunch of AI models you can run locally; Fly.io also created a blog post discussing how to run Ollama models on Fly
Ruby: Ruby on Jets is an interesting Ruby serverless framework for building and deploying APIs to AWS lambda
Libraries: We discovered Spotlight, a library pitched as “Sentry for Development” (the library is created by Sentry), aims to provide a rich debugging experience during development

Contributors:

Learn more about how The Gnar builds software.

Bun JavaScript Runtime First Look

Royce Threadgill — Tue, 17 Oct 2023 12:00:00 +0000

When I first heard about the Bun project, I honestly thought it was overambitious to the point of obvious failure. You know the projects I’m talking about – the ones that promise the world but never reach fruition, leaving their early adopters to twist in the wind.

But here we are: Bun 1.0. And by all accounts, the Bun JavaScript runtime has achieved its original goals.

In this article, we’re going to discuss Bun’s features, as well as its history and future. Since the Bun team claims that their product is a drop-in replacement for Node.js, we’ll also examine a non-trivial example of replacing Node.js with Bun in a pre-existing project.

What Is Bun?

Bun is a new JavaScript runtime developed by a company called Oven (yes, really). The mastermind behind the project is Jarred Sumner, although at this point the company appears to have attracted a small team of developers.

On an episode of the PodRocket podcast, Jarred summarized Bun as:

[2:10] …an all-in-one JavaScript Runtime. It combines a bundler, a transpiler, a package manager, a script runner, all-in-one in addition to being a runtime. And so it comes with a TypeScript transpiler, JSX transpiler. And all of this is quite a bit faster than anything that exists today.

How Fast Is Bun?

To be clear, when Jarred says “quite a bit faster”, he means many times faster than other prominent JavaScript runtimes such as Node.js and Deno.

One benchmark on the Bun website compares the HTTP requests per second processed by Bun, deno.serve(), and Node.js. When comparing Bun vs. Node, Bun processed 5x as many requests per second; when comparing Bun vs. Deno, Bun processed 2x as many requests per second.

Another benchmark asserts that yarn install runs 33x slower than bun install.

Yet another benchmark asserts that tests in a Jest/Babel configuration would run 20x slower than Bun’s test runner.

Of course, we all know that benchmarks can be misleading. I haven’t personally run the benchmarks provided by Bun, nor have I looked at the code to see if they make sense.

That being said, these claims have been backed up by some third-party testing. On our end, one of our talented software engineers has already looked into Bun and was very impressed with its speed compared to Node.js (more on his experience later).

How Is Bun So Fast?

According to Jarred Sumner, there are really two major contributors to Bun’s comparative speed: (1) use of the JavaScriptCore engine over V8 and (2) use of the Zig language for building the transpiler and runtime.

JavaScriptCore is the JavaScript engine built by Apple for Safari, while V8 is the engine built by Google for Chromium-based web browsers. I can’t speak much to their relative speed, nor have I heard Jarred or the Bun team discuss the benefits of JavaScriptCore in great detail.

The choice to use Zig, on the other hand, seems like a slam dunk for performance. Bun documentation claims the use of Zig results in a 4x faster startup time for Bun vs. Node when running scripts.

Frankly, I hadn’t heard of Zig prior to learning about Bun several months ago. It’s a relatively young language, but seems well-suited to building products like Bun based on Jarred’s statements:

[4:12] Zig is really good for this type of systems programming to do it as quickly as possible while also not going crazy because it's a low level systems' language with manual memory management. By its nature, without garbage collection, things are a little bit harder, but Zig does a really good job of making it easier than it would be otherwise in C.

Is Bun Production Ready?

By releasing version 1.0, the team is declaring that Bun is production ready.

Speaking on the JavaScript Jabber podcast, Jarred stated there are already “companies using it in production” with a “decent amount of traffic in some cases”.

That’s not to say that Bun is flawless. The host of that podcast – which aired May 30, 2023, only three months before 1.0 – mentioned that he had encountered several issues when attempting to use Bun.

Of course, Jarred assured the host that progress was being made on many known issues.

My personal opinion? Bun is ready for production use, so long as you’re willing to tackle the weird compatibility issues and edge cases that inevitably arise when using bleeding edge technology.

So the question really should be: do the pros of adopting Bun outweigh these inconveniences?

Why Should You Switch to Bun?

There are a few benefits to Bun that jump out at me:

Do you have a giant test suite that takes a long time to run? Adopting Bun will reduce the time to run that test suite, which can save CI/CD dollars and developer time.
Do you run serverless JavaScript functions? Switching over to Bun will reduce cold start and execution times.
Do you like TypeScript and want it to work out-of-the-box? Bun can directly execute .ts and .tsx files with no additional configuration.
Do you want to reduce your dependencies and simplify bundling? Bun can probably help. If you like languages such as Go that have rich standard libraries, Bun brings some of that ethos to the JavaScript world by including its own bundler and package manager.

Aside from directly reducing costs via faster execution time, Bun’s performance has the potential to increase developer productivity. By reducing the amount of time that developers spend waiting on test suites to run, for instance, you also reduce the time needed to iterate on those tests.

And lastly, the improved developer experience of having an all-in-one product shouldn’t be underestimated. How much time have you invested messing with webpack configurations or troubleshooting a Jest upgrade? Grouping these disparate elements of JavaScript development within a single, batteries-included framework should help mitigate these sorts of problems.

What Is the Future of Bun?

Jarred envisions a future in which Bun facilitates fast server-side JavaScript rendering. This certainly agrees with the recent shift back to server-side rendering, as embodied by the changes introduced in Next.js 13 and the creation of React Server Components.

Jarred discusses this concept in his PodRocket interview:

[7:00] Bun will eventually have a production transpiler API/bundling API. And I think what people will do with that is they will actually bundle and transpile in network requests. And so for that, you need it to be really fast. But the reason why I think people will do that is because it's going to enable a lot of new kinds of plugin systems where you have this dynamic code generation and you do server-side JavaScript rendering. Similarly you do server-side HTML rendering. But if you can embed the data…it'll let people delete a bunch of code.

This use-case for Bun seems supportive of the so-called islands architecture (a phrase popularized most recently by Astro). If you’re unfamiliar with this concept, the main gist is: since web pages are largely static content, only ship JavaScript when and where you need it.

More specifically, I can imagine a scenario in which a user submits data to a server and the server responds by creating data-specific JavaScript which is bundled and sent back to the client as part of an interactive page element.

That sort of client/server interaction ensures you’re only sending the JavaScript you need to the client – and that the JavaScript you send has the smallest footprint possible.

I don’t think the value proposition for this sort of system is lost on Jarred and Bun, either. In his interview with JavaScript Jabber, Jarred mentions that he aims to eventually offer “really fast edge hosting for Javascript specialized cloud” as a commercial product.

And in his PodRocket interview, he also highlights that Oven wants to create a version of Bun specifically for edge computing:

[16:07] …one of the things we'll focus on is specifically [a] version of Bun for the edge. It will have single file deploys. And it'll do this really efficiently because it'll use a binary bundling format to turn it all into one compact file.

So based on these comments, I anticipate we’ll see Oven create something like Deno Deploy for the Bun ecosystem in the not-too-distant future.

Is Bun a Drop-In Replacement for Node.js?

Whenever a new project bills itself as a “drop-in replacement” for an existing tool, I’m immediately suspicious. In my experience, there’s usually some big issue that pops up soon after adopting these sorts of solutions.

Luckily, one of our Gnarnians has already looked into this! Alex Jarvis recently converted his randsum-ts library from Node.js to Bun and generously agreed to share his takeaways from the experience.

Firstly, let’s establish that his library itself isn’t extremely complicated. Alex states that it “has no databases, no HTTP calls, just logic and exhaustively-thorough TypeScript”.

But if you look at the library, I’m sure you’ll quickly notice that it’s a pretty far cry from a “hello, world” application. This is a production-ready, pre-existing project, making it a fantastic opportunity for putting Bun’s “drop-in replacement” claims to the test.

More importantly, this wasn’t just an experiment for Alex. He saw legitimate benefits in Bun and wanted to leverage those benefits in his project:

I have played with a number of different workflows and build scripts – rollup , parcel, straight-up tsc – and had lost my head a few times working my way around cjs vs. esm. What I wanted was a little existential stability in my workflow – something to put my back against. When I heard of Bun’s built-in (lightning fast) bundler and saw it operated with first-level TypeScript support, I decided to try my hand at converting from a yarn/node backed project to being one run on bun.

If you’ve lived in the JavaScript world for a while, this is probably a familiar sentiment. My hope is Bun helps to smooth out developer experience by avoiding these sorts of headaches.

Replacing Node.js with Bun was fairly straightforward, though Alex mentioned it did involve “a small amount of re-architecturing”. To be fair, I expected that changing the JavaScript runtime for an existing project would be an outright nightmare; his experience seemed positively seamless by comparison.

He did, however, highlight testing as a pain point during adoption:

The biggest headache was the test suite, where a few useful / mission critical things are not yet implemented when compared to the modern jest suite (while I can live without expect.arrayContaining, it is a slightly more annoying existence) With some creative dependency injection and well-architected tests, this was easy to get around.

That said, Alex seemed genuinely impressed with the results once he was done. He stated his test suite and build script ran “instantly” after the switch, which serves as yet more validation of Bun’s impressive performance claims.

Alex additionally pointed out an interesting benefit to Bun’s TypeScript support that hadn’t occurred to me:

There is already a plugin ecosystem developing (making it easy for my build script to also spit out a d.ts file). Being able to REPL one of my TypeScript files natively has really opened up my debugging possibilities.

So is Bun a drop-in replacement for Node.js? I’ll let you come to your own conclusion on that. But from my perspective, Alex’s experience is a solid endorsement of that claim.

Anything Can be Used for File Storage if You Use it Wrongly Enough

Nick Maloney — Mon, 31 Jul 2023 19:32:43 +0000

I recently came across the most excellent blog post “Anything can be a message queue if you use it wrongly enough” (It is a fun read and I highly recommend checking it out). After reading it, it dawned on me that I recently created an abomination that essentially did the inverse, I used a “message queue” (if you would please indulge me in considering Redis one) as a semi-ephemeral file storage service. Please do not use this for production, you have been warned!

In building out a proof-of-concept for some fun with Machine Learning (ML) audio processing, I needed a quick, easy way to store processed files. One of the challenges was that files required multiple processing steps across different services so local file storage was not the best option. The ideal solution would be to use something like S3, but given this was purely a proof of concept (POC) and being a lazy developer, I was looking for something simple and easy. The processing was happening via the most excellent Dramatiq library, which uses Redis. This got me thinking that Redis is actually pretty well suited for this use case; it stores binary data well, is relatively fast, is quite stable AND by using expiration param in SET it would handle house cleaning of old files.

For the sake of this example, we’ll create a simple Flask application that handles POST requests for file uploads and saves them to Redis, using a sha256 of the payload as the key:

from flask import Flask, request, Response, send_file
import base64
import datetime
import hashlib
import logging
import magic
import mimetypes
import re
import redis

app = Flask(__name__)
app.logger.setLevel(logging.DEBUG)

r = redis.Redis(host='localhost', port=6379, db=0)

@app.route("/", methods=["POST"])
def create() -> Response:
  file = request.files['file']
  encoded_file = base64.b64encode(file.read())
  key = hashlib.sha256(encoded_file).hexdigest()
  expiration_time = datetime.timedelta(hours=24)
  r.set(key, encoded_file, ex=int(expiration_time.total_seconds()))
  return str(key)

The example above will save the data to Redis and return the key. It sets the file to expire in 24 hours.

To retrieve the files, we’ll use a few utilities for attempting to determine mime-type/extension of the saved files and use Flask’s send_file method for the response.

Using that endpoint, GET requests made to /sha_of_file will return the file, with the appropriate mime-type/extension.

@app.route("/<key>", methods=["GET"])
def show(key) -> Response:
  encoded_file = r.get(key)
  if encoded_file is None:
    return "File not found", 404
  decoded_file = base64.b64decode(encoded_file)
  mimetype = magic.from_buffer(decoded_file, mime=True)
  file_extension = mimetypes.guess_extension(mimetype)
  temp_filename = f'{key}.{file_extension}'

  with open(temp_filename, 'wb') as temp_file:
    temp_file.write(decoded_file)

  return send_file(temp_filename, mimetype=mimetype, as_attachment=True)

…and there you have it. This ended up working quite well for an audio processing pipeline, quickly and easily being able to send audio files exceeding 100mb. The Dramatiq library has the concept of storing results between tasks baked in, but doesn’t solve for sending results back over the wire to the browser. Again, do not use this in a production app, but I would absolutely use this technique again for future POC projects.

How Generative AI Impacts Software Development at The Gnar

Ethan Fertsch — Thu, 27 Jul 2023 18:50:26 +0000

It would be difficult to make it through a day without hearing, reading, or seeing something related to Artificial Intelligence (AI). While the concept of AI is nothing new, there is a new form of AI that has generated a lot of buzz: generative AI. In the simplest terms, generative AI is a system that can generate content (text, images, code) in response to user input. This type of system has the potential to significantly impact many industries - from healthcare to legal to the software development industry.

As a consultancy, we are constantly evaluating new tools and technologies that will help us to efficiently deliver high-quality work to our clients. At this point, it’s important to highlight that we are consumers of AI, not creators of it. That is to say, we won’t be building the next big natural language processing tool, but we may use one to help us write a test for a certain piece of code. There are a number of AI platforms that are already proliferating in the software design and development space, and our team is happy to experiment with them.

Generative AI at The Gnar

We asked our team what tools they were using to make their process more efficient and there were two at the top of the list: GitHub Copilot and ChatGPT. But we’re more than just an engineering shop - we also offer a full suite of design services and there are a number of tools that our designers use to improve the quality of their deliverables, such as MagiCopy.

GitHub Copilot

GitHub Copilot is marketed as an “AI pair programmer”. It is a paywalled service ($10/mo) that was released in the fall of 2021. The tool plugs into a text editor, such as VSCode, and can make real-time code suggestions based on input from the developer.

How We Are Using It

The majority of our team is using it to increase velocity and reduce the monotony of repetitive tasks. GitHub Copilot is anticipatory so if you begin typing some code it will try to automatically complete a word, line of code, or function. This may sound simple, but when we look at time spent on the keyboard over the course of an engagement, all of those reserved keystrokes have a cost savings associated with them. As a more practical example, we are firm believers in the value of comprehensive test coverage in the applications that we build. However, writing tests is time-consuming, and by nature, there is quite a bit of repetitive setup for each file. GitHub Copilot really shines here because it can handle much of the setup and can even write complete tests for you (though we strongly caution against accepting these at face value, more on this later).

Here’s what one of our team members had to say when asked how they were using AI to make their life easier:

“Github Copilot! I much prefer the in-editor interface to anything prompt-based and while it often spits out nonsense for business logic it excels at test suites. [...]”

Why We Are Using It

GitHub Copilot has been an easy choice for our team for a number of reasons. GitHub is a credible and familiar platform. We use it almost exclusively for storing and managing code. Moreover, GitHub was acquired by Microsoft back in 2018 so we know that they have strong financial and technical backing, which is promising for the tool’s longevity. It also integrates directly with VSCode (another Microsoft brainchild) which is a favorite text editor of many of our team members and therefore has a low barrier to entry. This combined with the time and effort savings during development makes it really attractive for developers and clients alike. However, it’s not all kittens and rainbows (more on this in the Challenges with Generative AI section).

ChatGPT

Chat Generative Pre-Trained Transformer (affectionately referred to as ChatGPT), is a natural language processing tool which is really just a fancy way of saying “an AI-based chatbot” which was developed by OpenAI and released in late 2022. A user can engage with ChatGPT via prompts and receive human-like responses. It is not software specific/focused - you can ask it what the meaning of life is, to build a keto meal plan for you, or to convert a Ruby method to Python. The world is your oyster.

How We Are Using It

ChatGPT is used less often than tools like GitHub Copilot but it did come up a number of times when discussing Generative AI with our team. It can be a great replacement for specific, simple questions about things like code syntax. With these types of questions, it’s often faster to use a tool like this than scouring blog posts or forums like Stack Overflow. One team member finds utility in ChatGPT as a “rubber duck” when they are trying to solve a problem.

“It's better curated than Stack Overflow. Sometimes AI is my "rubber duck". The process of forming a coherent question for ChatGPT helps me better understand the problem I'm working on.”

Why We Are Using It

The primary reason for using ChatGPT is that it is super easy to get started. Getting started requires nothing more than an account with OpenAI and a question. Developers spend a significant amount of time learning, researching, and reading documentation. There are certain situations in which tools like ChatGPT cut down on reading so more time can be spent writing code.

MagiCopy

MagiCopy is a Figma plug-in. Figma is the choice interface design application of our design team. The plug-in can generate copy based on project type, company, desired tone, and content type.

How We Are Using It

Our design team uses MagiCopy to generate meaningful text for wireframes and mockups.

Why We Are Using It

We use MagiCopy because it provides a more realistic feel to design deliverables, which translates to a more delightful experience for our clients and their stakeholders. Without a tool like this, there would be a time investment in generating realistic copy in the specific context of a project, or worse, we’d see a lot more lorem ipsum. Additionally, as with many of the other tools mentioned in this article, MagiCopy integrates with a platform that we know and love, lowering the barrier to entry.

“There's a constant struggle when designing of whether we need copy before design or design before copy. In instances when copy isn't written yet or fully approved for a website, designers will use "Lorem Ipsum" as placeholder text in their work, but it doesn't do a good job of representing how real copy will flow on a page. Not only that, but telling the brand story is important to elevating the design, so if the copy isn't final I write my own to help make a design feel more real. Having the ability to generate copy for my designs with a tool like MagiCopy I not only save time, but no longer have to default to "Lorem ipsum" when copy is not available or I'm unable to write it myself.”

While these tools have the potential to enhance the design and development process, we also envision a number of broad challenges that Generative AI poses to the industry. With great power comes great responsibility…

Challenges with Generative AI

While these recent advances in Generative AI are remarkable and the conceptual utility is there, there are a number of challenges that have prevented widespread adoption at The Gnar.

Overreliance. At this stage, the output from these tools is often flat-out wrong and still requires a careful eye to ensure what is being returned is usable and correct. Could ChatGPT build a web app for you? Probably. Would it be production-ready or usable out of the box? Almost certainly not. The responses from the tools are only as good as the level of detail and prompts that you provide to them. As users of ChatGPT and GitHub Copilot, we’re still required to take everything with a grain of salt and double-check the output - it would be a mistake to become overly reliant on these tools to perform our work for us.
Misrepresentation. This applies less to our current team but more to potential hires (and the potential hires of our clients). It is becoming increasingly easier to misrepresent a skillset using tools like this. A design candidate could use an image-based Generative AI platform to create and submit a portfolio of work just as easily as a software developer could use ChatGPT or GitHub Copilot to complete a coding assessment. While we like to assume the best, this is a serious ethical concern that will need to be monitored as these tools become more advanced.
Intellectual Property. Generative AI tools are built and continuously trained on the data that they are fed. The more data they process, in theory, the more helpful they become. The work we produce is always considered the intellectual property of our clients. When it comes to the impact of using a plugin like Github Copilot, that intellectual property is being used as input data to improve that tool. There’s a big question mark in our minds about whether companies are aware of this and more importantly, if they’re okay with it.
Impact on Cost and Quality. While we don’t think AI is going to cost us our jobs or take over the world, there are specific concerns about how we work with AI that will impact software development:

“In its current form, generative AI could be a repeat of the "low code" experiments of the 1990s: I think a lot of non-technical decision makers will think it can heavily automate software development. They will pay consultancies to ‘use AI’ to cheaply write their apps. The apps won't work very well and they need more money to fix them than it would have taken to write them properly the first time.”

The takeaway from all of this? Generative AI tools are very powerful and have the potential to greatly impact the software development industry. We are still in the very early days of technology of this type and there are a lot of challenges and ethical concerns that prevent us from diving in head first. However, we plan to continue to evaluate these tools and to use them to boost productivity by assisting with repetitive tasks - but only when and where it makes sense to do so, without compromising quality.

Meet The Gnarnians: Erik

Ethan Fertsch — Fri, 21 Jul 2023 14:34:56 +0000

**Gnarnian [nahr-nee-uhn] noun:** An employee of The Gnar Company

In our Meet The Gnarnians series, we unravel the stories, experiences, and passions that drive the folks on our talented team at The Gnar. Through a collection of interview-style questions, you’ll get a sneak peek into daily life on our fully-remote team, some epic origin stories, and answers to some questions as weird and wonderful as our team itself.

The Basics

Where are you located? Chicago, IL

What is your Role? Software Engineer

When did you join the Gnar? December 2021

What’s the last song you played or are listening to right now?

Ballroom Blitz. The Crucial Taunt version.

What was your career journey up until joining the Gnar?

I started out in networking and servers and took a nice long education break before coming back as a developer, then worked for a nonprofit for a long time before joining an early stage startup. In general, I've just stayed curious by doing what I want and things have worked out pretty well.

In your role, do you have any specializations or areas of focus you really enjoy doing?

I really enjoy designing software systems: Thinking in terms of architectural patterns, how best to model the real world concepts involved, how you can play to the strengths of your chosen language, and so on. There's something very satisfying about producing things that are easy to understand and do what you expect, and the design phase is generally where you're closest to what stakeholders really want in the end, whether it's a feature or a greenfield app.

What is your ideal work/desk set-up?

A standing desk, (not a convertible, which I will not convert) with good light, decently-but-not-maximally clackety keyboard, enough screen real estate to read a browser tab and a terminal (dark text, light background) at the same time. Zsh, tmux, vim, asdf. Good headphones for music, which I will feel weird about wearing for meetings. Coffee, for which my taste is utterly gauche.

What has your experience been at Gnar?

I've gotten to be involved in a long standing state project with a really interesting back end architecture, which is maybe not the first thing you picture working on going into a Rails consulting shop. It's very satisfying to see features through not just to completion but all the way through fine tuning them in the real world. The best answer here though is the people--- folks at Gnar are really welcoming and supportive.

What advice would you give someone who is just starting out in your industry?

Don't let popular opinion tell you what success looks like for you. There are a ton of great jobs out there in the world, so keep an open mind and figure out what makes you happy and keeps you curious. And it's ok to go slow.

Outside of work, what do you enjoy doing?

Music. Listening to it, playing it, recording it, talking about it, etc.

If you weren’t in your current role, what would you be doing?

Live sound guy.

Learn more about The Gnar and our team.

Gnarly Learnings from June 2023

Ethan Fertsch — Fri, 30 Jun 2023 19:18:49 +0000

At The Gnar we are always reading, watching, and listening in order to keep our skills sharp and our perspectives fresh. Here are some of the resources we learned from this month.

Understanding TypeScript’s Newest Keyword: `using`

One of the reasons I appreciate TypeScript’s place in the Node.js ecosystem is how they approach incoming JS proposals, and how eager and willing they are to bring these new advancements to the ecosystem early enough to get excited, but late enough to trust it. using is a reflection of the upcoming ECMA TC39 proposal for more explicit handling of “temporary” connections (DB executions, file handlers, etc), and since it has made it far enough to be eventually adopted into JS proper, TypeScript is more than happy to prepare me by adopting it now.

Backtick Strings vs `URLSearchParams`

The title of the article linked above is a _little _clickbait-y but hey, I read it and I am glad I did. The React documentation provides an example of building a URL string to query an API using template literals or “backtick strings”. However, as the author correctly points out, this is not the best tool for the job. Template literals will _work _but aren’t made for creating serializable strings. For that, we have URLSearchParams, which will properly escape parameter values, among other things.

Removing Active Storage Objects via Form POST

Gone are the days of needing to reach for clunky conditionals to massage Active Storage-related params when using direct uploads! Previously, to remove an Active Storage object from a record it would need to be explicitly set to nil. This was all well and good until you would try to do it on form submission and receive an error because the passed value in the params was actually an empty string. Now, setting the value to nil or an empty string yields the same result. 🎉

The Gateway Pattern

Especially on large projects, my services directory admittedly ends up looking a bit like a junk drawer. So, if you’re like me and wrap all external API communication in service objects, you’ll be glad you found this article. A gateway is used to formalize the boundary between your app’s domain and an external API, translating between the two. This is more specific and nuanced than how I typically use service objects, and helps clean up the codebase.

Shopify’s Ruby LSP in VSCode

I was shopping around for a simpler way to auto-format my Ruby code with minimal extensions and config. In my research I came across the Ruby LSP (Language Server Protocol) created by Shopify, who maintain one of the most well-known commercial Rails monoliths. This article describes the LSP and the VSCode integration of it, but it also includes a nice dive into LSPs in general.

Stack Overflow Releases Their 2023 Developer Survey

Here at The Gnar, we love a good developer survey. Admittedly, this is my first experience with the one released by Stack Overflow (SO). There are a bunch of interesting takeaways but I loved reading about how Postgres is now the most loved, admired, and popular relational database (this is true here at The Gnar too - we have a whole series on some of its lesser-known features). SO also includes a new section on the prevalence of AI search tools where ChatGPT (unsurprisingly) is sitting pretty with 83% of professional respondents leveraging it in the past year.

Contributors:

Learn more about how The Gnar builds software.

Metaprogramming in Ruby: Advanced Level

Ethan Fertsch — Fri, 30 Jun 2023 19:15:47 +0000

This post is the third in a series focused on the application of Ruby metaprogramming. If you’re just starting to learn about metaprogramming, “Metaprogramming in Ruby: Beginner Level” is a great place to get started. For those seeking a more practical example of metaprogramming, check out “Metaprogramming in Ruby: Intermediate Level”. In this article, we’ll discuss how a few popular Ruby gems make use of metaprogramming to solve everyday programming problems.

When you go out for a walk, do you bring a paddle with you? Of course not! A paddle would be pointless. It’s only when you’re up the creek that a paddle is invaluable.

So too it goes with metaprogramming.

Welcome to the final installment of our Metaprogramming in Ruby series. Up to this point, we’ve been going through relatively simple, handcrafted Ruby metaprogramming examples. In the beginner level post, we discussed how to use Ruby define_method and send to dynamically create methods. And in the intermediate level post, we put those concepts into practice with a slightly more practical example.

This time, we’re going to look at how metaprogramming is used in the wild by diving into the code underlying popular Ruby gems. The libraries we’ll be looking at are:

devise: An authentication library designed for Rails
factory_bot: A fixtures replacement
rspec: A testing library

Ruby metaprogramming in the `devise` gem

Of the gems we’re analyzing today, this is probably the most straightforward example of metaprogramming in Ruby.

When initially setting up devise in your project, you generally run rails generate devise MODEL, where MODEL is the name of your devise model. So if you wanted your users to have a model name of User , you’d run rails generate devise User.

To make this example a little clearer, let’s assume you run rails generate devise Gnarnian, which will make your devise model Gnarnian (that’s what we call ourselves at Gnar).

After migrating, you’ll get access to a slew of helpers created by the generator, including some nifty url and path helpers like new_gnarnian_session_path, gnarnian_session_path, and destroy_gnarnian_session_path.

But that’s not all! As you add third-party sign in methods to your app/models/gnarnian.rb file, you additionally get access to those path helpers! For instance, you can add :omniauthable, omniauth_providers: [:google_oauth2] to your devise modules to set up Google sign in; that should provide you with user_google_oauth2_omniauth_authorize_path for redirecting users to Google sign in.

At its core, this is made possible by lib/devise/controllers/url_helpers.rb, which uses define_method to create the path helpers, like so:

# lib/devise/controllers/url_helpers.rb

def self.generate_helpers!(routes = nil)
  routes ||= begin
    mappings = Devise.mappings.values.map(&:used_helpers).flatten.uniq
    Devise::URL_HELPERS.slice(*mappings)
  end

  routes.each do |module_name, actions|
    [:path, :url].each do |path_or_url|
      actions.each do |action|
        action = action ? "#{action}_" : ""
        method = :"#{action}#{module_name}_#{path_or_url}"

        define_method method do |resource_or_scope, *args|
          scope = Devise::Mapping.find_scope!(resource_or_scope)
          router_name = Devise.mappings[scope].router_name
          context = router_name ? send(router_name) : _devise_route_context
          context.send("#{action}#{scope}_#{module_name}_#{path_or_url}", *args)
        end
      end
    end
  end
end

Ruby metaprogramming in the `factory_bot` gem

Factory Bot is considered by many to be a must-have tool for testing Rails projects. The factory_bot gem actually uses metaprogramming concepts in a couple of places, but here we’ll focus on the use of traits, callbacks, and the evaluator argument.

For the sake of example, let’s say you have articles and authors tables. Each Article belongs to a specific Author and each Author can have many Articles. You could create a basic factory like so:

# spec/factories/authors.rb

FactoryBot.define do
  factory :article do
    title { "MyString" }
    body { "MyText" }
    published { false }
    author
  end
end

But Factory Bot also provides callbacks that allow you to execute code for a given strategy. So if you’d like to run code after calling create, then you could write something like after(:create) do <something>.

Now let’s assume an Author has written Books that you need to access in your tests; to generate Books written by your Author, you could make something like:

# spec/factories/authors.rb

FactoryBot.define do
  factory :author do
    transient do
      book_names { ['The Color of Magic'] }
    end

    name { 'Terry Pratchett' }
  end

  trait :has_books do
    after(:create) do |author, evaluator|
      Array(evaluator.book_names).each do |book_name|
        create(:book, name: book_name, author: )
      end
    end
  end
end

Notice that you can use evaluator to access transient properties. So in your test, you could write create(:author, :has_books, book_names: ['Equal Rites', 'Mort']), which would create two books with the provided names and the same Author.

This flexible and powerful behavior is facilitated by the Ruby define_method and method_missing blocks found in factory_bot/lib/factory_bot/evaluator.rb.

# lib/factory_bot/evaluator.rb (selected snippets)

def method_missing(method_name, *args, &block)
  if @instance.respond_to?(method_name)
    @instance.send(method_name, *args, &block)
  else
    SyntaxRunner.new.send(method_name, *args, &block)
  end
end

def self.define_attribute(name, &block)
  if instance_methods(false).include?(name) || private_instance_methods(false).include?(name)
    undef_method(name)
  end

  define_method(name) do
    if @cached_attributes.key?(name)
      @cached_attributes[name]
    else
      @cached_attributes[name] = instance_exec(&block)
    end
  end
end

For more detailed examples, check out the getting started docs!

Ruby metaprogramming in the `rspec-core` gem

At long last, we’ve arrived at our final Ruby metaprogramming example: the 800-lb gorilla that is rspec and its many associated gems. Of the three examples discussed here, rspec uses metaprogramming most extensively. This makes some intuitive sense given that we’re talking about a full-fledged testing framework.

That being said, the code and documentation for rspec is generally clear and descriptive, making it a fantastic repository for learning about metaprogramming techniques. In rspec-core/lib/rspec/core/dsl.rb, for example, the implementation is spelled out in code comments.

Let’s create an example for illustration:

RSpec.describe "posts/index", type: :view do
  it "renders a list of posts" do
    # ...something
  end
end

# Creates RSpec::ExampleGroups::PostsIndex
# $ RSpec::ExampleGroups::PostsIndex.describe
# $  => RSpec::ExampleGroups::ArticlesIndex::Anonymous
# $ RSpec::ExampleGroups::PostsIndex.examples
# $  => [#<RSpec::Core::Example "renders a list of posts">]

For each spec, RSpec will construct the RSpec::ExampleGroups::Example subclass. Note as well that RSpec::ExampleGroups::Examples::Anonymous.describe will increment the id appended to the end of RSpec::ExampleGroups::Examples::Anonymous (e.g., Anonymous_2, Anonymous_3, Anonymous_4, etc.).

When you create your spec file with RSpec.describe, behind the scenes your arguments are being passed to dsl.rb:

# rspec-core/lib/rspec/core/dsl.rb
# In this case, `args` are `["posts/index", {:type=>:view}]`
# and `example_group_block` is the block of code representing your spec 

(class << RSpec; self; end).__send__(:define_method, name) do |*args, &example_group_block|
  group = RSpec::Core::ExampleGroup.__send__(name, *args, &example_group_block)
  RSpec.world.record(group)
  group
end

Those arguments are then passed to RSpec::Core::ExampleGroup, which determines if the block is top-level and, if so, defines a new ExampleGroup subclass.

# rspec-core/lib/rspec/core/example_group.rb (selected snippets)
# In this case, `name` is `:describe`

def self.define_example_group_method(name, metadata={})
  idempotently_define_singleton_method(name) do |*args, &example_group_block|
    thread_data = RSpec::Support.thread_local_data
    top_level   = self == ExampleGroup

    registration_collection =
      if top_level
        if thread_data[:in_example_group]
          raise "Creating an isolated context from within a context is " \
                "not allowed. Change `RSpec.#{name}` to `#{name}` or " \
                "move this to a top-level scope."
        end

        thread_data[:in_example_group] = true
        RSpec.world.example_groups
      else
        children
      end

    begin
      description = args.shift
      combined_metadata = metadata.dup
      combined_metadata.merge!(args.pop) if args.last.is_a? Hash
      args << combined_metadata

      subclass(self, description, args, registration_collection, &example_group_block)
    ensure
      thread_data.delete(:in_example_group) if top_level
    end
  end

  RSpec::Core::DSL.expose_example_group_alias(name)
end

def self.subclass(parent, description, args, registration_collection, &example_group_block)
  subclass = Class.new(parent)
  subclass.set_it_up(description, args, registration_collection, &example_group_block)
  subclass.module_exec(&example_group_block) if example_group_block

  # The LetDefinitions module must be included _after_ other modules
  # to ensure that it takes precedence when there are name collisions.
  # Thus, we delay including it until after the example group block
  # has been eval'd.
  MemoizedHelpers.define_helpers_on(subclass)

  subclass
end

The returned subclass, in this case, would be RSpec::ExampleGroups::PostsIndex. Calling subclass.module_exec will step through the example_group_block and define Examples (i.e., tests) for the RSpec::ExampleGroups::PostsIndex subclass:

# rspec-core/lib/rspec/core/example_group.rb
# In this case, `name` is `:it`
# and `all_args` is `renders a list of posts`

def self.define_example_method(name, extra_options={})
  idempotently_define_singleton_method(name) do |*all_args, &block|
    desc, *args = *all_args

    options = Metadata.build_hash_from(args)
    options.update(:skip => RSpec::Core::Pending::NOT_YET_IMPLEMENTED) unless block
    options.update(extra_options)

    RSpec::Core::Example.new(self, desc, options, block)
  end
end

Now that the ExampleGroups subclass (i.e., the spec) and its Examples (i.e., the tests within the spec) have been defined, the runner is called to execute the tests!

# rspec-core/lib/rspec/core/runner.rb
# If we're running only this spec, `example_groups` would be
# a single-member array containing `RSpec::ExampleGroups::PostsIndex`

def run_specs(example_groups)
  examples_count = @world.example_count(example_groups)
  examples_passed = @configuration.reporter.report(examples_count) do |reporter|
    @configuration.with_suite_hooks do
      if examples_count == 0 && @configuration.fail_if_no_examples
        return @configuration.failure_exit_code
      end

      example_groups.map { |g| g.run(reporter) }.all?
    end
  end

  exit_code(examples_passed)
end

Is metaprogramming in Ruby pointless?

If you’ve read all three installments in this series, then firstly – thank you! We hope we adequately addressed your Ruby metaprogramming questions, or at least inspired curiosity.

Secondly, you’ve probably noticed we reiterated ad nauseum that metaprogramming is a “break glass in case of emergency” kind of tool.

So let’s wrap this up by addressing the elephant in the room one last time: is Ruby metaprogramming useful to the average developer? Our hope is that these three articles have proven to you that the answer should be an emphatic, “YES”....

…followed by a cautiously muttered, “under the right circumstances and for specific use-cases.”

Learn more about how The Gnar builds Ruby on Rails applications.

Meet The Gnarnians: Taylor

Ethan Fertsch — Thu, 29 Jun 2023 17:56:14 +0000

Gnarnian [nahr-nee-uhn] noun: An employee of The Gnar Company

The Basics

Where are you located? Charlestown, MA

What is your Role? Software developer / grumpy old man

When did you join the Gnar? 2016

If you were in the middle of a zombie apocalypse, who are three people you'd want on your team?

My wife Lauren: she's the most practical person I know. The kids we can leave behind.
Nick Maloney. I'm not saying he's already prepared for this exact scenario, but he's probably pretty close.
Zach Galifianakis. I just feel like someone would need to lighten the mood.

What’s the last song you played or are listening to right now?

"Rust" by Lagwagon is generally running through my head a few times a week.

In your role, do you have any specializations or areas of focus you really enjoy doing?

From a technical perspective I'm a Rubyist and a Javascripter. I have had a lot of fun and made a lot of web applications armed with these very powerful tools. Being a full-stack developer means I never get tired of writing back-end or front-end code, as I get a pretty good mix of both all year round.

From a career perspective, I have always gravitated toward the people side of the work. Building software is fun, but seeing what it means for a founder and their users is what makes the work exciting for me. Consulting has given me an opportunity to build software and build relationships at the same time.

If you weren’t in your current role, what would you be doing?

If I didn't work at the Gnar, I would probably be starting a coffee roasting business. I have been a hobbyist coffee roaster for some time now, and have put most of my Gnar anniversary gifts towards grinders, roasters, espresso machines, even a refractometer! Google that one.

What has your experience been at Gnar?

I was the first full-time hire at The Gnar, more than six years ago. When I first met Mike (I already knew Nick), the company was located in the conference room of another company. There was a big white board with all of the client work organized on it, two large desks, about six chairs, and cables everywhere. I said to myself ""this is definitely where I want to work.""

Since that day I have upgraded offices four times, and I have watched the team grow from four to twenty-five. And throughout all of this change and growth, my sense of belonging and pride in the company has only grown. It's been a pleasure thus far.

What's your favorite part of working at Gnar?

The people. First and foremost, if Mike and Nick were not the people they are, this company would not be what it is. The trickle-down effect is that we have hired really great team members. Strong developers, designers, and relationship managers, of course. But as importantly, we've hired people with interesting perspectives, different ideas, and bold opinions. And mutual respect is table stakes. It makes for this evolving culture of growth and energy, pulled in a slightly different direction by each new hire.

Also clapping. There's a lot of clapping.

What advice would you give someone who is just starting out in your industry?

Ask questions early and often. Whether it's a question to a colleague about writing code or a question to a client about a requirement, make sure you understand exactly what is happening and what is needed. Nobody will ever fault you for wanting to get it right.

Outside of work, what do you enjoy doing?

I really enjoy gardening when I'm outside and reading fiction when I'm inside. I grew up in the Rocky Mountains, so winter sports are a big part of my life. I have used the term "gnar" many times prior to working here.

Learn more about The Gnar and our team.

Meet The Gnarnians: Erica

Ethan Fertsch — Thu, 01 Jun 2023 17:50:11 +0000

**Gnarnian [nahr-nee-uhn] noun:** An employee of The Gnar Company

The Basics

Where are you located? Philadelphia, PA

What is your Role? Design Director

When did you join the Gnar? November 2022

What's the best advice you've ever received?

When I was in college I used to order enough Chinese food to last me a couple of days (very normal, we all did it). The best part of not only having cheap meals that would last the week but the large amount of fortune cookies they would include in the assumed large family sized order. Most of the time the messages you get are pretty repetitive, "Don't hold onto things. that require a tight grip," "A faithful friend is a strong defense, " or like "Good luck will find you soon". However, this one night while I was stressing over my end of year portfolio, I opened one that said, "You can do anything but not everything", then another that said, "Don't Panic". Both very different than you'd typically get. I kept them, and taped them to a post card I pinned to my wall, and carried them with me until I lost them in a move. So yeah, I could say that was the best advice I've received thanks to my delivery food.

What’s the last song you played or are listening to right now?

Currently listening to "I'm a Princess" by Bill Wurtz.

What was your career journey up until joining the Gnar?

My entire career has been in the design industry but not the same mediums. When I graduated I worked for small NYC design studios, designing identities specifically for hotels, restaurants, and food & beverage companies. That work included a lot of print design, web design and creation of die-lines for physical product packaging. The work I did for restaurants focused around menus, branding for the interior, signage, and their websites. After working for a few small studios I moved to a global agency in NYC, and developed design systems for healthcare and consumer brands like Vonage, Amtrak, and Nestle Waters. At some point everyone was switching from agencies to tech start-ups and I thought I'd might try that out too. While working at various tech start-ups, I got to wear many hats (marketing hats, product management hats, and even an office design hat), was able to build my experience in product design, lead several small design teams, and most recently was part of a fintech start-up that went public during my tenure there.

If you weren’t in your current role, what would you be doing?

There was a point in my life where I was torn between culinary school and art school. Obviously I picked art school, but if I didn't I would 100% be doing Pastry/baking.

What is your ideal work/desk set-up?

I recently moved into my own house and for the first time had the freedom to put my desk in its own room other than my bedroom or living room. I built a wall-length desk with a counter top, added some table legs and desk drawers. Since it's technically a kitchen countertop I don't have to worry about the condensation from all my iced coffees ruining it. I also keep a lot of design books within reach, pens, my sketchbook, and a Wacom tablet. On the other end of the desk is a work area for my partner and the xbox. With summer coming, I'll probably move to take some calls on my back patio, but I prefer to work from my office. It's important to me to maintain that feeling of stepping away from my "work area" for a mental break which is why I tend to only be productive from one area versus multiple set-ups throughout my house.

How do you structure your work day or week?

One thing about me that has been forever true, I am NOT a morning person. I am not productive at all. I start my day either taking a brisk walk with my dog to a local coffee shop or just the walk and then make coffee at home. Either way I need coffee, coffee is a priority. Knowing my focus isn't the best in the morning I tend to designate that time then to things like, checking emails, planning my tasks for the day, and attending stand-ups for various projects. One of the best things about working remotely is I actually am more productive earlier than when I used to commute to work. Before lunch, I typically spend time doing any additional research, and looking up design inspiration. By the afternoon I am more heads down on client work which ranges from writing user research plans, designing, connecting with contract designers, and working internal projects for The Gnar like, designing social posts, writing blog posts, or documenting internal processes. At 3pm my dog reminds me it's time for her walk, and after that 'm usually heads down for the rest of the afternoon to early evening. Being a night-owl I will often be back online after 8pm for anything that is still swirling around in my head.

Outside of work, what do you enjoy doing?

My partner and I own a small gelato shop in Fishtown, Philadelphia. If I'm not there helping him in the shop, I'm either out with my dog, playing video games or visiting friends in NYC for the weekend.

Learn more about The Gnar and our team.

DEV Community: The Gnar Company

React Server Components Example with Next.js

What are React Server Components?

React Server Components vs SSR

Server Components vs. Client Components

React Server Components Without Next.js…?

But What If I Really Don’t Like Next.js?

React Server Components Example with Next.js

React Server Components and Suspense

Interleaving Client and Server Components

You Can Still Use Contexts (Carefully)

You Can Use Server Code in Server Components

What Are the Advantages of React Server Components?

What are the Disadvantages of React Server Components?

Are React Server Components Production Ready?

Open Questions About React Server Components

Further Resources and Special Thanks

Creating Passkey Authentication in a Rails 7 Application

Rails 7 Passkey Authentication Example

Contributors:

DevSecOps 101: What is DevSecOps?

DevSecOps vs. DevOps

DevSecOps as Company Culture

Plan: Threat Analysis

Develop: Secure Coding; Security as Code

Build: Static Application Security Testing (SAST)

Test: Dynamic Application Security Testing (DAST)

Test: Penetration ("Pen") Testing

Release: Digitally Sign

Deliver: Secure Transfer

Deploy: Security Config, Security Scan

Operate: Security Patch

Monitor: Security Audit, Security Monitor

Conclusion

Gnarly Learnings from December 2023

Business Applications of AI

Ecommerce Web Design

Design

Mobile App Development

Tech Insights

Gnarly Bytes

Contributors:

Bun JavaScript Runtime First Look

What Is Bun?

How Fast Is Bun?

How Is Bun So Fast?

Is Bun Production Ready?

Why Should You Switch to Bun?

What Is the Future of Bun?

Is Bun a Drop-In Replacement for Node.js?

Anything Can be Used for File Storage if You Use it Wrongly Enough

How Generative AI Impacts Software Development at The Gnar

Generative AI at The Gnar

How We Are Using It

Why We Are Using It

How We Are Using It

Why We Are Using It

How We Are Using It

Why We Are Using It

Challenges with Generative AI

Meet The Gnarnians: Erik

Gnarnian [nahr-nee-uhn] noun: An employee of The Gnar Company

What’s the last song you played or are listening to right now?

What was your career journey up until joining the Gnar?

In your role, do you have any specializations or areas of focus you really enjoy doing?

What is your ideal work/desk set-up?

What has your experience been at Gnar?

What advice would you give someone who is just starting out in your industry?

Outside of work, what do you enjoy doing?

If you weren’t in your current role, what would you be doing?

Gnarly Learnings from June 2023

Contributors:

Metaprogramming in Ruby: Advanced Level

Ruby metaprogramming in the devise gem

Ruby metaprogramming in the factory_bot gem

Ruby metaprogramming in the rspec-core gem

Is metaprogramming in Ruby pointless?

Meet The Gnarnians: Taylor

Gnarnian [nahr-nee-uhn] noun: An employee of The Gnar Company

If you were in the middle of a zombie apocalypse, who are three people you'd want on your team?

React Server Components and `Suspense`

**Gnarnian [nahr-nee-uhn] noun:** An employee of The Gnar Company

Ruby metaprogramming in the `devise` gem

Ruby metaprogramming in the `factory_bot` gem

Ruby metaprogramming in the `rspec-core` gem

**Gnarnian [nahr-nee-uhn] noun:** An employee of The Gnar Company