Welcome to the Blok framework! This document provides an overview of the project’s objectives and architecture to help contributors understand its purpose and structure.

​
**Why We Are Building Blok **

Modern software architectures have evolved from monoliths to microservices, and now to nanoservices. While microservices introduced modularity and scalability, they also created significant maintenance overhead, code duplication, and complex dependency management. Blok is built to solve these challenges by maximizing code reusability and simplifying service management, while offering the flexibility to deploy applications in any architecture—whether nanoservices, microservices, or monoliths.

​
Problems with Microservices

Microservices separate logic based on business objectives rather than functional reusability, leading to:
  • 🚨 Massive Code Duplication – Similar functionalities (e.g., authentication, logging, database access) are implemented repeatedly across services.
  • 🔄 High Maintenance Overhead – Updating shared logic across multiple services requires significant effort and coordination.
  • 🏗 Operational Complexity – Managing multiple independent services introduces deployment, scaling, and observability challenges.
While microservices solve some scalability problems, they introduce architectural inefficiencies that bloks can address.

​
Our Approach: Nanoservices with Deployment Flexibility

We focus on the architectural benefits of bloks while ensuring that teams can deploy applications in any model—not just as nanoservices.

​
Key Design Principles

✅ Code Reusability – Nodes (nanoservices) are designed as reusable, independent execution units.
✅ Built-in Monitoring & Observability – Every nanoservice is containerized, automatically monitored, and resource-optimized.
✅ Workflow-Driven Development – Instead of writing services from scratch, developers compose workflows using nanoservices, reducing redundancy.

​
Deployment Flexibility

With Blok , developers can build with nanoservices but deploy in different architectures:
🔹 Blok – Fully isolated, event-driven services for maximum modularity.
🔹 Micro – Deploy a group of bloks together as a single microservice.
🔹 Monolith – Bundle all bloks into a single executable for easier management. Our goal: Enable teams to leverage nanoservice benefits without enforcing a single deployment approach.

​
Conclusion

Blok is designed to give developers control over how they build and deploy applications. Instead of being forced into a microservices-only approach, teams can:
  • ✅ Reuse code efficiently
  • ✅ Reduce maintenance overhead
  • ✅ Choose their preferred deployment model
We believe architecture should serve developers, not dictate constraints—and that’s why we’re building Blok . 🚀

​
Objectives

The primary goal of Blok is to provide a scalable, modular, and efficient nanoservice-based framework for building cloud-native workflows. It enables developers to create isolated, reusable, and dynamically scalable execution units with minimal operational overhead.

​
Core Objectives

  1. Extreme Modularity
    • Nodes (nanoservices) are independent, reusable components.
    • Designed to be lightweight and purpose-driven.
  2. Optimized Resource Utilization
    • Dynamic resource allocation to scale workloads efficiently.
    • Containerized execution to ensure security and isolation.
  3. Workflow Automation
    • Nodes are orchestrated in structured workflows.
    • Support for sequential, parallel, and conditional execution.
  4. Ease of Development & Contribution
    • Clear and structured approach to building and sharing nodes.
    • Support for multiple runtimes (e.g., TypeScript, Python).
    • Community-driven ecosystem for open-source collaboration.

​
Project Structure

The Blok framework follows a nanoservice architecture, where each node is a self-contained execution unit with its own runtime and lifecycle.

​
Core directories and components:

  1. /docs – project documentation and guides.
  2. /core – core application components, including runner and shared.
  3. /infra – monitoring & observability components, and Docker configurations. For more details, see here.
  4. /nodes – a collection of built-in nodes for common use cases. View full list here.
  5. /packages – npx-based CLI. For full list of commands, see here.
  6. /templates – list of templates available for use via CLI.
  7. /workflows – sample workflows and configurations. For more details, see here.
  8. /triggers – list of triggers available for use via CLI. For more details, see here.