SYMI is a gamified platform for promoting positive feedback and company morale. Employees get points for sending anonymous feedback directly to their CEO. CEO's can have a top-level overview of company sentiment in the form of data visualization personalized to company changes to employees.
This is the backend server implementation for SYMI.
To test out the working version or learn more about the front end, please check out the demo link above or see the frontend Readme.
✨ Demo
For this project we implemented a clean architecture (Onion Architecture).
SYMI backend makes use of Docker to create and image of the app and be able to deploy a docker container quickly and with easy
docker build -t symi-backend
//symi-backend can be replaced with your desired image name
docker run --rm -it -p 5000:8080 -e PORT=8080 symiback-end
-p 5000
-> determines which port your container will be accessible on
:8080
-> which port the app is listening on (inside the container).
By default the app listening port is 8080, however it can be changed by passing in a PORT environment variable (-e PORT=####).
If needed, it is possible to utilize Makefile, instead of Docker. If you have Make installed, you can run the app with
make run
Directly running the go application is also possible with
go run ./application.go
We kept track of all available endpoints, their required parameters (request body, query, etc) and the response (status and body(if any)). Details can be found in the SYMI endpoints
Symi-backend contains 2 setups that can be utilized - AWS and Heroku In both cases, please make sure to add the following Environment variables:
DB_INFO: the full link to the Database you plan to use for the app <user>:<password>@tcp(<link_to_db>)/<db_name>
SIGNING_KEY: <string> - will be used as SALT to hash and check your passwords for storage.
Make sure to run migrations (and seed some data) from /app/migrations
and /app/seeder
.
To deploy the backend server Heroku, create an app via the CLI or on Heroku. Fork your version of the backend-SYMI repository. Link your created app with the forked GitHub repository. Click "Deploy" in settings!
Based on Heroku.yml, a docker image will be created. Heroku will then start up a container in your app.
AWS Deployment will require some prior setup. The first step will be to create the initial CI/CD Pipeline that will be building the Docker image and deploying the rest of the infrastructure. This step has to be performed manually.
Either via the AWS CLI tool, or using the AWS CloudFormation website, create a new stack using the ready template.
Template: /cloudformation/codepipeline.yml
- Please make sure to add a Personal Access Token to your account allowing AWS CFN access to the repository.
- Change the current template info
GithubUserName
/GithubRepo
/GithubBranch
to match your fork.
Once the template is created, with every push to the branch that was specified in GitHubBranch, the AWS CodePipeline will build the Docker image, store it into an S3 bucket, and finally trigger the infrastructure build using ECS Fargate.
Once again, by default Fargate will create 2 tasks running in 2 different Subnets and create a load balancer that connects them both.
To get access to the server, please find the DNS address in the ECS Instances -> Elastic Load Balancers
.
The main steps of the deployment process are as follows:
- User manually deploys the initial Cloudformation template containing the CodePipeline infrastructure (
CodePipeline.yml
). - Cloudformation starts the deployment of the AWS CodePipeline infrastructure.
- After the Cloudformation deployment, CodePipeline pulls the source code from GitHub in the source stage.
- CodePipeline builds the docker image and pushes to the ECR in the build stage using AWS CodeBuild service.
- CodePipeline starts the deployment of the Cloudformation template (
Fargate-Cluster.yml
) containing Fargate ECS Cluster in the deploy stage.
Simplified structure can be seen below:
For more details details and information, please check out the following article: AWS Cloudformation Managed (Medium.com)
To match the complex data flow of SYMI information, the below structure was created.
Furthermore, due to the potentially large amount of user actions, instead of using ORM for DB interactions, the read/write operations are done using pure SQL, to achieve faster handling speed.
-
Utilize Go routines and/or channels to further speed up data handling.
-
Breakdown the monolith code into micro services (employee actions would be loaded more than CEO, so scaling only that part would be easier).
-
Create functionality to support the future features mentioned on the frontend Readme:
- Custom Assignments
- Employee Slack Notifications
- Invite Calendar Integration
- Points Animations
- Badges & Rewards
![]() Mini Tech Lead |
![]() Igor Fullstack |
![]() Steffie Harner Design/Frontend |
![]() Yukio Ueda Backend |
Give a ⭐️ if you like our stuff!
This project is ISC licensed.