It’s hard to follow a path if you can’t see it. I recommend putting your code guidelines in writing. They should be easy to follow and flexible enough to apply to many situations. Here are some of mine I’ve developed over the past decade:

Deploying an updated version of Temporal workflow code can result in errors if there are non-deterministic changes to the code. Determinism is verified during the “replay“ process that rebuilds the last known state of an ongoing workflow in order to continue its execution. Rebuilding execution state enables Temporal to support long-sleeping workflows and reliably relocate workflow executions to another worker when one crashes.

Ever wanted to host your own system to track important metrics over time?

Almost any web app with authenticated users will need to send some emails. You could work around it by using an authenticated service like Auth0 or AWS Incognito, but let’s assume you’ve set up Remix with a stack that ships with built-in authentication.

Using cloud services is standard practice for most backend application architectures. When using cloud services, it is important to understand and control what data is leaving your network and being sent to the cloud. Temporal Cloud has great options available to ensure that data sent to and from the cloud is securely encrypted. This post will showcase how Temporal Cloud might interact with your infrastructure by default and how you can customize Temporal to prevent any user or business-related data from being sent to the cloud.

Managing your own Temporal cluster is a daunting task. Between the four core services, the myriad of metrics to monitor, and a separate persistence service, it's a sizeable undertaking for any team. This post begins a new series that will review the work involved in hosting Temporal yourself and try to demystify it.

There’s a growing demand to create more polished user experiences in increasingly complex web applications. Making the jobs of QA engineers more important - and more difficult - than ever.

Software developers are superstitious out of necessity. Given the task of keeping a software system functioning properly without the ability to reason about or memorize its entire operation, developers have a healthy fear of unexpected breakages. We often raise the steps intended to mitigate breakages to the level of ritual. One of the most notable manifestations of superstition in software is legacy code.

Creating reusable components is often hindered by excess code accounting for each use case the components need to support. For example, a dropdown that supports text, links, buttons, and even complex components, or a text component that supports multiple different types of HTML tags, in addition to reusable components as well. In both cases, a variety of props will exist for each type of component we pass in that may need to be shared between the parent and child.

You've probably heard of a content management system (CMS), even if you’ve never used one. In short, a CMS is a piece of software that allows users to create, manage, and share website content without knowing how to code.