ORGZ: modern club organization app

ORGZ is web application designed for on-campus university clubs, allowing them track membership, manage attendance, chat, organize events, and earn fun badges by participating in club events.

I was the project manager and scrum master for ORGZ, managing a team of 4 student engineers.

Technical implementation

Orgz is a modern browser-based web application built with a classic MEAN (MongoDB, Express.js, Angular.js, Node.js) stack and deployed using Heroku. Before proceeding with the technical details, we’ll assume that the developer has set up and installed Node.js packaging tools (and their dependencies) through command line or homebrew as well as Git and other version control systems.

Project Configuration and Setup

All server-side communication and routing is handled through Node.js and Express.js middle layers. To view the app’s organization configuration, see the config/ directory, where we define our databases and routing schema. Note that database.js contains the url needed to access a cloud-based MongoDB database—this originally holds a private API key but has been removed for to the handoff; for those who wish to continue development of this project, is recommended to to create a free MongoDB instance. auth.js requires a Google developer account API key authorization. A Google developer account can be made for free to access to their account login API.

To handle user account login and management, we use the passport.js framework, defined and used in the file passport.js. We recommend reviewing the user guide and documentation for passport before getting started; note that we have email/password logins defined as LocalStrategy , whereas the Google account integration is a separate GoogleStrategy.

Database & Schemas

ORGZ uses MongoDB as our database service with Mongoose as our Node.js driver. Reviewing the MongoDB and Mongoose documentation is helpful for understanding our schema types, organization, and data structure. All schemas are stored in the app/models directory, and are generally named after the data type conversion role they perform. For example, club.js represents the schema for an individual club, with fields/parameters for name, description, officers, and so on. These are all saved as individual documents within our hosted MongoDB instance. For our use case, we used an account on and integrated it into our app, although we have since removed our API key from the application for handoff purposes.

Other schemas include clubsToAnnouncements.js, which is used to access all announcements that are part of a certain club, or userToClubs.js, which is used to access all clubs a given user is in. Using this type of relational data control system, other relationships can be built with our specified data types to extend functionality.


We handle routing using express.js middleware in our routes.js file in the app/ director. We recommend reviewing express.js documentation, especially for requests and responses. We followed their naming convention and coding paradigms closely throughout our implementation of ORGZ.

Each function our routes.js file corresponds to either an HTTP 1.1 GET or POST request handled at the specified URL path, relative to the current host name that ORGZ is using (either local or remote deployment; this should be handled by node.js automatically during compilation and runtime, so only the relative path should be specified). The code makes heavy use of javascript callback functions, where functions passed as arguments are then executed at given times with the parent function’s parameters.