Tutorial: Build a Points of Interest App with Vue.js, Node.js, Express, and Couchbase Server

Walking through the script section, you’ll see I make heavy use of the reactive capabilities in Vue. To understand this part, it will help if you have at least some familiarity with Vue, especially computed properties and watchers, data, method, and lifecycle hooks.

We make use of the mounted lifecycle callback to add a listener for server sent events, and to initially populate the dropdown list of cities. The heavier lifting of the business logic here happens in the database query, as we’ll see.

Let’s track how selecting a city works. Notice every item in the button dropdown is has a click listener bound that sets selected to the city data for that entry. We have a watch method defined on selected. Vue also automatically knows that the computed property display depends on selected.

That means whenever a city gets selected via the dropdown, we get a cascade of activity. Changing selected causes display to be recomputed. This, in turn, sets the dropdown button text, since that’s bound to display. The selectedmethod in the watch section triggers a refresh of the hotel listing table every time a new city is picked.

The table items are bound to destinationsProvider under methods. Refreshing the table causes that code to execute. Like the original city list, it pulls in the hotels via an asynchronous call to our database through a server REST endpoint.

Vue takes care of a lot here for us. For example, the call to refresh the table doesn’t receive data right away. Vue will rerender the relevant parts of the DOM automatically whenever the REST call returns. We don’t have to supply any of the wiring, other than specifying the binding between items and destinationProvider.

We load the Google Maps API key from a file config.js. Create that file and for now add this placeholder code.

Build the project again (npm run build). Start the server, reload the site, and you should see the beginnings of our real client looking like this.

The two blocks of code for connecting to our database are very straightforward.

The first three lines import the Couchbase Node client, create a new cluster object representing a cluster of database nodes, and authenticate to that cluster. That initiates the connection to the database.

For convenience, we add references to the client and cluster objects to app.locals. This makes them globally available.

Finally, the code establishes and saves connections to two buckets. Buckets are a high-level organizational structure in Couchbase.

The first bucket we will populate with sample data that comes with Couchbase Server installations. For the second bucket, I’m fudging things a little here. We need a meta-data bucket for the Eventing Service. We need just a couple of extra documents stored, as we’ll see, that need to go somewhere besides the main bucket. Rather than create a third bucket, I just put them in with the eventing data. You wouldn’t typically use this shortcut in production.

We have just a few lines of code we need to direct Express to serve our static pages built from the client code and to organize our server data API.

The boilerplate index.html home page for the app adds dist to all the file paths. This means our static files are actually served from a root directory of <project path>/client/dist.

I’ve separated the data API into two groups, organized under a general routes subdirectory. There’s the endpoints beginning with records. These will retrieve data from the database.

The events route is unique. The endpoints are used by both the web client and by the Couchbase Eventing Service.

Let’s look at the records code first.

We have three routes defined here, /destinations, /hotels/byCity/:id, and /select/geo. They all have the same basic structure. We get our database references, use bluebird to create a promise versions of the query method, construct a N1QL query, fire it off and return the results.

Let’s work through the queries, starting with the simplest.

We use The /select/geo endpoint to store the current hotel choice made by the user. Here’s the query broken out.

UPSERT will modify a document, or create it if it doesn’t already exist. We store the geolocation of the chosen hotel in a document with an id of trigger. That probably sounds odd. It will make more sense later, when we get to the Eventing code. What we’re really interested in isn’t just the hotel location, but the points of interest nearby. This document will set off the sequence that retrieves those POI. Hence the reason for calling the document trigger.

Here’s an example of the document created.

To understand the /hotels/byCity/:id query, first take a look at a couple of example documents.

For our hotels table, we need the hotel name, address, geolocation, the airport name, and airport code. Obviously that’s combining data from both documents. We do this using an INNER JOIN. Here’s the query.

Walking through it, you can see we are able to perform the join using documents from the same bucket. I use aliases to make things clearer. We use the city from each document to form the join condition. Notice I also use the document type, both in the join condition, and in the WHERE clause. The join conditions can be quite sophisticated. Read this blog post for more details and examples.

Finally, let’s examine how we came up with our city list in the first place. This is the query for the /destinationsendpoint.

The only result returned is a list of city names. In this case, we’re using an inner join effectively as a filter. By matching airport cities to hotel cities, we get back a list of only cities that have both.

Inner joins can use two different approaches algorithmically. The first join we looked at uses the default nested-loop join.

This last example uses an in-memory hash table. This can significantly speed up a join, particularly where one of the two datasets is small. We used the “USE HASH()” hint to inform N1QL how we wanted the query optimized. There’s a “probe” side and a “build” side. The hash table is built from the build side data. The the join is performed doing lookups from the probe side data.

The hint we gave above tells N1QL to use the hotel data for the probe side in this case. I.e. it will build the table from the airport data, then do the hash lookups using the hotel data.

If you haven’t before, I encourage you to try these queries directly in the Couchbase Server Query Workbench, part of the web administration console.

We already mentioned setting up an event listener for server sent events on the client side. These two endpoints show what’s needed on the server.

The “get” version of the poi endpoint is called by the browser when the EventSource is constructed. You can see we simply add the caller as a client.

We use the “post” version as the go between to send data to the client. The res.send(''); line gives a hint about how this works. In the Eventing code, we’ll use the N1QL cURL capabilities to push data to this endpoint. The empty reply is there to close out that transaction.

The server then forwards the data to any listening clients. There are a lot more details. If you want to find out more, this article has good information.

To finish the server side of our project, create a subdirectory routes under the server directory.

Copy the records code above into a file under routes called records.js. Copy the events code above into a file called events.js. And, finally, in the server directory itself, create a new file named .env. Paste the following configuration parameters there and save. (Of course, change any settings as you need.)

The server should be ready to go now. In the server root directory, run node app.js. Don’t forget to build the client code first.