Skip to content

Technology Stack

Jump to bottom
Johannes Ströbele edited this page Aug 17, 2020 · 16 revisions

This is the software architecture for the GitHub HR web application: image

Overview

The explanation for the deciding on the technology stack above, can be seen below:

1. Design tools

  • Figma was chosen
  • easiest for conducting user tests (collaboration features are great)
  • good usability and templates for wireframing
  • free

Possiblities

2. Frontend

  • Angular was chosen for this project
  • Some could argue that it should be coded with Vue.js or React due to the GitHub user dashboard being a small project.
  • However, the future job goals, previous knowledge, and the German job market need to be taken into account
  • The project creator wants to develop large applications in the future, which favors Angular (companies that build large applications mostly use Angular)
  • The learning disadvantage of Angular is minimized due to previous experience during internships
Name Popularity Fun/Learnability Performance Out-of-box-dep Flexibility Debugging Popularity (GER)
Angular High Low Low High Low Easy High
React Mid Mid Mid Mid Mid Difficult Mid
Vue.js Low High High Low High Medium Low

Explanation

  • Performance & out of the box dependencies & flexibility: Angular comes with many dependencies out of the box, which makes it less flexible than React and Vue.js. This lowers its performance, especially for smaller projects. However, if these mostly very useful dependencies are excluded or used, the performance difference is rather negligible.
  • Debugging: Angular uses TypeScript, which reduces the risk of errors significantly, especially in large projects. For smaller ones, the effort of writing type secure mostly outbalances this advantage.
  • Fun/Learnability: Angular comes with many dependencies and like React with an older approach. Therefore, Vue.js is easier and fun to learn.

References

3. UI Component Libraries

  • Angular Material, flex-box, and MDBoostrap were chosen
  • Angular Material and MDBoostrap are widely adopted and was used by the last three companies I worked for
  • flex-box and MDBoostrap makes building layouts easy, which Angular Material lacks
  • ag-Grid could be used for easily creating responsive tables
  • The other components libraries should be explored more deeply, but this is skipped here due to lack of time

** Possible Libraries**

Resources

4. Version Control Systems

  • Git was chosen
  • today it is the most widely adopted VCS
  • good for non-linear development due to distributed repository model
  • super-fast and efficient performance
  • code changes can be very easily tracked
  • has the most features
  • there are many free repository hosting providers
Name Distributed-VCS Centralized-VCS
Repository Is a distributed model without a central repository but has a complete local repository for every user Only one central repository which is the server
Access Allows every user to work completely offline, but the user need a network to share their repositories with other users Every user who needs to access the repository must be connected via a network.
Example tools Git, Mercurial, Bazaar, BitKeeper, Monotone Subversion (SVN), Perforce Revision Control System, CVS
Suitability 1) Is suitable for single or more developers because the project repository is distributed to all the developers 2) can be applied for small or big software projects because it makes less difficult for normal users to contribute to the development 3) Team located in multiple site or different countries and different timezones 1) Only suitable for projects that need only a few users to contribute to the software development 2) Team located in a single site

Comparing Git, Mercurial, Bazaar, BitKeeper, Monotone, SVN

  • Licensing: only BitKeeper has restricted its licensing and therefore is excluded in this comparison
  • Outdated: only Monotone, which is why it is excluded in this comparison
  • Features: Git has the most features, but therefore is more complicated than Bazaar or Mercurial
  • Ease of use: Mercurial and Bazaar are easy compared to Git
  • Performance: Git has the best performance, followed by Mercurial and then by Bazaar
  • Repository size: Git has the least size, followed by Bazaar and then by Mercurial
  • Network protocols: all support HTTP/HTTPS, SSH (Bazaar with plugins SFTP and RSYNC)
  • Repository hosting: Git has the most providers (e.g. GitHub), followed by Mercurial and then by Bazaar
  • Popularity: Git is most popular, followed by Mercurial and then by Bazaar

Resources

5. Free Git Hosting Providers

  • GitHub was chosen for this project because it has it was used in earlier projects and has only a slightly worse functionality than GitLab, especially for a single user
  • GitLab is the best free solution for users that want to get the most bang for the buck
  • BitBucket is the best solution for large teams that are prepared to pay for the best functionalities
Provider Free-Plan Paid-Plan Data-Plan Tools
GitHub Free up to 3 users $4/mo for organizations 10GB free, 5$/mo 50GB+50GB Bandwith Project management, quality management, wiki
GitLab Unlimited users $4/mo tiered pricing 10GB max limit Continuous Integration, project management (paid), wiki (paid), quality management, on-premises (self-hosting)
Bitbucket Free up to 5 users $4/mo per user 1GB free, $10/mo 100GB Continuous Integration, project management, quality management, on-premises (self-hosting)
Azure Free up to 5 users $3/mo for 10 users, $5.5/mo for 20 users Unlimited data Continuous Integration, project management

References

