4 posts tagged with "product announcement"

We're excited to announce the release of our completely free GitHub bot to visualize XState state machines in pull requests!

One of the amazing things about state machines is that your high-level logic becomes pure data that's easy to visualize to quickly understand.

You can install our bot in about 11 seconds here. Once installed, whenever a PR creates or updates a state machine, you'll see a helpful comment from the State Backed Visualizer bot with a visualization of the new machine to easily keep the whole team aligned.

Obviously, we bult the State Backed visualizer bot as a persistent workflow in State Backed! We found a really nice pattern for handling webhooks:

1. Identify the entities in the webhook
2. Map from entity types (e.g. pull request, repo, user) to a State Backed machine definition
3. Create a machine instance for the specific entities in the webhook (e.g. PR 12345 or user 123) if one doesn't already exist
4. Send the machine instance for each referenced entity the webhook as an event

This pattern makes it really easy to keep the state of the entity up to date in your machine instance.

We're thrilled to release the State Backed web UI!

You now have two options to choose from to create machines, deploy versions, and administer your State Backed account: the smply CLI and our brand new web dashboard.

We still recommend using the smply CLI to connect your CI/CD environment and build pipelines to State Backed but the web dashboard is really nice to quickly check in on your instances and to tweak deployments.

We even included a full-blown in-browser IDE to easily author new machine versions. We're not talking about an editor. We're talking npm and a command line right there in your browser.

Check it out:

State Backed, the first platform to allow anyone to launch any state machine as a persistent, reliable cloud actor, subscribe to real-time state updates from anywhere, and send fully authorized events from any client or server, is now available for use.

During this open beta period, we will not be charging clients for their usage and are looking for feedback from the community as we strive to create the nicest developer experience of any backend as a service platform.

Already, deploying a new machine consists of running a single command in our smply CLI or using our in-browser IDE and flow visualizer. Launching a new instance and connecting from the browser is just 3 substantive lines of code:

import { StateBackedClient } from "@statebacked/client";
import { useStateBackedMachine } from "@statebacked/react";
import { useActor } from "@xstate/react";

// Create an anonymous session.
// You can also easily create authenticated sessions using your existing identity provider,
// just by altering the config.
const client = new StateBackedClient({
  anonymous: {
    orgId: "org_YOUR-ORG-ID",
  }
});

function YourComponent() {
  const { actor } = useStateBackedMachine(
    client,
    {
      machineName: "your-machine",
      instanceName: "your-instance",
      getInitialContext() {
        return { "any": "initial-context" }
      }
    }
  );
  
  const [state, send] = useActor(actor);
  // render UI based on real-time updated state and send events
}

The traditional approaches to building backends are getting more and more cumbersome. Having built a ton of these traditional backends ourselves, we're tired of pretending that our individual endpoints or GraphQL resolvers are nicely decoupled bits of logic. In reality, bundles of endpoints, whether you call them microservices or domains within your monolith, are highly interdependent, with lots of assumptions baked into each about the overall flow of state updates. We are, after all, building cohesive user experiences, not merely APIs to be called in any order.

Pretending that these endpoints are decoupled only makes it more and more difficult to piece together an understanding of the high-level flow that we actually care about.

We're confident that the better path forward is to treat flows as first-class entities on the backend. That's what State Backed is about. You build a state machine that describes the logic for a flow or set of flows you care about and deploy it as a single package to the State Backed cloud. That means that you can always understand the most crucial aspects of your app - the evolution of your state and triggering of external effects. State Backed takes care of ensuring that you can launch as many instances of your flows as you want, that each instance is persistent and durable, and that every state update and effect creates a consistent, linearizable history for that machine instance.

And we forgot to mention: every instance creation, read request, and event you send is controled by the simple authorization functions you provide as part of your deployment package, based on the trusted user claims from your existing identity provider (or custom claims for anonymous access or specialized us cases).

We've started building invincible workflows and real-time, multiplayer backends on top of the platform (check out our examples) and we're super excited about the potential of applying this paradigm to these use cases.

You can deploy your first State Backed backend in less than five minutes at StateBacked.dev.

We'd love your feedback!

Everywhere you look, you'll find little bundles of state with little snippets of logic.

A user onboarding tutorial, general user activation state, a document that can be created, shared, and edited, a workflow to approve a piece of content, a rate-limited call to an external API.

There is nothing more annoying than discovering that you need yet another little bundle of state. State needs a place to live, its access patterns become hard to change at scale, changes and reads require careful authorization logic, and the structure of the state at rest rarely matches exactly what we want for the potentially-simple logic that we need to apply to it.

What if these little bundles of state and logic could live in a simple file, next to their authorization logic, came with their own simple-as-memory consistent data storage, and took one command to deploy?

Answering that question led us to build State Backed, the XState backend as a service.

You can now launch any XState state machine as an API-accessible, persistent state machine in the cloud with one command.

Send events and read instance state from your frontend or backend with simple, end-to-end authorization for every end-user and every action.

Check out our quick start to launch your first machine in the next 5 minutes.