Hello World: Azure Functions with Serverless Framework, Node.js and FaunaDB

Azure Functions offer serverless on-demand execution of your code based on external events like HTTP requests, chat messages, etc. FaunaDB Cloud is purpose-built to be a database for serverless runtimes like Azure Functions, AWS Lambda, and Google Cloud Functions. The post shows how to connect to FaunaDB Cloud from JavaScript running in Azure Functions. 

Here are three ways FaunaDB Cloud is tailored for serverless:

  • First, FaunaDB Cloud requires no provisioning, so you can start developing right away, and your database usage can scale up and down without any attention required from you.
  • Second, FaunaDB Cloud provides strong consistency and ACID transactions, even across global, multi-region datasets. Your application never has to check for quorums, or consider read repair, CRDTs, or other artifacts of eventual consistency.

  • Finally, the pay-as-you-go utility pricing model means you start for free and your costs scale with usage. There’s no need to provision capacity in the hopes of future traffic. In most cases, FaunaDB Serverless Cloud is less expensive than other options, and you never pay for more than you consume.

In this post, we’ll show you how to run JavaScript functions in Azure, with FaunaDB Cloud as a database-as-a-service. FaunaDB Cloud runs worldwide in multiple AWS and GCE regions, and is coming soon to Azure. When we spin up Azure support, any code you deploy today will transparently begin hitting our AWS, GCP, and Azure endpoints. With a trivial config change, you’ll see higher performance due to lower latency from FaunaDB Cloud running on the same network as your Azure Functions, and cost savings from not triggering Azure data egress costs.

As FaunaDB Cloud becomes available in more cloud providers and regions, you’ll be able to choose to replicate your data specifically to the providers and regions you need. Your app’s behavior and correctness won’t change, even as you expand your deployment to multiple regions and across cloud providers. Services you run in different clouds will all have a connection to an in-region FaunaDB Cloud endpoint, accessing the same globally consistent and correct data.

Stick around to look at the code, or jump to the full instructions to deploy your own Azure Functions with FaunaDB.

The JavaScript function below creates a FaunaDB client (line 3) and responds to HTTP requests by issuing a hello-world query. You can learn from realistic queries in the FaunaDB tutorials.

const faunadb = require('faunadb');
const q = faunadb.query;
const client = new faunadb.Client({
  secret: process.env.FAUNADB_SECRET
module.exports.hello = function (context, req) {
  // Add any necessary telemetry to support diagnosing your function
  context.log('HTTP trigger occurred!');
  // Read properties from the incoming request, and respond as appropriate.
  const name = req.query.name || (req.body && req.body.name) || 'World';
  client.query(q.Concat(["Hello ", name])).then((data) => {
    context.done(null, { body: `FaunaDB response: ${JSON.stringify(data)}` });

The query, in this case q.Concat(["Hello ", name]), concatenates the name value (which may be passed in the request) with a “Hello” message, returning a string like “Hello World”. The client constructs an abstract representation of the query and sends it to the server. Query execution happens on the server as part of transaction processing.

Queries in FTL (Functional Transaction Language) safely include complex expressions like loops and conditional logic. All processing happens on the server in the context of an isolated transaction.

Its global ACID properties make FaunaDB especially well-suited for use as an operational database.

In this hello world example, the query doesn’t read or write data so there is no transaction overhead. Stay tuned to this blog to learn more about consistency and isolation levels in FaunaDB.

Once you have a globally consistent database that’s accessible from all your cloud providers, it opens up the possibility of remixing services from different clouds. When the database can coordinate services, why not combine Azure Functions with speech-to-text from Google and image recognition from AWS? All clouds are not created equal, so multi-cloud support lets you arbitrage capabilities as well as pricing across any combination of platforms.