Page 18 - MSDN Magazine, October 2017

The Working Programmer TED NEWARD How To Be MEAN: Angular Plays Fetch
Welcome back again, MEANers.
In my last column, I wrote, “One of the common needs of an
Angular application is to obtain or update data from locations not inside the browser—which is usually everywhere.” I then proceeded to go on for another couple thousand words without ever actually doing anything across HTTP.
To be fair, the intention of that column was to prepare the code for being able to fetch data from an HTTP API by placing the HTTP request code inside of an Angular service. Given that I hadn’t looked at an Angular service prior to that point, I first needed to work through the basics of what an Angular service looks like and how to use it from the various components that might need it. Alas, all that work left me with no room to get to the actual goal: the data residing in the HTTP API endpoints.
It’s time to fix that. Let’s go fetch some data.
Speaker API
First things first, I need an HTTP API that I can hit with requests. Somewhere back in that pile of old MSDN Magazine issues, there’s the last version of the server-side API that I built a year ago. If you actually dig it up, you’ll find it’s an API that provides “Persons,” not speakers. Amazing how a project’s goals can “drift” over time, isn’t it?
In Node.js, however, the preferred approach is to hand back not an actual object, but the promise that one will show up— eventually. These are called, not surprisingly, Promises.
Given how simple that MEAN server was, and the fact that the only differences between then and now would be the objects returned, I could easily change the code to push Speaker objects (defined in the last column) back and forth. But doing that means missing out on a golden opportunity to point out something else: the Node.js community has a plethora of “MEAN stack frameworks,”
including Sails.js (sailsjs.com) and one I’ve been working with called Loopback (strongloop.com), among others. Many of these frameworks are “built up” off the same tools I used a year ago (Express, MongoDB and the like) to construct a server-side HTTP API, while gluing things together a bit more tightly and painting a lovely veneer over the top. Or you could put together an ASP.NET MVC Web API endpoint. The server-side implementation doesn’t matter, as long as it hides behind HTTP.
The first order of business is to see what the interface for the API looks like—what URLs to use, what verbs to use with those URLs, the expected parameters and the format of the returned JSON response. Given that this is a pretty simple service, it’s easy to imagine what they will look like, so there’s no need to list them out formally here. (Just enter GET on /speakers for the full list of speakers, GET on /speakers/:id to retrieve a particular speaker and so on.)
SpeakerService
If you recall from my last column, the module responsible for fetching data was called SpeakerService. Given that the entire point of the service is to encapsulate away the details of fetching and storing Speakers, you can assume that most (if not all) of the work I’m about to show here will be contained there.
When I left things last time, SpeakerService drew results from an in-memory constant:
@Injectable()
export class SpeakerService {
constructor() { }
getSpeakers() : Array<Speaker> {
return SPEAKERS; }
getSpeaker(id: number) : Speaker {
return SPEAKERS.find(speaker => speaker.id === id);
} }
The service will eventually need to provide update and deletion facilities, but for now let’s just work with the read operations. Notice how in each case, the “get” method returns an immediate object— either the Speaker itself, or an array of Speakers. For an in-memory operation, this is pretty reasonable, but for an operation that will take place through the TCP/IP stack, it’s not. Network operations take time, and forcing the caller to wait until the network opera- tion finishes—assuming it ever does—puts an undue burden on the developer building the front-end, because now the front-end has to somehow keep the UI responsive while blocked waiting for the response. Historically, in other UI platforms, the solution has been to have the UI incorporate multiple threads, forcing the UI
14 msdn magazine