hybrid web application development using …hybrid web application development using meteor.js 2...

UNIVERSITY OF MARIBOR FACULTY OF ELECTRICAL ENGINEERING

AND COMPUTER SCIENCE

Nejc Burič Novačan

HYBRID WEB APPLICATION DEVELOPMENT USING METEOR.JS FRAMEWORK

RAZVOJ HIBRIDNIH SPLETNIH APLIKACIJ Z

OGRODJEM METEOR.JS

Thesis work

Maribor, August 2016

HYBRID WEB APPLICATION DEVELOPMENT USING

METEOR.JS FRAMEWORK

RAZVOJ HIBRIDNIH SPLETNIH APLIKACIJ Z OGRODJEM

METEOR.JS

Thesis work

Student: Nejc Burič Novačan

Student Programme: University Student Programme

Computer Science

Mentor: D.Sc. Milan Ojsteršek, B.S.E.E..

Comentor: Teaching assistent. Goran Hrovat, B.S.C.S.

Proofreader: Mrs. Shelagh Margaret Hedges

ii

Zahvala

Zahvaljujem se doc. dr. Milanu Ojsteršku

za pomoč pri opravljanju diplomske naloge.

Prav tako se za pomoč in možnost izvedbe

zahvaljujem podjetju SODO in svojim staršem.

iii

Acknowledgment

Special thanks to Dr. Milan Ojsteršek

for his help in making this Bachelor Thesis.

I am also grateful to the company SODO and my parents for their help and the opportunity

to undertake this project.

iv

Razvoj hibridnih spletnih aplikacij z ogrodjem Meteor.js

Ključne besede: spletno programiranje, hibridne aplikacije, Meteor.js, MongoDB

UDK: 004.774.6(043.2)

Povzetek

Diplomska naloga prikazuje enega izmed možnih načinov razvoja hibridnih spletnih aplikacij.

V teoretičnem delu smo opisali ogrodje Meteor.js in podatkovno bazo MongoDB, ki smo ju

uporabili za realizacijo spletne aplikacije. V predstavitvi ogrodja so predstavljene novosti in

moderne metode, ki se uporabljajo v sodobnem spletnem programiranju. Hibridna spletna

aplikacija, ki smo jo razvili v praktičnem delu, omogoča navigiranje po turističnih zanimivostih

celotne Slovenije. Omogoča najdbo naravnih znamenitosti, kmečkega turizma, klubov,

električnih polnilnic za avtomobile, zanimivosti in informacijskih turističnih centrov.

Administratorju omogoča urejevanje vseh turističnih točk s pomočjo Google API-ja,

uporabnikom pa v realno-časovnem ciklu prikazuje trenutne razdalje do vsake lokacije in

spremembe, ki se zgodijo ob administraciji vsake turistične točke.

v

Hybrid Web Application Development Using

Meteor.js Framework

Key words: web programming, hybrid applications, Meteor.js, MongoDB

UDK: 004.774.6(043.2)

Abstract

This Thesis work shows one of many possible ways of developing hybrid web applications. In

the theoretical part, we described the Meteor.js framework and MongoDB database, which we

used for realization of the web application. In the presentation of the framework, new and

modern methods are described which are used in modern web programming. The hybrid web

application which we developed in the practical part enables the user to navigate to tourist

attractions in Slovenia. It enables the user to discover and locate natural landmarks, rural

tourism, clubs, electric car charging stations, places of interest,, and Tourist Information

Centres. Admin can regulate the points of interest with the help of Google API. The application

also displays current distances to every point of interest and notifies the users about the changes

made by the administrator.

vi

TABLE OF CONTENTS

1 INTRODUCTION.................................................................................................. 1

1.1 Purpose and goal of the thesis work ....................................................................................... 1

1.2 Structure of the thesis work ..................................................................................................... 1

2 MONGO DB ......................................................................................................... 2

2.1 Document database versus relational database .................................................................... 2

3 METEOR.JS FRAMEWORK ............................................................................... 4

3.1 Meteor rendering libraries ........................................................................................................ 5

3.1.1 Blaze ...................................................................................................................................................... 5

3.1.1.1 Spacebars ...................................................................................................................................... 5

3.1.1.2 Templates ..................................................................................................................................... 7

3.1.1.3 Helpers .......................................................................................................................................... 7

3.1.1.4 Events ............................................................................................................................................ 8

3.1.1.5 Tracker .......................................................................................................................................... 8

3.1.2 React ...................................................................................................................................................... 8

3.1.3 Angular .................................................................................................................................................. 8

3.2 Collections ................................................................................................................................. 9

3.2.1 Server-side, client-side and local collections ......................................................................................... 9

3.2.2 Publish and subscribe .......................................................................................................................... 10

3.2.3 Methods .............................................................................................................................................. 10

3.3 Command line and packages ................................................................................................. 10

