Fathym Technology.

Fathym simplifies cloud complexity by orchestrating cloud-native tools and services, and bringing together the exploding worlds of no-code and low-code with ‘high-code.’

Get Started Now

Learn More

Get started today with amazing biotech devices from:

All-in-one.

With Fathym you can get going with a full, best-practice, Azure cloud today – at the touch of a button. You can do this through Fathym's SaaS Cloud for shared resources, or through our Enterprise Cloud – deployed into your Azure tenant for maximum access and control. The Fathym platform is a composable application platform for delivering future-proof, enterprise-ready applications with Azure. Source Control via GitHub repositories. Build Pipelines via GitHub Actions. You can choose a different source control, such as GitLab, Bit Bucket, Azure, or even ZIP files. You can choose a different build pipeline, such as Azure, Netlify, or Cloudflare. Infrastructure as Code via Azure Bicep and ARM. You can choose a different Infrastructure management tools, such as Terraform, Chef, Puppet or Ansible. Low Code via Fathym’s Low Code Units. These flexible containers are not just configurations like other “low code” offerings. They’re real code – in components. Identity via Fathym’s Identity and Permission system integrated with Azure Active Directory. Other integration options include Okta, Auth0, and others. State Flow is a unique Fathym offering storing the “state” of applications, services, configurations and even user experiences.

Enterprise as Code graph database.

Enterprise as Code (EaC) is a directed graph database that is an all-in-one map to all the resources and services that make up your digital organization. This dynamic graph stores cloud configurations, codebases, deployment pipelines, states, identities, digital assets, applications and more. With Fathym’s EaC, out-of-the-box, an enterprise-scale cloud is configured, launched and maintained – ready for users of varying skills and backgrounds to easily create digital products and services.

From device to cloud in no time.

Flash your device's firmware and get connected to Fathym IoT Ensemble in just a few steps. Fathym gives you hot, warm and cold database storage and API flows for processing device data and sending downstream.

Cold

Raw, long term data-storage and access. Allows for deep learning, AI, ML, and more.

Warm

Structured, time series data for analytics, alerts, monitoring and dashboards.

Hot

Flow real-time data from your connected device using pub/sub or WebSockets.

Launching data-driven apps has never been so easy.

Fathym gives you the out-of-the-box workflow to rapidly launch apps, dashboards or alerts from open-source templates. Whether PowerBI dashboards or ML-powered web applications, launch apps at the click of a button or customize to fit your needs. Use Fathym to version, deploy and host applications with GitHub or npm.

Get Started with Open Devices.

The number of open biotech devices available is increasing every day. Visit these fine manufacturers and distributors to get yours and get started.

Emotibit

The EmotiBit is a small device that allows you to stream 16+ data streams from the body, including PPG, EDA/GSR, 9-axis IMU, and body temperature.

Get Started

Neurotech Kit

This bundle includes a Cyton, Ultracortex, and additional electrodes & accessories for EEG, EMG, and ECG sensing. Available in 8 or 16 channels.

Get Started

Myowear v2

A Muscle Sensor that has been designed from the ground up to be easy-to-use and compact focusing on sensor performance and reliability.

Get Started

HEGduino v2

A compact, state-of-the-art, open hardware solution for home NIR-HEG biofeedback. Monitor Heart Rate Variability (HRV), breathing, and skin temperature.

Get Started

Behind the scenes.

The future is what we want it to be.

Content

The growing world of data management

Enterprise as Code (EaC)

Fathym’s EaC is a proprietary directed graph database that holds the map for how your applications, LCUs, digital assets, permissions, and users come together.

Low-Code Units (LCUs)

Fathym’s LCUs are the most basic building blocks of the Fathym world. These flexible containers can hold anything ranging from small bits of data to large applications.

Distributed File System (DFS)

Fathym’s DFS stores all the components, code, builds, and assets of your applications. This system can span clouds and even cloud-edge architectures (for distributed applications like IoT).

State Flows

The current state of an application is made up of static and dynamic pieces, some user driven, some owner defined, some infrastructure driven. From how microservices are defined and deployed to what a user inputs in a form, Fathym’s proprietary State Flows keeps it all working together.

Data-driven Apps

Spinning up cloud-native apps to make full use of your data has never been so easy.

