Getting your front-end and back-end teams up to full speed is certainly something each company is looking for. Often though, what happens is that the teams fall into the pit of blocking dependencies. Those are situations where the upcoming work of one team is blocked by a user story owned by the other team.
One of those examples is the communication process between the front- and back-end. These days REST APIs have ascended the throne of so-called communication standards. The benefit of using JSON, a simple yet effective data transfer format, is that front-end workers do not need to care about the actual back-end anymore. Whatever crosses the wire is directly consumable and may be leveraged to bring data into your application. So it's not surprising that those elementary entities often do not get modeled at all on the front-end and are consumed as they arrive. This brings us to the fundamental problem of having to wait for the back-end team to provide something useful. As depicted in the following figure, we see that both teams start in parallel, but at a certain time one team is kept waiting for the other to catch up.
Besides this, having no kind of fixed structure makes each change a potentially dangerous one. So the focus of this article is to present a way that front-end teams can become independent of the back-end and at the same time provide a useful interface which reduces the risk of structural changes.
A Ticketing System Without a Real Back-end
In order to achieve that independence it's imperative to start thinking upfront about your project. What entities are you going to use? What communication endpoints result therefore?
This can be done by creating a small table highlighting the necessary REST endpoints and describing their purpose. Remember the reason we are doing that upfront is for both parties to agree upon a common structure for communication. That does not mean it has to be perfectly done but it should help you get started with the most important steps. As time passes, just update your interface accordingly with the new routes needed.
The actual process of creating a back-endless environment is to capture all HTTP requests and instead of letting them go out into the wild, reply with a fake response containing the information we'd like to have. This article will demonstrate the approach by describing a simple ticketing system. It uses the endpoints shown in the following table.
Please note that the example utilizes the POST verb for both the update and create route. Another option would be to leverage PUT for the update process. Keep in mind though that PUT should be idempotent, meaning every consecutive call has to produce the same result. Feel free to choose whatever suites your needs.
| Method |
Route |
Request body |
Description |
| GET |
/ticket |
None |
Request all tickets |
| GET |
/ticket/:id |
None |
Request a single ticket via the provided :id parameter |
| POST |
/ticket |
Ticket entity |
Create a new or update an existing ticket |
| DELETE |
/ticket/:id |
None |
Delete a ticket, identified by the :id parameter |
Table 1: Consumed endpoints of the ticketing system
The Ticket entity is a simple TypeScript class containing some basic ticket information:
export class Ticket {
public _id: string;
public title: string;
public assignedTo: string;
public description: string;
public percentageComplete: number;
constructor(id: string, title: string, assignedTo: string,
description: string, percentageComplete: number) {
this._id = id;
this.title = title;
this.assignedTo = assignedTo;
this.description = description;
this.percentageComplete = percentageComplete;
}
}
ticket.entity.ts describing the ticket entity
You may find the complete code as well as a preview for this example on Plunker:
The Angular 2 project setup
Enough theory, lets get our hands dirty with some coding. The project structure shown here is built upon the proposed Angular 2 Getting Started guide. As such, we won't waste too much time explaining every part of it. If you're searching for a introductory article, take a look at Getting Started with Angular 2 using TypeScript. For this article, you can just open up the above mentioned Plunker to follow the code parts explained below.
As most single page applications start with an index.html file, lets take a look at it first. The first section imports the necessary 3rd party dependencies and Angular's application files located in the vendor sub-folder. The Reactive Extensions (Rx) aren't actually a true dependency but will simplify the work with Angular's observables, which are the replacement for the previously used Promises. I highly recommend this article by Cory Rylan to learn more about the topic.
Note that manual script referencing is not the recommended way to create production-ready apps, nor is the framework itself either, being in beta state. You should use a package manager like npm or jspm. The later one works hand in hand with SystemJS, described in section two. SystemJS is a module loader previously based on the ECMAScript 2015 draft and now part of WHATWG's Loader specification. As such, it enables the use of the import x from 'module' syntax. In order to use it properly we need to configure it and then import the application's main entry point, the file app/boot.ts.
Note that we configured the defaultExtension so that we can omit the file extension in our import statements.
Finally we create the app by using a custom tag named my-app. Those are called Components and are somewhat comparable to Angular.JS 1.x directives.
Continue reading %Look Ma, No Server: Developing Apps with Angular 2 MockBackend%
by Vildan Softic via SitePoint