3.3.1 Command line ...................................................................................................................................... 11

3.3.2 Packages .............................................................................................................................................. 11

3.4 Application structure .............................................................................................................. 12

3.5 Deployment .............................................................................................................................. 13

4 DEVELOPMENT ................................................................................................ 13

4.1 Web application ....................................................................................................................... 13

vii

4.2 Mobile application ................................................................................................................... 19

4.3 Real-time concepts in the project .......................................................................................... 19

4.3.1 Real-time concepts from the Administrator ........................................................................................ 20

4.3.2 Real-time changes from the clients ..................................................................................................... 20

4.3.3 How these real-time changes work ..................................................................................................... 21

4.4 Test server and database ....................................................................................................... 23

5 CONCLUSION ................................................................................................... 24

6 LITERATURE AND RESOURCES .................................................................... 26

viii

TABLE OF CONTENTS OF FIGURES

FIGURE 1: ROWS AND TABLES VERSUS DOCUMENTS AND COLLECTIONS .................................................................................. 3

FIGURE 2: PROPERTIES AND COLUMNS ............................................................................................................................. 3

FIGURE 3: SCHEMA STRUCTURE ...................................................................................................................................... 4

FIGURE 4: SCHEMA-FREE STRUCTURE ............................................................................................................................... 4

FIGURE 5: MAIN PAGE ................................................................................................................................................ 14

FIGURE 6: MAP SECTION, SHOWING LOCATIONS ............................................................................................................... 15

FIGURE 7: NATURAL LANDMARKS .................................................................................................................................. 16

FIGURE 8: FAVOURITES SECTION ................................................................................................................................... 16

FIGURE 9: LOGIN AND REGISTRATION PAGE ..................................................................................................................... 17

FIGURE 10: ADMIN PAGE ............................................................................................................................................ 18

FIGURE 11: COLLECTION OVERVIEW .............................................................................................................................. 18

FIGURE 12: TRADITIONAL WEB APPS .............................................................................................................................. 21

FIGURE 13: SINGLE PAGE WEB APPS ............................................................................................................................... 22

FIGURE 14: METEOR REAL-TIME WEB APPS ..................................................................................................................... 22

FIGURE 15: HEROKU DASHBOARD ................................................................................................................................. 23

FIGURE 16: MLAB COLLECTIONS .................................................................................................................................... 24

TABLE OF CONTENTS OF TABLES

TABLE 1: ANNOTATIONS FOR VARIOUS DATABASES ............................................................................................................. 2

USED ACRONYMS

HTTP – is an application protocol for data communication (Hypertext Transfer Protocol)

DDP – is a protocol for synchronizing updates between clients and server (Distributed Data

Protocol)

NFC – is a protocol that enabled two electronic devices to communicate (Near Field

Communication)

UI – is a space of human and machine interaction (User interface)

SQL – is a programming language for managing data (Structured Query Language)

JSON – is a format to transmit data objects (JavaScript Object Notation)

HTML – is a markup language to create web pages (HyperText Markup Language)

ix

CSS – is a style sheet language for describing the presentation of the markup language

(Cascading Style Sheets)

NPM – is a package manager for Node.js (Node Package Manager)

URL – is a reference to a web source that specifies its location (Uniform Resource Locator)

ORM – is a technique for converting data between incompatible type systems (Object

Relational Mapping)

DOM – is an application programming interface that treats documents as a tree structure

(Document Object Model)

SSL – is a protocol that provides communication security (Secure Sockets Layer)

Hybrid web application development using Meteor.js

1

1 INTRODUCTION

Nowadays, there are various applications on the market that are not used on all devices. The

development of a hybrid or cross-platform application is the perfect solution for this problem.

While developing an application, a programmer has to know what he or she is dealing with – I

am referring to the devices which run the application. The first problem is the screen size. If

we want to make a user-friendly application it has to be simple to use. We determined that

searching for something should not be strenuous while using this application. This is why the

most important data has to be visible and simple to navigate to. To achieve that, we have to

work on our user interface design. The second major problem when it comes to hybrid

applications is the operating systems. The web application works on every device that has a

connection to the Internet and a browser installed. When it comes to smartphones, we will try

to make the application work on various operating systems.

1.1 Purpose and goal of the thesis work

The purpose of the thesis work is to show the instructions on how to work with the Meteor.js

framework; show its advantages, disadvantages, and introduce new ways of interacting with

users on a real-time basis. The purpose of the product is to serve tourists who are going to

visit Slovenia. It is going to show them easier ways to get in touch with interesting and tourist

attractive destinations. The product is going to serve the company and its clients with its user

friendly interface.

The goal is to create an application which is going to help tourists who are visiting or traveling

through Slovenia and to let them know how to get to every important destination. To make the

application usable in production we will also build an application for smartphones and tablets

which are using the Android operating system. Our goal is also to show the advantage of the