Fathym Runtime

Our proprietary runtime brings all the pieces and services together. It conducts the orchestration of cloud-native services, making your enterprise and applications run seamlessly out of the parts. The Fathym runtime powers the deployment, hosting and seamless integration of modular and distributed frontends and services as composable web projects.

Behind the scenes.

The future is what we want it to be.

Content

The growing world of data management

Enterprise as Code (EaC)

Fathym’s EaC is a proprietary directed graph database that holds the map for how your applications, LCUs, digital assets, permissions, and users come together.

Low-Code Units (LCUs)

Fathym’s LCUs are the most basic building blocks of the Fathym world. These flexible containers can hold anything ranging from small bits of data to large applications.

Distributed File System (DFS)

Fathym’s DFS stores all the components, code, builds, and assets of your applications. This system can span clouds and even cloud-edge architectures (for distributed applications like IoT).

State Flows

Data-driven Apps

Spinning up cloud-native apps to make full use of your data has never been so easy.

Fathym Runtime

Introducing State Flow APIs: Headless API State Management

A State Flow API is an application programming interface (API) which manages an application’s state. It manages the storage of an application’s state and the actions that can modify that application’s state: A State Entity stores the Count and exposes a State Action to IncreaseCount. The aim of State Flows is to manage and store an application’s state, logic and integrations at the API layer. This facilitates the decoupling and separation of responsibilities for different parts of an application. In this architecture, the backend is responsible for state management, logic, integrations, and receiving user actions from the user interface and triggers from backend data sources, and the frontend is responsible for UI components, sending user actions to the API and rendering the updated state. In this way there are two decoupled loops in play: A state rendering loop in the frontend and a state logic loop in the backend. Organizations can use this State Flow pattern to develop all their application logic in a completely ‘headless’ manner. Frontend teams within an organisation can then focus solely on building the ‘head’. Any changes to the implementation or the replacement of a State Flow API does not impact the frontend, as responsibilities are decoupled. Likewise, any UI updates are simpler, and if an organisation migrates an applications’ frontend to a different framework, the application’s logic and state implementation remain unaffected.

What is an API?

An application programming interface is an intermediary for two or more computer programs or applications to communicate with each other. An API consists of a set of definitions and protocols for building and integrating application software. In general, an API follows the pattern of request and response, whereby an action is submitted for some information in order to fulfil a ‘request’, and that information is then returned as a ‘response’. In modern microservices approaches, this is typically executed through a request and response-based protocol such as HTTP.

Low-code meets AI.

Habistack is the most flexible, cloud-native API for delivering machine learning and statistics-based forecasts with any combination of variables. Habistack brings together NOAA’s HRRR and GFS as a predictive weather forecast data stream with current conditions data from ground-based weather stations all over the US. Habistack incorporates into this model historical sensor data from current-conditions sensors, building a forecast-to-IoT sensor machine learning model. This model becomes the basis for an AI/ML engine with the ability to predict IoT sensor readings from a wide variety of environmental (and other) sensors. This prediction capability, when combined with current sensor readings and recent and historic data, is a geospatial intelligence system that exposes the AI/ML model and data into micro-climate forecast APIs.

Habistack’s demo application is a surface-level, road-weather application. It uses infrared and temperature sensors on roads to predict the temperature of the road surface anywhere in the world. Combining this temperature prediction with known weather variables such as recent precipitation, it outputs a Road State variable.

What is State?

State is the current data representation of something, an object or a system. It describes and remembers the condition of a variable: The count is 1, or the count is 10. The state is also particular to an interaction and is specific to the individual environment. It is usually not meant to be exported or deployed to another environment. The state is simple and can be read, written or deleted. State can operate at different scopes, whether centralized or at the edge. A computer program or application can have a global state, and within that can also have different states for various contexts, such as the state of a project or an individual user session.

What is a State Flow API?

State Flow APIs are APIs that store and manage an application’s state. In this architectural pattern, frontends do not store or manage the state, but render the state that is presented by State Flow APIs. State Flow APIs interact with servers, databases, APIs and third-party integrations to retrieve updated state information, while a frontend client simply connects with a State Flow API to render the state. Through this pattern:

