How is the TEA Project Serverless?
Computer programming has long made use of pure anonymous functions that aren’t bound to any identifiers. A particularly useful features of these pure functions is that once the function is completed, nothing is stored in memory (i.e. they’re stateless). The TEA Project makes prominent use of pure functions in its serverless architecture design that’s both similar and different to commercial competitors like Amazon’s Lambda.
The Benefits of Server-less Pure Functions
Pure functions have many practical benefits. For example, the order of pure functions can be reversed as well as being performed in parallel if there’s no data dependency between them. Pure functions are thread-safe and cannot interfere with one another.
Pure functions are also easy to mix together as their output only depends on the input. A simple example is code that’s written as a series of linked pure function calls. Additionally, pure functions are declared inline and can access variables in parent scopes. And because pure functions have no surprise side effects or hidden I/O, it’s easy to grok what they do.
What are the Pure Functional / Server-less Options from Commercial Providers?
In practical terms, pure functions can be farmed out to service providers where they run computational tasks on behalf of the clients who don’t have to run a server. Different companies have different implementations of these server-less pure functions:
- Amazon calls their implementation AWS Lambda.
- Google calls their implementation Google Cloud Functions.
- We at the TEA Project call our implementation actors.
One difference that the TEA Project has with Amazon or Google is that our node infrastructure is comprised of decentralized miners. These nodes are where the pure functions run in the TEA Project ecosystem. Depending on the complexity of the app, the TApp developer can require a higher number of nodes before its TApp will run. The number of CML nodes hosting a TApp will fluctuate according to a number of factors which includes the profitability of hosting that TApp.
In the TEA Project, our CML hosting nodes don’t store anything. These nodes can be called by anyone at any time, and all resulting state changes are stored in our state machine nodes.
Because nothing is stored, this is similar to a lambda function. Any node can die, and it won’t affect the rest of the TEA ecosystem. In this way, the TEA Project is built using modern computer architecture design.
Ethereum’s Missing “Server” in the Traditional 3-Tier Stack
We’ve previously discussed how the TEA Project offers all three tiers of the traditional 3-tier architecture. This makes it straightforward for developers to make the jump from web2 to web3.
The TApps 3-tier Decentralized Tech Stack
TEA Project TApps are decentralized apps that are able to run fast and provide a rich user experience. It’s true that…
The Data Tier: The Database (State Machine) of TApps
Earlier we explained the front consumer-facing tier of the typical TEA Project TApp (the presentation tier) as well as…
In contrast to smart contract platforms like Ethereum that lack the middle server layer, the TEA Project offers a middle compute layer to the dApps on its platform. We could say that the various TEA Project actors act as server-less pure functions, and together in aggregate make up the TEA Project’s middle server layer. This tier is integral to allowing web3 apps on top of the blockchain to run as fast as their web2 counterparts in the TEA Project ecosystem.
We love discussing server-less and pure function topics (as well as less technical topics) and invite you to join the discussion on our Telegram.