Architectural Overview
The following section describes beLocal's client side architecture.
The following diagram is a high level overview of beLocal's client side architecture.
Since beLocal Victoria was implemented using the AngularJS, its design heavily follows the MVC software design pattern. The model component is represented by StateService.js. This AngularJS service is responsible for making the majority of the REST calls to the server. Any data received (such as user profile information, market lists, vendor lists, etc.) is then stored locally in the service for use by other views/controllers.
There are several views used throughout beLocal. Each of these is contained in a standalone HTML file. Angular-UI-Router is then used to serve the correct view depending on the value in a browser's address bar. Each view also has its own controller, a JavaScript file with an isolated scope from the rest of the site that contains all business logic for that specific view. Furthermore, in AngularJS, controllers act as a sort of per-view model. Any variables defined on the $scope object of a particular controller can be accessed in that controller's view using AngularJS's injection notation {{}}. For beLocal, each controller typically accesses the information it needs from StateService and stores it in a variable defined on its $scope. Views then bind to this information using the aforementioned process.
A second service used heavily in beLocal is AuthService, which is responsible for performing all registration and authentication related actions in beLocal. This service is heavily used in the routing logic of beLocal to ensure that certain views are restricted to only authenticated users. It also sets various cookies related to user authentication and login, and makes calls to OAuth.io for login using Facebook.
Finally, several AngularJS directives are also used in beLocal to modularize reused functionality across the application. Directives typically consist of an HTML template file that is injected into a view on page load. They also have their own JavaScript controller files which encapsulate their business logic. One example of this is the be-local-map directive, which is responsible for displaying maps and pins across the application. Another example is the nav-bar directive, which is injected at the top of every page.
On the whole, the architecture used on the client side of beLocal works extremely well, as it allows for ease of extensibility and scalability.
The following section describes beLocal's server side architecture.
beLocal is currently running with Amazon Web Services (AWS). We are also using NGINX as our web server due to its superior versatility and efficiency over Apache.
We decided to use Django REST API to interface with our MySQL database to easily allow for us to expand to a native application at a future date. For serving Python (Django is written in Python) we utilize Gunicorn, recommended in the Django documentation.
The following diagram represents the current configuration of the modules installed in our AWS ec2 Ubuntu server.
The following is the Entity-Relation Diagram for beLocal.
All foodies registering on beLocal have a User object associated with them, while all farmers/foodmakers will have both a User and Vendor object. The is_active flag on Vendors is used to control whether or not a vendor's selling locations/products appear on the application, while the is_active flag on Users can be used to completely deactivate any type of user account.
It is also important to note that Tags are implemented using django-taggit, which generates several models under the hood for use in tagging. For convenience, these generated models have been omitted from the ER diagram.