real-time based applications using the Meteor.js framework, to minimise the time of the

development, and to run the same source code on as many popular devices as possible.

1.2 Structure of the thesis work

The thesis consists of six Chapters. In the second Chapter we will talk about the Mongo

database and its features. We will point out the differences between relational and document-


2

based databases. In the third Chapter, we will talk about the Meteor.js framework. Next, we

will discuss rendering libraries and take a closer look at the recommended Blaze rendering

library. We will proceed by introducing the collections with publications and subscriptions

operations and continue with Meteor methods. We will also talk about the command line and

packages, and the structure of a Meteor application. In the fourth Chapter, we will talk about

the development of the web application and the mobile application. The Chapter is going to

end with an explanation of the test server and the database. In the fifth Chapter, we will

summarise the thesis and conclude our work.

2 MONGO DB

Even though the Meteor framework is the main theme of this thesis, we are going to start with

MongoDB, which works with Meteor Framework and, therefore, plays an important part.

According to the MongoDB manual, MongoDB is an open source database which provides

high scalability, performance, and availability. MongoDB obviates the need for Object

Relational Mapping (ORM) to facilitate development [13].

2.1 Document database versus relational database

According to the Lenni Lobel blog post, a document database, or NoSQL database (Mongo

database), stores entities as documents in collections which are JSON documents. On the

other hand, a relational database or SQL database stores entities as rows in Tables. In Table

1 we can see the main differences between a Relational database and MongoDB.

Relational database MongoDB

Database Database

Table Collection

Row Document

Column Field

Primary key Primary key

Table 1: Annotations for various databases

More about the differences between Tables and Collections can be seen in Figure 1 as well.


3

Figure 1: Rows and Tables versus Documents and Collections

Furthermore, relational databases have columns, while document databases have properties

(Figure 2).

Figure 2: Properties and columns

In the relational world, every Table has a schema that defines the columns and data types that

every row in the Table must conform to. In contrast, a document database has no defined

schema, and every document can be structured differently. As seen from the example in Figure

3, there are four columns defined for a Table, and it would be necessary to alter the Table

schema if we wanted a fifth column, or if we wanted to change the maximum length of the

name column, or if we wanted to allow nulls in date-of-birth. But, because document databases

are schema-free, they aren’t subject to these constraints. This makes them ideal when you

have a rapidly evolving schema, as is usually the case in software development today.


4

Figure 3: Schema structure

As said before, redefining Documents or Collections is unnecessary when it comes to the

schema-free structure. We only have to insert another document with a different structure or

update the one already inserted with custom values. This is ideal if fast prototyping or database

evolving has to be done. An example of a schema-free structure is shown in Figure 4 (different

documents) [3].

Figure 4: Schema-free structure

3 METEOR.JS FRAMEWORK

According to Meteor documentation, Meteor is a full-stack JavaScript platform for developing

modern web and mobile applications. Meteor includes a key set of technologies for building

connected-client reactive applications, a build tool, and a curated set of packages from the

Node.js and general JavaScript community. Meteor gives one the ability to write back-end and

front-end code with Javascript. Building applications for mobile phones is currently available in


5

Android and iOS. Meteor can be programmed in various editors. Sublime Text, Atom, and

WebStorm are the most popular. A developer can also use Vim or Notepad++ editors to create

Meteor applications. Meteor is running on all major operating systems (Windows, Mac and

Linux) [4].

3.1 Meteor rendering libraries

Meteor has three rendering libraries: Blaze, Angular, and React. Blaze is a built-in library with

templates written in Spacebars. Rendering libraries give developers the capability of fast

prototyping and the advantage at using the Meteor reactivity system. This project is written

using Blaze and Spacebars – we will take a look at these two in the next Chapter [2].

3.1.1 Blaze

Blaze is a rendering library developed by Meteor. It uses Spacebars syntax, which looks similar

to Handlebars. Even though Angular and React are more popular when building larger and

more complex applications, Blaze is the one that is still used mostly for development of Meteor

applications. According to Blaze documentation, Blaze is a powerful library for creating user

interfaces by writing reactive HTML templates. Compared to using a combination of traditional

templates and jQuery, Blaze eliminates the need for all the “update logic” in our app that listens

