DEV Community: Tim Bright

Frontend Code from a Backend Perspective

Tim Bright — Tue, 26 Nov 2024 03:03:52 +0000

I don't call myself a frontend developer.

To be clear, I know how to do frontend work. I'm trying to keep myself up-to-date with all the newest ways to try to more easily put content on the browser in a performant way. I build web applications, so you have to know how to build a user-facing client to call your backend.

I would call myself a backend developer.

But I definitely wouldn't call myself a frontend developer.

People say the frontend is the "easy" work. I don't. For me, it's a special kind of hell where you have every tool available but none of the right ones. It always seemed to me that it was inevitable that frontend code always ends up in spaghetti and you have to scrap and redo it periodically.

Recently, I found a paradigm that resonates with me and I thought I'd share my thinking. It came to me from a more backend-focused perspective, but the more I think about it, I see it's just good programming practice.

"Architecture: The Lost Years"

One of the talks that influenced me the most was one Robert "Uncle Bob" Martin has that's titled "Architecture: The Lost Years".

In it, he laments how software development evolved over the last few decades:

"I call this talk 'The Lost Years' [...] because from 1993 until now we have forgotten this thing we were on the verge of learning...and do you know what drove it out of our heads? The Web. The Web was so all-consuming [...] and it drove all those ideas out of our brains for [years] and they're just now starting to come back..."

