All pages
Powered by GitBook
1 of 2

Loading...

Loading...

Javascript | V8

The JavaScript functions that Nex executes are run inside a V8 sandbox, which is often also contained within a Firecracker sandbox. As a result, these JavaScript functions don't have the same kind of freedom of access to capabilities that other function types (e.g. Node.js in a cloud provider). However, we've made the most common use cases available by default through host services.

Host services aren't just access to arbitrary capabilities, they're access to managed capabilities that are designed to be pre-provisioned and ready to go, so function developers don't have to write provisiong code, they can focus solely on the capability abstractions they need.

HTTP Client

If you want to make HTTP calls from your function, you can do so with the HTTP client:

All of the HTTP methods are supported as functions:

  • get

  • post

  • put

  • patch

Key-Value Store

Every Nex-managed JavaScript function has access to an abstraction over a key-value store, which is internally backed by a NATS Key-Value bucket.

Again, note that you don't have to manually or explicitly provision the bucket. You can assume that your function has its own, isolated bucket and that it is safe in a multi-tenant environment.

Object Store

Every Nex-managed function has access to a managed object store. The following code shows how JavaScript can interact with this store:

Core Messaging

JavaScript functions receive messages on their trigger subjects, which are specified at deployment time. To publish or make requests, host services provides access to a core NATS black box.

get = this.hostServices.http.get('https://example.org');
  • del

  • head

  • this.hostServices.kv.set('hello', payload);
    this.hostServices.kv.delete('hello');
    
    this.hostServices.kv.set('hello2', payload);
    return {
      keys: this.hostServices.kv.keys(),
      hello2: this.hostServices.kv.get('hello2')
    }
    (subject, payload) => {
      this.hostServices.objectStore.put('hello', payload);
      this.hostServices.objectStore.delete('hello');
    
      this.hostServices.objectStore.put('hello2', payload);
      return {
        list: this.hostServices.objectStore.list(),
        hello2: String.fromCharCode(...this.hostServices.objectStore.get('hello2'))
      }
    };
    this.hostServices.messaging.publish('hello.world', payload);
    
    req = this.hostServices.messaging.request('hello.world.request', payload);
    
    reqMany = this.hostServices.messaging.requestMany('hello.world.request.many', payload);

    Host Services

    If we're building cloud native/12-factor application components, then we agree that things like connection strings, credentials, database client libraries, etc, are all things that should be treated as external services, configured with external configuration. Very rarely does the typical application component care about which key value store is supplying data, only that it gets the data the environment and those who operate it make available.

    This is the driving philosophy behind host services. If you're using Nex, you're already deploying workloads that consume NATS services. We make that much easier for functions by giving them access to managed resources such as key-value buckets, messaging subject spaces, object stores, and even HTTP clients.