Hello again everyone! This week at Standard Library, we're excited to announce something that's been cooking for a while — we're officially migrating to a new API Gateway beginning today. We've updated the FaaSlang spec to include some awesome new features and we'll be moving everybody's APIs to api.stdlib.com from lib.id, the current Gateway domain. More on what that means for you in terms of features and actions you may have to take below.

Before we jump in to that, we want to give a quick and big shoutout to both nwHacks 2019 and QHacks 19 which we were very pleased to be able to sponsor over the last two weekends. Between the two events we saw nearly 1,000 student attendees, and the projects built with Standard Library were phenomenal. Thank you for having us!

New API Gateway

As of today — February 6th, 2019 — all new APIs deployed to the Standard Library platform using our Command Line Utilities or Code on Standard Library will be given a new web address on [username].api.stdlib.com. This API Gateway is running version 0.4.0 of FaaSlang, our Gateway specification that performs type coercion, schema validation and more.

New API Gateway Features

  • Functions may no longer be called with Arrays or lists of parameters that map to function arguments — they must be invoked using an object of key-value pairs representing parameter names and values

  • As a result of this change, the first parameter in a function can now be of type any or object, reducing frustration for developers who want to pass in objects as the first (or only) parameter

  • Functions now support Object Schemas which can define specific key / value expectations in both type array and type object

Object Schemas

Standard Library API endpoint functions could previously be documented to be type-coerced and type-enforced based a modified ESDoc implementation, i.e.

* My API endpoint does something!
* @param {string} name
* @param {number} age
* @returns {string}
module.exports = async (name, age) => {
  return `Hello ${name}, you are ${age} years old`;

With Object Schemas, you can now accept object types and nest expected parameter values. Note that Objects can be overloaded and that a schema represents the minimum (smallest) object signature the function will accept. For arrays, Only one top-level value may be supplied and it must match every entry. In the example below, the friends array is an array of string types.

* My API endpoint does something!
* @param {object} person
*  {string} name
*  {number} age
* @param {array} friends
*  {string} friendName 
module.exports = async (person = {}, friends = []) => {
  return `Hello ${person.name}, you are ${person.age} years old.` +
    `You have these friends: ${friends.join(',')}`;

Migration Period

All of our developers and customers to date are currently using the lib.id gateway, but new developers will be directed towards api.stdlib.com immediately. For those using lib.id for webhooks, integrations and more — we're setting an End of Life target for October 6th, 2019, or eight months from today. Note that the old Gateway will no longer be receiving feature upgrades and improvements. Old functionality will remain the same, but if you're looking for new features we encourage you to reference the new Gateway. Your APIs will be available on [username].api.stdlib.com/[service]@[env] instead of [username].lib.id/[service]@[env].

If you've been connecting to Standard Library APIs with our lib package in Node.js or from your browser, you can simply upgrade the package to the most recent version 4.0.0 and the Gateway hostname will be updated automatically.

Thanks, and Happy Hacking!

Thanks for reading, and we hope you enjoy the new Gateway and features! You'll be seeing many more updates in the coming weeks. If you have any questions, support or otherwise, feel free to join our Slack workspace. You can also follow us on Twitter, @StandardLibrary.

Keith Horwood
Founder and CEO, Standard Library