Free Alf Core Training

Getting Started With Free Alf Core Training

ALF Core is an open source component orchestration framework used mainly for building configurable workflow automation systems. The Free Alf Core Training materials are scattered across a few public repos and community boards, and figuring out where to actually start is the hardest part. Here is how to get from zero to running a basic pipeline without wasting a week. Start with the official repo at alf-core.org/docs. The README is bare-bones, which is intentional. The real documentation lives under /docs/core/concepts/ and /docs/core/workflows/. I found the concepts section most useful because it explains the object graph system before you touch any code. The workflow tutorials assume you already understand nodes, edges, and the serialization layer. If you skip that, you will spend hours debugging why your pipeline refuses to load. The training modules are labeled v1 through v5. Modules v1 and v2 cover installation and a hello-world style workflow. Modules v3 and v4 go into custom node development and runtime configuration. Module v5 is basically a capstone project with no hand-holding. I recommend doing v3 before v4 because the runtime config section in v4 references patterns introduced in v3 without explanation.

Installation and Setup

You need Node.js 18 or higher. The official docs mention 16, but several core functions use optional chaining and nullish coalescing that break on older runtimes. Run: npm install -g alf-core-cli Then initialize a project:

alf init my-project --template workflow-base The template scaffold gives you a basic structure with a sample pipeline.json and a nodes directory. The important thing most people miss is that you need to set the ALF_CONFIG_PATH environment variable before running anything. Without it, the CLI defaults to ~/.alf/config which often causes permission errors on Linux systems. I have my scripts set this to ~/alf-data/config in .bashrc and it has been stable.

Understanding the Core Architecture

ALF Core works on a directed acyclic graph model. Each node in your pipeline represents a discrete operation. Edges define data flow between nodes. The framework serializes intermediate state to disk between nodes by default, which is why pipeline runs can feel slow on the first pass. You can disable disk serialization with the --memory-mode flag during development, and execution time typically drops from around 45 seconds per run to under 3 seconds for the same pipeline. The object graph system uses a schema defined in JSON Schema Draft 7. Every node input and output must declare its schema. This sounds rigid but it is what catches type mismatches before runtime. A common mistake is treating the schema as optional decoration. It is not. If your node outputs a field called timestamp but declares it as a string when the downstream node expects a float, the pipeline will fail silently during deserialization and return null. I spent three days tracking down a bug that turned out to be exactly this issue on a legacy node from a prior version of the framework.

Common Pitfalls and What Actually Works

Node version drift is the biggest problem. When you update ALF Core via npm, your custom nodes may still reference APIs from the previous major version. The framework does not provide deprecation warnings for custom node code. I resolved this by maintaining a separate lock file for my nodes directory using npm shrinkwrap, which pins exact versions independently of the global CLI installation. Another thing nobody mentions in the training: the default retry logic only covers network timeouts. It does not retry on deserialization failures, validation errors, or custom exceptions thrown by your node logic. If you are building pipelines that depend on external API calls, you need to implement your own retry wrapper. I wrote a small decorator that retries up to 5 times with exponential backoff and it handles everything the built-in system ignores.

Writing Your First Custom Node

Nodes are plain JavaScript or TypeScript modules exported as classes extending AlfNode. Here is a minimal example that takes a string input, uppercases it, and outputs the result: class UppercaseNode extends AlfNode {\n async execute(input) {\n return { result: input.value.toUpperCase() };\n }\n}\n\nmodule.exports = UppercaseNode; The execute method receives the parsed input object and must return an object matching the node's declared output schema. Anything extra gets stripped. Anything missing causes a validation error. Keep it simple. Don't try to return metadata or status codes alongside your actual output in the same object. Use the context object for that instead.

Debugging Strategies That Actually Help

The built-in log level is set to info by default, which means you see node names and timestamps but nothing about data flowing between them. Set ALF_LOG_LEVEL to debug and pipe the output to a file. The debug logs include full input and output schemas for every node execution. I use this whenever a pipeline behaves unexpectedly. Another trick: ALF Core supports a --dry-run flag that validates your pipeline graph without executing any nodes. It catches circular dependencies, missing schema declarations, and disconnected nodes. Run this before every deployment. It saves considerable time compared to running the full pipeline and watching it fail halfway through.

Resources and Links

The Free Alf Core Training materials are available through the official documentation site and the community Discord. There is also a GitHub Discussions board where maintainers occasionally post updates that never make it into the README. I check it weekly because breaking changes to the serialization format tend to get announced there first. If you are working on a production system and need support beyond the community forums, the core team offers paid consulting at alf-core.org/support. It is not free, but the response time is measured in hours rather than weeks.