Skip to content
This repository was archived by the owner on Jul 22, 2024. It is now read-only.

Home

Jump to bottom
Daniel Krook edited this page Feb 22, 2017 · 19 revisions

OpenWhisk 101: Creating Serverless REST APIs

This wiki contains the getting started content posted to both Bluemix and the Accelerate developer advocacy site.

Bluemix tile title and description

Build serverless REST API handlers Create actions that execute logic to execute in response to HTTP REST API calls.

Accelerate intro

Serverless platforms like Apache OpenWhisk provide a runtime that scales automatically in response to demand, resulting in a better match between the cost of cloud resources consumed and business value gained. One of the key use cases for OpenWhisk is to map HTTP REST API calls to business logic functions that create, read, update, and delete entities.

Accelerate overview

This project shows the power of serverless, event-driven architectures to execute code that scales automatically in response to demand from HTTP REST API calls. No resources are consumed until the API endpoints are called. When they are called, resources are provisioned to exactly match the current load.

It shows four OpenWhisk actions (written in JavaScript) that write and read data in a MySQL database. This demonstrates how actions can work with supporting data services and execute logic in response to HTTP requests.

One action is mapped to HTTP POST requests. It inserts the supplied cat name and color parameters into the database. A second action is mapped to PUT requests to update those fields for an existing cat. A third action is mapped to GET requests that return specific cat data. A fourth action deletes a given cat data.

The Node.js runtime on Bluemix provides a pre-built set of NPM modules. This demo also highlights how additional Node.js dependencies - such as the MySQL client - can be packaged in a ZIP file along with custom actions to provide a high level of extensibility.

Accelerate flow and diagram

  1. The developer uploads the first action and maps a route to it. When invoked with a POST request, this connects to MySQL and inserts cat data.
  2. The developer uploads the second action and maps a route to it. When invoked with a PUT request, this connects to MySQL and updates the cat data.
  3. The developer uploads the third action and maps a route to it. When invoked with a GET request, this connects to MySQL and retrieves the cat data.
  4. The developer uploads the fourth action and maps a route to it. When invoked with a DELETE request, this connects to MySQL and deletes the cat data.

Accelerate components

  • OpenWhisk
  • MySQL from Compose

Accelerate technology

  • OpenWhisk
  • MySQL from Compose

Accelerate links

  • What makes serverless architectures so attractive? - Serverless architectures are one of the hottest trends in cloud computing this year, and for good reason. There are several technical capabilities and business factors coming together to make this approach very compelling from both an application development and deployment cost perspective.

  • Build a cloud native app with Apache OpenWhisk - At this live coding event, Daniel Krook provides an overview of serverless architectures, introduces the OpenWhisk programming model, and then deploys an OpenWhisk application on IBM Bluemix, while you watch, step-by-step.

Accelerate blog post

Creating Serverless REST APIs with OpenWhisk Building Serverless REST APIs – Responding to HTTP calls in an event-driven architecture

Imagine that you're a mobile video game studio with three people on your team. You just realized an addictive new puzzle game that users can play with their friends. People love it. Then Apple features it on the App Store homepage. The social connections enabled by your gaming backend is overloaded. Score data overwhelms your database. The one-star reviews pour in.

But it doesn't have to be this way. If you had implemented your backend logic as individual functions deployed to a serverless platform like OpenWhisk, the platform could have autoscaled to match demand exactly. And you would have paid only for the resources consumed by the exact number of users that paid for your game.

This is the promise of an event-driven, serverless architecture for new cloud-native applications such as those that support the microservices needed for mobile gaming backends. Check out the new OpenWhisk 101 project on building Serverless HTTP REST APIs and start dreaming about your next hit game, not its backend infrastructure.

Clone this wiki locally