Technologies Used - sms-trevature/user-interface GitHub Wiki

Zuul

Zuul served as our API Gateway for our Staging Management System. For each client request that comes in, Zuul will delegate each to our microservices. Zuul acts as a reverse proxy and therefore when one user or computer accesses our application, Zuul will distribute our requests to multiple services. In our case, we have a user, interview and survey service.

Eureka

Eureka acts as our Service Registry. This allows our microservices to register themselves so that others can discover them. Eureka has an individual heartbeat for each service to make sure that they are healthy. The heartbeats also ensure that the services are still up and running.

Ng Bootstrap

Bootstrap allowed us to achieve the desired aesthetic of our application. By implementing bootstrap, we were easily able to import ready-to-use modals, input fields and buttons amongst other components.

Ng Charts

Easily allows us to import multiple graphs such as pie charts, bar graphs, line graphs, as well as other charts and graphs. We use this to show survey results as well as any interview feedback we may have.

Ng Calendars

Imports a calendar feature. When scheduling an interview, we can select a date. Also, we use the ng calendar feature when selecting a start and end date for our cohorts.

Ng Http Loader

The Ng Http Loader provides an HTTP Interceptor and some spinner components. This is used in our application whenever data is being loaded and there is a load bar animation on the screen.

Angular 7

Our entire front end was built upon the Angular framework. Specifically, with Angular, we used HTML, SCSS, and Typescript. Our styling was done with SCSS. The functionality of our DOM was done with Typescript and we were able to display our data with HTML. Within Angular, we had components which each served a separate functionality. Using router links, we were able to able a single page application allowing for a smooth and faster website.

Spring Framework

The middle end of our application was done in Spring Boot. The application that was handed to us already included Spring Boot and so we didn't touch this side as much. But what Spring allowed us to achieve was enabling our microservice components as well as add any business logic. Whenever we have a client request to receive any information that is stored in the database, Spring was the physical connection to both. Our methods within Spring handled the requests and sent it off to our database to retrieve the information.

Cognito

Cognito was our way to authenticated security tokens. This makes it so that if a user logs in and then logs out, no other user is allowed to go into that user's session. Whenever a user tries to hit the backspace button after another user logs out, it won't allow that user to see the previous user's information. Also if a user tries to enter a component within our application by typing out the URI, it will simply redirect them back to the login page.

Postgres

Postgres is what was used to manipulate our database. By using CRUD methods, we were able to create tables, specify columns, delete information if needed, and insert some initial values. We were able to achieve the manipulation of our data by using scripts. All of our information including all users, interviews, and surveys are stored within our database.

Postman

We used Postman in order to test all of our endpoints. We shared a Cognito file that tested out authenticated tokens, the search user by group method, add a user to a group as well as a few other methods. Postman was an easy way to tell if we were getting any status code errors without opening up the actual application.

JUnit

JUnit was used sporadically throughout our business logic. Several methods were tested using JUnit which would simply return a green color for success or a red for failure. If the color red is returned then we are given detail as to what method went wrong and how many failures we got.

Mockito

Mockito is a mocking framework that allows us to test our methods. We can split up the data the test returns by blocks of code, lines, methods, and classes. Mockito gives us back a percent of how successful we were so we are able to fine-tune exactly where our code breaks and where it is working.

CodePro Analytix

This technology is owned by Google. CodePro Analytix is going to be our code coverage plugin in Spring Tool Suite. It will allow us to check how much code throughout the application is being used through testing. Normally code coverage is to be 70%-80%. This means that 70%-80% of our code is being touched by testing.