GitBook: [main] 53 pages and 14 assets modified
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 43 KiB |
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 43 KiB |
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 43 KiB |
Before Width: | Height: | Size: 41 KiB After Width: | Height: | Size: 41 KiB |
Before Width: | Height: | Size: 41 KiB After Width: | Height: | Size: 41 KiB |
Before Width: | Height: | Size: 41 KiB After Width: | Height: | Size: 41 KiB |
BIN
.gitbook/assets/air_sequential_2 (1) (1) (1) (1) (1) (1).png
Normal file
After Width: | Height: | Size: 86 KiB |
BIN
.gitbook/assets/air_sequential_2 (1) (1) (1) (1) (1) (2).png
Normal file
After Width: | Height: | Size: 86 KiB |
@ -1,27 +1,27 @@
|
||||
# Building a Frontend with JS-SDK
|
||||
# Building A Frontend with JS SDK
|
||||
|
||||
Fluence provides means to connect to the network from a javascript environment. It is currently tested to work in nodejs and modern browsers.
|
||||
Fluence provides means to connect to the network from a javascript environment. It is currently tested to work in nodejs and modern browsers.
|
||||
|
||||
To create an application you will need two main building blocks: the JS SDK itself and the aqua compiler. Both of them are provided in a form npm packages. JS SDK wraps the air interpreter and provides a connection to the network. There is low-level api for executing air scripts and registering for service calls handlers. Aqua compiler allows to write code in aqua language and compile it into typescript code which can be directly used with the SDK.
|
||||
|
||||
Even though all the logic could be programmed by hand with raw air it is strongly recommended to use aqua.
|
||||
|
||||
## Basic usage
|
||||
### Basic usage
|
||||
|
||||
As previously said you can use fluence with any frontend or nodejs framework. JS SDK could be as any other npm library. For the purpose of the demo we will init a bare-bones nodejs package and show you the steps needed install JS SDK and aqua compiler. Feel free to use the tool most suitable for the framework used in application, the installation process should be roughly the same
|
||||
As previously said you can use fluence with any frontend or nodejs framework. JS SDK could be as any other npm library. For the purpose of the demo we will init a bare-bones nodejs package and show you the steps needed install JS SDK and aqua compiler. Feel free to use the tool most suitable for the framework used in application, the installation process should be roughly the same
|
||||
|
||||
### 1. Start with npm package
|
||||
#### 1. Start with npm package
|
||||
|
||||
For the purpose of the demo we will use a very minimal npm package with typescript support:
|
||||
|
||||
```
|
||||
```text
|
||||
src
|
||||
┗ index.ts (1)
|
||||
package.json (2)
|
||||
tsconfig.json
|
||||
```
|
||||
|
||||
index.ts (1):
|
||||
index.ts \(1\):
|
||||
|
||||
```typescript
|
||||
async function main() {
|
||||
@ -31,9 +31,9 @@ async function main() {
|
||||
main();
|
||||
```
|
||||
|
||||
package.json (2):
|
||||
package.json \(2\):
|
||||
|
||||
```json
|
||||
```javascript
|
||||
{
|
||||
"name": "demo",
|
||||
"version": "1.0.0",
|
||||
@ -49,7 +49,6 @@ package.json (2):
|
||||
"typescript": "^4.2.4"
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
Let's test if it works:
|
||||
@ -71,7 +70,7 @@ Hello, world!
|
||||
$ C:\work\demo>
|
||||
```
|
||||
|
||||
### 2. Setting JS SDK and connecting to Fluence network
|
||||
#### 2. Setting JS SDK and connecting to Fluence network
|
||||
|
||||
Install the dependencies, you will need these two packages.
|
||||
|
||||
@ -81,7 +80,7 @@ npm install @fluencelabs/fluence @fluencelabs/fluence-network-environment
|
||||
|
||||
The first one is the SDK itself and the second is a maintained list of Fluence networks and nodes to connect to.
|
||||
|
||||
All of the communication with the Fluence network is done by using `FluenceClient`. You can create one with `createClient` function. The client encapsulates air interpreter and connects to the network through the relay. Currently any node in the network can be used a relay.
|
||||
All of the communication with the Fluence network is done by using `FluenceClient`. You can create one with `createClient` function. The client encapsulates air interpreter and connects to the network through the relay. Currently any node in the network can be used a relay.
|
||||
|
||||
```typescript
|
||||
import { createClient } from "@fluencelabs/fluence";
|
||||
@ -95,7 +94,6 @@ async function main() {
|
||||
}
|
||||
|
||||
main();
|
||||
|
||||
```
|
||||
|
||||
Let's try it out:
|
||||
@ -108,16 +106,15 @@ $ npm run exec
|
||||
|
||||
Is client connected: true
|
||||
$
|
||||
|
||||
```
|
||||
|
||||
**Note**: typically you should have a single instance`FluenceClient` per application since it represents it's identity in the network. You are free to store the instance anywhere you like.
|
||||
|
||||
### 3. Setting up aqua compiler
|
||||
#### 3. Setting up aqua compiler
|
||||
|
||||
Aqua is the proffered language for the Fluence network. It can be used with javascript-based environments via npm package.
|
||||
Aqua is the proffered language for the Fluence network. It can be used with javascript-based environments via npm package.
|
||||
|
||||
**Warning: the package requires java to be installed (it will call "java -jar ... ") **
|
||||
**Warning: the package requires java to be installed \(it will call "java -jar ... "\)**
|
||||
|
||||
```bash
|
||||
npm install --save-dev @fluencelabs/aqua-cli
|
||||
@ -125,13 +122,13 @@ npm install --save-dev @fluencelabs/aqua-cli
|
||||
|
||||
We will also need the standard library for the language
|
||||
|
||||
```
|
||||
```text
|
||||
npm install --save-dev @fluencelabs/aqua-lib
|
||||
```
|
||||
|
||||
Let's add our first aqua file:
|
||||
|
||||
```
|
||||
```text
|
||||
aqua (1)
|
||||
┗ demo.aqua (2)
|
||||
node_modules
|
||||
@ -143,11 +140,11 @@ package.json
|
||||
tsconfig.json
|
||||
```
|
||||
|
||||
Add two directories, one for aqua sources (1) and another for the typescript output (3)
|
||||
Add two directories, one for aqua sources \(1\) and another for the typescript output \(3\)
|
||||
|
||||
Create a new text file called `demo.aqua` (2):
|
||||
Create a new text file called `demo.aqua` \(2\):
|
||||
|
||||
```
|
||||
```text
|
||||
import "@fluencelabs/aqua-lib/builtin.aqua"
|
||||
|
||||
func demo(nodePeerId: PeerId) -> []string:
|
||||
@ -160,7 +157,7 @@ This script will gather the list of external addresses from some node in the net
|
||||
|
||||
The aqua code can now be compiled by using the compiler CLI. We suggest adding a script to the package.json file like so:
|
||||
|
||||
```json
|
||||
```javascript
|
||||
...
|
||||
"scripts": {
|
||||
"exec": "node -r ts-node/register src/index.ts",
|
||||
@ -177,7 +174,7 @@ npm run compile-aqua
|
||||
|
||||
A typescript file should be generated like so:
|
||||
|
||||
```
|
||||
```text
|
||||
aqua
|
||||
┗ demo.aqua
|
||||
node_modules
|
||||
@ -190,7 +187,7 @@ package.json
|
||||
tsconfig.json
|
||||
```
|
||||
|
||||
### 4. Consuming the compiled code
|
||||
#### 4. Consuming the compiled code
|
||||
|
||||
Using the code generated by the compiler is as easy as calling a function. The compiler generates all the boilerplate needed to send a particle into the network and wraps it into a single call. Note that all the type information and therefore type checking and code completion facilities are there!
|
||||
|
||||
@ -214,12 +211,11 @@ async function main() {
|
||||
}
|
||||
|
||||
main();
|
||||
|
||||
```
|
||||
|
||||
if everything is fine you have similar result:
|
||||
|
||||
```
|
||||
```text
|
||||
$ npm run exec
|
||||
|
||||
> demo@1.0.0 exec C:\work\demo
|
||||
@ -231,19 +227,16 @@ Node 12D3KooWHk9BjDQBUqnavciRPhAYFvqKBe4ZiPPvde7vDaqgn5er is connected to: /ip4/
|
||||
$
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Advanced usage
|
||||
### Advanced usage
|
||||
|
||||
Fluence JS SDK gives options to register own handlers for aqua vm service calls
|
||||
|
||||
**TBD**
|
||||
|
||||
### References
|
||||
|
||||
* For the list of compiler options see: [https://github.com/fluencelabs/aqua](https://github.com/fluencelabs/aqua)
|
||||
* **Repository with additional examples:** [**https://github.com/fluencelabs/aqua-playground**](https://github.com/fluencelabs/aqua-playground)\*\*\*\*
|
||||
|
||||
## References
|
||||
**Building A Frontend with JS SDK**
|
||||
|
||||
- For the list of compiler options see: https://github.com/fluencelabs/aqua
|
||||
- Repository with additional examples: https://github.com/fluencelabs/aqua-playground
|
||||
=======
|
||||
# Building A Frontend with JS SDK
|
||||
|
@ -1,8 +1,6 @@
|
||||
# Overview
|
||||
|
||||
|
||||
In the Quick Start section we incrementally created a distributed, database-backed request processing application using existing services with Aquamarine. Of course, we left a lot of detail uncovered including where the services we used came from in the first place. In this section, we tackle the very issue of development and deployment of service component.
|
||||
|
||||
|
||||
Before we proceed, please make sure your Fluence environment is [setup](../recipes_recipes/recipes_setting_up.md) and ready to go. Moreover, we are going to run our own Fluence node to test our services in a network environment. Please refer to the [Running a Local Fluence Node](../tutorials_tutorials/tutorial_run_local_node.md) tutorial if you need support.
|
||||
|
||||
|
@ -4,7 +4,6 @@ In the previous sections we obtained block reward data by discovering the latest
|
||||
|
||||
As we have seen in our AIR workflows, particles travel the path, trigger execution, and update their data. So far, we have only seen services consume previous outputs as \(complete\) inputs, which means that service at workflow sequence s needs to be fairly tightly coupled to service at sequence s-1, which is less than ideal. Luckily, Fluence provides a solution to access certain types of results as j_son paths_.
|
||||
|
||||
|
||||
## Peer-Based Script Storage And Execution
|
||||
|
||||
As discussed previously, a peer-based ability to "poll" is a valuable feature to some applications. Fluence nodes come with a set of built-in services including the ability to store scripts on a peer with the intent of periodic execution.
|
||||
@ -120,7 +119,6 @@ In order to upload the periodic "block to db poll", we can use parts of the _eth
|
||||
)
|
||||
```
|
||||
|
||||
|
||||
```bash
|
||||
# script file to string variable
|
||||
AIR=`cat air-scripts/ethqlite_block_committer.clj`
|
||||
@ -184,10 +182,9 @@ Particle id: 5fb0af87-310f-4b12-8c73-e044cfd8ef6e. Waiting for results... Press
|
||||
And we are golden. Give it some time and start checking Ethqlite for latest block and reward info!!
|
||||
|
||||
{% hint style="info" %}
|
||||
Unfortunately, our daemonized service won't work just yet as the current implementation cannot take the \(client\) seed we need in order to get our SQLite write working. It's on the to-do list but if you need it, please contact us and we'll see about juggling priorities.
|
||||
Unfortunately, our daemonized service won't work just yet as the current implementation cannot take the \(client\) seed we need in order to get our SQLite write working. It's on the to-do list but if you need it, please contact us and we'll see about juggling priorities.
|
||||
{% endhint %}
|
||||
|
||||
|
||||
For completeness sake, let's remove the stored service with the following AIR script:
|
||||
|
||||
```bash
|
||||
@ -199,7 +196,6 @@ For completeness sake, let's remove the stored service with the following AIR sc
|
||||
|
||||
As Aquamarine advances a particle's journey through the network, output from a service at workflow sequence s-1 method tends to be the input for a service at sequence s method. For example, the _hex\_to\_int_ method, as used earlier, takes the output from the _get\_latest\_block_ method. With single parameter outputs, this is a pretty straight forward and inherently decoupled dependency relation. However, when result parameters become more complex, such as structs, we still would like to keep services as decoupled as possible.
|
||||
|
||||
|
||||
Fluence provides this capability by facilitating the conversion of \(Rust\) struct returns into [json values](https://github.com/fluencelabs/aquamarine/blob/master/interpreter-lib/src/execution/boxed_value/jvaluable.rs#L30). This allows json type key-value access to a desired subset of return values. If you got back to the _ethqlite.clj_ script, you may notice some fancy `$`, `!` operators tucked away in the deep recesses of parenthesis stacking. Below the pertinent snippet:
|
||||
|
||||
```text
|
||||
@ -247,7 +243,6 @@ pub struct RewardBlock {
|
||||
|
||||
and the input expectations of _get\_miner\_rewards_, also an ethqlite service method, with the following [function](https://github.com/fluencelabs/examples/blob/c508d096e712b7b22aa94641cd6bb7c2fdb67200/multi-service/ethqlite/src/crud.rs#L177) signature: `pub fn get_miner_rewards(miner_address: String) -> MinerRewards`.
|
||||
|
||||
|
||||
Basically, _get\_miner\_rewards_ wants an Ethereum address as a `String` and in the context of our AIR script we want to get the value from the _get\_reward\_block_ result. Rather than tightly coupling _get\_miner\_rewards_ to _get\_reward\_block_ in terms of, say, the _RewardBlock_ input parameter, we take advantage of the Fluence capability to turn structs into json strings and then supply the relevant key to extract the desired value. Specifically, we use the `$` operator to access the json representation at the desired index and the `!` operator to flatten the value, if desired.
|
||||
|
||||
For example,
|
||||
|
@ -104,7 +104,6 @@ modules_dir = "artifacts/"
|
||||
name = "block_getter"
|
||||
```
|
||||
|
||||
|
||||
If you haven't done so already, run `./scripts/build.sh` to compile the projects. Once we have _wasm_ files and the service configuration, we can check out our accomplishments with the REPL:
|
||||
|
||||
```bash
|
||||
@ -342,7 +341,5 @@ Particle id: 930ea13f-1474-4501-862a-ca5fad22ee42. Waiting for results... Press
|
||||
===================
|
||||
```
|
||||
|
||||
|
||||
Right on! Our two services coordinate into the intended application returning the reward data for the latest block. Before we move on, locate the corresponding services on the Fluence testnet via the [ dashboard](https://dash.fluence.dev/), update your command-line with the appropriate service and node ids and run the same AIR script. Congratulations, you just run an app coordinated by distributed services!
|
||||
|
||||
|
||||
|
@ -106,7 +106,6 @@ The script extends our previous incarnation by adding only one more method: `upd
|
||||
"api_key": "MC5H2NK6ZIPMR32U7D4W35AWNNVCQX1ENH"}'
|
||||
```
|
||||
|
||||
|
||||
and run the AIR script with the revised `fldist` command:
|
||||
|
||||
```bash
|
||||
|
@ -83,7 +83,6 @@ wget https://github.com/fluencelabs/sqlite/releases/download/v0.10.0_w/sqlite3.w
|
||||
mv sqlite3.wasm artifacts/
|
||||
```
|
||||
|
||||
|
||||
Run `./build.sh` and check the artifacts for the expected wasm files
|
||||
|
||||
Like all Fluence services, Ethqlite needs a [service configuration](https://github.com/fluencelabs/examples/blob/main/multi-service/ethqlite/Config.toml) file, which looks a little more involved than what we have seen so far.
|
||||
@ -114,7 +113,6 @@ name = "ethqlite"
|
||||
|
||||
Let's break it down:
|
||||
|
||||
|
||||
* the first \[\[module\]\] section
|
||||
* specifies the _sqlite3.wasm_ module we pulled from the repo,
|
||||
* allocates memory, where each page is about 64KB, and
|
||||
@ -371,7 +369,6 @@ Particle id: 2fb4a366-6f40-46c1-9329-d77c6d03dfad. Waiting for results... Press
|
||||
===================
|
||||
```
|
||||
|
||||
|
||||
If you run the init script again, you will receive an error _"Service already initiated"_, so we can be reasonably confident our code is working and it looks like our Ethqlite service is up and running on the local node.
|
||||
|
||||
Due to the security concerns for our database, it is not advisable, or even possible, to use an already deployed Sqlite service from the Fluence Dashboard. Instead, we deploy our own instance with our own \(secret\) client seed. To determine which network nodes are available, run:
|
||||
|
@ -2,7 +2,6 @@
|
||||
|
||||
In Fluence, a service is based on one or more [Wasm](https://webassembly.org/) modules suitable to be deployed to the Fluence Compute Engine \(FCE\). In order to develop our modules, we use Rust and the [Fluence Rust SDK](https://github.com/fluencelabs/rust-sdk).
|
||||
|
||||
|
||||
## Preliminaries
|
||||
|
||||
The general process to create a Fluence \(module\) project is to:
|
||||
@ -13,7 +12,6 @@ cargo +nightly create your_module_name --release
|
||||
|
||||
and add the [binary target](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#binaries) and [Flunece Rust SDK](https://crates.io/crates/fce) to the Cargo.toml:
|
||||
|
||||
|
||||
```text
|
||||
<snip>
|
||||
|
||||
@ -111,7 +109,6 @@ modules_dir = "artifacts/"
|
||||
|
||||
The source code for the module can be found in the [examples repo](https://github.com/fluencelabs/examples/tree/main/greeting).
|
||||
|
||||
|
||||
## Taking The Greeting Module For A Spin
|
||||
|
||||
Now that we have a Wasm module and service configuration, we can explore and test our achievements locally with the Fluence REPL tool `fce-repl`. Load the service for inspection and testing:
|
||||
@ -260,7 +257,6 @@ client seed: AgZjbuMvZmCWbqZBABXXtv3cjGTqYFfiVj7aqg8dm2fA
|
||||
client peerId: 12D3KooWFhUMisVC2VtXAertXt5oQQ7Xj1qppFZRM4mvEQ1iUaBP
|
||||
relay peerId: 12D3KooWQQYXh78acqBNuL5p1J5tmH4XCKLCHM21tMb8pcxqGL17
|
||||
[{"config":{"logger_enabled":true,"logging_mask":null,"mem_pages_count":100,"mounted_binaries":null,"wasi":{"envs":null,"mapped_dirs":null,"preopened_files":[]}},"hash":"c8aec6cbbc0a9632bf532b9553092ae6f66d2e3a5f71e11d1fe65e423c2204e2","name":"greeting"},{"config":{"logger_enabled":true,"logging_mask":null,"mem_pages_count":100,"mounted_binaries":null,"wasi":{"envs":null,"mapped_dirs":null,"preopened_files":[]}},"hash":"915d7487d4ae99f6136a7fe053c4ebd52cde1650c47492a315287117cedd0d3a","name":"greeting"}]
|
||||
|
||||
```
|
||||
|
||||
Which confirms our recent upload!!
|
||||
@ -279,7 +275,6 @@ Now that we have a service on our local node, we need to construct our AIR scrip
|
||||
|
||||
As we've seen in the Quick Start section, we call the service _"greeting"_ with service id _service_ and the method parameter _name_. As usual, we use the `fldist` tool to execute the AIR script:
|
||||
|
||||
|
||||
```bash
|
||||
fldist --node-id 12D3KooWQQYXh78acqBNuL5p1J5tmH4XCKLCHM21tMb8pcxqGL17 --node-addr /ip4/127.0.0.1/tcp/9999/ws/p2p/12D3KooWQQYXh78acqBNuL5p1J5tmH4XCKLCHM21tMb8pcxqGL17 run_air -p greeting.clj -d '{"service":"9712f9ca-7dfd-4ff5-817d-aef9e1e92e03", "name": "Fluence"}'
|
||||
```
|
||||
|
@ -8,5 +8,3 @@ The further your understanding, please checkout the remainder of the documentati
|
||||
* The [Tutorials](../tutorials_tutorials/) section offers a a set of how-to's ranging from node and network configuration to fairly large-scale application development.
|
||||
* The [Recipes](../recipes_recipes/) section provides a \(growing\) set of pattern and pattern-like best practices and approaches.
|
||||
|
||||
|
||||
|
||||
|
@ -12,7 +12,6 @@ An alternative, complementary approach is based on [Process calculus](https://en
|
||||
|
||||
Aquamarine, Fluence's distributed composition language and runtime, is based on π-calculus and provides a solid theoretical basis toward the design, modeling, implementation, and verification of a wide class of distributed, peer-to-peer networks, applications and backends.
|
||||
|
||||
|
||||
## Language
|
||||
|
||||
[Aquamarine Intermediate Representation](https://github.com/boneyard93501/docs/tree/a512080f81137fb575a5b96d3f3e83fa3044fd1c/src/knowledge-base/knowledge_aquamarine__air.md) \(AIR\) is a low-level language modeled after the [WebAssembly text format](https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format) and allows developers to manage network peers as well as services and backends. AIR, while intended as a compile target, is currently the only Aquamarine language implementation although a high level language \(HLL\) is currently under active development.
|
||||
|
@ -1,6 +1,6 @@
|
||||
# HLL
|
||||
|
||||
|
||||
## Aquamarine High Level Language
|
||||
|
||||
_**Stay Tuned -- Coming Soon To A Repo Near You**_
|
||||
|
||||
|
@ -33,7 +33,7 @@ The _**par**_ instruction takes two instructions at most as its arguments and pa
|
||||
|
||||
TODO: add better graphic showing the disticntion of branching vs seq.
|
||||
|
||||
**Figure 4: Fold Instruction** ![Execution](../../.gitbook/assets/air_fold_4%20%281%29%20%282%29%20%281%29.png)
|
||||
**Figure 4: Fold Instruction** ![Execution](https://github.com/fluencelabs/gitbook-docs/tree/84e814d02d9299034c9c031adf7f081bb59898b9/.gitbook/assets/air_fold_4%20%281%29%20%282%29%20%281%29.png)
|
||||
|
||||
The _**fold**_ instruction iterates over the elements of an array and workds as follows:
|
||||
|
||||
@ -49,8 +49,7 @@ This instruction is intended for organizing branches in the flow of execution as
|
||||
* The first instruction is executed and if the execution is successful, then the second instruction is ignored
|
||||
* If the first instruction fails, then the second one is executed.
|
||||
|
||||
**Figure 6: Null Instruction** ![Execution](../../.gitbook/assets/air_null_6%20%281%29%20%282%29.png)
|
||||
**Figure 6: Null Instruction** ![Execution](https://github.com/fluencelabs/gitbook-docs/tree/84e814d02d9299034c9c031adf7f081bb59898b9/.gitbook/assets/air_null_6%20%281%29%20%282%29.png)
|
||||
|
||||
This is an empty instruction: it takes no arguments and does nothing. The _**null**_ instruction is useful for generating code.
|
||||
|
||||
|
||||
|
@ -26,8 +26,7 @@ q/quit/Ctrl-C exit
|
||||
|
||||
## Fluence Proto Distributor: FLDIST
|
||||
|
||||
\`\`[`fldist`](https://github.com/fluencelabs/proto-distributor) is a command line interface \(CLI\) to Fluence peers allowing for the lifecycle management of services and offers the fastest and most effective way to service deployment.
|
||||
|
||||
\`\`[`fldist`](https://github.com/fluencelabs/proto-distributor) is a command line interface \(CLI\) to Fluence peers allowing for the lifecycle management of services and offers the fastest and most effective way to service deployment.
|
||||
|
||||
```text
|
||||
mbp16~(:|✔) % fldist --help
|
||||
|
@ -14,12 +14,10 @@ Each Fluence peer is equipped with a set of "built-in" services that can be call
|
||||
|
||||
Please note that the [`fldist`](../knowledge_tools.md#fluence-proto-distributor-fldist) CLI tool, as well as the [JS SDK](../knowledge_tools.md#fluence-js-sdk), provide access to node-based services.
|
||||
|
||||
|
||||
## API
|
||||
|
||||
### peer is\_connected
|
||||
|
||||
|
||||
Checks if there is a direct connection to the peer identified by a given PeerId
|
||||
|
||||
* **Arguments**:
|
||||
@ -89,7 +87,6 @@ Example of service call:
|
||||
|
||||
### peer timestamp\_ms
|
||||
|
||||
|
||||
Get Unix timestamp in milliseconds
|
||||
|
||||
* **Arguments**: None
|
||||
@ -103,7 +100,6 @@ Example of service call:
|
||||
|
||||
### peer timestamp\_sec
|
||||
|
||||
|
||||
Get Unix timestamp in seconds
|
||||
|
||||
* **Arguments**: None
|
||||
@ -365,8 +361,7 @@ Example of service call:
|
||||
|
||||
### deprecated add\_provider
|
||||
|
||||
Used in service aliasing. _\*\*_Stores the specified service provider \(provider\) in the internal storage of the node indicated in the service call and associates it with the given key \(key\). After executing add\_provider, the provider can be accessed via the get\_providers service using this key.
|
||||
|
||||
Used in service aliasing. \_\*\*\_Stores the specified service provider \(provider\) in the internal storage of the node indicated in the service call and associates it with the given key \(key\). After executing add\_provider, the provider can be accessed via the get\_providers service using this key.
|
||||
|
||||
* Arguments:
|
||||
|
||||
@ -394,7 +389,6 @@ Used in service aliasing to retrieve providers for a given key.
|
||||
* Returns: an array of objects of the following structure:
|
||||
|
||||
```javascript
|
||||
|
||||
{
|
||||
"peer": "123D...", // required field
|
||||
"service_id": "uuid-1234-..." // optional field
|
||||
@ -404,7 +398,6 @@ Used in service aliasing to retrieve providers for a given key.
|
||||
Example of service call:
|
||||
|
||||
```scheme
|
||||
|
||||
(call node ("deprecated" "get_providers") [key] providers)
|
||||
```
|
||||
|
||||
|
4
p2p.md
@ -4,9 +4,9 @@ Building and operating distributed networks, backends and applications are non-t
|
||||
|
||||
Consider a workflow tasked with calling multiple REST endpoints, in sequence, where the response of the previous call is the input to the current call. As illustrated in Figure 1, the application is the focal point and data relay.
|
||||
|
||||
![Figure 1: Stylized Data Flow For Application With Multiple Endpoint Calls](.gitbook/assets/image%20%283%29.png)
|
||||
![Figure 1: Stylized Data Flow For Application With Multiple Endpoint Calls](.gitbook/assets/image%20%283%29.png)
|
||||
|
||||
Programming a frontend application in the Fluence peer-to-peer solution, an application is not a workflow intermediary but merely the initiator of a workflow as workflow logic and data traverses the network from service to service. See Figure 2 for an illustration and please note that services may be deployed to different nodes as well as to more than one node.
|
||||
Programming a frontend application in the Fluence peer-to-peer solution, an application is not a workflow intermediary but merely the initiator of a workflow as workflow logic and data traverses the network from service to service. See Figure 2 for an illustration and please note that services may be deployed to different nodes as well as to more than one node.
|
||||
|
||||
![Figure 2: Stylized Data Flow For Application With Fluence Distributed Services ](.gitbook/assets/image%20%284%29.png)
|
||||
|
||||
|
@ -4,8 +4,7 @@ So far, all of the modules we have used were stateless and we did not have to gi
|
||||
|
||||
Without diving too deep into the Fluence security framework, you should be aware that Fluence has an out-of-the box authentication primitive that allows a `user == owner` check not unlike what we've seen in various blockchain platforms or plain old _sudo_. Of course, the Fluence security framework goes much further and affords developers a great deal of flexibility to code a security solution to their needs. For the purpose of our tutorial, however, we'll stick with the built-in authentication and use it as a base for [ambient authority](https://en.wikipedia.org/wiki/Ambient_authority). That is, we use authentication as an authorization guard for select functions at development time and provide the necessary credentials at service call time.
|
||||
|
||||
For the purposes of this tutorial, there is a caveat you need to keep in mind: Every reader of this document inevitably ends up using the same sample service with the same ownership control. In the highly, highly unlikely event you're getting funky results, it's most likely due to someone else doing the very same tutorial at the very same time. \[Jinx\]\([https://en.wikipedia.org/wiki/Jinx\_\(game](https://en.wikipedia.org/wiki/Jinx_%28game)\)\) ! Buy me a Coke, drink the Coke, slowly, try again and you should be fine.
|
||||
|
||||
For the purposes of this tutorial, there is a caveat you need to keep in mind: Every reader of this document inevitably ends up using the same sample service with the same ownership control. In the highly, highly unlikely event you're getting funky results, it's most likely due to someone else doing the very same tutorial at the very same time. \[Jinx\]\([https://en.wikipedia.org/wiki/Jinx\_\(game](https://en.wikipedia.org/wiki/Jinx_%28game)\)\) ! Buy me a Coke, drink the Coke, slowly, try again and you should be fine.
|
||||
|
||||
The next sections explore both the setup and the use of our database: Sqlite as a Service.
|
||||
|
||||
|
@ -106,7 +106,6 @@ The new service components called are:
|
||||
* _get\_reward\_block_, which takes a miner address and in this cae the one produced by `get_block`, and finally
|
||||
* _get\_miner\_rewards_, which returns a list of miner rewards for a particular miner address; in this case, the one provided by the `get_reward_block` result. Note the `$` operator to access the `block_miner` field in the return struct and the `!` operator to flatten the response
|
||||
|
||||
|
||||
From the previous section we know that
|
||||
|
||||
* service\_1: 74d5c5da-4c83-4af9-9371-2ab5d31f8019 , node\_1: 12D3KooWGzNvhSDsgFoHwpWHAyPf1kcTYCGeRBPfznL8J6qdyu2H
|
||||
|
@ -50,7 +50,7 @@ _seq_ is the _sequential_ instruction that wraps arguments and executes them, yo
|
||||
_xor_ is the _branching_ instruction that takes two **instructions,** e.g., two _seq_ instructions as arguments and evaluates the first argument only to proceed to the second instruction if the first one failed.
|
||||
|
||||
_call_ is the _execution_ instruction to launch distributed service methods and takes the following data:
|
||||
**\(**_call_ **node-id \(service-id service-method\) \[input parameters\] result\)**
|
||||
**\(**_call_ **node-id \(service-id service-method\) \[input parameters\] result\)**
|
||||
{% endhint %}
|
||||
|
||||
As with the previous AIR script, the _xor_ takes care of capturing errors in case things don't pan out the way we've planned. Other than that, we are calling the `hex_to_int` method and we need to supply the service and node ids as well the the hex value. Save the above script to a local file called _hex2int.clj_ and use `fldist` to deploy the script:
|
||||
|
@ -21,7 +21,7 @@ In order to execute the cUrl service and collect the result, i.e., response, we
|
||||
)
|
||||
```
|
||||
|
||||
Without going too deep into Aquamarine and AIR, this script specifies that we call a public peer-to-peer relay \(node\) on the network, ask to run the \(curl\) _request_ function with data parameter _url_ and _service\_id_ parameter, and collect the _result_ **xor** the _error message_ in case of execution failure. We also promise to pass the _service\_id_ and _url_ parameters to the scripts.
|
||||
Without going too deep into Aquamarine and AIR, this script specifies that we call a public peer-to-peer relay \(node\) on the network, ask to run the \(curl\) _request_ function with data parameter _url_ and _service\_id_ parameter, and collect the _result_ **xor** the _error message_ in case of execution failure. We also promise to pass the _service\_id_ and _url_ parameters to the scripts.
|
||||
|
||||
The "magic" happens by handing the script to the `fldist` CLI tool, which then sends the script for execution to the specified p2p network and locally shadows the execution. Please note that Instead of developing full-fledged frontend applications, we use the `fldist` CLI tool. However, a [JS SDK](https://github.com/fluencelabs/fluence-js) is available to accelerate the development of more complex frontend applications.
|
||||
|
||||
|
@ -1,6 +1,5 @@
|
||||
# cUrl as a Service
|
||||
|
||||
|
||||
## Overview
|
||||
|
||||
[Curl](https://curl.se/) is a widely available and used command-line tool to receive or send data using URL syntax. Chances are, you probably just used it when you set up your Fluence development environment. For Fluence services to be able to interact with the world, cUrl is one option to facilitate https calls. Since Fluence modules are Wasm IT modules, cUrl cannot not be a service intrinsic. Instead, the curl command-line tool needs to be made available and accessible at the node level. And for Fluence services to be able to interact with Curl, we need to code a cUrl adapter taking care of the mounted \(cUrl\) binary.
|
||||
@ -48,7 +47,6 @@ We are basically linking the [external](https://doc.rust-lang.org/std/keyword.ex
|
||||
* [Mounted binaries](https://github.com/fluencelabs/fce/blob/c559f3f2266b924398c203a45863ebf2fb9252ec/fluence-faas/src/host_imports/mounted_binaries.rs)
|
||||
* [cUrl](https://github.com/curl/curl)
|
||||
|
||||
|
||||
### Service Construction
|
||||
|
||||
In order to create a valid Fluence service, a service configuration is required.
|
||||
|
@ -3,4 +3,3 @@
|
||||
* [Fluence Manifesto](https://fluence.network/manifesto.html)
|
||||
* [Fluence Protocol](https://github.com/fluencelabs/rfcs/blob/main/0-overview.md)
|
||||
|
||||
|
||||
|
@ -1 +1,2 @@
|
||||
# Tutorials
|
||||
|
||||
|