6. Data Foundations

  • In order to create a GitHub user dashboard, data from the GitHub user profile is necessary
  • GitHub provides [https://docs.github.com/en](several solutions) to get this data
  • the GitHub REST API was chosen as explained below

6.1. Communication protocols

  • Before deciding on the API, basic understanding of the communication protocols such as HTTP is needed
  • Is crucial for the communication in application layer of the Open Systems Interconnection model
  • application-layer protocol for transmitting hypermedia documents, such as HTML
  • In the past, the communication consisted of the client requesting and the server responding
  • Example: nothing happens, until the client clicks or navigates to the next page

Issues

  • Sometimes the server wants to also request something from the client -> bidirectional communication
  • AJAX enables to update web pages without reloading the page (asynchronous data exchange)
  • Push or Comet used hacks to create the illusion that the server is sending data to the client. This is called long polling. The client opens an HTTP connection to the server which keeps it open until a response is sent. Whenever the server has new data that has to be sent, it transmits it as a response.
  • All these workarounds share the same problem though: they carry the overhead of HTTP
  • WebSocket as a solution
    • it defines an API establishing “socket” connections between a web browser and a server
    • In plain words: there is a persistent connection between the client and the server and both parties can start sending data at any time (two-way and real time communication)

Resources

6.2. Data communication technologies

  • are mostly stateless (have not the ability to maintain their state on their own (so if you reload the page, everything is reset)
  • most popular nowadays are APIs and Webhooks

6.2.1. API

  • does stuff when you ask it to
  • General example; you send a text message to a friend and sends you a response
  • Concrete example: you want a dashboard that shows every second analyzed Twitter posts (new posts every second)
  • will place calls for data whether there’s been a data update response, or not
  • when this happens you’re simply wasting resources
  • if there is a limit the number of calls you make in a set time period, request errors will occur if you exceed it
  • should be used if data changes constantly
  • operations: GET, POST, PUT, and other HTTP methodologies
  • REST
    • The API defines what data they provide and in what format you can get it
    • accessible data is described as a linear list of endpoints that is decided by the API PROVIDERS
    • if there is a limit the number of calls you make in a set time period, lead to large issues
    • is very resource heavy (you get everything that the endpoint provides and cannot choose only certain data like with GraphQL)
    • less complex then GraphQL
    • GitHub REST API v3
  • GraphQL
    • the client determines what data they want, how they want it, and in what format they want it in
    • accessible data is described as a schema with relationships that YOU can decide
    • additional complexity of implementing in comparison to REST
    • advantageous because it typically delivers the smallest possible request (REST, on the other hand, typically sends everything it has all at once by default)
    • GitHub GraphQL API v4

6.3.2. Webhook

  • does stuff on its own when certain criteria is met or scenarios takes place
  • General example; you tell your friend that he should notify you, if he organizes the next party
  • Concrete example: only if a payment fails, a company gets a automated email via Stripe
  • simply put, it’s an HTTP POST that is only triggered automatically when an event occurs (the external system you’re hooked to have a data update)
  • reversal of the classic client-server relationship
  • should be used if data doesn't change constantly and to perform smaller requests and tasks
  • be aware, they aren’t used to regularly request data (never learn if something is borken)
  • also, is gives less control over the total flow of data, as you have to accept the total data amount that’s available with the given update
  • GitHub Webhooks

6.4. Choosing an API

  • Objectively, GraphQL would be the best fit for this project due to GitHub having strict call and resource limits for get requests via their APIs. However, it is questionable if the effort for setting up the schemas takes too long for this small university project.
  • A Webhook is not really needed, because the data of GitHub users does not change frequently, so a ordinary GET request via an API when pressing on the search user button, is sufficient

Resources

7. Data Visualization Tools

  • ng2-charts was choosen due to supporting the responsive graphs from chart.js
  • uses Angular to render and animate the SVG elements with all of its binding and speed goodness
  • allows to customize the styling using CSS
  • ngx-charts was tried out, but lacked either functionalities or documentation for making graphs responsie
  • d3 should be used if many math functions, scales, axis and shape generators, etc are necessary
  1. ng2-charts
  2. ngx-charts
  3. Angular Bootstrap Charts
  4. DlChart
  5. ngx-echarts
  6. canvasJS
  7. d3.js

References

8. Backend

Node.js was used as a cross-platform runtime environment. The Node HTTP package enables the creation of a simple web server. Further, Node.js makes it possible to write the backend in JavaScript or TypeScript. Finally, it supports the node package manager (NPM), which makes it easy to access and manage the packages needed for this project (e. g. MDBoostrap, Express).

Node.js does not directly support serving static files, specify common web application settings like the port (needed for Heroku deployment), and separately handle requests at different URL paths. Therefore, Express was chosen due to its lightweight, popularity, and ease of use.

  • Express.js
  • Meteor.js
  • Socket.io among others

Resources:

9. Deployment

The application needs to be deployed for making it accessible via the Internet. Several free options exist such as Heroku, Netlify, or GitHub Pages. GitHub Pages would be the easiest solution but uses Jekyll as the middleware, which is written in Ruby. Netlify was tested but not chosen due to insufficient documentation for deploying Express applications. Therefore, Heroku was used (Heroku, 2020a).

  • Netlify
  • Heroku
  • GitHub Pages

Resource: https://stackshare.io/stackups/heroku-vs-netlify

  1. Home
  2. Online Research
  3. Interviews
  4. Project Goals
  5. User Needs
  6. Concept
  7. Design Mockup
  8. Technology Stack
  9. Application Explanation
  10. Lessons Learned
  11. Potential Enhancements
Clone this wiki locally