search

abstractionhq / gallery-gateway

📷Gallery Review System
https://gallerygateway.rit.edu
Apache License 2.0
5 stars 4 forks source link

readme

Gallery Gateway

Gallery Gateway Logo

About

Motivation

The RIT School of Photographic Arts and Sciences (SPAS) holds an annual art exhibition highlighting the top works of RIT student artists. Students can submit works for consideration during an open call, and a panel of RIT faculty jurors vote on which art will be displayed in the gallery at this show. Currently, SPAS has been paying for and using a software as a service product, CaFÉ, to facilitate this process; however, frustrations with CaFÉ’s difficult-to-use interface and poor user-experience for both administrative and student workflows has led them to seek custom replacement software which better fits their use case and work process.

Gallery Gateway is this custom replacement software.

Team

Gallery Gateway was built as a Senior Project for RIT's Software Engineering Undergraduate Program during the Fall 2017 and Spring 2018 semesters.

It was built by Team A B S T R A C T I O N, whose members were Kayla Davis, Bill Dybas, Robert McLaughlin, and Tina Howard.

The project was sponsored by Nanette Salvaggio and coached by Bill Stumbo.

Process

We followed a Distributed Scrum process with sprints lasting two weeks. We conducted daily stand-ups over Slack and used ZenHub to manage our backlog of stories. Before each sprint, we met to triage, plan, and point stories, and after each sprint, we held a retrospective meeting. We met with our sponsor weekly to verify and validate requirements, whiteboard interface designs, and demo progress. We tracked our time using Toggl.

Our two primary metrics were Velocity and Code Coverage.

See our Interim Presentation and Final Presentation for more details.

Architecture

Both the frontend and backend are written in JavaScript.

Frontend:

Backend:

See each of their package.json files for the other tools we used (eg. transpiling, linting, testing).

New to React, Redux, & GraphQL?

Here are some useful resources on these tools and our architecture:

React

Redux

GraphQL

Development

You'll need to be running both the frontend and backend for development. Check out each of their README's for further instructions.

Deployment

We deploy our application on Ubuntu 16.04.

Prequisites

Install Node (8.x LTS) & NPM (>= 5.6)

curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -
sudo apt-get install -y nodejs

Install Yarn (>= 1.6)

curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
sudo apt-get update
sudo apt-get install yarn

Nginx and Supervisor must be installed and running.

Additionally, setup HTTPS using Let's Encrypt.

Deploy the App

Run our deploy/deploy.sh script.

It will:

You will need to provide the MySQL database password, RSA keys used for JWT authentication (see below), and the Identity Provider Certificate.

cd /opt/node/gallerygateway/keys
sudo openssl genrsa -out private.key 4096
sudo openssl rsa -in private.key -outform PEM -pubout -out public.key

Maintenance

Because the JavaScript community tends to move faster than other language communities, this app will require regular maintenance to make sure it can run on the current LTS Node.js runtime. Additionally, npm packages this app depends on should be periodically monitored, including updating to their latest stable versions (possibly even switching packages if the current maintainer abandons support).

Package dependencies will generally only need to be updated if packages contain security vulnerabilities or you will be developing additional features or upgrading Node versions. When running npm install or yarn install, you generally will be warned of deprecated package versions. It is recommended to also install npm-check-updates and run ncu to check which packages are out-of-date. Then, read through the CHANGELOGs of each out-dated package (they're usually found on the package's npm page or GitHub repo) to see if there are any breaking changes. If there are, update any of this project's code impacted by the breaking changes and update the version of the package in the corresponding package.json file. Double check that the upgrade is compatible by making sure that all existing tests pass (Note: frontend updates that impact styling will likely need to be manually tested).

Determining the health of a package is subjective but usually involves identifying when its most recent commits were, how active the maintainers are in responding to Issues and Pull Requests, and the number of Issues and Pull Requests the project has. Additionally, new packages may be developed which offer similar features to a package we use, but because of non-functional characteristics (e.g. performance, user experience), the JavaScript community may collectively favor this new package over the old and recommend switching. A word of caution; though, beware of hype-driven development – it plagues the JavaScript community.

Node.js LTS releases are cut every year in April. Upgrading Node versions involves updating any uses of deprecated Node API calls and making sure that all npm dependencies are compatible with the new Node version.

Changes to ECMAScript are generally backwards compatible, so it is unlikely that the language syntax will need maintenance. However, since we currently rely on Babel to transpile down to what's supported in major browsers and Node, Babel may need to be periodically updated. Ideally, Babel could be removed when the language features we're using are supported natively in all major browsers and Node.