vibe.d contains several packages that provide a variety of functionality for different layers of web development. From low-level socket handling to the high-level web framework, the packages can be used as needed to meet the needs of a server application. Following is a brief introduction to some of the packages:

As a demonstration of a vibe.d based server that expands on what vibe.d provides, take a look at vibenews at https://github.com/rejectedsoftware/vibenews. The project includes a web forum, but also implements an NNTP server using the vibe.core and vibe.stream packages.

Getting started with vibe.d is extremely easy with DUB. In fact, DUB began life as a tool for generating and building vibe.d projects and distributing vibe.d extensions. Only later did it morph into a more generic build tool and package manager. Its roots as a vibe.d specific tool live on in the init command that we first saw way back in Chapter 1, How to Get a D in Programming. It takes an optional argument, -t, to specify the type of project to create. There are three options:

To get a look at a simple vibe.d app, open up a command prompt to any directory and execute the following command:

dub init MyWebApp -t vibe.d

This creates a MyWebApp directory with the layout shown in the following screenshot:

The first file in the list, .gitignore, is a convenience for those working with the git source control program. Quite a number of D projects live on GitHub and private git servers. .gitignore is a text file that contains a list of file patterns git should not consider when evaluating local changes. dub.sdl is the DUB project configuration we're already familiar with. For this vibe.d based project, it looks like this:

name "mywebapp"
description "A simple vibe.d server application."
copyright "Copyright © 2015, Mike Parker"
authors "Mike Parker"
dependency "vibe-d" version="~>0.7.23"
versions "VibeDefaultMain"

The only thing here that should warrant explanation at this point is the VibeDefaultMain version. When this version is specified, vibe.d apps need not implement a main function; the implementation in the vibe.appmain module will be used instead. This is a simple implementation that does some logging, runs the event loop, and catches all exceptions. It can be overridden by specifying VibeCustomMain as a version in the configuration file.

The public folder is where publicly accessible files, such as static HTML pages and style sheets, should be saved. The source folder is for the source code and, just as with a normal DUB app, the tool looks for source/app.d by default. Finally, the views folder is for Diet templates, an HTML template engine based on Jade (much of the documentation at http://jade-lang.com/ serves for Diet templates as well). We'll dig a bit into the details when we implement MovieManWeb.

Peek into the source directory and you'll find that DUB has generated a default app.d. It does everything necessary to set up a minimal HTTP server that accepts connections and perpetually serves a plain text document that says, "Hello, World!". The unmodified output of that file follows:

import vibe.d;

shared static this()
{
  auto settings = new HTTPServerSettings;
  settings.port = 8080;
  settings.bindAddresses = ["::1", "127.0.0.1"];
  listenHTTP(settings, &hello);

  logInfo("Please open http://127.0.0.1:8080/ in your browser.");
}

void hello(HTTPServerRequest req, HTTPServerResponse res)
{
  res.writeBody("Hello, World!");
}

First off, notice the import of vibe.d at the top of the file. Although any D programmer should know that this indicates a file with the path vibe/d.d, it is all too easy for the human brain to subconsciously interpret it as a file named vibe.d (full disclosure: it happens to me every time I see it). Since the module does nothing more than publicly import vibe.vibe, then anyone bothered by vibe.d can directly import vibe.vibe instead.

The next thing to point out is that there is no main function in sight. We already know that vibe.d has its own implementation of main. When using the default main, all of the initialization the app requires should happen in a module constructor. As you can see, getting a minimal HTTP server up and running with vibe.d requires very little initialization. This generated implementation uses the low-level API from vibe.http. First, the connection settings for the server are set up in an HTTPServerSettings instance, then listenHTTP is called to start listening for active connections. The function is given a pointer to the hello function, which accepts HTTPServerRequest and HTTPServerResponse objects. Since this particular function isn't interested in any input from the request, it only concerns itself with the response by printing a plain text message, which is sent back to the browser.

There are more complex examples of how to use the low-level API in the project's source repository at https://github.com/rejectedsoftware/vibe.d, as well as in the documentation at the project home page.