Boulevard

Boulevard is a framework designed so you can build applications using JavaScript for the client, server, and everything in between. Like many cats, it is warm, friendly, and greatly enjoys catnip.

This document is a work in progress, much like the library itself, and nothing within the document should be considered final.

If you want to dive right into learning how to use Boulevard, jump to Getting Started. To learn a bit more about Boulevard, including every possible question you could ever ask about the framework, read on.

Why

A number of MVC frameworks (or variations on that acronym) exist today, but very few of them encompass the entire model. Libraries such as React and Angular largely handle the View, with little regard for the back end, while frameworks like Ruby on Rails don't have the opportunity to utilize the strengths of writing the entire application in JS.

I wanted to write a framework where we can:

• Use JavaScript throughout the entire application (or languages built upon JS, such as TypeScript)
• Share common code between the client and server to represent objects (the "model") while being able to clearly control what is left to the server or client (the "controller" and "view" code, respectively)
• Do as such in a thorough developer environment with support for a variety of view libraries and databases

So, I did.

What

The App

The App is used to refer to the base of the application. (Note this is different from the concept of the "server," as we'll see in a second.) It is best thought of as a series of Contexts.

Context

A Context is used to refer to an area where Models are stored, which we'll cover in a second. The significance of a Context who can access the Context. By default, an app has two contexts:

• The Server Context is only within the scope of the Server, and can store Items and Models to a local database, along with fetch Items and Models from the database.
• The Session Context is within the scope of both the Server and a single Client - each Client shares a different Session Context with the same Server, and both the Client and Server can add or remove items to the Session Context at will. This means that, when either the Server or Client updates an Item in the Context, the update is communicated to the other end (either the Server or Client) so that they both share the same information.

However, one can create their own contexts for a variety of uses. The only restraint is that each context must contain your Server.

• You could create a Chat Room Context, consisting of several Clients and a single Server. You can give Clients the power to add Items of a certain Model ("ChatMessage") to the Context, but not remove these items.
  • You could then create a Chat Room Admin Context within this Context which does have the ability to remove Items of the ChatMessage Model.
• You could create a User Context, consisting of a single Client and a single Server, but only accessible by Clients which can pass certain authentication methods.

The possibilities are endless.

Models and Items

A Model represents, essentially, a type of object. An instance of a Model, or an object, can be thought of as an Item.

Your app consists of a variety of Models, which are then added into different Contexts, giving these Contexts the ability to store the Models in question. Each Context can also fine-grain how each Model is used within its Context, and each Model can be added to multiple Contexts. An Item is created within a Context, but can be moved or duplicated to other Contexts.

Each Item is differentiated from other Items of the same Model using properties. Each Model defines the property types of each Item of that Model, but the Items themselves define the properties. For example, you could have a ChatMessage model with the property types:

class ChatMessage extends Model {
  static propertyTypes = {
    message: PropertyTypes.string,
    time: PropertyTypes.time,
    user: PropertyTypes.itemOf(User)
  }
}

Meaning that each ChatMessage has a message property (which must be a string), a time property (which must be a time), and a user property (which must be an Item which is a User, presumably another Model defined somewhere else.)

We could then create a ChatMessage which looks like this:

const message = new ChatMessage({
  message: 'Hey gamers!',
  time: new Date(),
  user: currentUser
})

And then add it to a Chat Room context like this:

chatRoom.addItem(message)

The chat room Context would then replicate the message on the Server, and the Server would replicate the message on the other Clients within the same chat room Context.

How

Boulevard is written in TypeScript, which is itself a superset of JavaScript. Boulevard applications themselves can be written in either. For further information on how to get started using Boulevard, check out the Getting Started page to the left there.

Who

Boulevard is a project of the blvd group, and more information can be found on our page at blvd.space.