FunctionScript

An API gateway and framework for turning functions into web services

FunctionScript is a language and specification for turning JavaScript functions into typed HTTP APIs. It allows JavaScript (Node.js) functions to be seamlessly exported as HTTP APIs by defining what the HTTP interface will look like and how it behaves in the preceding comment block - including type-safety mechanisms.

FunctionScript arose out of a need to introduce developers with little programming experience, but familiarity with JavaScript, to full-stack API development and best practices around defining and connecting HTTP application interfaces. For this reason, the goals of the language are significantly different than TypeScript. FunctionScript is intended to provide an easy introduction to API development for those of any skill level, while maintaining professional power and flexibility.

FunctionScript is the primary specification underpinning the Autocode platform and its standard library of APIs.

Quick Example of a FunctionScript API

The following is a real-world excerpt of an API that can be used to query a Spreadsheet like a Database. The underlying implementation has been hidden, but the parameters for the API can be seen.

/**
* Select Rows from a Spreadsheet by querying it like a Database
* @param {string} spreadsheetId The id of the Spreadsheet.
* @param {string} range The A1 notation of the values to use as a table.
* @param {enum} bounds Specify the ending bounds of the table.
*   ["FIRST_EMPTY_ROW", "FIRST_EMPTY_ROW"]
*   ["FULL_RANGE", "FULL_RANGE"]
* @param {object} where A list of column values to filter by.
* @param {object} limit A limit representing the number of results to return
* @ {number} offset The offset of records to begin at
* @ {number} count The number of records to return, 0 will return all
* @returns {object} selectQueryResult
* @ {string} spreadsheetId
* @ {string} range
* @ {array} rows An array of objects corresponding to row values
*/
module.exports = async (
  spreadsheetId = null,
  range,
  bounds = 'FIRST_EMPTY_ROW',
  where = {},
  limit = {offset: 0, count: 0},
  context
) => {

  /* implementation-specific JavaScript */

  return {/* some data */};

};

It generates an API which accepts (and type checks against, following schemas):

• spreadsheetId A string
• range A string
• bounds An enum, can be either "FIRST_EMPTY_ROW" or "FULL_RANGE"
• where An object
• limit An object that must contain:
  • limit.offset, a number
  • limit.count, a number

It will return an object:

• selectQueryResult
  • selectQueryResult.spreadsheetId must be a string
  • selectQueryResult.range must be a string
  • selectQueryResult.rows must be an array

Background

The impetus for creating FunctionScript is simple: it stems from the initial vision of Autocode. We believe the modern web is missing a base primitive - the API. Daily, computer systems and developers around the planet make trillions of requests to perform specific tasks: process credit card payments with Stripe, send team messages via Slack, create SMS messages with Twilio. These requests are made primarily over HTTP: Hypertext Transfer Protocol. However, little to no "hypertext" is actually sent or received, these use cases have emerged in an ad hoc fashion as a testament to the power of the world wide web. Oftentimes, API standardization attempts have been presented as band-aids instead of solutions: requiring developers to jury rig a language, framework, markup language and hosting provider together just to get a simple "hello world" out the door.

By creating API development standards as part of a language specification instead of a framework, FunctionScript truly treats the web API as a base primitive of software development instead of an afterthought. This allows teams to be able to deliver high-quality APIs with the same fidelity as organizations like Stripe in a fraction of the time without requiring any additional tooling.

Table of Contents

1. Introduction
2. Why FunctionScript?
3. FunctionScript Examples
   1. All Available Types
4. Specification
   1. FunctionScript Resource Definition
   2. Context Definition
   3. Parameters
      1. Constraints
      2. Types
      3. Type Conversion
      4. Nullability
   4. FunctionScript Resource Requests
      1. Context
      2. Errors
         1. ClientError
         2. ParameterError
            1. Details: Required
            2. Details: Invalid
         3. FatalError
         4. RuntimeError
         5. ValueError
5. FunctionScript Server and Gateway: Implementation
6. Acknowledgements

Introduction

To put it simply, FunctionScript defines semantics and rules for turning exported JavaScript (Node.js) functions into strongly-typed, HTTP-accessible web APIs. In order to use FunctionScript, you'd set up your own FunctionScript Gateway or you would use an existing FunctionScript-compliant service like Autocode.

FunctionScript allows you to turn something like this...

// hello_world.js

/**
* My hello world function!
*/
module.exports = (name = 'world') => {

  return `hello ${name}`;

};

Into a web API that can be called over HTTP like this (GET):

https://$user.api.stdlib.com/service@dev/hello_world?name=joe

Or like this (POST):

{
  "name": "joe"
}

And gives a result like this:

"hello joe"

Or, when a type mismatch occurs (like {"name":10}):

{
  "error": {
    "type":"ParameterError"
    ...
  }
}

Why FunctionScript?

FunctionScript is intended primarily to provide a scaffold to build and deliver APIs easily. It works best as a part of the Autocode platform which consumes the FunctionScript API definitions, hosts the code, generates documentation from the definitions, and automatically handles versioning and environment management. The reason we've open sourced the language specification is so that developers have an easier time developing against the highly modular API ecosystem we've created and can contribute their thoughts and requests.

You can break down the reason for the development of FunctionScript into a few key points:

• Modern developers and people being introduced to software development for the first time are often trying to build web-native scripts. It is exceedingly difficult to go from "zero to API" in less than a few hours, writing code is just the first step of many. We'd like it to be the first and only step.

• No true standards around APIs have ever been built or enforced in a rigorous manner across the industry. Primarily, opinions around SOAP, REST and GraphQL requests have been built into frameworks and tools instead of a language specification, which has artificially inflated the cognitive overhead required to ship functional web-based software.

• Companies like Stripe and Twilio which have built and enforced their own API development paradigms internally have unlocked massive developer audiences in short timeframes, indicating the power of treating web APIs as a first-class citizen of development.

• Serverless computing, specifically the Function-as-a-Service model of web-based computation, has made API development significantly more accessible but has not brought us over the "last-mile" hump.

• JavaScript, specifically Node.js, is an ideal target for API development standardization due to its accessibility (front-end and back-end), growth trajectory, and flexibility. Most new developers are introduced to JavaScript out of necessity.

• As opposed to something like TypeScript, FunctionScript helps newer entrants to software development by extending JavaScript with very little overhead. It adds types around only the HTTP interface, leaving the majority of the language footprint untouched but strengthening the "weakest" and least predictable link in the development chain: user input.

With FunctionScript, it's our goal to develop a language specification for building APIs that automatically provides a number of necessary features without additional tooling:

• Standardized API Calling Conventions (HTTP)
• Type-Safety Mechanisms at the HTTP -> Code Interface
• Automatically Generated API Documentation

FunctionScript Examples

We'll be updating this section with examples for you to play with and modify on your own.

All Available Types

Here's an example of a hypothetical createUser.js function that can be used to create a user resource. It includes all available type definitions.

/**
* @param {integer} id ID of the User
* @param {string} username Name of the user
* @param {number} age Age of the user
* @param {float} communityScore Community score (between 0.00 and 100.00)
* @param {object} metadata Key-value pairs corresponding to add