for data changes and manipulates the DOM. Instead, familiar template directives like {{#if}}

and {{#each}} integrates with Tracker’s “transparent reactivity” and Minimongo’s database

cursors so that the DOM updates automatically [1].

3.1.1.1 Spacebars

According to the Meteor guide, Spacebars is a templating language built for the concept of

rendering a reactively changing data context [10]. Spacebars syntax has curly braces that

define functions, template inclusions, helpers etc. It is used when we want something dynamic

to occur. It bridges the gap between the interface and the application logic. It allows us to

include a template, add logic to the template, add arguments, arrays etc. These fields are then

controlled by Javascript functions.

Looking at a Spacebars based HTML file, we can tell that our style and logic are not included.

Meteor makes this easier by including them itself. Therefore, we do not need to include .css


6

and .js files in our HTML. The second major difference is a template tag. It is a Blaze tag which

enables us to include a section multiple times and use the same section in a different HTML

file without rewriting it. The template tag has an attribute name. We include it in the desired

section according to its name. The browser will not show the template tag and its content

unless we include it in a body tag. Every interface element in the template tag can be

referenced and used to build an interface.

Here we have two Spacebars templates from the example application called “Leaderboard”,

which Meteor provides for learning. These two templates display a sorted list of players.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

<template name="leaderboard">

<ol class="leaderboard">

{{#each players}}

{{> player}}

{{/each}}

</ol>

</template>

<template name="player">

<li class="player {{selected}}">

<span class="name">{{name}}</span>

<span class="score">{{score}}</span>

</li>

</template>

We have {{name}} and {{score}}, which refer to properties of the data context, and we also

have players and selected which are helper functions. Helper functions and event handlers are

defined in Javascript as we can see below.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

Template.leaderboard.helpers({

players: function () {

// Perform a reactive database query against minimongo

return Players.find({}, { sort: { score: -1, name: 1 } });

}

});

Template.player.events({

'click': function () {

// click on a player to select it

Session.set("selectedPlayer", this._id);

}

});

Template.player.helpers({

selected: function () {

return Session.equals("selectedPlayer", this._id) ? "selected" : '';

}

});


7

According to Blaze documentation, no additional UI code is necessary to ensure that the list

of players stays up-to-date, or that the “selected” class is added and removed from the LI

elements as appropriate when the user clicks on a player.

Thanks to a powerful template language it doesn’t take much ceremony to write a loop, include

another template, or bind an attribute (or part of an attribute) and, thanks to Tracker’s

transparent reactivity, there’s no ceremony around depending on reactive data sources like

the database or Session; it just happens when you read the value, and when the value

changes, the DOM will be updated in a fine-grained way.

3.1.1.2 Templates

Templates are elements of Spacebars language and contain HTML code. They are not

included or shown in the page unless we include them explicitly. Templates can possess every

kind of HTML tag and can be styled with CSS. However, they have functions such as helpers,

events, onCreated, onRendered etc. We can include templates into our page dynamically or

statically. Static inclusion is done with two curly braces and the right arrow key:

({{>template_name}}). They can be added with arguments or without them. Dynamic inclusion

is when the template is passed with different data. For example, we can have different

templates in different sections of our page. Syntax of dynamic inclusion is similar to static

inclusion but has to pass data as well: ({{> template.dynamic template=template [data=data]

}}). Helpers are one of the Templates' functions. More about Helpers can be read in the next

Chapter.

3.1.1.3 Helpers

Helpers are functions which are executed in Javascript engine but have to be included in HTML

(Spacebars). They are attributed to templates and can run the function with arguments or

without them. Defining a helper without arguments in Spacebars is done with curly braces. If

we want to pass an argument, we have to put the argument next to the helper name. Helper

functions can serve as conditions. if-else, unless are all used to form conditional sentences.

If-else works in the traditional way. If the condition is true, everything in the if statement will

be executed, if not, everything in the else statement will be executed. Unless condition works

the opposite way of if condition. Helpers can also fetch data from a database and pass it to

iterators of query cursors or arrays. Helper each gets the cursor and can then display every

document attribute in our page.


8

3.1.1.4 Events

Like Helpers, Events are functions in the template. They are not included in the HTML as

Spacebars syntax but “live” in Javascript. In the event function “block of code” we can define

events like clicks, double clicks, submits etc. These events can be defined for every HTML tag,

and they have two arguments in every function. The first one is an event which has some

information on the event that was triggered, and the second one is a template which is an

instance of the template in which the event was triggered.

3.1.1.5 Tracker

According to Tracker documentation, Tracker is a simple dependency tracking system which

allows it to rerun templates automatically and other computations whenever Session variables,

database queries, and other data sources change.

Unlike most other systems, you don’t have to declare these dependencies manually. The

mechanism is simple and efficient. When you call a function that supports reactive updates

(such as a database query), it saves the current Computation object automatically, if any

representing, (for example, the current template being rendered). Later, when the data

changes, the function can “invalidate” the Computation, causing it to rerun (rerendering the

template) [12].

3.1.2 React

React is one of the rendering libraries available in Meteor. Developed by Facebook, it is used

widely in production. React uses JSX and is a great choice when it comes to building large

apps. It also has a bigger community than Blaze.

3.1.3 Angular

Angular is one of Meteor’s rendering libraries. It is developed by Google and uses attribute

syntax. It is more popular than Blaze and has a large number of users.

https://docs.meteor.com/api/tracker.html#session


9

3.2 Collections

Collections are entities for storing data in the Mongo database. In Meteor, we can write a

server-side and a client-side code, therefore we can create collections on both of these sides.

Defining a collection can be done this way: Chargers = new

Mongo.Collection(“chargers”); This collection is accessible through a global variable

called Chargers. We can make it accessible throughout all of the project. “Chargers” is

referenced on the server-side and will be used for reading and writing in the Mongo database.

On the server-side we can manipulate with collections, which basically means changing the

data in the database. On the client we do not have these advantages because of the security.

Security reasons for disabling the option to change data in a database from clients are

important. If they did not exist every client would be able to change the database and, with

that, destroy and delete important data from our application. Also, showing the data to the

client has to be defined. We exchange the information with the publish/subscribe system.

3.2.1 Server-side, client-side and local collections

Collections in Meteor can be defined and used in various ways. Creating a server-side

collection means that we are creating a collection within MongoDB, and an interface to that

collection to be used on the server. We define server-side collection like this: Todos = new

Mongo.Collection('Todos'); in the subdirectory server/ or in condition Meteor.isServer,

to make sure it is defined on the server-side.

Client-side collections are defined in exactly the same way as server-side collections, except

that client-side collections have to be defined in the subdirectory client/ or condition

Meteor.isClient. Even though these two types of collections look the same they do something

totally different. According to Meteor guide, on the client, there is no direct connection to the

MongoDB database and, in fact, a synchronous API to it is not possible. Instead, on the client-

side, a collection is a client-side cache of the database. This is achieved thanks to the

Minimongo library—an in-memory, all JS, implementation of the MongoDB API. The way that

you move data from the server (and MongoDB-backed) collection into the client (in-memory)

collection is the subject of the data loading. Generally speaking, you subscribe to a

publication, which pushes data from the server to the client. Usually, you can assume that

the client contains an up-to-date copy of some subset of the full MongoDB collection [9]. If we

https://www.meteor.com/mini-databases


10

want to write data back to the server, we use a Method, which are we going to explain in the

next Chapters.

And the last use of collections in Meteor are local collections. We define local collections the

same way, except we pass null istead of a collection name. A local collection does not have

any connection with MongoDB. It can be used instead of a simple array if we need to execute

complex queries over our data. It can also be used to take advantage of its reactivity on the

client to run some UI so it feels natural for the Meteor environment.

3.2.2 Publish and subscribe

According to the Meteor guide, the client and server communicate in a request-response

fashion (in a traditional, HTTP-based web application). A client has to make a request, and

then it gets the HTML or JSON data in return. It is impossible for a server to push the data

when it has changed. Meteor is built from the ground up on DDP, which gives it the possibility

to transfer data in both directions. All the data that the client should see and manipulate with

has to be defined. With “publish” we specify what data is sent to the client, and with “subscribe”

we specify data the client can subscribe to and operate with [10].

3.2.3 Methods

Meteor guide says that Methods are Meteor’s remote procedure call system, used to save user

input events and data that come from the client. We can think of them like POST requests to

our server, but with many nice features optimized for building a modern web application. At its

core, a Method is an API endpoint for our server; we can define a Method on the server and

its counterpart on the client, then call it with some data, write to the database, and get the

return value in a callback. Meteor Methods are also integrated tightly with the

publications/subscription and data loading systems of Meteor to allow for Optimistic UI - the

ability to simulate server-side actions on the client to make your app feel faster than it actually

is [7].

3.3 Command line and packages

The command line is used for executing basic Meteor commands. Mostly, they are important

for updating, deploying, and running our application. Packages; on the other hand, are

http://info.meteor.com/blog/optimistic-ui-with-meteor-latency-compensation


11

additions to Meteor development. They have features which make development easier and

faster. The most popular packages are NPM packages or packages from Atmosphere (a third

party site).

3.3.1 Command line

We used the command line to create a project, run it, and stop it from running. We have

enumerated the commands that are important for the development of a project:

Meteor help (get help from the Meteor command line),

Meteor run or Meteor (run the Meteor project you have selected),

Meteor debug (run the project but suspend the server process for debugging),

Meteor create “name” (create a new Meteor project),

◦ When Meteor creates a project, it is not structured for complex work. We have to

define and create special directories ourselves.

Meteor login / logout (log in and out of your account using Meteor’s authentication

system),

Meteor deploy “address” (deploy your site to a test server),

◦ When this project was written, Meteor did not support deployment to their test

servers, which was free. Momentarily, Meteor recommends deployment to Galaxy

servers which are payable and provide great support for applications.

Meteor update (update project to latest version).

3.3.2 Packages

According to the Meteor guide, building the application from scratch is a long process. Dealing

with the accounting system, URL routing, animation making with transitions, modern UI

building etc. can take much of a developer’s time. That is why packages are developed and

used widely in Meteor development. There are two sources of packages: Atmosphere, and

NPM packages. Packages facilitate the subsequent development of every Meteor product.

Atmosphere packages are written by various developers, whereas NPM packages were


12

intended solely for Node.js server-side environment. NPM packages are fully supported on the

1.3 version of Meteor [5].

The packages used in our project are from Atmosphere only. We can search for packages on

their website or use a Meteor search command from the command line. Packages can be

included in the project by writing the package name in the project’s packages.json file.

Manipulating with them is also available from the command line. Here are some basic

commands:

Meteor add “package name” (add a package),

Meteor remove “package name” (remove a package),

Meteor list (list all packages in your project),

Meteor test-packages (test packages in your project either by name or by directory).

3.4 Application structure

According to the Meteor guide, if we want to use the module system and ensure that our code

only runs when we ask it to, it is recommended that all of our application code should be placed

inside the imports/ directory. This means that the Meteor build system will only bundle and

include that file if it is referenced from another file using an import (also called “lazy evaluation

or loading”).

Meteor will load all files outside of any directory named imports/ in the application using the

default file load order rules (also called “eager evaluation or loading”). It is recommended that

we create exactly two eagerly loaded files, client/main.js and server/main.js, in order to define

explicit entry points for both the client and the server. Meteor ensures that any file in any

directory named server/ will only be available on the server, and likewise for files in any

directory named client/. This also precludes trying to import a file to be used on the server from

any directory named client/ even if it is nested in an imports/ directory and vice versa for

importing client files from server/.

These main.js files won’t do anything themselves, but they should import some startup

modules which will run immediately, on client and server respectively, when the app loads.

These modules should do any configuration necessary for the packages you are using in your

app, and import the rest of your app’s code.

https://guide.meteor.com/structure.html#load-order


13

3.5 Deployment

Deploying a Meteor application is similar to deploying some other websocket-based Node.js

applications, but is different in some other specifics. We have the ability to configure our

application outside of the code. We can do that with environmental variables and settings.

Environmental variables are used to specify things that can change for different instances of

our application. For instance, we can set a different KADIRA_OPTIONS_HOSTNAME for

each process to ensure that kadira logs timings with useful hostnames. On the other hand,

setting should be used to set the environment of specific things, like MONGO_URL and

ROOT_URL. It is also recommended to store keys like Android API, Google Maps API, iOS,

Filepicker, etc.

Deployment can be done using custom servers. The server needs to have Node.js and

MongoDB installed. We can also deploy on Heroku servers using custom builds and connect

our MongoDB to other MongoDB hosting providers like mLab, but the most recommended way

to host our application is on Galaxy servers, which provide easy deployment, SSL security,

monitoring the number of connections, monitoring resource usage, viewing logs and changing

settings. However, Galaxy servers do not provide MongoDB and a MongoDB hosting provider

has to be found.

4 DEVELOPMENT

4.1 Web application

An overview of this application and its basic functions is described in the Chapters above. In

this Chapter, I will demonstrate how it works. The main page can be seen as we visit the

website (Figure 5).


14

Figure 5: Main page

In the main page, all of the topics referring to tourism are displayed: Natural attractions, Tourist

Farms, clubs, interesting (did you know?), electric car charging stations, information etc. The

user is able to select any of these topics by clicking on the picture associated with the topic.

There is a yellow button with a location icon referring to each topic. If the user clicks on it, all

the points of interest relating to the chosen topic will be shown on the map. Lastly, the user

can read more about the topic by clicking on the blue icon with three white dots. The map

section displays the user’s location with the bouncing marker, which is currently pointing at

Tarragona, Spain; and locations of places with normal markers, which are pointing at areas in

Slovenia. The locations of car charging stations are shown in Figure 6.


15

Figure 6: Map section, showing locations

When the user chooses a topic, he or she can see multiple places referring to the topic as seen

in Figure 7. By default, the user will only see three places at first. These are different for

everyone, because only the closest places to the user's current location are displayed. The

user can sort the data by name and/or distance by clicking on the icons next to the column

headings. By clicking on the icon to the far right of the Table heading, the user can see either

the three closest places, or all of them. A registered user can add a place to his or her favourites

by clicking on the star button. One can also navigate to a desired place by clicking the green

button with a navigation icon. This opens a Google Maps path from the user’s current location

to the desired destination. Places are sorted according to the user’s current location in

ascending order. When the user is travelling, all the distances keep on updating in real-time.

Pictures and descriptions of places can also be accessed. Pictures of all the places are

requested from Google API.


16

Figure 7: Natural landmarks

After choosing some locations for his or her favourite ones, the user can go to the “favourites”

section by clicking on “Favourites” in the navigation bar. The page that opens up is shown in

Figure 8.

Figure 8: Favourites section


17

The screenshot above shows the Favourites section of a registered user. The user can see

his favourite locations in the form of “cards”. These locations are again sorted based on the

user’s current distance from them. With a click on the green button with a navigation icon, the

user will be navigated to the location. By clicking on the red button with a bin icon, the user

removes his or her favourite station. A photograph of the location is included. If the user wishes

to know more about the chosen location, he or she can click on the icon “more” (the icon with

three dots), which will expand the text area and provide the user with a brief explanation of the

place.

In the Registration and Login page as seen in Figure 9, the user is asked for his or her e-mail

and password. After clicking the login link, the last field vanishes and the user can log in without

repeating his or her password. The user also has an option to click on the “forgot password”

link, which results in an e-mail being sent to the mail of the registered user. There is also a

spot for the administrator to log in.

Figure 9: Login and registration page


18

Figure 10: Admin page

We logged in as Administrator and clicked on “Admin Section” in our navigation bar. One can

see in Figure 10 that the Admin Section has a different navigation bar. The overview section

shows basic information about the users and places. In this section, the Administrator can only

see the information gathered by the application; he or she cannot change or modify anything.

Figure 11: Collection overview


19

The Collections overview is shown in Figure 11. The Administrator can view all the collections

with the exception of “users”. The stations which are shown in the Figure can be modified and

sorted by the Administrator. He or she can retype the name and change the status (availability).

If the status is IACT (inactive), the station will not be displayed to the users. In the last column

the Administrator can see the usage of all stations. If he or she wishes to add a new place or

a station of any type, this can be done by scrolling down and referring to the Google Maps

autocomplete helper, which not only locates the place, but also gets all the necessary data.

4.2 Mobile application

According to the Meteor Mobile Guide, Meteor integrates with Cordova. Cordova is an open

source project for building mobile apps with the same code web apps are built with. A regular

Cordova app is written in HTML, CSS and Javascript. It runs as a native app, instead of running

as an app in a web browser. Cordova also supports hot code push, which means that we do

not need to go to the app store and update it; it updates on the user’s device automatically.

Plugins of Cordova also allow us to use features that are usually not available to web

applications. We can access the camera, local file system, NFC readers etc. In Meteor, there

is no need to install Cordova, as it comes with every Meteor project. Likewise, we do not need

to configure the config.xml file, because Meteor provides a mobile-config.js file, which has

specified settings to configure the app. The product was developed partly on Ubuntu 14.04

where we had the option to create the mobile app; building apps for Android or iOS is not

supported on Windows.

Installing prerequisites is obligatory. Next, we have to configure our Ubuntu with Ubuntu Make

and set the mobile server to run the app on Android mobile devices successfully [8].

4.3 Real-time concepts in the project

We made this project with Meteor to show the modern concepts of the framework. Explaining

all the Meteor’s features leads us to the real-time concepts. Firstly, let us define what we mean

by that. A real-time concept is a process which makes all the changes in the database, and

reactive variables, visible in an instant to every client.

Changes in our application are visible due to a change in the collection document. In Meteor.js,

we can do that on the server side and on the client side. Changes, important to the


20

Administrator, are server changes. They show instantly what has happened with the Mongo

DB document. What clients are currently seeing is also shown. The client side changes are

different. Everything that is changed in the client side collection is only visible to the client that

changed it. With this, we change the document again, but this time the change applies only to

this client, thanks to the Minimongo library. This is possible because for the client, a collection

is a client-side cache of database.

4.3.1 Real-time concepts from the Administrator

An admin user is basically just another user who has admin privileges. Admin can edit the

server-side collections because he or she has privileges to do it. Everything the admin changes

in the database should be instantly visible to all the clients in our applications. When the admin

edits a place, he or she changes the collection’s document in the database. A real-time change

is shown when admin changes the name, activates or deactivates the place, changes the

description or changes the pictures of the place. This can be done in the Admin Navigation

page. In our case, the documents are places referring to each topic which are displayed to

every client in the Table. Real-time changes make the change instantly visible to all the clients.

Whenever the admin has to update a place, every field edited is shown to other clients without

them having to refresh the page. The second thing that admin is working with in real-time is

actions of other users. For example, the Administrator can, in his or her page, see who is

registered and who is currently online. If a user has logged in, the icon changes from red to

green on the Admin page. If a new user has registered, it adds a new record of a user to the

admin UI page instantly.

4.3.2 Real-time changes from the clients

Clients without admin privileges can only update the client-side or their own collections. They

do not need any privileges for that because everything they write into that collection is only

displayed to them.

In our application, each client's device calculates the distance from him or her to every place.

Every distance is different; therefore, it is useful to write the value only to the local collection.

When the calculated distance changes according to the previous one, each client updates his

or her local collection with the new value. Distances to every place in our database are being

updated when we drive from one place to another. A client has to write to his local collection,


21

because then all of the collections are sorted in real-time based on the client's distance to

them.

4.3.3 How these real-time changes work

Let us say that we have three main web applications: Traditional web applications, single page

web applications, and real-time web applications. Let us compare them. In traditional web

applications, each time a user accesses a new page on the site, a client makes a request to

the server and gets the content (usually an HTML file) in return as seen in Figure 12.

Figure 12: Traditional web apps

In single page web applications, the client’s first request triggers the download of a Javascript

file which contains the code needed to render every other page (Figure 13).


22

Figure 13: Single page web apps

In a real-time, single page application (like Meteor), the client can request more data, and the

server can also push data to the client (Figure 14).

Figure 14: Meteor real-time web apps


23

4.4 Test server and database

The application is currently deployed on an Heroku server. The Heroku server provides

availability for Meteor applications by allowing the inclusion of the Mongo database. The

Mongo database is included via add-ons, and the dashboard for this project on Heroku can be

seen in Figure 15.

Figure 15: Heroku dashboard

The application is deployed and the MongoDB instance is connected with mLab. The

collections which I included in this application are shown in Figure 16.


24

Figure 16: mLab collections

5 CONCLUSION

At the company, we wanted to create a hybrid application that would work on computers (web

browser), smartphones, and tablets with Android or iOS. Building it in native programming

language for every mobile operating system would require plenty of developers and hours of

work. Meteor was the solution to create everything with a single source code. In the future, we

will have to make the application compatible with the Oracle database, add features the users

will ask of us, and add an iOS mobile platform. The project has to be updated regularly due to

framework upgrades and, most importantly, user wishes. We will have to adapt the application

constantly to the needs of the modern world (e.g. electric car charging stations).

The purpose of creating this project was to show instructions on how to work with the Meteor.js

framework, show its advantages, disadvantages, and introduce new ways of interacting with

users on a real-time basis. We presented the Meteor framework to a great degree. Knowing

the advantages and disadvantages will help us update and maintain the application. Using

real-time concepts was one of the main reasons we chose this framework. We explained how

they work and showed their benefits.


25

We came to the conclusion that modern web frameworks are going the way of real-time

communication between the server and the client. Using the Meteor rendering library, which

works in a similar way as popular rendering libraries like React and Angular, was crucial in

getting to know the modern UI standards. Explaining and using the Mongo database, which is

a document-based database, is a new way of storing the important data.

This framework gives us a lot of freedom for developing front-end and back-end in one

language. With freedom and fast prototyping comes great concern about the security of the

application. We need to be very careful what data we publish to the clients and what operations

over database collections we allow them to manipulate. Keeping our keys or any other discrete

information should not be written in the code that is loaded to the client. In the future, we will

have to make more tests on resource usage and optimization.

Developing this application and working on this project made me appreciate this framework. I

picture myself working with it in the future. The basic work has been done, and the new

technology has been described, which will henceforward be used more and more. I look

forward to updating the project and seeing this application used by many people.

The world of computers is changing rapidly. New technologies are appearing every day. Being

up-to-date with every change that occurs in web development is obligatory if we want to keep

the application modern and competitive with other similar projects.


26

6 LITERATURE AND RESOURCES

[1] Blaze documentation. (n.d.). Retrieved 9 7, 2016, from http://blazejs.org/

[2] Coleman, T., & Greif, S. (2015). Dicover Meteor. Melbourne.

[3] Lobel, L. (2015, June 1). Relational Databases vs. NoSQL Document Databases. Retrieved

5 22, 2016, from https://lennilobel.wordpress.com/2015/06/01/relational-databases-vs-

nosql-document-databases/

[4] Meteor docs. (n.d.). Retrieved 9 7, 2016, from http://docs.meteor.com/#/full/

[5] Meteor Guide - File Structure. (n.d.). Retrieved 8 6, 2016, from

https://guide.meteor.com/structure.html#javascript-structure

[6] Meteor Guide - Methods. (brez datuma). Pridobljeno 7. 9 2016 iz

https://guide.meteor.com/methods.html

[7] Meteor Guide - Mobile. (n.d.). Retrieved 9 7, 2016, from

https://guide.meteor.com/mobile.html

[8] Meteor Guide - Mongo Collections. (n.d.). Retrieved 9 7, 2016, from

https://guide.meteor.com/collections.html#mongo-collections

[9] Meteor Guide - Publications and Data Loading. (brez datuma). Pridobljeno 8. 8 2016 iz

https://guide.meteor.com/data-loading.html

[10] Meteor Guide - Spacebars. (n.d.). Retrieved 5 22, 2016, from

https://guide.meteor.com/blaze.html#spacebars

[11] Meteor Guide - Tracker. (n.d.). Retrieved 9 7, 2016, from

https://docs.meteor.com/api/tracker.html

[12] Meteor Guide Introduction. (n.d.). Retrieved 8 8, 2016, from https://guide.meteor.com/

[13] Mongo database introduction. (n.d.). Retrieved 6 8, 2016, from

https://docs.mongodb.com/manual/introduction/