Skip to content
This repository was archived by the owner on Feb 17, 2025. It is now read-only.

Tech Stack Architecture Review

Bhalachandra Malghan edited this page Aug 20, 2019 · 1 revision

Conducted: May 15

Members: All members of team 1 and 2, Mena, and Rabih

Notes

  • Presented basic tech stack to Rabih
  • He seemed rather concerned about whether or not we should be using whatever tech we want to write the app (i.e. React) as opposed to something that is more standardized across the department (i.e. Angular).
  • He had his concerns about how maintainable/supportable the application would be by members of the department once the student group had left.
  • As for architecture (i.e. GCP), Rabih wasn't overtly concerned about it because switching where the app is hosted isn't that big of a problem; especially considering that we'd be dockerizing all of our services. He agreed that moving from GKE to EKS wouldn't be that big of a problem.
  • Mena, however, was concerned about us wanting to use AWS, because that's what the department has been trying to move to, and because of something about data processing laws where all of the data has to be kept in Canada. Who knows if the data processing rules actually apply to us.
  • Ultimately, the bulk of the meeting came down to Mena and Rabih discussing whether or not this program weighs more heavily in favour of the students trying out and learning whatever technologies they want or more in favour of building something that the department can use and maintain.

Discussion with Rabih and Jim

aka Tech Review 2: Electric Boogaloo

Conducted: May 15

Members: Devin, Rabih, Jim

Notes

  • After the above tech stack + architecture review meeting, I went and basically continued the discussion with Rabih and Jim.
  • Got some feedback on the project idea as a whole from Jim: he generally seemed ok with it, but seemed more interested in the 'Skills' half of the project as opposed to the 'Projects' half; this was because he indicated that people can dip into projects on Jira for creating e.g. non-technical tickets or even just that they have created tickets on Jira projects but haven't actually worked on the them (e.g. bug reports). As such, he thought there would be too much whitenoise to figure out who actually worked on what through Jira.
  • However, Jim seemed to think that just cloning repos from Bitbucket would be much more relevant in terms of finding skills.
  • Jim also indicated that he thought it was strange that 'IT' said that the Jira API was 'disabled', since their Jira and Bitbucket instances are integrated together.
  • Rabih questioned Jim on how feasible it would be for the department to maintain a React stack since Rabih was unaware of whether anyone here actually had any experience with it; Jim indicated that there was (at least) one project that was using it. Rabih seemed satisfied with that.
  • Re: overall choice of tech stack, Jim also questioned whether the priorities of the program are for student experimentation vs departmental value gain.
  • Jim mentioned that they have an OpenShift deployment that can be used for container deployment [this is also where Jarvis is currently hosted].
  • Jim indicated that it didn't really matter where the frontend/backend of our application is hosted, as long as the service that queries Jira/Bitbucket is hosted on-prem. This is because the on-prem service can communicate outbound just fine, but communicating off-prem to on-prem is a bit more of a headache.
  • Jim also mentioned that if we needed to deploy a container on-prem for the scraping service, he'd be willing to help us set that up; he mentioned that they might have one server that could run the container (as most of their servers are apparently very old and can't run Docker, nor modern versions of Node). However, since the scraping service would only have to run every so often (every couple weeks, once a month, etc), then it wouldn't be too big a deal to schedule our container on that one server.
  • Jim also mentioned that it'd be a good idea to get just a "hello world" proof-of-concept of deploying this on-prem container just to get the process down.
  • Overall, the conclusion of this set of discussions was that the Skillhub project seems feasible. All members were more-or-less in agreement that that all parts of the technical stack and architecture sounded sane and would work out.
  • Note: Jim mentioned that he can be contacted through internal RocketChat through something called 'GCCollab'? Apparently you just need to sign up for an account with your @canada.ca email. I mentioned to him the possibility to bringing him into our Slack team, but he seemed to prefer staying in 'GCCollab'.

Clone this wiki locally