Skip to content
tau.how

Functions (dfunctions)

Serverless functions, often referred to as cloud functions or Functions-as-a-Service (FaaS), are the backbone of serverless architecture. They allow developers to focus on writing code, which is executed in response to events (such as HTTP requests, database changes, or specific queue messages) rather than managing or provisioning servers.

Unlike traditional systems, where serverless functions are implemented through centralized systems, Taubyte takes a unique approach with its serverless functions, referred to as ‘dfunctions’ due to their decentralized nature.

In traditional systems, a centralized API Gateway handles all incoming requests, routing them to the appropriate function. These functions are generally stateless and short-lived, existing and operating within the infrastructure managed by centralized cloud providers.

In contrast, Taubyte dfunctions do not require a centralized API Gateway for request routing. Instead, any node with capacity can capture the trigger event (HTTP, P2P, PubSub, etc.), provision the function, and execute it.

Moreover, Taubyte leverages the InterPlanetary File System (IPFS) protocol, but not necessarily the network, for storing the function code in a decentralized manner. This implies that the function code is not confined to a single central server, but accessible across a network of nodes, thereby enhancing reliability and accessibility.

The decentralized implementation of serverless functions in Taubyte offers several advantages:

  1. Reduced Latency: The ability of any node to respond to a function trigger usually results in quicker response times, thereby improving the performance of applications.
  2. Improved Resilience: The decentralized network provides a more resilient system. Even if certain nodes fail, others can continue to process requests, ensuring uninterrupted operation.
  3. Increased Security: Each function execution occurs in isolation, enhancing the security of code execution.
  4. Scalability: The distributed nature of the system allows for high scalability as more nodes can be added to manage increasing demand.

Here’s a sample of what a dfunction’s configuration file could look like:

id: QmdwAdQ9epgFRqqb9F7nFME5y8shBGzzvUE6pfFcgjCwwo  
description: "an ipfs gateway"  
tags: []  
source: .  
trigger:  
  type: https  
  method: GET  
  paths:  
    - /get  
domains:  
  - taulink  
execution:  
  timeout: 10s  
  memory: 10MB  
  call: get

Here’s some explanation of the yaml

  • id: The unique identifier for the dfunction.
  • description: A short description of what the dfunction does.
  • trigger: This section specifies the conditions under which the dfunction is triggered.
    • type: The type of the event that triggers the function. This could be ‘https’, ‘p2p’, ‘pubsub’, and so on.
    • method: The HTTP method (‘GET’, ‘POST’, etc.) in case of ‘https’ type trigger.
    • paths: The paths that, when hit, will trigger the function. These paths are relative to the base path of the domain.
  • domains: The domains under which the dfunction is available.
  • execution: This section specifies the execution parameters of the dfunction.
    • timeout: The maximum time the function is allowed to run before it is terminated.
    • memory: The maximum amount of memory the function is allowed to use.

Overall, Taubyte’s implementation of dfunctions maximizes the benefits of decentralized networks, providing a solution that is more resilient, efficient, and secure than traditional centralized methods. This innovative approach has the potential to revolutionize the way developers build and deploy serverless applications in a cloud-native environment.