Now, I will say Uncle Bob has some hot takes. There are a lot of people that disagree with him on his version of what "clean code" is (and I'm one of them). I try not to blindly parrot his or anyone's takes, or follow them without a deeper understanding of what they're trying to say. I can't speak to this "Middle Ages of Software Architecture" that he seems to be referring to. Back in 1991 when the Web was new, I think I was just starting to write my first "Hello world" applications in C++. Compared to him and lot of others, I'm a relative n00b.

However, I have noticed that there seems to be a rift between what people say we should do, and what we actually do in practice. For example: why do most of the web app test suites I've ever seen require the web server to be running in order to run the tests?

Unless you're testing for the actual user responses being received (which can be tested independent of the business logic), there's absolutely no reason for the web server to be running. Whenever I've seen it, it's an artifact of treating the web server as the central abstraction of the application. The application then becomes a web server spidered with business logic. In order to test the code, you need to run the web server for the tests and do mock HTTP calls to it. This makes your testing unnecessarily slow because you have the web server in the middle of it.

I've seen the same thing with frontend code. In a lot of cases, you're not able to test the business logic independent of the UI. Why should I have to render the React code to test fetching data from the backend? React is a UI framework; it should never be the central abstraction for my frontend code. However, that's what it seems most frontend clients are: "React apps" instead of applications using React. It also seems that most tutorials (and even some tools!) direct you to "Reactify" all your code, further feeding into this pattern of making React the center of your application.

The "Ports and Adapters" Pattern

So how can we avoid this?

Uncle Bob's architectural recommendation in that talk is remarkably similar to the "ports and adapters" pattern for hexagonal architecture. What Uncle Bob calls the interactor object is a part of the application. It implements a specific interface that defines the functions of how the application object should be interacted with. To use the "ports and adapters" language, the interface is a port, and the interactor is an adapter.

interface Application {
  doAppFunction(): void;
}

class Interactor extends Application {
  constructor(...) { }

  public doAppFunction() {
    ...execute some application code
  }
}

This adapter can be plugged into another bit of code that uses the port, perhaps as an argument to a function or it can be dependency injected at creation time.

class UI {
   constructor(app: Application) { this.app = app; }

   someUIFunction() {
      ...

      this.app.doAppFunction();

      ... do other UI code
   }
}

This way, the UI can do application-specific functions via the Application interface but the UI code does not contain any of that code. This allows you to test the Interactor object independently from the UI, meaning you don't have to run the UI and also you don't have to run the app to do UI unit tests.

Working with React

So how would this work with React?

One way to do this is to make a React Context that holds an Application object and then just fetch the object with useContext whenever you need to interact with something outside of React:

const AppContext = createContext<Application>(undefined);

export const useApplication = () => {
  const context = useContext(AppContext);
  if (!context) {
    throw new Error("useApplication must be used within a ApplicationProvider");
  }
  return context;
};

export const ApplicationProvider = (props) => {
  const { children, value } = props;
  return <AppContext.Provider value={value}>{children}</AppContext.Provider>;
};

You can create the Interactor object just before you render your React application:

const application = new Interactor();

export const renderApp = () => {
  const root = document.getElementById("root");
  ReactDOM.createRoot(root).render(
    <React.StrictMode>
      <ApplicationProvider value={application}>
        <MyReactApp />
      </ApplicationProvider>
    </React.StrictMode>,
  );
};

Now you can use the hook in the children to get access to the Application object:

export const MyReactApp = () => {
  const app = useApplication();
  app.doAppFunction();

  return <> ... </>;
};

This pattern allows you to separate your UI from what essentially are your models and controllers. You can now work with app state and not have to bind it with React's UI state, which gives you a lot of control. However, you can still use tools like @tanstack/query to control overzealous calls to your application object.

Your Mileage May Vary

I know I'm going against the grain on this one.

I'm probably going to get a lot of comments like, "You shouldn't do that because ___ and _____, you n00b!"

And that's okay.

I don't claim to be a frontend developer.

But I will say my frontend code became a lot more simple once I started using this pattern. This same thing actually happened when I started doing this with my backend code as well. I would inject my app dependencies into my app object, and then I would inject my app object as a dependency to my REST/GraphQL/gRPC code. It abstracted a lot of the unnecessary details away and kept my concerns separate.

Try it out. You might like it.

Distribute your Go CLI tools with GoReleaser and Homebrew

Tim Bright — Fri, 01 Sep 2023 22:01:08 +0000

Cobra is awesome.

At Duro, my team and I made a sweet CLI tool that allows us to create microservices for our platform quickly and easily. The tool sets up a standard service configuration for TypeScript, linting, integration with our shared library, and specific Github Actions for pushing the service to the cloud. It's been really nice to have.

We're constantly tweaking things with it, fixing little things and changing our configurations. We decided to use GoReleaser to help us version the tool and create the binaries and publish them to Github. It's been awesome.

Until we had to distribute it.

Revisions started increasing and it was a hassle trying to make sure that you have the latest version of the tool. In the spirit of "get things done", we just had everyone download it and delete it when they were done. Not a great solution, but hey, we had more things to worry about.

Lately, I decided to take it upon myself to show this tool some love (and curry favor with my fellow devs) to try to manage versions of this tool via Homebrew. I didn't know the internals of how Homebrew worked, so I decided to dig in.

Homebrew Basics

Homebrew is a package manager that allows users to install packages through a simple interface. If you need curl and you don't have it, you can simply run brew install curl and Homebrew will fetch it. You can even specify specific versions of a package if you need.

How does Homebrew know where to get things from?

Homebrew has a list of core packages you can browse here and those are available when you type in brew install. Each of these packages has a formula, which is just a Ruby file that shows what the latest SHA is of a package and allows Homebrew to select the right binary based on your operating system. Here's an example of a formula:

class Wget < Formula
  homepage "https://www.gnu.org/software/wget/"
  url "https://ftp.gnu.org/gnu/wget/wget-1.15.tar.gz"
  sha256 "52126be8cf1bddd7536886e74c053ad7d0ed2aa89b4b630f76785bac21695fcd"

  def install
    system "./configure", "--prefix=#{prefix}"
    system "make", "install"
  end
end

The repository that this formula is stored in is called a tap. In fact, the list of core package are stored in the core tap. This is not only tap you can have; you can create your own tap.

How do I create a tap and what happens when I do?

There's standard documentation on how to create a tap.

The short version is that when you type in brew tap <tap_name> <URL>, it will go to that URL and clone the repository there and save it in $(brew --repository)/Library/Taps. Then, when you type in brew install <package>, it will search the core tap first and then any additional taps you've created. It will then look for the formula Ruby file and grab the latest package (or the version you specify) from the specified location in the formula and put it in Homebrew's path so you can access it.

How do I create a formula?

You can create one by hand, but GoReleaser can do it for you.

Here's the basic config:

brews:
  -
    # Name of the recipe
    #
    # Default: ProjectName
    # Templates: allowed
    name: some_app

    # Folder inside the repository to put the formula.
    folder: Formula

    # Your app's description.
    #
    # Templates: allowed
    description: "Put in description here."

    # Repository to push the generated files to.
    repository:
      owner: example
      name: some_app
      branch: brew-releases/{{ .Version }}
      token: "{{ .Env.GITHUB_TOKEN }}"
      pull_request:
        enabled: true
        base:
          owner: example
          name: some_app
          branch: master

    # NOTE: make sure the url_template, the token and given repo (github or
    # gitlab) owner and name are from the same kind.
    # We will probably unify this in the next major version like it is
    # done with scoop.

    # URL which is determined by the given Token (github, gitlab or gitea).
    #
    # Default depends on the client.
    # Templates: allowed
    url_template: "https://github.com/example/some_app/releases/download/{{ .Tag }}/{{ .ArtifactName }}"

    # Allows you to set a custom download strategy. Note that you'll need
    # to implement the strategy and add it to your tap repository.
    # Example: https://docs.brew.sh/Formula-Cookbook#specifying-the-download-strategy-explicitly
    download_strategy: GitHubPrivateRepositoryReleaseDownloadStrategy

    custom_require: './custom_release_strategy'

    # Git author used to commit to the repository.
    commit_author:
      name: goreleaserbot
      email: goreleaserbot@example.com

    # The project name and current git tag are used in the format string.
    #
    # Templates: allowed
    commit_msg_template: "Brew formula update for {{ .ProjectName }} version {{ .Tag }}"

Here, GoReleaser will generate the Ruby formula file for you and try to commit it into the Formula folder in this repository. In my case, we made our main branch protected so we had to specify the section that auto-creates a PR with the new formula.

We also have a Github Action that uses GoReleaser's custom action to trigger a release whenever a new tag is created in our repo. Now all one of us has to do is create a release with a new tag and the GitHub Action will prepare a release with the binaries and then auto-create the PR with the updated formula. Once it's merged in, Homebrew should take care of updating the revisions.

Then it's just the brew tap and brew install combo FTW!(You might need to have a GitHub personal access token in your HOMEBREW_GITHUB_API_TOKEN env variable).

That doesn't sound so bad! Why were you complaining about it being a pain?

Ah, that's right. The gotcha.

Homebrew uses several different methods to download/clone repos, such as CurlDownloadStrategy (which does exactly what it says).

They used to support one called GitHubPrivateRepositoryReleaseDownloadStrategy. It's exactly what the name implies: it downloads releases from GitHub private repositories. At the time I was doing my research into doing this myself, there was a good amount of documentation floating around that says to use that strategy for fun and profit.

Problem is, Homebrew no longer supports that strategy. Then GoReleaser stopped supporting it.

Screwed? Not really, thanks to some help from the community and open source software!

This comment in a GoReleaser issue showed me I can copy the old code from older versions of Homebrew and include them into my formula with GoReleaser.

I think in the end we used the recommendation made here with the code contained in this Gist link. We put that code into the same Formula folder in the repo and named it custom_release_strategy.rb. That file is pointed to in the custom_require field in the brews section and automatically includes it in the formula file so Homebrew knows how to download the packages.

Hope that helps anyone who wants to build their own CLI tool and ship it via Homebrew!

React Context with React Router v6.4

Tim Bright — Sun, 27 Nov 2022 21:16:51 +0000

I searched for a while to find how to use the Context API with createBrowserRouter. What I found is that you can use layout routes to wrap your components with the provider:

import { Outlet } from 'react-router-dom';
export default function ContextLayout() {
  return (
    <ContextProvider>
      <Outlet />
    </ContextProvider>
  );
};

Then, you can create a RouteObject without a path that renders that layout route with the children as the components you want to wrap in the provider.

import { createBrowserRouter, RouterProvider } from 'react-router-dom';
const router = createBrowserRouter([
  {
    element: <ContextLayout />,
    children: [
      {
        path: '/some/path',
        element: <SomeContextConsumer />
      }
    ]
  },
  ...
]);

export default () => {
  const rootElement = document.getElementById('root');
  const root = createRoot(rootElement!);
  root.render(
    <RouterProvider router={router} />
  );
};

That's it! Hopefully this saves someone the time it took me to figure this out.