User interface and application state are decoupled
Responsibility for application state management is shifted from the frontend to the headless API layer
Frontends are simplified and responsible for rendering the UI
A State Flow API operates as an intermediary and secure layer between client and servers, external APIs and data sources

Simplified and decoupled

In recent years the Facebook developed flux pattern for building client-side, MVC (model-view-controller) web applications has been widely adopted. In this pattern, frontends reflect some state, and when an action alters the state, the UI then renders this updated state. These stateful processes generally take place in the frontend.

In contrast, State Flow APIs push the flux philosophy to the backend, so that frontends are no longer concerned with state, third-party integrations or making API calls. A frontend simply connects to a State Flow, renders the state, and executes actions against the state. The State Flow is responsible for handling actions, running logic that reacts to state changes and integrates with other APIs and data sources.  Consequently, frontends are simplified and focused on performant user interfaces, and frontend and backend logic are decoupled. User interfaces frame the presentation layer of an application and look to render a current state that is reflected in the UI. In this way, State Flow APIs can be set up in a pattern similar to a Backend for Frontend (BFF) architecture, with small, dedicated APIs for each frontend. However, instead of just creating BFFs for different client types (browser, mobile, third party), State Flow APIs can operate as microservices paired with micro (or modular) frontends. This facilitates a highly flexible, modular, scalable and future-proof architecture. Applications are more testable, maintainable and replaceable. Here is a basic overview of a State Flow API architecture:

View: The view is a declarative mapping of the state on the client (the frontend user interface). State Actions: State Actions are triggers that can modify the state. State Actions are invoked by user inputs from the view and in response to changes in backend data sources, via triggers such as webhooks or WebSockets. Entity Actions: Entity Actions are specific to each Entity Store, and control how State Actions retrieve and manipulate an Entity Store’s data. The Entity Actions can also integrate with and retrieve data from databases, other internal APIs, and third-party integrations. Entity Stores: Entity Stores hold the application’s state. A State Flow API can have many Entity Stores (operating in sync or separately), or also none. Entity Stores update the current state in response to Entity Actions and map the updated state to the view.

Request and response

The State Flow API architectural pattern is agnostic to tech stacks and flexible in implementation. State Flows can be implemented as a standard request and response scenario, whereby the UI updates when a user invokes a State Action, or a request is made for new data from a data source at scheduled intervals. If a user navigates to or refreshes a page, that creates a request for new data. The client can access state data from a cache, but if the cache is not up to date the State Flow sends a HTTP request to a server which returns a response. Through this model it is also possible to implement long polling, whereby servers only return a response to a client if there is new information available.

Persistent listening

Another approach is to take advantage of technologies, such as WebSockets, that facilitate near real-time state rendering. In this model, backend services update State Flow APIs with new and aggregated event data as it becomes available, rather than a server waiting for a frontend client to request new data. In this way, State Flows maintain bi-directional connections with backend services (via WebSockets) that are persistent, unlike a classic HTTP connection, which is re-established for each communication. A frontend immediately renders new state in real-time as it is updated in a State Flow. Application types that are good candidates for real-time state rendering include dashboards and monitoring applications, live feeds, chat applications and real-time collaboration applications. A State Flow implementation for these application types helps boost performance and response times. State Flow APIs react to, draw from and aggregate state information from a variety of different sources, such as user actions, databases, internal APIs (including other state APIs) and third-party integrations.

State Flows: A living system

This always fluid, moving and updated implementation of State Flow APIs is a paradigm shift from the standard request and response method. In the request and response model, data moves on request. But in this fluid paradigm, data moves continuously, consistently and securely. Data is constantly updated and available, for whatever or whoever wants or needs it. It is a living system, where technologies such as WebSockets and serverless functions can handle events and actions and render always up to date state information in real-time. Furthermore, a State Flow architecture can supersede and incrementally replace a more standard HTTP-based microservices architecture. By updating to a State Flow-based architecture, there is no need to wholesale replace existing microservices or monolithic legacy architectures. State Flow APIs can provide a means for incrementally isolating, replacing and modernizing systems, with minimum disruption. They provide the scalability and abstraction, whereby business logic can be developed without being tied to the tech implementation. The framework of the frontend UI that renders the state or the cloud a tech stack is deployed on can change, but the business logic that orchestrates and integrates data through State Flows remains unaffected.