With the revolution of cloud we got very used to IaaS. Whenever we want a server, we just call an API and here we are with a brand new server ready within minutes!

But minutes were way too long for us! So, then came Docker, which made it possible to have all our environments loaded within seconds.

Of course, for all this you still needed a server to run on. Two years ago, AWS came up with Lambda, where all we have to do is store the function and trigger it either by other AWS services events or by an HTTP request.

Now, let’s take the example of running lots of small services, which are called only a few thousand times per month, but as we cannot predict the time when they’ll be used, they are just sitting there the rest of the time. Without Lambda, we will need more than one Docker container to run these services with failover. So the idea of having the failover and scaling without having to take care of any containers or servers was a no-brainer for me.


When you use Lambda and want to expose through HTTP, you discover that you can use the API Gateway of AWS. It is a nice technology but kind of complex to configure. When something goes wrong in your code, you cannot debug it as easily as when it was hosted on your machine.

So, this is where the idea of Webda comes in!

The Goal

The goal of Webda is to have a framework that allows you to code locally and test it using a Node.JS and then deploy it automatically either to Lambda with API Gateway or by creating a Docker image with it including a NodeJS server.

This way you can easily debug locally and then deploy to your AWS environment in a second.

Let’s take a look at how to get started and create a new project.


To start with you can checkout our demo project in GitHub and our video presentation in Youtube

1. Create a Project

npm install -g webda-shell webda config

You have the configuration UI available, where you can create a service, use a service, or create a custom API resource. You can also manually edit the webda.config.json if you want.

Below is the manual step with the manual modification. I would recommend using the configuration UI to modify the webda.config.json

2. Create a New Route

We will use the inline RouteHelper here. Except the Lambda Route helper, the others are mainly there for quick and easy tests but you should use a Service when you can as they are easier to unit test and also makes code cleaner.

javascript { "*": "demo.webda.io", "demo.webda.io": { ... "/myurl": { "type": "inline", "callback": "function(ctx) { ctx.write('I am an inline route'); }" } } }

3. Create a New Service

We will now create a new executor so that we can map some urls directly to the service.

```javascript const Executor = require(‘webda/services/executor’)

class MyService extends Executor {

init(config) { // Let’s add our routes here, for Modda the URL should be dynamic config[‘/myservice’]={method:[“GET”, “DELETE”], _method: this.handleRequest, executor: this}; } delete(ctx) { // If we dont output anything, then the default result will be a 204 } get(ctx) { // Should output : I am a getter and i’ve sent an welcome email to you ctx.write(this._params.sentence); let otherService = this.getService(“Mailer”); otherService.send(); } handleRequest(ctx) { if (ctx._route._http.method === “GET”) { this.get(ctx); } else { this.delete(ctx); } } ) ```

Here is the corresponding configuration:

```javascript { … services: { … “MyService”: { require: “./myservice.js”, sentence: “I am a getter and i’ve sent an welcome email to you” } … } … }

#### 4\. Run it

``` webda serve

You can call http://localhost:18080/myservice, and see the nice output:

“I am a getter and i’ve sent an welcome email to you”

And call http://localhost:18080/myurl to get:

“I am a inline route”

Deploy It to the Cloud

First, you need to create a deployment from the configuration UI. Then just use the Deploy button on the UI or the webda bin:

webda deploy Test

That’s it! Your new API is now ready to rock!


Here are some more resources to help you:

Website: webda.io
Channel: Youtube