Designing a large scale software application: the Histia Story

When designing a large-scale software system there are many aspects of software design that go into making a successful final product. This document seeks to give insight into the software design process, using my capstone project, Hestia, as a case study. Hestia is an all-encompassing household management application that combines all the features of a budgeting, calendar, to-do list, and meal planning app into one single easy-to-use application. Hestia's goal is to help make managing your life and household easier to help users stay on top of their lives in this chaotic modern world. Hestia was developed by the following team of developers: Bridger Peterson, Liam Zhou, Pierce Bringhurst, Thang Ngyuen, and myself (Shawn Michael Linnebach III). I will present this case study to help explain the design decisions that must be made in the field of web development in software engineering. After talking about the field in general I will then give an introduction to Hestia, which lays the groundwork for what we wanted Hestia to be and the requirements for an application of this size. Then, the design decisions we made for the application are explained based on the kind of application we wanted to create and the role of each team member is discussed. A timeline of the entire development process is shown which documents how the 30 week development time frame over two semesters was divided. Then, our results are examined by giving an in-depth look at the completed application and showing off all the features implemented. After this, I explain the roles I served on the team as the database designer, a backend developer, the backend quality engineer, and the public website designer and explain how I contributed to the final product in each of these roles. After this, I break down our design decisions and analyze which decisions worked well and which did not and explain my recommended design decision changes were we to develop the application from scratch again. ii Next, I explain the future of Hestia after this semester. The current plan is to maintain ownership of the code but not release the application yet because our team has to commit to maintaining and improving the application once it is released if we want it to be successful. We as a team have decided to take a break from development after this semester but in the future, we plan on continuing work on Hestia and releasing it at that point. We have already brainstormed additional features we would like to add to the application in the future. Overall, our team is very proud of what we have accomplished with the Hestia application. We feel like this application could make household management easier for any user. We hope that Hestia can be released to the general public shortly and help make a difference in their lives. Keep on the lookout for the future release of Hestia, the one-stop-shop for all your home management needs.

‌ DESIGNING‌A ‌ ‌L‌ ARGE‌S‌ CALE‌S‌ OFTWARE‌A ‌ PPLICATION:‌ ‌ THE‌‌HESTIA‌‌STORY‌ ‌ ‌‌ ‌‌ by‌‌ ‌ ‌‌ Shawn‌‌Michael‌‌Linnebach‌‌III‌ ‌ ‌‌ ‌‌ ‌‌ A‌‌Senior‌‌Honors‌‌Thesis‌‌Submitted‌‌to‌‌the‌‌Faculty‌‌of‌ ‌ ‌ The‌‌University‌‌of‌‌Utah‌‌ ‌ In‌‌Partial‌‌Fulfillment‌‌of‌‌the‌‌Requirements‌‌for‌‌the‌‌ ‌ ‌‌ Honors‌‌Degree‌‌in‌‌Bachelor‌‌of‌‌Science‌‌ ‌ ‌‌ ‌‌ ‌‌ In‌‌ ‌ ‌‌ Computer‌‌Science‌‌ ‌ Approved:‌ ‌ ‌ _________________________________‌ ________________________________‌ ‌ Thomas‌‌Henderson‌ ‌Mary‌‌Hall‌ Honors‌‌Faculty‌‌Advisor‌ ‌Director,‌‌School‌‌of‌‌Computing‌‌ ‌ ‌ ‌ ‌ ‌ _________________________________‌ ________________________________‌ ‌ Christopher‌‌Scott‌‌Brown‌ Sylvia‌‌D.‌‌Torti,‌‌PhD‌ ‌ Thesis‌‌Faculty‌‌Supervisor‌ Dean,‌‌Honors‌‌College‌ ‌ ‌ ‌‌ December‌‌2021‌‌ ‌ Copyright‌‌©‌‌2021‌‌ ‌ All‌‌Rights‌‌Reserved‌ ‌ ‌ ‌ ABSTRACT‌ ‌ When‌‌designing‌‌a‌‌large-scale‌‌software‌‌system‌‌there‌‌are‌‌many‌‌aspects‌‌of‌‌software‌‌design‌‌ that‌ ‌go‌ ‌into‌ ‌making‌ ‌a‌ ‌successful‌ ‌final‌ ‌product.‌ ‌This‌ ‌document‌ ‌seeks‌ ‌to‌ ‌give‌ ‌insight‌ ‌into‌ ‌the‌‌ software‌ ‌design‌ ‌process,‌ ‌using‌ ‌my‌ ‌capstone‌ ‌project,‌ ‌Hestia,‌ ‌as‌ ‌a‌ ‌case‌ ‌study.‌ ‌Hestia‌ ‌is‌ ‌an‌‌ all-encompassing‌ ‌household‌ ‌management‌ ‌application‌ ‌that‌ ‌combines‌ ‌all‌ ‌the‌ ‌features‌ ‌of‌ ‌a‌‌ budgeting,‌ ‌calendar,‌ ‌to-do‌ ‌list,‌ ‌and‌ ‌meal‌ ‌planning‌ ‌app‌ ‌into‌ ‌one‌ ‌single‌ ‌easy-to-use‌ ‌application.‌‌ Hestia's‌‌goal‌‌is‌‌to‌‌help‌‌make‌‌managing‌‌your‌‌life‌‌and‌‌household‌‌easier‌‌to‌‌help‌‌users‌‌stay‌‌on‌‌top‌‌of‌‌ their‌ ‌lives‌ ‌in‌ ‌this‌ ‌chaotic‌ ‌modern‌ ‌world.‌ ‌Hestia‌ ‌was‌ ‌developed‌ ‌by‌ ‌the‌ ‌following‌ ‌team‌ ‌of‌‌ developers:‌‌Bridger‌‌Peterson,‌‌Liam‌‌Zhou,‌‌Pierce‌‌Bringhurst,‌‌Thang‌‌Ngyuen,‌‌and‌‌myself‌‌(Shawn‌‌ Michael‌ ‌Linnebach‌ ‌III).‌ ‌I‌ ‌will‌ ‌present‌ ‌this‌ ‌case‌ ‌study‌ ‌to‌ ‌help‌‌explain‌‌the‌‌design‌‌decisions‌‌that‌‌ must‌ ‌be‌ ‌made‌ ‌in‌‌the‌‌field‌‌of‌‌web‌‌development‌‌in‌‌software‌‌engineering.‌‌After‌‌talking‌‌about‌‌the‌‌ field‌‌in‌‌general‌‌I‌‌will‌‌then‌‌give‌‌an‌‌introduction‌‌to‌‌Hestia,‌‌which‌‌lays‌‌the‌‌groundwork‌‌for‌‌what‌‌we‌‌ wanted‌ ‌Hestia‌ ‌to‌ ‌be‌ ‌and‌ ‌the‌ ‌requirements‌ ‌for‌ ‌an‌ ‌application‌ ‌of‌ ‌this‌ ‌size.‌ ‌Then,‌ ‌the‌ ‌design‌‌ decisions‌‌we‌‌made‌‌for‌‌the‌‌application‌‌are‌‌explained‌‌based‌‌on‌‌the‌‌kind‌‌of‌‌application‌‌we‌‌wanted‌‌ to‌‌create‌‌and‌‌the‌‌role‌‌of‌‌each‌‌team‌‌member‌‌is‌‌discussed.‌ ‌ A‌ ‌timeline‌ ‌of‌ ‌the‌ ‌entire‌ ‌development‌ ‌process‌ ‌is‌ ‌shown‌ ‌which‌ ‌documents‌ ‌how‌ ‌the‌ ‌30‌‌ week‌ ‌development‌ ‌time‌ ‌frame‌‌over‌‌two‌‌semesters‌‌was‌‌divided.‌‌Then,‌‌our‌‌results‌‌are‌‌examined‌‌ by‌ ‌giving‌ ‌an‌ ‌in-depth‌ ‌look‌ ‌at‌ ‌the‌ ‌completed‌ ‌application‌ ‌and‌ ‌showing‌ ‌off‌ ‌all‌ ‌the‌ ‌features‌‌ implemented.‌ ‌After‌ ‌this,‌ ‌I‌ ‌explain‌ ‌the‌ ‌roles‌ ‌I‌ ‌served‌ ‌on‌ ‌the‌ ‌team‌ ‌as‌ ‌the‌ ‌database‌ ‌designer,‌ ‌a‌‌ backend‌ ‌developer,‌ ‌the‌ ‌backend‌ ‌quality‌ ‌engineer,‌ ‌and‌ ‌the‌ ‌public‌ ‌website‌ ‌designer‌ ‌and‌ ‌explain‌‌ how‌‌I‌‌contributed‌‌to‌‌the‌‌final‌‌product‌‌in‌‌each‌‌of‌‌these‌‌roles.‌‌After‌‌this,‌‌I‌‌break‌‌down‌‌our‌‌design‌‌ decisions‌ ‌and‌ ‌analyze‌ ‌which‌ ‌decisions‌ ‌worked‌ ‌well‌ ‌and‌ ‌which‌ ‌did‌ ‌not‌ ‌and‌ ‌explain‌ ‌my‌‌ recommended‌‌design‌‌decision‌‌changes‌‌were‌‌we‌‌to‌‌develop‌‌the‌‌application‌‌from‌‌scratch‌‌again.‌‌ ‌ ii‌ ‌ ‌ Next,‌ ‌I‌ ‌explain‌ ‌the‌ ‌future‌ ‌of‌ ‌Hestia‌ ‌after‌ ‌this‌ ‌semester.‌ ‌The‌ ‌current‌ ‌plan‌ ‌is‌‌to‌‌maintain‌‌ ownership‌ ‌of‌ ‌the‌ ‌code‌ ‌but‌ ‌not‌ ‌release‌ ‌the‌ ‌application‌ ‌yet‌ ‌because‌ ‌our‌ ‌team‌ ‌has‌ ‌to‌ ‌commit‌ ‌to‌‌ maintaining‌‌and‌‌improving‌‌the‌‌application‌‌once‌‌it‌‌is‌‌released‌‌if‌‌we‌‌want‌‌it‌‌to‌‌be‌‌successful.‌‌We‌‌ as‌‌a‌‌team‌‌have‌‌decided‌‌to‌‌take‌‌a‌‌break‌‌from‌‌development‌‌after‌‌this‌‌semester‌‌but‌‌in‌‌the‌‌future,‌‌we‌‌ plan‌ ‌on‌ ‌continuing‌‌work‌‌on‌‌Hestia‌‌and‌‌releasing‌‌it‌‌at‌‌that‌‌point.‌‌We‌‌have‌‌already‌‌brainstormed‌‌ additional‌‌features‌‌we‌‌would‌‌like‌‌to‌‌add‌‌to‌‌the‌‌application‌‌in‌‌the‌‌future.‌ ‌ Overall,‌ ‌our‌ ‌team‌ ‌is‌ ‌very‌ ‌proud‌ ‌of‌ ‌what‌ ‌we‌ ‌have‌ ‌accomplished‌ ‌with‌ ‌the‌ ‌Hestia‌‌ application.‌‌We‌‌feel‌‌like‌‌this‌‌application‌‌could‌‌make‌‌household‌‌management‌‌easier‌‌for‌‌any‌‌user.‌‌ We‌‌hope‌‌that‌‌Hestia‌‌can‌‌be‌‌released‌‌to‌‌the‌‌general‌‌public‌‌shortly‌‌and‌‌help‌‌make‌‌a‌‌difference‌‌in‌‌ their‌ ‌lives.‌ ‌Keep‌ ‌on‌ ‌the‌ ‌lookout‌ ‌for‌ ‌the‌ ‌future‌ ‌release‌‌of‌‌Hestia,‌‌the‌‌one-stop-shop‌‌for‌‌all‌‌your‌‌ home‌‌management‌‌needs.‌ ‌ iii‌ ‌ ‌ TABLE‌‌OF‌‌CONTENTS‌ ‌ ABSTRACT‌‌…………………………………………....………………………………..……….‌ii‌ ‌ 1‌‌INTRODUCTION‌ ‌………………………………………....………………………………….‌ 1‌ ‌ ‌1.1‌‌Design‌‌Decisions‌‌in‌‌Computer‌‌Science‌ ‌………………………………………....……….‌‌1‌ ‌ ‌1.1.1‌‌Team‌‌Structure‌‌Decisions‌ ‌………………………………..…………………………‌ 1‌ ‌ ‌1.1.2‌‌Code‌‌Structure‌‌Decisions‌ ‌………………………………………....………………..‌ 7‌ ‌ ‌1.1.3‌‌Code‌‌Implementation‌‌Decisions‌‌………………………………………....………...‌ 11‌ ‌ ‌1.2‌‌What‌‌is‌‌Hestia‌‌………………………………………....……………………….………..‌ 16‌ ‌ 2‌‌METHODS‌ ‌…………………………………………....………………………………….….‌ 20‌ ‌ ‌2.1‌‌Team‌‌Structure‌‌Decisions‌‌for‌‌Hestia‌‌………………………………………..……….….‌ 20‌ ‌ ‌2.2‌‌Code‌‌Structure‌‌Decisions‌‌for‌‌Hestia‌‌……………………………………………..…...…‌24‌ ‌ ‌2.3‌‌Code‌‌Implementation‌‌Decisions‌‌for‌‌Hestia‌‌………………………………………....…..‌ ‌28‌ ‌ 3‌‌TIMELINE‌‌…………………………………………....………………………………..……..‌‌33‌ ‌ ‌3.1‌‌Weeks‌‌1-4:‌‌Idea‌‌Pitch‌‌and‌‌Team‌‌Formation‌‌……………………………………....…….‌ 33‌ ‌ ‌3.2‌‌Weeks‌‌5-8:‌‌Project‌‌Refinement‌ ‌…………………………………………....……………‌‌34‌ ‌ ‌3.3‌‌Weeks‌‌9-15:‌‌Prototype‌‌Development‌ ‌…………………………………………....……...‌34‌ ‌ ‌3.4‌‌Weeks‌‌16-20:‌‌Alpha‌‌Release‌‌..…………………………………………....……………...‌36‌ ‌ ‌3.5‌‌Weeks‌‌21-24:‌‌Beta‌‌Release‌‌..…………………………………………....……………….‌36‌ ‌ ‌3.6‌‌Weeks‌‌25-30:‌‌Final‌‌Release‌‌..…………………………………………....………………‌37‌ ‌ 4‌‌RESULTS‌‌…………………………………………....………………………………..………‌38‌ ‌ ‌4.1‌‌Account‌‌Creation‌‌and‌‌Log‌‌In‌ ‌…………………………………………....……………...‌40‌ ‌ ‌4.2‌‌The‌‌Household‌‌Invitation‌‌System‌‌and‌‌Household‌‌Settings‌‌Page‌‌………....……………..‌43‌ ‌ ‌4.3‌‌The‌‌Home‌‌Page‌‌Dashboard‌‌……………………....………………………………..…….‌48‌ ‌ ‌4.4‌‌Budgets‌‌.……………………………………....………………………………..………...‌49‌ ‌ ‌4.5‌‌The‌‌To-do‌‌List‌‌………………………………....………………………………..……….‌51‌ ‌ ‌4.6‌‌The‌‌Calendar‌‌…………………………………....……………………………..…………‌53‌ ‌ ‌4.7‌‌The‌‌Household‌‌Recipe‌‌Book‌‌and‌‌Meal‌‌Planning‌‌..……………………………..………..‌55‌ ‌ ‌ ‌ ‌4.8‌‌The‌‌Grocery‌‌List‌‌…………………………....……………………………..…………….‌ 58‌ ‌ 5‌‌INDIVIDUAL‌‌CONTRIBUTIONS‌‌…………....……………………………..………………‌60‌ ‌ ‌5.1‌‌Designer‌‌and‌‌Maintainer‌‌of‌‌the‌‌Main‌‌Hestia‌‌Database…………....……………………..‌60‌ ‌ ‌5.2‌‌Backend‌‌Web‌‌API‌‌Developer‌‌……………....……………………………..…………….‌ ‌67‌ ‌ ‌5.3‌‌Quality‌‌Engineer‌‌(QE)‌‌for‌‌the‌‌Backend‌‌Web‌‌API‌‌…………………………..…………..‌69‌ ‌ ‌5.4‌‌Public‌‌Facing‌‌Website‌‌Designer‌‌…………....……………………………..……………..‌70‌ ‌ 6‌‌ANALYSIS‌ ‌…………………………....……………………………..……………...………..‌72‌ ‌ ‌6.1‌‌Team‌‌Structure‌‌Decisions‌‌Retrospective‌‌…………………………..……………...……..‌72‌ ‌ ‌6.2‌‌Code‌‌Structure‌‌Decisions‌‌Retrospective‌‌…………………………..……………...……..‌74‌ ‌ ‌6.3‌‌Code‌‌Implementation‌‌Decisions‌‌Retrospective‌‌……………………..……………...…..‌ 76‌ ‌ 7‌‌FUTURE‌‌DEVELOPMENT‌‌…………....……………………………..……………...……...‌ ‌82‌ ‌ 8‌‌CONCLUSION‌‌………………………....……………………………..……………...………‌85‌ ‌ 9‌‌REFERENCES‌‌………………………....……………………………..……………...……….‌90‌ ‌ 10‌‌APPENDIX‌‌………………………....……………………………..……………...………….‌94‌ ‌ ‌10.1‌‌API‌‌Endpoints‌‌Spec‌‌..……………………………..……………...……………………..‌94‌ ‌ ‌10.2‌‌Original‌‌Hestia‌‌Design‌‌Document‌‌..……………………………..……………...………‌98‌ ‌ ‌ ‌ ‌ v‌ ‌ 1‌ ‌ 1‌‌INTRODUCTION‌ ‌ 1.1‌‌ Design‌‌Decisions‌‌in‌‌Software‌‌Development‌ ‌ When‌‌designing‌‌a‌‌large-scale‌‌software‌‌application‌‌many‌‌design‌‌decisions‌‌must‌‌be‌‌made‌‌ before‌‌development‌‌work‌‌even‌‌begins.‌‌These‌‌decisions‌‌can‌‌make‌‌or‌‌break‌‌the‌‌entire‌‌application‌‌ because‌ ‌they‌ ‌create‌ ‌the‌ ‌entire‌ ‌foundation‌ ‌on‌ ‌which‌ ‌the‌ ‌code‌ ‌is‌ ‌developed.‌ ‌They‌ ‌will‌ ‌help‌‌ determine‌ ‌the‌ ‌success‌ ‌of‌ ‌the‌‌code‌‌at‌‌the‌‌first‌‌release‌‌and‌‌all‌‌future‌‌releases‌‌of‌‌the‌‌product.‌‌Our‌‌ team‌ ‌divided‌ ‌these‌ ‌decisions‌ ‌into‌ ‌three‌ ‌main‌ ‌categories‌ ‌that‌ ‌encompassed‌ ‌all‌ ‌the‌ ‌necessary‌‌ pre-development‌‌decisions‌‌that‌‌had‌‌to‌‌be‌‌made‌‌for‌‌our‌‌project.‌‌First,‌‌there‌‌are‌‌the‌‌team‌‌structure‌‌ decisions.‌ ‌These‌ ‌determine‌ ‌how‌ ‌the‌ ‌team‌ ‌of‌ ‌developers‌ ‌will‌ ‌be‌ ‌organized‌ ‌and‌ ‌operate.‌ ‌Next,‌‌ there‌ ‌are‌ ‌code‌ ‌structure‌ ‌decisions‌ ‌that‌ ‌determine‌ ‌how‌ ‌the‌ ‌code‌ ‌itself‌ ‌will‌ ‌be‌ ‌organized.‌ ‌These‌‌ types‌ ‌of‌ ‌decisions‌ ‌include‌ ‌how‌ ‌individual‌ ‌features‌ ‌of‌ ‌the‌ ‌code‌ ‌should‌ ‌be‌‌structured‌‌to‌‌interact‌ with‌ ‌one‌ ‌another‌ ‌and‌ ‌how‌ ‌the‌ ‌code‌‌should‌‌be‌‌deployed‌‌so‌‌that‌‌users‌‌can‌‌use‌‌it‌‌without‌‌having‌‌ access‌ ‌to‌ ‌the‌ ‌source‌ ‌code.‌ ‌Lastly,‌ ‌there‌ ‌are‌ ‌implementation‌ ‌decisions‌ ‌that‌ ‌determine‌ ‌the‌‌ individual‌ ‌coding‌ ‌languages‌ ‌and‌ ‌frameworks‌ ‌and‌ ‌the‌ ‌type‌ ‌of‌ ‌database‌ ‌that‌ ‌will‌ ‌be‌ ‌used‌ ‌to‌‌ implement‌‌the‌‌project.‌‌My‌‌team‌‌wanted‌‌to‌‌make‌‌Hestia‌‌an‌‌all-encompassing‌‌home‌‌management‌‌ application.‌ ‌It‌ ‌was‌ ‌these‌ ‌pre-development‌ ‌design‌ ‌decisions‌ ‌that‌ ‌would‌ ‌help‌ ‌determine‌ ‌the‌‌ successfulness‌‌of‌‌our‌‌development‌‌approach,‌‌which‌‌help‌‌determine‌‌how‌‌great‌‌of‌‌a‌‌final‌‌product‌‌ Hestia‌ ‌would‌ ‌be.‌ ‌Before‌ ‌discussing‌ ‌our‌ ‌individual‌ ‌decisions‌‌for‌‌Hestia‌‌it‌‌is‌‌valuable‌‌to‌‌look‌‌at‌‌ how‌ ‌these‌ ‌decisions‌ ‌are‌ ‌made‌ ‌in‌ ‌general‌ ‌for‌ ‌large-scale‌ ‌software‌‌systems,‌‌which‌‌served‌‌as‌‌the‌‌ starting‌‌point‌‌for‌‌our‌‌team‌‌as‌‌we‌‌made‌‌our‌‌design‌‌decisions.‌ ‌ 1.1.1‌‌ Team‌‌Structure‌‌Decisions‌ ‌ Modern‌ ‌software‌ ‌systems‌ ‌are‌‌large‌‌and‌‌complex.‌‌This‌‌complexity‌‌means‌‌it‌‌is‌‌infeasible‌‌ for‌‌one‌‌developer‌‌to‌‌design‌‌the‌‌entire‌‌system‌‌by‌‌themselves,‌‌which‌‌means‌‌that‌‌a‌‌team‌‌is‌‌almost‌ ‌ 2‌ ‌ always‌ ‌required.‌ ‌Therefore,‌ ‌establishing‌ ‌team‌ ‌dynamics‌ ‌before‌ ‌development‌ ‌work‌ ‌begins‌ ‌is‌‌ essential‌‌in‌‌creating‌‌a‌‌successful‌‌product.‌‌ ‌ A‌ ‌key‌ ‌component‌ ‌of‌ ‌this‌ ‌is‌ ‌determining‌ ‌the‌ ‌role‌ ‌of‌ ‌each‌‌team‌‌member.‌‌This‌‌lets‌‌every‌‌ team‌ ‌member‌ ‌know‌ ‌what‌ ‌tasks‌ ‌they‌ ‌are‌ ‌responsible‌ ‌for‌ ‌and‌ ‌how‌ ‌the‌ ‌work‌ ‌should‌ ‌be‌ ‌divided‌‌ between‌ ‌the‌ ‌members.‌ ‌Overall,‌ ‌every‌ ‌web‌ ‌developer‌ ‌can‌ ‌be‌ ‌classified‌ ‌into‌ ‌one‌‌of‌‌three‌‌types:‌‌ front-end,‌‌back-end,‌‌or‌‌full-stack.‌ ‌ First,‌‌there‌‌are‌‌front-end‌‌developers‌‌who‌‌are‌‌responsible‌‌for‌‌everything‌‌the‌‌user‌‌sees‌‌and‌‌ interacts‌‌with.‌‌These‌‌developers‌‌are‌‌responsible‌‌for‌‌designing‌‌all‌‌the‌‌application‌‌pages‌‌to‌‌ensure‌‌ the‌ ‌correct‌ ‌information‌ ‌is‌ ‌shown‌ ‌to‌ ‌the‌ ‌user‌ ‌in‌ ‌a‌‌visually‌‌appealing‌‌way.‌‌Their‌‌responsibilities‌‌ include‌‌creating‌‌links‌‌to‌‌redirect‌‌you‌‌from‌‌one‌‌part‌‌of‌‌the‌‌application‌‌to‌‌another,‌‌determining‌‌the‌‌ colors‌ ‌shown‌ ‌on‌ ‌the‌ ‌pages,‌ ‌determining‌ ‌font‌ ‌and‌ ‌font‌ ‌size‌ ‌for‌ ‌text,‌ ‌and‌ ‌creating‌ ‌data‌‌ representations‌ ‌that‌ ‌make‌ ‌the‌ ‌data‌ ‌easily‌ ‌understandable‌ ‌for‌ ‌the‌ ‌user‌ ‌(Wales,‌ ‌2020).‌ ‌Thus,‌ ‌a‌‌ front-end‌ ‌developer‌ ‌for‌ ‌Google‌ ‌might‌ ‌be‌ ‌responsible‌ ‌for‌ ‌writing‌ ‌code‌ ‌for‌‌the‌‌web‌‌page‌‌layout‌‌ and‌ ‌displaying‌ ‌the‌ ‌search‌ ‌results,‌ ‌and‌ ‌they‌ ‌would‌ ‌not‌ ‌be‌ ‌responsible‌ ‌for‌ ‌writing‌ ‌the‌ ‌code‌ ‌that‌‌ retrieves‌‌the‌‌search‌‌results.‌ ‌ Then‌ ‌there‌ ‌are‌ ‌back-end‌ ‌developers‌‌responsible‌‌for‌‌all‌‌data‌‌storage‌‌and‌‌retrieval.‌‌These‌‌ developers‌‌must‌‌create‌‌a‌‌data‌‌storage‌‌system‌‌that‌‌allows‌‌the‌‌user-facing‌‌part‌‌of‌‌the‌‌application‌‌to‌‌ exist‌ ‌because‌ ‌without‌ ‌storing‌ ‌the‌ ‌application‌ ‌data‌ ‌and‌ ‌information‌ ‌there‌ ‌would‌ ‌be‌ ‌nothing‌ ‌to‌‌ show‌ ‌on‌ ‌the‌‌application‌‌pages.‌‌Backend‌‌developers‌‌are‌‌also‌‌responsible‌‌for‌‌the‌‌database‌‌which‌‌ stores‌ ‌structured‌ ‌information‌ ‌in‌ ‌tables‌ ‌using‌ ‌rows‌ ‌and‌ ‌columns‌ ‌which‌ ‌makes‌ ‌information‌‌ retrieval‌ ‌as‌ ‌efficient‌ ‌as‌ ‌possible‌ ‌(“What‌ ‌is‌ ‌a‌ ‌database?”,‌ ‌n.d.).‌ ‌For‌ ‌example,‌ ‌a‌ ‌University’s‌‌ database‌ ‌may‌ ‌include‌ ‌a‌ ‌student‌ ‌table‌ ‌with‌ ‌columns‌ ‌representing‌ ‌a‌ ‌student's‌‌university‌‌ID,‌‌first‌‌ name,‌‌last‌‌name,‌‌and‌‌date‌‌of‌‌birth.‌‌Then,‌‌each‌‌row‌‌in‌‌the‌‌table‌‌would‌‌represent‌‌a‌‌single‌‌student‌‌ ‌ 3‌ ‌ with‌ ‌their‌ ‌ID,‌ ‌first‌ ‌name,‌ ‌last‌ ‌name,‌ ‌and‌ ‌date‌ ‌of‌ ‌birth‌ ‌listed‌ ‌in‌ ‌that‌ ‌row.‌ ‌Some‌ ‌of‌ ‌the‌‌ responsibilities‌ ‌of‌ ‌a‌ ‌back-end‌ ‌developer‌ ‌include‌ ‌data‌ ‌storage‌ ‌and‌ ‌retrieval‌ ‌through‌‌ communication‌ ‌with‌ ‌the‌ ‌database,‌‌setting‌‌up‌‌a‌‌way‌‌for‌‌the‌‌front-end‌‌developer‌‌to‌‌easily‌‌access‌‌ the‌ ‌information,‌ ‌and‌ ‌ensuring‌ ‌information‌ ‌is‌ ‌stored‌ ‌securely‌ ‌through‌ ‌data‌ ‌encryption‌ ‌(Wales,‌‌ 2020).‌ ‌Therefore,‌ ‌a‌ ‌back-end‌‌developer‌‌at‌‌Google‌‌may‌‌be‌‌responsible‌‌for‌‌writing‌‌the‌‌code‌‌that‌‌ connects‌ ‌to‌ ‌the‌ ‌database,‌ ‌retrieves‌ ‌the‌ ‌search‌ ‌results,‌ ‌and‌ ‌gives‌ ‌the‌‌results‌‌to‌‌the‌‌front-end‌‌but‌‌ would‌‌not‌‌be‌‌responsible‌‌for‌‌writing‌‌the‌‌code‌‌that‌‌displays‌‌the‌‌search‌‌results‌‌for‌‌the‌‌user.‌‌ ‌ Lastly,‌ ‌there‌ ‌are‌ ‌full-stack‌ ‌developers‌ ‌whose‌ ‌responsibilities‌ ‌are‌ ‌not‌ ‌limited‌ ‌to‌ ‌just‌‌ front-end‌ ‌or‌ ‌back-end‌ ‌tasks.‌ ‌Instead,‌ ‌a‌ ‌full-stack‌ ‌developer‌ ‌is‌‌responsible‌‌for‌‌all‌‌aspects‌‌of‌‌the‌‌ application‌ ‌and‌ ‌is‌ ‌comfortable‌ ‌writing‌ ‌code‌ ‌for‌ ‌either‌ ‌frontend‌ ‌or‌ ‌backend‌ ‌tasks‌ ‌because‌‌ oftentimes‌ ‌there‌ ‌is‌ ‌not‌ ‌a‌ ‌clear‌ ‌distinction‌ ‌between‌ ‌them.‌ ‌This‌ ‌developer‌ ‌role‌ ‌which‌ ‌was‌‌ popularized‌ ‌by‌ ‌the‌ ‌Facebook‌ ‌Engineering‌ ‌department‌ ‌means‌ ‌that‌ ‌developer‌ ‌must‌ ‌be‌ ‌a‌‌ jack-of-all-trades‌ ‌who‌ ‌is‌ ‌capable‌ ‌of‌ ‌working‌ ‌on‌‌any‌‌aspect‌‌of‌‌the‌‌application‌‌(Wales,‌‌2020).‌‌A‌‌ front-end‌‌developer‌‌may‌‌work‌‌on‌‌a‌‌front-end‌‌task‌‌one‌‌week‌‌and‌‌a‌‌back-end‌‌task‌‌the‌‌next,‌‌or‌‌may‌‌ even‌ ‌work‌ ‌on‌ ‌a‌ ‌task‌ ‌that‌ ‌involves‌‌working‌‌on‌‌both‌‌at‌‌the‌‌same‌‌time.‌‌For‌‌example,‌‌a‌‌full-stack‌‌ developer‌‌at‌‌google‌‌may‌‌be‌‌working‌‌on‌‌retrieving‌‌search‌‌results‌‌and‌‌displaying‌‌search‌‌results‌‌to‌‌ the‌‌user.‌ ‌ While‌ ‌there‌ ‌are‌ ‌more‌‌specific‌‌roles,‌‌every‌‌role‌‌can‌‌be‌‌simplified‌‌into‌‌one‌‌of‌‌these‌‌three‌‌ categories.‌ ‌Therefore,‌ ‌an‌ ‌important‌ ‌aspect‌ ‌of‌ ‌team‌‌dynamics‌‌is‌‌determining‌‌how‌‌many‌‌of‌‌each‌‌ type‌ ‌of‌ ‌developer‌ ‌is‌‌needed‌‌for‌‌your‌‌application.‌‌The‌‌2020‌‌StackOverflow‌‌developer‌‌survey‌‌of‌‌ over‌ ‌60k‌ ‌developers‌ ‌showed‌ ‌that‌ ‌25.2%‌ ‌are‌ ‌front-end‌ ‌developers,‌ ‌37.5%‌ ‌are‌ ‌back-end‌‌ developers,‌ ‌and‌ ‌37.3%‌ ‌are‌ ‌full-stack‌ ‌(when‌ ‌you‌ ‌adjust‌ ‌for‌ ‌some‌ ‌developers‌ ‌having‌ ‌multiple‌‌ roles).‌ ‌(”Stack‌ ‌Overflow”,‌ ‌n.d.)‌ ‌Thus‌ ‌we‌ ‌see‌ ‌that‌ ‌there‌ ‌is‌ ‌a‌ ‌pretty‌ ‌even‌‌spread‌‌for‌‌all‌‌types‌‌of‌‌ ‌ 4‌ ‌ developers.‌‌The‌‌number,‌‌or‌‌percentage,‌‌of‌‌developers‌‌you‌‌need‌‌in‌‌each‌‌role‌‌varies‌‌depending‌‌on‌‌ the‌‌goals‌‌of‌‌your‌‌application‌‌and‌‌the‌‌developers‌‌available.‌‌By‌‌tailoring‌‌the‌‌number‌‌of‌‌each‌‌type‌‌ of‌ ‌developer‌ ‌to‌ ‌your‌ ‌application‌ ‌it‌ ‌allows‌ ‌each‌ ‌team‌ ‌member‌ ‌to‌ ‌always‌ ‌have‌ ‌something‌ ‌to‌‌do‌‌ without‌ ‌being‌ ‌overwhelmed.‌ ‌This‌ ‌has‌ ‌the‌ ‌effect‌ ‌of‌ ‌increasing‌ ‌the‌ ‌efficiency‌ ‌of‌ ‌the‌ ‌team‌ ‌and‌‌ helps‌‌ensure‌‌the‌‌team‌‌will‌‌stay‌‌on‌‌track‌‌with‌‌the‌‌development‌‌timeline‌‌(when‌‌you‌‌want‌‌to‌‌release‌‌ certain‌ ‌features‌‌of‌‌your‌‌application).‌‌Therefore,‌‌determining‌‌the‌‌correct‌‌number‌‌of‌‌each‌‌type‌‌of‌‌ developer‌‌needed‌‌is‌‌necessary‌‌to‌‌create‌‌a‌‌successful‌‌team‌‌to‌‌create‌‌the‌‌desired‌‌application.‌ ‌ Another‌ ‌essential‌ ‌aspect‌ ‌of‌ ‌team‌ ‌dynamics‌ ‌is‌ ‌how‌ ‌the‌ ‌team‌ ‌should‌ ‌be‌ ‌structured‌ ‌to‌‌ perform‌ ‌work‌ ‌to‌ ‌complete‌ ‌the‌ ‌application.‌ ‌The‌ ‌two‌ ‌methodologies‌ ‌commonly‌ ‌used‌ ‌for‌ ‌this‌‌ purpose‌‌are‌‌waterfall‌‌and‌‌agile,‌‌each‌‌having‌‌its‌‌pros‌‌and‌‌cons.‌ ‌ In‌ ‌the‌ ‌waterfall‌ ‌approach,‌ ‌shown‌ ‌in‌ ‌Fig‌ ‌1,‌ ‌you‌ ‌have‌ ‌five‌ ‌main‌‌phases‌‌of‌‌development:‌‌ requirements,‌‌design,‌‌implementation,‌‌verification,‌‌and‌‌maintenance.‌‌In‌‌the‌‌requirements‌‌phase,‌‌ you‌ ‌determine‌ ‌the‌ ‌requirements‌ ‌for‌ ‌the‌ ‌application,‌ ‌essentially‌ ‌deciding‌ ‌what‌ ‌you‌ ‌want‌ ‌your‌‌ application‌‌to‌‌do.‌‌Then,‌‌in‌‌the‌‌design‌‌phase,‌‌you‌‌construct‌‌mock-ups‌‌of‌‌the‌‌design‌‌and‌‌determine‌ how‌ ‌you‌ ‌want‌ ‌individual‌ ‌components‌ ‌to‌ ‌function,‌ ‌deciding‌ ‌what‌ ‌coding‌ ‌languages‌ ‌and‌‌ frameworks‌ ‌to‌ ‌use‌ ‌in‌ ‌development.‌ ‌Next,‌ ‌in‌‌the‌‌implementation‌‌phase,‌‌you‌‌create‌‌the‌‌code‌‌for‌‌ the‌‌application‌‌based‌‌on‌‌the‌‌design‌‌decisions.‌‌From‌‌here,‌‌you‌‌move‌‌into‌‌verifying‌‌the‌‌code‌‌and‌‌ testing‌‌it‌‌to‌‌ensure‌‌its‌‌correct‌‌operation.‌‌Then,‌‌at‌‌the‌‌last‌‌phase,‌‌you‌‌deploy‌‌the‌‌code‌‌and‌‌deliver‌‌ the‌‌final‌‌product.‌‌This‌‌final‌‌phase‌‌is‌‌named‌‌maintenance‌‌because‌‌you‌‌must‌‌maintain‌‌the‌‌code‌‌to‌‌ ensure‌ ‌it‌ ‌continues‌ ‌behaving‌ ‌as‌ ‌intended.‌ ‌In‌ ‌the‌ ‌waterfall‌ ‌approach,‌ ‌each‌ ‌of‌ ‌the‌ ‌5‌ ‌phases‌ ‌is‌‌ structured‌ ‌so‌ ‌that‌ ‌each‌ ‌phase‌ ‌sequentially‌ ‌cascades‌ ‌into‌ ‌the‌ ‌next‌ ‌like‌ ‌a‌ ‌waterfall‌‌(Lotz,‌‌2018).‌‌ This‌ ‌philosophy‌ ‌means‌ ‌that‌ ‌you‌‌determine‌‌the‌‌requirements‌‌of‌‌your‌‌system‌‌once‌‌at‌‌the‌‌start‌‌of‌‌ the‌‌project.‌‌Then,‌‌you‌‌seek‌‌to‌‌deliver‌‌a‌‌product‌‌that‌‌meets‌‌all‌‌these‌‌original‌‌requirements.‌ ‌ ‌ 5‌ ‌ ‌ Fig.‌‌1‌‌-‌‌The‌‌Waterfall‌‌Methodology‌‌Diagram‌‌(Hughey‌‌2009)‌ ‌ The‌ ‌Waterfall‌ ‌approach‌‌differs‌‌from‌‌the‌‌Agile‌‌approach‌‌shown‌‌in‌‌Fig‌‌2.‌‌which‌‌contains‌‌ six‌ ‌repeating‌ ‌phases‌ ‌of‌ ‌development:‌ ‌requirements,‌ ‌design,‌ ‌development,‌ ‌testing,‌ ‌deployment,‌‌ and‌ ‌review.‌ ‌In‌ ‌the‌ ‌requirements‌ ‌phase,‌ ‌you‌‌determine‌‌the‌‌requirements‌‌for‌‌a‌‌single‌‌portion‌‌of‌‌ the‌‌application,‌‌essentially‌‌deciding‌‌what‌‌you‌‌want‌‌that‌‌single‌‌feature‌‌of‌‌your‌‌application‌‌to‌‌do.‌‌ Then,‌‌in‌‌the‌‌design‌‌phase,‌‌you‌‌construct‌‌mock-ups‌‌of‌‌the‌‌design‌‌and‌‌determine‌‌how‌‌you‌‌want‌‌to‌‌ implement‌ ‌that‌ ‌feature‌ ‌of‌ ‌the‌ ‌application.‌ ‌This‌ ‌includes‌ ‌making‌ ‌decisions‌ ‌about‌ ‌the‌ ‌coding‌‌ languages‌ ‌and‌ ‌frameworks‌ ‌to‌ ‌use‌‌for‌‌development.‌‌Next,‌‌in‌‌the‌‌development‌‌phase,‌‌you‌‌create‌‌ the‌‌code‌‌for‌‌the‌‌application‌‌based‌‌on‌‌the‌‌design‌‌decisions.‌‌From‌‌here,‌‌you‌‌move‌‌into‌‌the‌‌testing‌‌ phase,‌ ‌where‌ ‌you‌ ‌test‌ ‌the‌ ‌code‌ ‌to‌ ‌ensure‌ ‌its‌ ‌correct‌ ‌operation.‌ ‌Then,‌ ‌at‌ ‌the‌ ‌deploy‌‌phase,‌‌you‌‌ deploy‌ ‌the‌ ‌code‌ ‌making‌ ‌sure‌ ‌that‌ ‌the‌ ‌new‌ ‌feature‌‌is‌‌working‌‌as‌‌intended.‌‌Lastly,‌‌is‌‌the‌‌review‌‌ phase,‌ ‌which‌ ‌involves‌ ‌having‌ ‌the‌ ‌code‌ ‌owner‌ ‌review‌ ‌the‌ ‌changes‌ ‌to‌‌ensure‌‌that‌‌they‌‌meet‌‌the‌‌ standard‌ ‌expected.‌ ‌After‌ ‌this,‌ ‌the‌ ‌team‌ ‌moves‌‌back‌‌into‌‌the‌‌requirements‌‌phase‌‌and‌‌begins‌‌the‌‌ entire‌‌process‌‌again.‌‌While‌‌the‌‌phases‌‌in‌‌the‌‌Agile‌‌methodology‌‌are‌‌very‌‌similar‌‌to‌‌the‌‌phases‌‌in‌‌ ‌ 6‌ ‌ the‌‌Waterfall‌‌methodology‌‌the‌‌main‌‌difference‌‌is‌‌that‌‌it‌‌is‌‌not‌‌structured‌‌to‌‌take‌‌the‌‌entire‌‌project‌‌ on‌ ‌at‌ ‌once‌ ‌and‌ ‌is‌ ‌an‌ ‌iterative‌ ‌development‌‌pattern‌‌instead‌‌of‌‌a‌‌sequential‌‌pattern‌‌(Lotz.‌‌2018).‌‌ This‌‌pattern‌‌means‌‌that‌‌each‌‌development‌‌cycle‌‌(one‌‌iteration‌‌of‌‌each‌‌phase)‌ ‌is‌‌a‌‌single‌‌“sprint”‌‌ in‌‌which‌‌one‌‌small‌‌portion‌‌of‌‌the‌‌application‌‌gets‌‌prioritized‌‌and‌‌developed.‌‌At‌‌the‌‌start‌‌of‌‌each‌‌ sprint,‌‌requirements‌‌are‌‌re-analyzed,‌‌which‌‌allows‌‌for‌‌changes‌‌in‌‌application‌‌design‌‌on‌‌the‌‌fly‌‌as‌‌ the‌ ‌need‌ ‌to‌ ‌tweak‌ ‌the‌ ‌application‌ ‌behavior‌ ‌arises.‌ ‌These‌ ‌tweaks‌ ‌may‌ ‌come‌ ‌from‌ ‌a‌ ‌customer‌‌ requesting‌ ‌an‌ ‌additional‌ ‌feature‌ ‌or‌ ‌the‌ ‌realization‌ ‌the‌ ‌original‌ ‌idea‌ ‌for‌ ‌the‌ ‌application‌ ‌is‌‌ infeasible‌‌to‌‌develop‌‌given‌‌the‌‌current‌‌development‌‌time‌‌frame.‌‌Therefore,‌‌the‌‌Agile‌‌framework‌‌ allows‌ ‌for‌ ‌partial‌ ‌completion‌ ‌of‌ ‌the‌ ‌application‌ ‌instead‌ ‌of‌ ‌the‌ ‌all-or-nothing‌ ‌approach‌ ‌of‌ ‌the‌‌ Waterfall‌‌framework.‌ ‌ ‌ Fig.‌‌2‌‌-‌‌The‌‌Agile‌‌Methodology‌‌Diagram‌‌(Okeke,‌‌2021)‌ ‌ The‌ ‌waterfall‌ ‌framework‌ ‌has‌ ‌been‌‌the‌‌traditional‌‌approach‌‌for‌‌a‌‌long‌‌time‌‌but‌‌the‌‌agile‌‌ framework‌ ‌has‌‌quickly‌‌become‌‌the‌‌dominant‌‌development‌‌framework.‌‌In‌‌a‌‌study‌‌that‌‌surveyed‌‌ over‌‌600‌‌software‌‌developers‌‌and‌‌IT‌‌professionals,‌‌67%‌‌of‌‌respondents‌‌said‌‌that‌‌they‌‌either‌‌use‌‌ ‌ 7‌ ‌ a‌‌pure‌‌agile‌‌framework‌‌or‌‌leaned‌‌towards‌‌an‌‌agile‌‌framework‌‌as‌‌opposed‌‌to‌‌only‌‌9%‌‌that‌‌use‌‌a‌‌ pure‌ ‌waterfall‌ ‌framework‌ ‌or‌ ‌leaned‌ ‌towards‌ ‌a‌ ‌waterfall‌ ‌framework,‌ ‌and‌ ‌the‌ ‌other‌ ‌24%‌ ‌used‌‌a‌‌ hybrid‌ ‌approach‌ ‌(Jeremiah,‌ ‌2019).‌ ‌Although‌ ‌the‌ ‌Agile‌ ‌framework‌ ‌has‌ ‌become‌ ‌the‌ ‌dominant‌‌ development‌‌framework‌‌there‌‌are‌‌still‌‌pros‌‌and‌‌cons‌‌to‌‌each‌‌approach.‌‌The‌‌benefits‌‌of‌‌the‌‌Agile‌‌ framework‌ ‌are‌ ‌that‌ ‌it‌ ‌leads‌ ‌to‌ ‌a‌ ‌faster‌ ‌software‌ ‌development‌ ‌timeline‌ ‌because‌ ‌of‌ ‌the‌ ‌sprint‌‌ structure,‌ ‌it‌ ‌is‌ ‌very‌ ‌flexible‌ ‌to‌ ‌changing‌ ‌demands,‌ ‌and‌ ‌it‌ ‌promotes‌ ‌team‌ ‌member‌ ‌interactions.‌‌ However,‌ ‌some‌ ‌of‌ ‌the‌ ‌disadvantages‌ ‌of‌ ‌the‌ ‌Agile‌ ‌framework‌ ‌are‌ ‌that‌ ‌it‌ ‌requires‌ ‌constant‌‌ dedication‌ ‌from‌ ‌all‌ ‌team‌ ‌members‌ ‌for‌ ‌development,‌ ‌requirements‌ ‌are‌‌constantly‌‌changing‌‌that‌‌ often‌ ‌leads‌ ‌to‌ ‌increased‌ ‌development‌ ‌time,‌ ‌and‌ ‌it‌ ‌requires‌ ‌extensive‌ ‌team‌ ‌communication‌ ‌to‌‌ work.‌‌In‌‌contrast,‌‌the‌‌pros‌‌of‌‌the‌‌waterfall‌‌framework‌‌are‌‌that‌‌it‌‌lays‌‌out‌‌a‌‌very‌‌defined‌‌scope‌‌of‌‌ work‌ ‌which‌ ‌allows‌ ‌for‌ ‌clearer‌ ‌measurements‌ ‌of‌ ‌progress,‌‌it‌‌has‌‌more‌‌straightforward‌‌planning‌‌ since‌‌requirements‌‌are‌‌only‌‌reviewed‌‌at‌‌the‌‌start‌‌of‌‌the‌‌project‌‌instead‌‌of‌‌at‌‌every‌‌iteration‌‌of‌‌the‌‌ project,‌‌and‌‌it‌‌allows‌‌for‌‌more‌‌clearly‌‌defined‌‌team‌‌roles‌‌in‌‌the‌‌development‌‌process.‌‌However,‌‌ it‌ ‌also‌ ‌has‌ ‌some‌ ‌major‌ ‌drawbacks,‌ ‌its‌ ‌rigid‌ ‌structure‌ ‌doesn’t‌ ‌allow‌ ‌for‌ ‌necessary‌ ‌changes,‌ ‌it‌‌ doesn’t‌ ‌allow‌ ‌for‌ ‌any‌ ‌uncertainty‌ ‌in‌ ‌requirements‌ ‌at‌ ‌the‌‌start‌‌of‌‌the‌‌project,‌‌and‌‌the‌‌end‌‌of‌‌the‌‌ project‌ ‌can‌ ‌be‌ ‌far‌ ‌in‌ ‌the‌ ‌future‌ ‌that‌ ‌it‌ ‌is‌ ‌hard‌‌to‌‌have‌‌a‌‌complete‌‌development‌‌plan‌‌at‌‌the‌‌start‌‌ (Santos,‌ ‌2021).‌ ‌As‌ ‌a‌ ‌team,‌ ‌you‌ ‌must‌ ‌weigh‌ ‌the‌ ‌positives‌ ‌and‌ ‌negatives‌ ‌of‌ ‌both‌ ‌approaches‌ ‌to‌‌ decide‌‌what‌‌framework‌‌is‌‌best‌‌for‌‌the‌‌application‌‌you‌‌are‌‌developing.‌‌ ‌ 1.1.2‌‌ Code‌‌Structure‌‌Decisions‌ ‌ The‌ ‌next‌‌major‌‌design‌‌decision‌‌that‌‌needs‌‌to‌‌be‌‌made‌‌is‌‌how‌‌to‌‌structure‌‌the‌‌code.‌‌One‌‌ possible‌‌approach‌‌to‌‌this‌‌problem‌‌is‌‌to‌‌use‌ ‌a‌‌monolithic‌‌design.‌‌In‌‌this‌‌approach‌‌all‌‌components‌‌ of‌‌the‌‌code‌‌are‌‌kept‌‌in‌‌a‌‌single‌‌entity‌‌that‌‌for‌‌simplicity,‌‌I‌‌will‌‌refer‌‌to‌‌as‌‌a‌‌package‌‌(Richardson,‌‌ n.d.).‌‌This‌‌package‌‌is‌‌just‌‌a‌‌common‌‌namespace‌‌that‌‌organizes‌‌your‌‌set‌‌of‌‌related‌‌classes‌‌that‌‌are‌‌ ‌ 8‌ ‌ the‌ ‌implementations‌ ‌of‌ ‌the‌ ‌code‌ ‌which‌ ‌make‌ ‌the‌ ‌application‌ ‌function‌ ‌properly.‌ ‌This‌ ‌can‌ ‌be‌ ‌a‌‌ good‌‌approach‌‌for‌‌small‌‌software‌‌systems‌‌which‌‌are‌‌not‌‌very‌‌complex.‌‌It‌‌keeps‌‌all‌‌the‌‌code‌‌in‌‌an‌‌ easy-to-access‌ ‌spot,‌ ‌and‌ ‌the‌ ‌codebase‌ ‌(the‌ ‌complete‌ ‌source‌ ‌code‌ ‌for‌ ‌the‌ ‌application)‌ ‌is‌ ‌small‌‌ enough‌ ‌to‌ ‌still‌ ‌be‌ ‌easily‌ ‌maintained.‌ ‌However,‌ ‌as‌ ‌the‌ ‌codebase‌ ‌grows‌ ‌in‌ ‌size‌ ‌this‌ ‌approach‌‌ becomes‌ ‌a‌ ‌lot‌ ‌worse‌ ‌overall‌ ‌because‌ ‌it‌ ‌gets‌ ‌to‌ ‌a‌ ‌point‌ ‌where‌ ‌it‌ ‌becomes‌ ‌so‌ ‌large‌ ‌it‌ ‌is‌ ‌hard‌‌to‌‌ maintain‌‌and‌‌track‌‌down‌‌bugs‌‌when‌‌they‌‌occur.‌‌A‌‌bug‌‌is‌‌simply‌‌an‌‌unforeseen‌‌failure‌‌or‌‌flaw‌‌in‌‌ the‌ ‌program‌ ‌that‌ ‌causes‌ ‌the‌ ‌application‌ ‌to‌ ‌not‌ ‌work‌ ‌as‌‌intended.‌‌These‌‌bugs‌‌become‌‌harder‌‌to‌‌ track‌ ‌down‌‌because‌‌as‌‌a‌‌codebase‌‌grows‌‌larger‌‌you‌‌will‌‌have‌‌thousands‌‌and‌‌thousands‌‌of‌‌lines‌‌ of‌ ‌code‌ ‌within‌ ‌the‌ ‌code‌ ‌base,‌ ‌and‌ ‌often‌ ‌it‌ ‌is‌ ‌a‌ ‌single‌ ‌line‌ ‌of‌ ‌the‌ ‌code‌ ‌that‌ ‌is‌ ‌causing‌‌the‌‌bug.‌‌ Therefore,‌ ‌the‌ ‌larger‌ ‌the‌ ‌codebase‌ ‌the‌ ‌harder‌ ‌it‌ ‌becomes‌ ‌to‌ ‌find‌ ‌the‌ ‌bug‌ ‌because‌ ‌you‌ ‌have‌ ‌to‌‌ examine‌‌more‌‌lines‌‌of‌‌code.‌‌ ‌ At‌ ‌this‌ ‌point,‌ ‌an‌ ‌important‌ ‌concept‌ ‌in‌ ‌Computer‌ ‌Science‌ ‌and‌ ‌software‌ ‌development‌‌ comes‌ ‌into‌ ‌play,‌ ‌the‌ ‌separation‌ ‌of‌ ‌concerns‌ ‌principle.‌ ‌This‌ ‌is‌ ‌the‌ ‌concept‌ ‌that,‌ ‌as‌ ‌much‌ ‌as‌‌ possible,‌ ‌a‌ ‌software‌ ‌system‌ ‌should‌ ‌be‌ ‌divided‌ ‌into‌ ‌parts‌ ‌that‌ ‌are‌ ‌each‌ ‌responsible‌ ‌for‌ ‌a‌‌single‌‌ aspect‌‌of‌‌functionality‌‌as‌‌much‌‌as‌‌possible‌‌(Makebee,‌‌2012).‌‌You‌‌can‌‌apply‌‌this‌‌inside‌‌the‌‌code‌‌ to‌‌avoid‌‌code‌‌duplication.‌‌If‌‌there‌‌are‌‌two‌‌features‌‌in‌‌the‌‌system‌‌and‌‌they‌‌both‌‌compute‌‌the‌‌same‌‌ value‌‌instead‌‌of‌‌duplicating‌‌the‌‌code‌‌a‌‌separate‌‌method‌‌(an‌‌individual‌‌unit‌‌of‌‌code‌‌that‌‌is‌‌called‌‌ to‌‌perform‌‌a‌‌specific‌‌task)‌‌should‌‌be‌‌created‌‌to‌‌perform‌‌this‌‌task.‌‌Then,‌‌both‌‌the‌‌features‌‌should‌‌ make‌‌use‌‌of‌‌this‌‌method.‌‌Overall,‌‌this‌‌design‌‌principle‌‌helps‌‌avoid‌‌bugs‌‌in‌‌code‌‌since‌‌each‌‌part‌‌ of‌ ‌the‌ ‌code‌ ‌is‌ ‌only‌ ‌concerned‌ ‌with‌ ‌a‌ ‌single‌ ‌aspect‌ ‌of‌ ‌the‌ ‌application.‌ ‌Therefore,‌ ‌you‌ ‌know‌‌ exactly‌‌where‌‌to‌‌look‌‌if‌‌there‌‌is‌‌a‌‌problem‌‌within‌‌that‌‌aspect‌‌of‌‌the‌‌application.‌‌ ‌ This‌ ‌design‌ ‌principle‌‌can‌‌also‌‌be‌‌applied‌‌when‌‌determining‌‌how‌‌to‌‌structure‌‌your‌‌code.‌‌ Instead‌ ‌of‌ ‌having‌ ‌a‌ ‌single‌ ‌code‌ ‌base‌ ‌that‌ ‌contains‌ ‌all‌ ‌of‌ ‌the‌ ‌code‌ ‌you‌ ‌can‌ ‌have‌ ‌multiple‌‌ ‌ 9‌ ‌ codebases‌‌each‌‌of‌‌which‌‌handles‌‌a‌‌single‌‌aspect‌‌of‌‌the‌‌application.‌‌For‌‌example,‌‌you‌‌could‌‌have‌‌ a‌ ‌separate‌ ‌code‌ ‌base‌ ‌for‌ ‌both‌ ‌the‌ ‌front-end‌ ‌and‌ ‌back-end‌ ‌of‌ ‌your‌ ‌application.‌‌However,‌‌If‌‌the‌‌ front-end‌ ‌and‌‌back-end‌‌are‌‌completely‌‌separate‌‌and‌‌live‌‌in‌‌different‌‌code‌‌bases‌‌it‌‌brings‌‌up‌‌the‌‌ question‌ ‌of‌ ‌how‌ ‌do‌ ‌these‌ ‌two‌ ‌code‌ ‌bases‌ ‌communicate‌ ‌and‌ ‌work‌ ‌together?‌ ‌Although‌ ‌the‌‌ front-end‌ ‌and‌ ‌back-end‌ ‌have‌ ‌different‌ ‌concerns‌ ‌they‌ ‌still‌ ‌rely‌ ‌on‌ ‌each‌ ‌other‌ ‌to‌ ‌operate.‌‌ Therefore,‌ ‌they‌ ‌must‌ ‌still‌ ‌interact‌ ‌in‌ ‌some‌ ‌way‌‌to‌‌work‌‌correctly.‌‌This‌‌problem‌‌is‌‌solved‌‌most‌‌ often‌‌by‌‌using‌‌an‌‌Application‌‌Programming‌‌Interface‌‌(API).‌‌ ‌ An‌‌API‌‌is‌‌a‌‌way‌‌for‌‌the‌‌front-end‌‌of‌‌an‌‌application‌‌to‌‌communicate‌‌with‌‌the‌‌back-end‌‌of‌‌ an‌ ‌application‌ ‌by‌ ‌sending‌ ‌requests‌ ‌that‌ ‌tell‌ ‌it‌ ‌to‌ ‌retrieve,‌ ‌create,‌ ‌update,‌ ‌or‌ ‌delete‌ ‌the‌ ‌data‌ ‌it‌‌ stores.‌‌This‌‌is‌‌done‌‌by‌‌the‌‌front-end‌‌sending‌‌a‌‌request‌‌over‌‌the‌‌internet‌‌to‌‌a‌‌specific‌‌URL‌‌that‌‌the‌‌ back-end‌ ‌is‌ ‌located‌ ‌at.‌ ‌Then,‌ ‌the‌ ‌back-end‌ ‌will‌ ‌see‌ ‌this‌ ‌request‌ ‌and‌ ‌respond‌ ‌to‌ ‌the‌ ‌front-end‌‌ accordingly‌ ‌(IBM‌ ‌Cloud‌ ‌Education,‌‌2020).‌‌For‌‌example,‌‌if‌‌the‌‌front-end‌‌sends‌‌a‌‌request‌‌to‌‌the‌‌ back-end‌ ‌to‌ ‌get‌ ‌a‌ ‌user’s‌ ‌information‌ ‌after‌ ‌they‌ ‌log‌ ‌in,‌ ‌the‌‌back-end‌‌will‌‌respond‌‌with‌‌the‌‌user‌‌ credentials‌‌stored‌‌in‌‌the‌‌database‌‌for‌‌that‌‌user.‌‌APIs‌‌allow‌‌the‌‌frontend-end‌‌application‌‌to‌‌make‌‌ requests‌‌to‌‌create,‌‌update,‌‌modify,‌‌and‌‌delete‌‌data‌‌within‌‌the‌‌database.‌ ‌ These‌ ‌APIs‌ ‌serve‌ ‌as‌ ‌the‌ ‌middleman‌ ‌between‌ ‌the‌ ‌front-end‌ ‌and‌ ‌the‌ ‌back-end‌ ‌of‌ ‌the‌‌ application‌‌and‌‌they‌‌are‌‌crucial‌‌in‌‌promoting‌‌the‌‌separation‌‌of‌‌concerns‌‌principle.‌‌Almost‌‌all‌‌big‌‌ tech‌ ‌companies‌ ‌use‌ ‌APIs‌ ‌frequently,‌ ‌including‌ ‌Google,‌ ‌Apple,‌ ‌Amazon,‌ ‌Facebook,‌ ‌and‌‌ Microsoft‌‌(Wang‌‌&‌‌McLarty,‌‌2021).‌‌Additionally,‌‌splitting‌‌up‌‌the‌‌front-end‌‌and‌‌back-end‌‌of‌‌the‌‌ application‌ ‌using‌ ‌an‌ ‌API‌ ‌allows‌‌a‌‌developer‌‌to‌‌use‌‌different‌‌coding‌‌languages‌‌and‌‌frameworks‌‌ for‌ ‌each,‌ ‌which‌ ‌are‌ ‌more‌ ‌specialized‌ ‌for‌ ‌handling‌ ‌back-end‌ ‌and‌ ‌front-end‌ ‌coding‌ ‌tasks.‌‌ However,‌‌like‌‌all‌‌other‌‌design‌‌decisions‌‌in‌‌Computer‌‌Science,‌‌the‌‌usefulness‌‌of‌‌an‌‌API‌‌for‌‌your‌‌ application‌ ‌depends‌ ‌on‌ ‌the‌ ‌application‌ ‌you‌ ‌are‌ ‌developing.‌ ‌The‌ ‌team‌ ‌must‌ ‌come‌ ‌together‌ ‌to‌‌ ‌ 10‌ ‌ determine‌‌the‌‌best‌‌course‌‌of‌‌action‌‌and‌‌determine‌‌if‌‌an‌‌API‌‌is‌‌necessary‌‌for‌‌the‌‌application‌‌or‌‌if‌‌ it‌‌would‌‌be‌‌better‌‌to‌‌have‌‌the‌‌front-end‌‌directly‌‌communicate‌‌with‌‌the‌‌database.‌ ‌ Then,‌‌another‌‌major‌‌design‌‌decision‌‌related‌‌to‌‌code‌‌structure‌‌is‌‌the‌‌IT‌‌setup‌‌that‌‌must‌‌be‌‌ done‌‌to‌‌deploy‌‌your‌‌code,‌‌so‌‌it‌‌can‌‌be‌‌used‌‌by‌‌users‌‌other‌‌than‌‌yourself.‌‌When‌‌code‌‌is‌‌developed‌‌ it‌‌lives‌‌on‌‌the‌‌machine‌‌it‌‌was‌‌created‌‌on,‌‌and‌‌then‌‌a‌‌developer‌‌has‌‌to‌‌type‌‌in‌‌a‌‌command‌‌to‌‌get‌‌it‌‌ to‌ ‌run‌ ‌on‌ ‌their‌ ‌hardware‌ ‌(laptop‌ ‌or‌ ‌desktop‌ ‌computer).‌ ‌However,‌‌this‌‌option‌‌only‌‌works‌‌if‌‌the‌‌ user‌‌has‌‌access‌‌to‌‌the‌‌actual‌‌source‌‌code‌‌of‌‌the‌‌project‌‌and‌‌the‌‌necessary‌‌hardware‌‌to‌‌be‌‌able‌‌to‌‌ run‌‌it.‌‌This‌‌is‌‌infeasible‌‌because‌‌as‌‌a‌‌user‌‌you‌‌should‌‌not‌‌need‌‌to‌‌have‌‌access‌‌to‌‌the‌‌source‌‌code‌‌ for‌‌Instagram‌‌to‌‌use‌‌the‌‌application.‌‌This‌‌problem‌‌often‌‌is‌‌solved‌‌by‌‌using‌‌third-party‌‌resources‌‌ that‌ ‌you‌ ‌can‌ ‌pay‌ ‌to‌ ‌persistently‌ ‌host‌ ‌your‌ ‌code‌ ‌so‌ ‌that‌ ‌a‌ ‌user‌ ‌can‌ ‌visit‌ ‌your‌ ‌URL‌ ‌and‌ ‌the‌‌ application‌ ‌is‌ ‌ready‌ ‌to‌ ‌use.‌ ‌Furthermore,‌ ‌these‌ ‌services‌ ‌can‌ ‌be‌ ‌used‌ ‌to‌ ‌host‌ ‌your‌ ‌database‌ ‌to‌ persistently‌ ‌store‌ ‌back-end‌ ‌data.‌ ‌These‌ ‌deployment‌ ‌options‌ ‌are‌ ‌referred‌ ‌to‌‌as‌‌cloud‌‌computing‌‌ services‌‌since‌‌they‌‌will‌‌host‌‌the‌‌code‌‌on‌‌the‌‌cloud.‌‌Hosting‌‌on‌‌the‌‌cloud‌‌the‌‌third-party‌‌resources‌‌ will‌‌take‌‌care‌‌of‌‌all‌‌the‌‌hardware‌‌requirements‌‌necessary‌‌to‌‌constantly‌‌run‌‌your‌‌code‌‌and‌‌make‌‌it‌‌ accessible‌‌via‌‌the‌‌internet.‌‌This‌‌is‌‌done‌‌through‌‌a‌‌collection‌‌of‌‌physical‌‌and‌‌virtual‌‌web‌‌servers‌‌ that‌‌the‌‌third-party‌‌resource‌‌operates‌‌that‌‌accomplishes‌‌the‌‌goal‌‌of‌‌hosting‌‌your‌‌code‌‌on‌‌the‌‌web‌‌ (Perepa,‌‌n.d.).‌‌ ‌ The‌ ‌three‌ ‌leaders‌ ‌in‌ ‌this‌ ‌area‌ ‌are‌ ‌Amazon‌ ‌Web‌ ‌Services‌ ‌(AWS),‌ ‌Microsoft‌‌Azure,‌‌and‌‌ Google‌‌Cloud‌‌each‌‌having‌‌its‌‌pros‌‌and‌‌cons.‌‌Overall,‌‌you‌‌can‌‌use‌‌any‌‌of‌‌these‌‌to‌‌host‌‌code,‌‌and‌‌ depending‌ ‌on‌ ‌what‌ ‌your‌ ‌code‌ ‌is‌ ‌doing‌ ‌one‌ ‌may‌ ‌be‌ ‌better‌ ‌than‌ ‌the‌ ‌others.‌ ‌AWS‌ ‌is‌ ‌the‌ ‌market‌‌ leader‌ ‌in‌ ‌this‌ ‌area,‌ ‌which‌ ‌means‌ ‌all‌ ‌its‌ ‌services‌ ‌are‌ ‌very‌ ‌well‌ ‌established‌ ‌and‌ ‌easy‌ ‌to‌ ‌use.‌‌ However,‌‌a‌‌drawback‌‌to‌‌using‌‌AWS‌‌is‌‌that‌‌it‌‌is‌‌also‌‌the‌‌most‌‌expensive‌‌of‌‌the‌‌three.‌‌Microsoft‌‌ Azure‌ ‌is‌ ‌a‌ ‌hosting‌ ‌service‌ ‌that‌ ‌is‌ ‌also‌ ‌very‌ ‌well‌ ‌established‌ ‌and‌ ‌is‌ ‌good‌ ‌for‌ ‌integration‌ ‌with‌‌ ‌ 11‌ ‌ Windows‌‌products.‌‌Lastly,‌‌Google‌‌Cloud‌‌is‌‌the‌‌newest‌‌service‌‌which‌‌means‌‌it‌‌can‌‌be‌‌harder‌‌to‌‌ use‌ ‌but‌ ‌comes‌ ‌at‌ ‌a‌ ‌lower‌ ‌price‌ ‌point.‌ ‌Google‌ ‌Cloud‌ ‌is‌ ‌a‌ ‌good‌ ‌choice‌‌if‌‌you‌‌want‌‌to‌‌use‌‌it‌‌for‌‌ machine‌ ‌learning‌ ‌and‌ ‌artificial‌ ‌intelligence‌ ‌(Harvey,‌ ‌2021).‌ ‌While‌ ‌you‌ ‌could‌ ‌use‌ ‌any‌ ‌of‌ ‌these‌‌ services‌ ‌for‌ ‌deployment‌ ‌it‌ ‌is‌ ‌important‌ ‌to‌ ‌choose‌ ‌one‌‌early‌‌on.‌‌There‌‌is‌‌often‌‌a‌‌learning‌‌curve‌‌ involved‌ ‌with‌ ‌using‌ ‌these‌ ‌deployment‌ ‌services‌ ‌which‌ ‌means‌ ‌if‌ ‌this‌ ‌aspect‌ ‌of‌ ‌the‌ ‌application‌‌ structure‌‌is‌‌not‌‌decided‌‌upon‌‌early,‌‌it‌‌can‌‌cause‌‌a‌‌major‌‌delay‌‌when‌‌it‌‌comes‌‌time‌‌to‌‌release‌‌the‌‌ application‌‌for‌‌public‌‌use.‌ ‌ 1.1.3‌‌ Code‌‌Implementation‌‌Decisions‌ ‌ Then,‌ ‌there‌ ‌are‌ ‌implementation‌ ‌decisions.‌ ‌These‌ ‌design‌ ‌decisions‌ ‌determine‌ ‌the‌‌ individual‌ ‌programming‌ ‌languages‌ ‌and‌ ‌frameworks‌ ‌to‌ ‌use‌ ‌to‌ ‌create‌ ‌the‌ ‌code‌ ‌and‌ ‌the‌ ‌type‌ ‌of‌‌ database‌ ‌to‌ ‌use.‌ ‌A‌ ‌programming‌ ‌language‌ ‌is‌‌a‌‌set‌‌of‌‌commands,‌‌instructions,‌‌and‌‌other‌‌syntax‌‌ patterns‌ ‌used‌ ‌to‌ ‌create‌ ‌a‌ ‌software‌ ‌program‌ ‌(C ‌ hristensson,‌ ‌2011)‌.‌ ‌Then,‌ ‌a‌ ‌framework‌ ‌for‌‌ programming‌ ‌is‌ ‌a‌ ‌collection‌ ‌of‌ ‌classes‌ ‌and‌ ‌functions‌ ‌for‌ ‌a‌ ‌specific‌ ‌programming‌ ‌language‌ ‌or‌ multiple‌‌languages‌‌that‌‌provide‌‌a‌‌foundation‌‌for‌‌developers‌‌to‌‌build‌‌large-scale‌‌software‌‌systems‌‌ (‌Christensson,‌ ‌2013)‌.‌ ‌Every‌ ‌framework‌ ‌gets‌ ‌created‌‌to‌‌specialize‌‌in‌‌specific‌‌types‌‌of‌‌tasks‌‌and‌‌ there‌ ‌are‌ ‌hundreds‌ ‌or‌ ‌even‌ ‌thousands‌ ‌of‌ ‌these‌ ‌frameworks‌ ‌and‌ ‌new‌ ‌ones‌ ‌are‌ ‌constantly‌‌being‌‌ created.‌ ‌There‌ ‌are‌ ‌frameworks‌ ‌geared‌ ‌for‌ ‌both‌ ‌front-end‌ ‌development‌ ‌and‌ ‌back-end‌‌ development.‌‌ ‌ Some‌ ‌common‌ ‌back-end-focused‌ ‌frameworks‌ ‌include‌ ‌ASP.NET‌ ‌Core,‌ ‌Django,‌ ‌and‌‌ Express‌‌(Wintemute,‌‌2021).‌‌ASP.NET‌‌is‌‌a‌‌framework‌‌developed‌‌by‌‌Microsoft‌‌which‌‌works‌‌with‌‌ the‌ ‌C#‌ ‌programming‌ ‌language.‌ ‌It‌ ‌is‌ ‌good‌ ‌to‌ ‌use‌ ‌when‌ ‌writing‌ ‌database‌ ‌access‌ ‌code‌‌due‌‌to‌‌its‌‌ implementation‌ ‌of‌ ‌Language‌ ‌Integrated‌ ‌Query‌ ‌(LINQ).‌ ‌Normally,‌ ‌when‌ ‌accessing‌ ‌data‌ ‌in‌ ‌a‌‌ database‌‌you‌‌must‌‌write‌‌a‌‌query‌‌in‌‌a‌‌completely‌‌different‌‌syntax‌‌than‌‌the‌‌programming‌‌language‌‌ ‌ 12‌ ‌ to‌‌operate‌‌on‌‌the‌‌database.‌‌However,‌‌using‌‌LINQ‌‌you‌‌can‌‌write‌‌these‌‌queries‌‌to‌‌the‌‌database‌‌in‌‌ the‌ ‌same‌ ‌way‌ ‌you‌ ‌would‌ ‌write‌‌code,‌‌which‌‌makes‌‌it‌‌easy‌‌to‌‌write‌‌database‌‌access‌‌code.‌‌Next,‌‌ Django‌‌is‌‌a‌‌web‌‌framework‌‌that‌‌works‌‌with‌‌the‌‌python‌‌language.‌‌It‌‌is‌‌easy‌‌to‌‌work‌‌with‌‌which‌‌ means‌‌a‌‌developer‌‌can‌‌quickly‌‌pick‌‌up‌‌and‌‌use‌‌it‌‌without‌‌much‌‌prior‌‌knowledge.‌‌Additionally,‌‌it‌‌ is‌‌good‌‌to‌‌use‌‌if‌‌data‌‌security‌‌is‌‌a‌‌top‌‌priority‌‌because‌‌it‌‌automatically‌‌includes‌‌security‌‌measures‌‌ on‌ ‌any‌ ‌application‌ ‌using‌ ‌the‌ ‌framework.‌ ‌Furthermore,‌ ‌Express‌‌is‌‌a‌‌minimalistic‌‌and‌‌simplistic‌‌ framework‌ ‌that‌‌uses‌‌the‌‌JavaScript‌‌programming‌‌language.‌‌It‌‌is‌‌easy‌‌to‌‌learn‌‌and‌‌its‌‌simplicity‌‌ makes‌‌it‌‌a‌‌good‌‌choice‌‌when‌‌developing‌‌web‌‌applications‌‌that‌‌do‌‌not‌‌have‌‌a‌‌complex‌‌back-end‌‌ component.‌ ‌The‌ ‌Express‌ ‌framework‌ ‌integrates‌ ‌well‌ ‌with‌ ‌a‌ ‌Node.js‌ ‌front-end‌ ‌framework‌‌ (Wintemute,‌‌2021).‌ ‌ Then,‌ ‌some‌ ‌common‌ ‌front-end-focused‌ ‌frameworks‌ ‌are‌ ‌Angular,‌ ‌Node.js,‌ ‌and‌ ‌React.‌‌ Angular‌‌is‌‌a‌‌framework‌‌developed‌‌by‌‌Google‌‌that‌‌specializes‌‌in‌‌single-page‌‌applications‌‌(where‌‌ each‌ ‌feature‌ ‌acts‌ ‌as‌ ‌a‌ ‌singular‌ ‌web‌ ‌page‌‌and‌‌links‌‌to‌‌the‌‌web‌‌pages‌‌for‌‌the‌‌other‌‌features)‌‌and‌‌ uses‌‌the‌‌HTML‌‌and‌‌Javascript‌‌language.‌‌It‌‌is‌‌good‌‌for‌‌creating‌‌readable‌‌code‌‌that‌‌can‌‌be‌‌tested‌‌ easily.‌ ‌Next,‌ ‌Node.js‌ ‌is‌ ‌a‌ ‌framework‌ ‌that‌ ‌uses‌ ‌the‌ ‌JavaScript‌ ‌language.‌ ‌It‌ ‌is‌ ‌ideal‌ ‌for‌ ‌creating‌‌ dynamic‌ ‌content‌ ‌on‌ ‌pages,‌ ‌this‌ ‌makes‌ ‌it‌ ‌an‌ ‌ideal‌ ‌choice‌ ‌for‌ ‌multiplayer‌ ‌games‌ ‌and‌‌ communication‌ ‌applications.‌ ‌Lastly,‌ ‌React‌ ‌is‌ ‌a‌ ‌web‌ ‌framework‌ ‌that‌ ‌works‌ ‌well‌ ‌for‌ ‌creating‌‌ mobile‌ ‌and‌‌single-page‌‌applications.‌‌It‌‌has‌‌a‌‌vast‌‌array‌‌of‌‌resources‌‌to‌‌use,‌‌thus‌‌making‌‌it‌‌very‌‌ good‌ ‌at‌ ‌developing‌ ‌a‌ ‌wide‌ ‌variety‌ ‌of‌ ‌applications.‌ ‌However,‌ ‌this‌ ‌broad‌ ‌focus‌ ‌is‌ ‌also‌ ‌its‌ ‌main‌‌ drawback‌‌because‌‌it‌‌also‌‌means‌‌it‌‌has‌‌a‌‌steep‌‌learning‌‌curve‌‌when‌‌developing‌‌with‌‌it‌‌for‌‌the‌‌first‌‌ time.‌ ‌ As‌‌a‌‌developer,‌‌you‌‌must‌‌be‌‌able‌‌to‌‌examine‌‌the‌‌endless‌‌quantity‌‌of‌‌frameworks‌‌at‌‌your‌‌ disposal‌‌and‌‌pick‌‌the‌‌one‌‌that‌‌best‌‌suits‌‌the‌‌needs‌‌of‌‌your‌‌application.‌‌Commonly,‌‌this‌‌decision‌‌ ‌ 13‌ ‌ of‌ ‌choosing‌ ‌the‌ ‌best‌ ‌framework‌ ‌for‌ ‌your‌ ‌application‌ ‌comes‌ ‌down‌‌to‌‌which‌‌framework‌‌has‌‌the‌‌ largest‌ ‌number‌ ‌of‌ ‌abstractions‌ ‌you‌ ‌can‌ ‌make‌ ‌use‌ ‌of‌ ‌when‌ ‌developing‌ ‌the‌ ‌code.‌ ‌Choosing‌ ‌the‌‌ correct‌‌framework‌‌ensures‌‌you‌‌do‌‌not‌‌have‌‌to‌‌reinvent‌‌the‌‌wheel‌‌and‌‌therefore,‌‌can‌‌save‌‌months‌‌ of‌ ‌development‌ ‌time‌ ‌as‌ ‌some‌ ‌frameworks‌ ‌make‌ ‌certain‌ ‌types‌ ‌of‌ ‌applications‌ ‌much‌ ‌easier‌ ‌to‌‌ develop.‌ ‌If‌ ‌you‌ ‌keep‌ ‌the‌ ‌front-end‌ ‌and‌ ‌back-end‌ ‌of‌ ‌your‌ ‌application‌ ‌in‌ ‌a‌ ‌single‌ ‌codebase‌ ‌this‌‌ means‌ ‌that‌ ‌you‌ ‌must‌ ‌find‌ ‌a‌ ‌framework‌ ‌that‌ ‌can‌ ‌handle‌ ‌what‌ ‌you‌ ‌need‌ ‌for‌ ‌both‌ ‌ends‌ ‌of‌ ‌the‌‌ application.‌ ‌Oftentimes,‌ ‌this‌ ‌leads‌ ‌to‌ ‌a‌ ‌more‌ ‌difficult‌ ‌time‌ ‌implementing‌ ‌one‌ ‌end‌ ‌of‌ ‌the‌‌ application‌‌as‌‌many‌‌frameworks‌‌are‌‌either‌‌front-end‌‌or‌‌back-end‌‌focused.‌‌Therefore,‌‌the‌‌features‌‌ available‌ ‌to‌ ‌you‌ ‌will‌ ‌be‌ ‌geared‌ ‌more‌ ‌towards‌ ‌either‌ ‌front-end‌ ‌or‌ ‌back-end‌ ‌development.‌ ‌In‌‌ contrast,‌ ‌if‌ ‌you‌ ‌choose‌ ‌to‌ ‌create‌ ‌separate‌ ‌front-end‌ ‌and‌‌back-end‌‌modules‌‌for‌‌your‌‌application‌‌ you‌ ‌can‌ ‌use‌ ‌different‌ ‌frameworks‌ ‌for‌ ‌both‌‌ends‌‌of‌‌the‌‌application.‌‌Then,‌‌these‌‌two‌‌portions‌‌of‌‌ the‌‌application‌‌would‌‌be‌‌connected‌‌through‌‌an‌‌API,‌‌which‌‌means‌‌the‌‌frameworks‌‌you‌‌choose‌‌do‌‌ not‌ ‌need‌ ‌to‌ ‌be‌ ‌compatible‌ ‌with‌ ‌one‌ ‌another.‌ ‌These‌ ‌features‌ ‌of‌ ‌the‌ ‌frameworks‌ ‌must‌ ‌be‌‌ considered‌ ‌when‌ ‌selecting‌ ‌the‌ ‌correct‌ ‌framework‌ ‌for‌ ‌the‌ ‌application.‌ ‌The‌ ‌choice‌ ‌of‌ ‌the‌‌ framework‌ ‌will‌ ‌go‌ ‌a‌ ‌long‌ ‌way‌ ‌in‌ ‌determining‌ ‌how‌ ‌easy‌ ‌the‌ ‌development‌ ‌process‌ ‌of‌ ‌the‌‌ application‌‌can‌‌be.‌ ‌ Furthermore,‌ ‌the‌ ‌framework‌ ‌decided‌ ‌on‌ ‌also‌ ‌determines‌ ‌the‌ ‌best‌ ‌IDE‌ ‌to‌ ‌use‌ ‌for‌ ‌code‌ development.‌ ‌An‌ ‌IDE‌ ‌is‌ ‌an‌ ‌integrated‌ ‌development‌ ‌environment‌ ‌that‌ ‌is‌ ‌an‌‌application‌‌used‌‌to‌‌ create‌ ‌and‌ ‌run‌‌code.‌‌Each‌‌IDE‌‌specializes‌‌in‌‌a‌‌certain‌‌programming‌‌language.‌‌Therefore,‌‌since‌‌ the‌‌framework‌‌used‌‌also‌‌will‌‌decide‌‌the‌‌programming‌‌language‌‌it‌‌will‌‌oftentimes‌‌decide‌‌the‌‌IDE‌‌ that‌ ‌should‌ ‌be‌ ‌used‌ ‌as‌ ‌well.‌ ‌Essentially‌ ‌an‌ ‌IDE‌ ‌is‌‌an‌‌interface‌‌that‌‌provides‌‌an‌‌easy‌‌way‌‌for‌‌a‌‌ developer‌ ‌to‌ ‌write,‌ ‌maintain,‌ ‌and‌ ‌run‌ ‌code.‌‌Some‌‌of‌‌the‌‌most‌‌common‌‌IDEs‌‌are‌‌Visual‌‌Studio‌‌ for‌ ‌C,‌ ‌C++,‌ ‌and‌ ‌C#‌ ‌development,‌ ‌PyCharm‌ ‌for‌ ‌Python‌ ‌development,‌ ‌Visual‌ ‌Studio‌ ‌Code‌ ‌for‌‌ ‌ 14‌ ‌ JavaScript‌ ‌development,‌ ‌and‌ ‌IntelliJ‌ ‌for‌ ‌Java‌ ‌and‌ ‌HTML‌ ‌development.‌ ‌Overall,‌ ‌having‌ ‌a‌‌ compatible‌ ‌IDE‌ ‌with‌‌your‌‌chosen‌‌programming‌‌language‌‌can‌‌help‌‌make‌‌software‌‌development‌‌ easier.‌ ‌ Then,‌ ‌a‌ ‌final‌ ‌implementation‌ ‌decision‌ ‌for‌ ‌many‌ ‌applications‌ ‌is‌ ‌what‌ ‌type‌ ‌of‌ ‌database‌‌ should‌‌be‌‌used.‌‌There‌‌are‌‌two‌‌main‌‌types‌‌of‌‌databases‌‌called‌‌SQL‌‌and‌‌NoSQL.‌‌SQL‌‌databases‌‌ or‌ ‌relational‌ ‌databases‌ ‌support‌ ‌the‌ ‌Structured‌ ‌Query‌ ‌Language‌ ‌(SQL)‌ ‌to‌ ‌manipulate‌ ‌the‌ ‌data‌‌ stored‌ ‌in‌ ‌the‌ ‌database.‌ ‌They‌ ‌are‌ ‌organized‌ ‌using‌ ‌sets‌ ‌of‌ ‌tables‌ ‌that‌ ‌relate‌ ‌to‌‌each‌‌other.‌‌These‌‌ tables‌‌are‌‌combined‌‌to‌‌retrieve‌‌specific‌‌information‌‌and‌‌each‌‌table‌‌encompasses‌‌a‌‌singular‌‌entity‌‌ (“SQL‌ ‌vs.‌ ‌NoSQL”,‌ ‌n.d.).‌ ‌For‌ ‌example,‌ ‌in‌ ‌a‌ ‌SQL‌ ‌database‌ ‌for‌ ‌chess‌ ‌players,‌ ‌each‌ ‌player's‌‌ information‌ ‌would‌ ‌be‌ ‌stored‌ ‌in‌ ‌one‌ ‌table‌ ‌and‌ ‌the‌ ‌information‌ ‌for‌ ‌each‌ ‌chess‌ ‌match‌ ‌would‌ ‌be‌‌ stored‌ ‌in‌ ‌a‌ ‌different‌ ‌table.‌ ‌Then,‌ ‌to‌ ‌retrieve‌ ‌the‌ ‌information‌ ‌about‌ ‌which‌ ‌players‌ ‌competed‌ ‌in‌‌ each‌‌match,‌‌an‌‌ID‌‌would‌‌be‌‌assigned‌‌to‌‌each‌‌player,‌‌and‌‌each‌‌chess‌‌match‌‌would‌‌list‌‌the‌‌IDs‌‌of‌‌ the‌‌players‌‌competing.‌‌Then,‌‌this‌‌ID‌‌could‌‌be‌‌used‌‌to‌‌combine‌‌the‌‌players‌‌and‌‌the‌‌matches‌‌table‌‌ to‌ ‌determine‌ ‌the‌ ‌players‌ ‌in‌ ‌each‌ ‌chess‌ ‌match.‌ ‌The‌ ‌most‌ ‌popular‌ ‌SQL‌ ‌database‌ ‌engines‌ ‌are‌‌ Oracle,‌ ‌MySQL,‌‌Microsoft‌‌SQL‌‌Server,‌‌and‌‌PostgreSQL,‌‌which‌‌are‌‌also‌‌the‌‌four‌‌most‌‌popular‌‌ database‌‌engines‌‌overall‌‌ranking‌‌overall‌‌NoSQL‌‌databases‌‌(“DB-Engines‌‌Ranking,‌‌2021).‌‌Then,‌‌ a‌ ‌NoSQL‌ ‌database‌ ‌is‌ ‌a‌‌different‌‌type‌‌of‌‌database‌‌in‌‌which‌‌string‌‌representations‌‌of‌‌the‌‌entities‌‌ are‌ ‌stored‌ ‌in‌‌each‌‌of‌‌the‌‌tables.‌‌Each‌‌entry‌‌in‌‌the‌‌table‌‌contains‌‌all‌‌information‌‌associated‌‌with‌‌ that‌ ‌entity‌ ‌(“SQL‌ ‌vs.‌ ‌NoSQL”,‌ ‌n.d.).‌ ‌Therefore,‌ ‌in‌ ‌the‌ ‌chess‌‌players‌‌database,‌‌the‌‌match‌‌table‌‌ would‌‌also‌‌store‌‌the‌‌information‌‌associated‌‌with‌‌each‌‌player‌‌in‌‌the‌‌match.‌‌Even‌‌though‌‌the‌‌same‌‌ information‌‌is‌‌given‌‌in‌‌the‌‌players‌‌table‌‌already.‌‌The‌‌most‌‌common‌‌NoSQL‌‌database‌‌engines‌‌are‌‌ MongoDB,‌‌Redis,‌‌and‌‌ElasticSearch‌‌(“DB-Engines‌‌Ranking,‌‌2021).‌ ‌ ‌ 15‌ ‌ Each‌ ‌of‌ ‌these‌ ‌implementations‌ ‌has‌ ‌its‌ ‌benefits‌ ‌and‌ ‌weaknesses.‌ ‌When‌ ‌using‌ ‌an‌ ‌SQL‌‌ database‌‌its‌‌rigid‌‌structure‌‌means‌‌that‌‌data‌‌can‌‌be‌‌more‌‌easily‌‌monitored‌‌and‌‌maintained‌‌making‌‌ it‌ ‌harder‌ ‌for‌ ‌data‌ ‌errors‌ ‌to‌ ‌occur.‌ ‌Its‌ ‌structure‌ ‌also‌ ‌means‌ ‌duplicate‌ ‌data‌ ‌is‌ ‌not‌ ‌stored‌ ‌in‌ ‌the‌‌ database‌ ‌thus,‌ ‌decreasing‌ ‌the‌ ‌overall‌ ‌database‌ ‌size.‌ ‌However,‌ ‌this‌ ‌structure‌ ‌also‌ ‌means‌ ‌that‌‌ queries‌ ‌to‌ ‌manipulate‌ ‌data‌ ‌in‌ ‌the‌ ‌database‌ ‌are‌ ‌slower,‌ ‌and‌ ‌queries‌ ‌to‌ ‌manipulate‌ ‌the‌ ‌data‌ ‌are‌‌ much‌‌more‌‌complex‌‌since‌‌they‌‌rely‌‌on‌‌joining‌‌multiple‌‌tables‌‌to‌‌retrieve‌‌the‌‌information.‌‌ ‌ On‌‌the‌‌other‌‌hand,‌‌NoSQL‌‌databases‌‌are‌‌much‌‌faster‌‌in‌‌manipulating‌‌data‌‌since‌‌tables‌‌do‌‌ not‌ ‌have‌ ‌to‌ ‌be‌ ‌combined‌ ‌when‌ ‌looking‌ ‌for‌ ‌information.‌ ‌Therefore,‌ ‌the‌ ‌queries‌ ‌themselves‌‌are‌‌ also‌‌much‌‌less‌‌complex.‌‌However,‌‌NoSQL‌‌databases‌‌are‌‌also‌‌much‌‌more‌‌susceptible‌‌to‌‌storing‌‌ inaccurate‌ ‌data‌ ‌since‌ ‌it‌ ‌is‌‌much‌‌harder‌‌to‌‌create‌‌checks‌‌to‌‌reject‌‌incorrect‌‌data‌‌and‌‌they‌‌do‌‌not‌‌ support‌‌automatically‌‌updating‌‌or‌‌deleting‌‌data‌‌when‌‌referenced‌‌entities‌‌are‌‌updated‌‌or‌‌deleted.‌‌ Furthermore,‌‌NoSQL‌‌databases‌‌are‌‌also‌‌larger‌‌since‌‌they‌‌will‌‌store‌‌duplicate‌‌data‌‌in‌‌each‌‌entity‌‌ (“SQL‌‌vs.‌‌NoSQL”,‌‌n.d.).‌‌Developers‌‌must‌‌consider‌‌these‌‌pros‌‌and‌‌cons‌‌to‌‌determine‌‌what‌‌type‌‌ of‌ ‌database‌ ‌would‌ ‌best‌ ‌suit‌ ‌their‌ ‌back-end‌ ‌needs‌ ‌or‌ ‌if‌ ‌a‌ ‌database‌ ‌is‌ ‌even‌ ‌necessary‌ ‌at‌ ‌all.‌‌ Primarily,‌ ‌developers‌ ‌must‌ ‌consider‌ ‌if‌ ‌they‌ ‌want‌ ‌to‌ ‌prioritize‌ ‌the‌ ‌speed‌ ‌of‌ ‌operation‌ ‌or‌ ‌the‌‌ guarantee‌‌of‌‌the‌‌correctness‌‌of‌ ‌the‌‌data‌‌stored.‌‌ ‌ Additionally,‌ ‌if‌ ‌a‌ ‌database‌ ‌is‌ ‌required‌ ‌and‌‌you‌‌are‌‌using‌‌the‌‌.NET‌‌framework,‌‌which‌‌is‌‌ very‌ ‌common‌ ‌for‌ ‌this‌‌task,‌‌developers‌‌have‌‌the‌‌choice‌‌of‌‌taking‌‌a‌‌code-first‌‌or‌‌a‌‌database-first‌‌ approach.‌‌In‌‌a‌‌code-first‌‌approach,‌‌you‌‌create‌‌your‌‌data‌‌models‌‌inside‌‌of‌‌the‌‌code‌‌itself‌‌and‌‌then‌‌ use‌‌a‌‌migration‌‌tool‌‌to‌‌automatically‌‌create‌‌tables‌‌in‌‌the‌‌database‌‌to‌‌match‌‌the‌‌data‌‌models‌‌you‌‌ have‌ ‌in‌ ‌the‌ ‌code.‌ ‌This‌ ‌approach‌ ‌is‌‌good‌‌for‌‌smaller‌‌databases‌‌since‌‌there‌‌aren’t‌‌too‌‌many‌‌data‌‌ models‌ ‌to‌ ‌keep‌ ‌track‌ ‌of,‌ ‌and‌ ‌this‌ ‌approach‌ ‌generally‌ ‌makes‌ ‌the‌ ‌process‌ ‌much‌ ‌quicker.‌‌ Furthermore,‌ ‌this‌ ‌approach‌ ‌is‌ ‌also‌ ‌good‌ ‌if‌ ‌the‌ ‌developers‌ ‌do‌ ‌not‌ ‌have‌ ‌experience‌ ‌in‌ ‌writing‌‌ ‌ 16‌ ‌ database‌ ‌queries‌ ‌because‌ ‌in‌ ‌this‌ ‌approach‌ ‌the‌ ‌developer‌ ‌does‌ ‌not‌ ‌have‌ ‌to‌ ‌write‌ ‌any‌‌queries‌‌to‌‌ create‌‌tables‌‌in‌‌the‌‌database.‌‌This‌‌approach‌‌also‌‌guarantees‌‌there‌‌will‌‌never‌‌be‌‌any‌‌mismatch‌‌in‌ the‌ ‌data‌‌models‌‌in‌‌code‌‌and‌‌the‌‌tables‌‌in‌‌the‌‌database‌‌since‌‌it‌‌is‌‌the‌‌code‌‌determining‌‌what‌‌the‌‌ tables‌ ‌in‌ ‌the‌ ‌database‌ ‌should‌ ‌be.‌ ‌However,‌ ‌this‌ ‌approach‌ ‌struggles‌ ‌with‌ ‌very‌ ‌large‌ ‌databases‌‌ since‌‌it‌‌is‌‌more‌‌error-prone.‌‌Small‌‌errors‌‌in‌‌the‌‌code‌‌can‌‌lead‌‌to‌‌major‌‌errors‌‌in‌‌the‌‌database‌‌with‌‌ what‌ ‌tables‌ ‌reference‌ ‌each‌ ‌other‌ ‌and‌ ‌these‌ ‌errors‌ ‌also‌ ‌become‌ ‌harder‌ ‌to‌ ‌track‌ ‌down‌ ‌since‌ ‌the‌‌ database‌‌will‌‌always‌‌make‌‌sure‌‌its‌‌data‌‌models‌‌agree‌‌with‌‌the‌‌code’s‌‌data‌‌models‌‌(Wade,‌‌2021).‌‌ ‌ The‌‌alternative‌‌approach‌‌to‌‌this‌‌design‌‌is‌‌the‌‌database‌‌first‌‌approach.‌‌In‌‌this‌‌approach,‌‌a‌‌ developer‌‌will‌‌manually‌‌write‌‌‘create‌‌table’‌‌queries‌‌to‌‌create‌‌all‌‌tables‌‌in‌‌the‌‌database‌‌manually.‌‌ Usually,‌ ‌these‌ ‌queries‌ ‌are‌ ‌based‌ ‌on‌ ‌an‌ ‌entity-relationship‌ ‌(ER)‌ ‌diagram‌ ‌that‌ ‌documents‌‌which‌‌ data‌‌model‌‌(entity)‌‌tables‌‌should‌‌be‌‌created‌‌in‌‌the‌‌database‌‌and‌‌how‌‌each‌‌table‌‌should‌‌relate‌‌to‌‌ one‌‌another.‌‌Once‌‌the‌‌diagram‌‌has‌‌been‌‌created,‌‌it‌‌can‌‌be‌‌converted‌‌into‌‌‘create‌‌table’‌‌queries‌‌to‌‌ create‌ ‌the‌‌tables‌‌in‌‌the‌‌database‌‌(“What‌‌is‌‌Entity‌‌Relationship”,‌‌n.d.).‌‌After‌‌this,‌‌a‌‌tool‌‌called‌‌a‌‌ scaffolder‌ ‌is‌ ‌used‌ ‌to‌ ‌automatically‌ ‌create‌ ‌the‌ ‌data‌ ‌models‌ ‌in‌ ‌the‌ ‌code‌ ‌based‌ ‌on‌ ‌the‌‌tables‌‌that‌‌ exist‌‌in‌‌the‌‌database.‌‌This‌‌approach‌‌has‌‌the‌‌advantage‌‌of‌‌being‌‌less‌‌error-prone‌‌since‌‌a‌‌developer‌‌ has‌ ‌to‌ ‌manually‌ ‌write‌ ‌each‌ ‌query,‌ ‌which‌ ‌makes‌ ‌it‌ ‌a‌ ‌good‌ ‌choice‌ ‌when‌ ‌designing‌ ‌very‌‌ large-complex‌‌databases‌‌with‌‌many‌‌tables.‌‌Furthermore,‌‌it‌‌is‌‌a‌‌good‌‌approach‌‌if‌‌the‌‌developers‌‌ already‌‌have‌‌experience‌‌writing‌‌database‌‌queries.‌‌However,‌‌this‌‌approach‌‌is‌‌a‌‌lot‌‌slower‌‌because‌‌ of‌‌the‌‌manual‌‌work‌‌that‌‌it‌‌requires,‌‌which‌‌is‌‌its‌‌major‌‌drawback‌‌(Wade,‌‌2021).‌ ‌ Overall,‌‌if‌‌you‌‌are‌‌using‌‌the‌‌.NET‌‌framework,‌‌either‌‌of‌‌these‌‌approaches‌‌can‌‌be‌‌used‌‌to‌‌ design‌ ‌your‌ ‌database‌ ‌and‌ ‌create‌ ‌data‌ ‌models‌ ‌in‌ ‌your‌ ‌code.‌ ‌Assuming‌ ‌that‌ ‌you‌ ‌are‌ ‌creating‌ ‌a‌‌ database‌ ‌from‌ ‌scratch,‌ ‌either‌ ‌of‌ ‌these‌ ‌approaches‌ ‌can‌ ‌be‌ ‌used‌ ‌to‌ ‌accomplish‌ ‌the‌ ‌same‌ ‌thing.‌‌ Therefore,‌‌it‌‌is‌‌up‌‌to‌‌the‌‌developers‌‌to‌‌decide‌‌which‌‌approach‌‌works‌‌best‌‌for‌‌their‌‌application.‌ ‌ ‌ 17‌ ‌ 1.2‌‌ What‌‌is‌‌Hestia‌ ‌ As‌ ‌mentioned‌ ‌previously,‌ ‌there‌‌is‌‌not‌‌a‌‌clear‌‌answer‌‌to‌‌the‌‌design‌‌decisions‌‌that‌‌should‌‌ be‌ ‌made‌ ‌when‌ ‌designing‌ ‌a‌ ‌large-scale‌ ‌software‌ ‌system.‌ ‌Different‌ ‌projects‌ ‌necessitate‌ ‌using‌‌ different‌‌approaches.‌‌Therefore,‌‌it‌‌is‌‌important‌‌to‌‌tailor‌‌these‌‌decisions‌‌to‌‌the‌‌application‌‌you‌‌are‌‌ developing.‌‌Thus,‌‌before‌‌discussing‌‌what‌‌design‌‌decisions‌‌we‌‌made‌‌for‌‌Hestia‌‌it‌‌is‌‌important‌‌to‌‌ understand‌‌the‌‌application‌‌we‌‌wanted‌‌to‌‌develop.‌‌We‌‌realized‌‌that‌‌there‌‌are‌‌many‌‌different‌‌home‌‌ management,‌ ‌meal‌ ‌planning,‌ ‌family‌ ‌calendar,‌ ‌budgeting,‌ ‌and‌ ‌to-do‌ ‌lists‌ ‌apps‌ ‌on‌ ‌the‌ ‌market‌‌ today.‌‌The‌‌problem‌‌with‌‌this‌‌is‌‌while‌‌they‌‌can‌‌be‌‌useful‌‌it‌‌necessitates‌‌the‌‌use‌‌of‌‌multiple‌‌apps.‌‌ When‌ ‌using‌ ‌several‌ ‌apps,‌ ‌it‌ ‌can‌ ‌be‌ ‌hard‌ ‌to‌ ‌remember‌ ‌information‌ ‌when‌ ‌you‌ ‌switch‌ ‌from‌ ‌one‌‌ application‌‌to‌‌another,‌‌making‌‌home‌‌management‌‌very‌‌difficult.‌‌We‌‌wanted‌‌our‌‌application‌‌to‌‌be‌‌ a‌ ‌home‌ ‌and‌ ‌life‌ ‌management‌ ‌system‌ ‌that‌ ‌would‌ ‌consolidate‌ ‌the‌ ‌functionality‌‌of‌‌all‌‌these‌‌apps‌‌ into‌‌one‌‌single‌‌easy-to-use‌‌web‌‌and‌‌mobile‌‌application.‌‌We‌‌decided‌‌to‌‌name‌‌this‌‌app‌‌Hestia‌‌after‌‌ the‌‌Greek‌‌Goddess‌‌of‌‌hearth‌‌and‌‌home‌‌(“Hestia‌‌::‌‌Greek‌‌goddess”,‌‌n.d.).‌‌Hestia‌‌is‌‌meant‌‌to‌‌be‌‌a‌‌ versatile‌ ‌and‌ ‌functional‌ ‌tool‌ ‌suited‌ ‌to‌ ‌all‌ ‌home‌ ‌management‌ ‌needs,‌ ‌which‌ ‌will‌ ‌help‌ ‌the‌ ‌user‌‌ thrive‌‌in‌‌the‌‌modern‌‌world.‌‌We‌‌formed‌‌a‌‌team‌‌consisting‌‌of‌‌Bridger‌‌Peterson,‌‌Liam‌‌Zhou,‌‌Pierce‌‌ Bringhurst,‌‌Thang‌‌Ngyuen,‌‌and‌‌myself‌‌to‌‌make‌‌the‌‌Hestia‌‌application‌‌we‌‌desired‌‌a‌‌reality.‌ ‌ Someone‌ ‌should‌ ‌use‌ ‌Hestia‌ ‌because‌ ‌it‌ ‌will‌ ‌help‌ ‌a‌ ‌user‌ ‌to‌ ‌better‌ ‌manage‌ ‌all‌ ‌aspects‌ ‌of‌‌ their‌ ‌home.‌ ‌Home‌ ‌management‌‌is‌‌a‌‌major‌‌part‌‌of‌‌everyone’s‌‌life‌‌whether‌‌you‌‌live‌‌by‌‌yourself,‌‌ with‌ ‌roommates,‌ ‌or‌ ‌with‌ ‌a‌ ‌family.‌ ‌The‌ ‌U.S.‌ ‌Bureau‌ ‌of‌ ‌Labor‌ ‌Statistics‌ ‌found‌ ‌that‌ ‌in‌ ‌2019‌‌ Americans‌‌spent‌‌1.78‌‌hours‌‌per‌‌day‌‌on‌‌household‌‌management‌‌tasks‌‌on‌‌average‌‌(U.S.‌‌Bureau‌‌of‌‌ Labor‌ ‌Statistics,‌ ‌2020).‌ ‌Hestia‌ ‌will‌ ‌help‌ ‌you‌ ‌take‌‌charge‌‌of‌‌these‌‌home‌‌management‌‌tasks‌‌and‌‌ thus‌ ‌help‌ ‌you‌ ‌better‌ ‌manage‌ ‌your‌ ‌life.‌ ‌Hestia‌ ‌is‌ ‌designed‌ ‌to‌ ‌work‌ ‌for‌ ‌various‌ ‌household‌‌ situations.‌ ‌There‌ ‌is‌ ‌no‌ ‌need‌ ‌to‌ ‌have‌ ‌a‌ ‌family‌ ‌to‌ ‌make‌ ‌Hestia‌ ‌work‌ ‌or‌ ‌even‌ ‌live‌ ‌with‌ ‌others.‌‌ ‌ 18‌ ‌ Everyone‌ ‌is‌ ‌a‌ ‌part‌ ‌of‌ ‌a‌ ‌household,‌ ‌even‌ ‌if‌ ‌it‌ ‌is‌ ‌a‌ ‌household‌ ‌of‌ ‌one.‌ ‌Therefore,‌ ‌Hestia‌ ‌was‌‌ designed‌‌so‌‌that‌‌anyone‌‌can‌‌gain‌‌value‌‌from‌‌it‌‌and‌‌use‌‌it‌‌to‌‌help‌‌improve‌‌their‌‌lives.‌ ‌ Hestia‌‌will‌‌allow‌‌a‌‌user‌‌to‌‌create‌‌and‌‌manage‌‌a‌‌household‌‌calendar,‌‌a‌‌to-do‌‌list,‌‌budgets,‌‌ recipes,‌‌meals,‌‌and‌‌grocery‌‌lists‌‌in‌‌a‌‌single‌‌application.‌‌When‌‌using‌‌Hestia,‌‌a‌‌user‌‌can‌‌invite‌‌new‌‌ users‌ ‌to‌ ‌their‌ ‌household‌ ‌and‌ ‌accept‌ ‌an‌ ‌invitation‌ ‌to‌ ‌an‌ ‌existing‌ ‌household.‌ ‌They‌ ‌can‌ ‌manage‌‌ shared‌ ‌and‌ ‌individual‌ ‌calendars‌ ‌by‌ ‌creating‌ ‌events‌ ‌that‌ ‌involve‌ ‌just‌ ‌them,‌ ‌everyone‌ ‌in‌ ‌the‌‌ household,‌ ‌or‌ ‌a‌ ‌subset‌ ‌of‌ ‌the‌ ‌household.‌ ‌They‌ ‌can‌ ‌create‌ ‌household‌ ‌to-dos‌ ‌and‌ ‌add‌ ‌them‌‌to‌‌a‌‌ to-do‌‌list,‌‌which‌‌can‌‌then‌‌be‌‌checked‌‌off‌‌once‌‌completed.‌‌They‌‌can‌‌use‌‌the‌‌budgeting‌‌feature‌‌to‌‌ make‌ ‌budgets‌ ‌and‌ ‌control‌ ‌who‌ ‌has‌ ‌access‌ ‌to‌ ‌which‌ ‌budgets.‌ ‌Each‌ ‌budget‌ ‌can‌ ‌have‌ ‌multiple‌‌ sources‌‌of‌‌income‌‌and‌‌allows‌‌expenses‌‌to‌‌be‌‌categorized.‌‌Additionally,‌‌a‌‌user‌‌can‌‌use‌‌the‌‌meal‌‌ planning‌‌feature‌‌to‌‌add‌‌recipes‌‌and‌‌create‌‌their‌‌household‌‌recipe‌‌book,‌‌and‌‌then‌‌they‌‌can‌‌choose‌‌ a‌ ‌recipe‌ ‌from‌ ‌this‌ ‌book‌ ‌to‌ ‌schedule‌ ‌a‌ ‌meal‌ ‌on‌ ‌a‌ ‌specific‌ ‌day.‌ ‌Furthermore,‌‌they‌‌can‌‌use‌‌these‌‌ scheduled‌ ‌meals‌ ‌to‌ ‌generate‌ ‌a‌ ‌shopping‌ ‌list‌‌based‌‌on‌‌the‌‌recipe’s‌‌ingredients‌‌and‌‌they‌‌can‌‌add‌‌ additional‌ ‌items‌ ‌to‌ ‌their‌ ‌shopping‌ ‌list‌ ‌as‌ ‌they‌ ‌see‌ ‌fit.‌ ‌Overall,‌ ‌each‌ ‌of‌ ‌these‌ ‌aspects‌ ‌of‌ ‌life‌ ‌is‌‌ essential‌ ‌to‌ ‌household‌ ‌management,‌ ‌and‌ ‌combining‌ ‌them‌ ‌into‌ ‌a‌‌single,‌‌easy-to-use‌‌application‌‌ makes‌‌this‌‌difficult‌‌task‌‌much‌‌more‌‌manageable.‌ ‌.....‌ ‌ In‌‌the‌‌remaining‌‌portion‌‌of‌‌the‌‌document‌‌I‌‌will‌‌focus‌‌entirely‌‌on‌‌the‌‌development‌‌of‌‌the‌‌ Hestia.‌ ‌Every‌ ‌pre-developmental‌ ‌design‌ ‌decision‌ ‌for‌ ‌the‌ ‌application‌ ‌and‌ ‌the‌ ‌development‌‌ timeline‌‌will‌‌be‌‌discussed.‌‌Then,‌‌the‌‌final‌‌product‌‌we‌‌created‌‌for‌‌our‌‌capstone‌‌project‌‌demo‌‌will‌‌ be‌‌shown‌‌off‌‌from‌‌a‌‌user’s‌‌perspective.‌‌After‌‌this‌‌I‌‌will‌‌look‌‌retrospectively‌‌back‌‌at‌‌our‌‌design‌‌ decisions‌‌to‌‌discuss‌‌which‌‌of‌‌them‌‌worked‌‌well‌‌and‌‌which‌‌I‌‌would‌‌change‌‌were‌‌we‌‌to‌‌start‌‌the‌‌ project‌‌again‌‌from‌‌scratch.‌‌Lastly,‌‌the‌‌future‌‌of‌‌Hestia‌‌will‌‌be‌‌discussed‌‌pertaining‌‌to‌‌what‌‌future‌‌ development‌ ‌of‌ ‌the‌‌application‌‌will‌‌look‌‌like‌‌after‌‌this‌‌capstone‌‌project.‌‌The‌‌goal‌‌of‌‌this‌‌thesis‌ ‌ 19‌ ‌ document‌ ‌is‌ ‌give‌ ‌outside‌ ‌the‌ ‌field‌ ‌of‌ ‌Software‌ ‌Development‌ ‌insight‌ ‌into‌ ‌the‌ ‌software‌‌ development‌‌process‌‌and‌‌to‌‌give‌‌those‌‌in‌‌the‌‌field‌‌of‌‌Software‌‌Development‌‌the‌‌ability‌‌to‌‌learn‌‌ from‌‌our‌‌success‌‌and‌‌failures‌‌when‌‌creating‌‌Hestia.‌ ‌ ‌ 20‌ ‌ 2‌‌METHODS‌ ‌ Now‌‌that‌‌we,‌‌as‌‌a‌‌team,‌‌had‌‌decided‌‌on‌‌the‌‌application‌‌we‌‌wanted‌‌to‌‌build,‌‌it‌‌was‌‌time‌‌to‌‌ make‌ ‌our‌ ‌design‌ ‌decisions‌ ‌for‌ ‌developing‌ ‌Hestia.‌ ‌To‌ ‌make‌ ‌these‌ ‌decisions‌ ‌we‌ ‌chose‌ ‌what‌‌we‌‌ thought‌ ‌would‌ ‌be‌ ‌the‌ ‌best‌ ‌approach‌ ‌based‌ ‌on‌ ‌the‌ ‌application‌‌we‌‌had‌‌in‌‌mind.‌‌These‌‌decisions‌‌ formed‌ ‌the‌ ‌methods‌ ‌by‌ ‌which‌ ‌the‌‌entire‌‌software‌‌project‌‌would‌‌be‌‌completed.‌‌Once‌‌again,‌‌the‌‌ design‌ ‌decisions‌ ‌can‌ ‌be‌ ‌divided‌ ‌up‌ ‌into‌ ‌team‌ ‌structure‌‌decisions,‌‌code‌‌structure‌‌decisions,‌‌and‌‌ code‌‌implementation‌‌decisions.‌ ‌ 2.1‌ Team‌‌Structure‌‌Decisions‌‌for‌‌Hestia‌ ‌ The‌‌first‌‌decisions‌‌that‌‌had‌‌to‌‌be‌‌made‌‌to‌‌start‌‌work‌‌on‌‌the‌‌Hestia‌‌application‌‌were‌‌how‌‌ we‌‌wanted‌‌to‌‌develop‌‌the‌‌application.‌‌We‌‌needed‌‌to‌‌decide‌‌the‌‌number‌‌of‌‌backend,‌‌frontend,‌‌and‌‌ full-stack‌ ‌developers‌ ‌we‌ ‌wanted‌ ‌on‌ ‌our‌ ‌team‌ ‌and‌ ‌assign‌ ‌each‌ ‌team‌ ‌member‌ ‌into‌ ‌one‌ ‌of‌ ‌these‌‌ categories‌‌based‌‌on‌‌the‌‌numbers‌‌we‌‌decided.‌‌Then,‌‌we‌‌also‌‌needed‌‌to‌‌decide‌‌which‌‌development‌‌ methodology,‌‌agile‌‌or‌‌waterfall,‌‌we‌‌were‌‌going‌‌to‌‌use‌‌to‌‌create‌‌the‌‌application.‌ ‌ For‌‌the‌‌question‌‌of‌‌the‌‌number‌‌of‌‌each‌‌type‌‌of‌‌developer,‌‌we‌‌decided‌‌that‌‌for‌‌our‌‌team‌‌of‌‌ five‌ ‌we‌ ‌would‌ ‌have‌ ‌two‌ ‌backend‌ ‌developers,‌ ‌three‌ ‌frontend‌ ‌developers,‌ ‌and‌ ‌zero‌ ‌full-stack‌‌ developers.‌ ‌We‌ ‌decided‌ ‌to‌ ‌have‌ ‌no‌ ‌full-stack‌ ‌developers‌‌because‌‌of‌‌the‌‌time‌‌constraints‌‌of‌‌the‌‌ project.‌ ‌In‌ ‌total,‌ ‌we‌ ‌had‌ ‌two‌ ‌semesters‌ ‌to‌ ‌create‌ ‌the‌ ‌Hestia‌ ‌application‌ ‌which‌ ‌correlates‌ ‌to‌‌ roughly‌‌6‌‌months‌‌of‌‌development‌‌time.‌‌In‌‌order‌‌to‌‌get‌‌the‌‌largest‌‌amount‌‌of‌‌work‌‌we‌‌wanted‌‌to‌‌ leverage‌ ‌skills‌ ‌we‌ ‌already‌ ‌had,‌ ‌and‌ ‌to‌ ‌spend‌ ‌as‌ ‌little‌ ‌time‌‌learning‌‌new‌‌programming‌‌skills‌‌as‌‌ possible.‌ ‌Any‌ ‌time‌ ‌spent‌ ‌on‌ ‌this‌ ‌would‌ ‌be‌ ‌time‌ ‌not‌ ‌spent‌ ‌developing‌ ‌the‌ ‌application‌ ‌and‌‌ therefore‌‌we‌‌decided‌‌against‌‌having‌‌anyone‌‌on‌‌the‌‌team‌‌becoming‌‌a‌‌full-stack‌‌developer.‌‌By‌‌not‌‌ having‌ ‌any‌ ‌full-stack‌ ‌developers‌ ‌we‌ ‌were‌ ‌able‌‌to‌‌assign‌‌team‌‌members‌‌into‌‌roles‌‌based‌‌on‌‌the‌‌ ‌ 21‌ ‌ type‌ ‌of‌ ‌programming‌ ‌they‌ ‌are‌ ‌already‌ ‌very‌ ‌skilled‌ ‌at.‌ ‌This‌ ‌would‌ ‌help‌ ‌us‌ ‌develop‌ ‌the‌ ‌app‌‌ quicker‌‌which‌‌we‌‌felt‌‌would‌‌lead‌‌to‌‌the‌‌best‌‌final‌‌product‌‌we‌‌could‌‌create‌‌in‌‌the‌‌time‌‌frame.‌ ‌ Then,‌ ‌we‌ ‌decided‌ ‌on‌ ‌a‌ ‌2‌ ‌to‌ ‌3‌ ‌split‌ ‌of‌ ‌back-end‌ ‌to‌‌front-end‌‌developers‌‌for‌‌a‌‌couple‌‌of‌‌ reasons.‌ ‌Firstly,‌ ‌we‌ ‌felt‌ ‌like‌ ‌having‌ ‌more‌ ‌frontend‌ ‌developers‌ ‌was‌‌necessary‌‌because‌‌since‌‌we‌‌ wanted‌‌to‌‌make‌‌Hestia‌‌both‌‌a‌‌web‌‌and‌‌mobile‌‌application‌‌there‌‌would‌‌be‌‌more‌‌places‌‌where‌‌the‌‌ user‌ ‌would‌ ‌interact‌ ‌with‌ ‌the‌ ‌application‌ ‌which‌ ‌requires‌ ‌more‌ ‌frontend‌ ‌developers‌ ‌to‌ ‌create.‌‌ These‌ ‌3‌ ‌frontend‌ ‌developers‌ ‌were‌ ‌divided‌ ‌up‌ ‌into‌ ‌different‌ ‌roles‌ ‌based‌ ‌on‌ ‌the‌ ‌part‌ ‌of‌ ‌the‌‌ application.‌‌This‌‌meant‌‌that‌‌we‌‌had‌‌1‌‌frontend‌‌developer‌‌working‌‌on‌‌the‌‌mobile‌‌application‌‌and‌‌ 2‌ ‌frontend‌ ‌developers‌ ‌working‌ ‌on‌ ‌the‌ ‌web‌ ‌application‌ ‌since‌ ‌we‌ ‌felt‌ ‌like‌ ‌the‌ ‌web‌ ‌application‌‌ would‌ ‌be‌ ‌more‌ ‌complex‌ ‌than‌ ‌the‌ ‌web‌ ‌application.‌ ‌Then,‌ ‌the‌ ‌other‌ ‌reason‌ ‌we‌ ‌decided‌ ‌on‌ ‌this‌‌ specific‌‌2‌‌to‌‌3‌‌split‌‌of‌‌back-end‌‌to‌‌front-end‌‌developers‌‌was‌‌because‌‌of‌‌the‌‌developers‌‌we‌‌had‌‌on‌‌ the‌ ‌team.‌ ‌We‌ ‌had‌ ‌two‌ ‌team‌ ‌members‌‌who‌‌were‌‌most‌‌comfortable‌‌with‌‌backend‌‌programming,‌‌ two‌‌team‌‌members‌‌who‌‌were‌‌most‌‌comfortable‌‌with‌‌front-end‌‌web‌‌programming,‌‌and‌‌one‌‌team‌‌ member‌ ‌who‌ ‌was‌ ‌most‌ ‌comfortable‌ ‌with‌ ‌either‌ ‌front-end‌ ‌web‌ ‌or‌ ‌mobile‌ ‌programming.‌‌ Therefore,‌ ‌this‌ ‌split‌ ‌of‌ ‌2‌ ‌backend‌ ‌developers,‌ ‌2‌ ‌front-end‌ ‌web‌ ‌developers,‌ ‌and‌ ‌1‌ ‌front-end‌‌ mobile‌ ‌developer‌ ‌also‌ ‌fits‌ ‌in‌ ‌very‌ ‌well‌ ‌with‌ ‌the‌ ‌strengths‌ ‌of‌ ‌each‌ ‌team‌ ‌member.‌‌By‌‌using‌‌the‌‌ strengths‌‌of‌‌each‌‌team‌‌member‌‌we‌‌would‌‌be‌‌able‌‌to‌‌develop‌‌features‌‌for‌‌the‌‌application‌‌quicker‌‌ and‌‌decrease‌‌the‌‌amount‌‌of‌‌time‌‌learning‌‌and‌‌not‌‌developing.‌‌ ‌ After‌ ‌this‌ ‌deliberation‌ ‌on‌ ‌how‌ ‌to‌ ‌divide‌ ‌up‌ ‌the‌ ‌team‌ ‌each‌ ‌of‌ ‌the‌ ‌team‌ ‌members‌ ‌was‌‌ assigned‌‌their‌‌roles.‌‌Since‌‌the‌‌numbers‌‌lined‌‌up‌‌each‌‌team‌‌member‌‌was‌‌assigned‌‌their‌‌role‌‌based‌‌ on‌ ‌the‌ ‌type‌ ‌of‌ ‌programming‌ ‌they‌ ‌were‌ ‌the‌ ‌most‌ ‌comfortable‌‌with.‌‌Bridger‌‌and‌‌I‌‌would‌‌be‌‌the‌‌ backend‌‌developers‌‌for‌‌the‌‌team,‌‌Liam‌‌and‌‌Pierce‌‌would‌‌be‌‌the‌‌frontend‌‌web‌‌developers‌‌of‌‌the‌‌ team,‌‌and‌‌Thang‌‌would‌‌be‌‌the‌‌sole‌‌frontend‌‌mobile‌‌developer‌‌for‌‌the‌‌team.‌ ‌ ‌ 22‌ ‌ After‌ ‌these‌ ‌roles‌ ‌were‌ ‌assigned‌ ‌the‌ ‌team‌ ‌had‌ ‌to‌ ‌determine‌ ‌which‌ ‌software‌ ‌design‌‌ methodology‌ ‌should‌ ‌be‌ ‌used‌ ‌to‌ ‌develop‌ ‌Hestia.‌ ‌Ultimately,‌ ‌through‌ ‌a‌‌unanimous‌‌decision,‌‌the‌‌ team‌‌decided‌‌to‌‌use‌‌the‌‌agile‌‌framework‌‌because‌‌it‌‌aligned‌‌itself‌‌much‌‌more‌‌with‌‌the‌‌application‌‌ we‌‌planned‌‌on‌‌developing.‌‌ ‌ For‌ ‌starters,‌ ‌the‌ ‌agile‌ ‌approach‌ ‌seemed‌ ‌better‌ ‌because‌ ‌this‌ ‌was‌ ‌a‌ ‌very‌ ‌large-scale‌‌ software‌‌project‌‌which‌‌meant‌‌that‌‌scoping‌‌out‌‌every‌‌design‌‌requirement‌‌at‌‌the‌‌beginning‌‌of‌‌the‌‌ project‌‌would‌‌be‌‌infeasible‌‌and‌‌this‌‌would‌‌be‌‌required‌‌with‌‌the‌‌waterfall‌‌approach.‌‌Furthermore,‌‌ the‌ ‌concept‌ ‌of‌ ‌flexible,‌ ‌iterative‌ ‌development‌ ‌of‌ ‌the‌ ‌agile‌ ‌framework‌ ‌was‌ ‌much‌ ‌more‌ ‌aligned‌‌ with‌ ‌our‌ ‌vision‌ ‌for‌ ‌Hestia.‌ ‌We‌ ‌viewed‌ ‌Hestia‌ ‌as‌ ‌not‌ ‌just‌ ‌one‌ ‌app,‌‌but‌‌a‌‌collection‌‌of‌‌different‌‌ apps‌‌put‌‌together‌‌as‌‌each‌‌feature‌‌of‌‌the‌‌Hestia‌‌application‌‌(budgeting,‌‌calendar,‌‌to-dos,‌‌and‌‌meal‌‌ planning)‌‌could‌‌theoretically‌‌stand‌‌on‌‌its‌‌own‌‌as‌‌its‌‌application.‌‌Therefore,‌‌it‌‌made‌‌sense‌‌to‌‌view‌‌ the‌ ‌development‌ ‌of‌ ‌Hestia‌ ‌iteratively‌ ‌with‌ ‌each‌ ‌new‌ ‌feature‌ ‌being‌ ‌a‌ ‌new‌ ‌iteration‌ ‌on‌ ‌the‌‌ application‌ ‌making‌ ‌it‌ ‌better‌ ‌and‌ ‌more‌ ‌complete.‌ ‌Additionally,‌ ‌this‌ ‌concept‌ ‌of‌ ‌iterative‌‌ development‌ ‌also‌ ‌aligned‌ ‌very‌ ‌well‌ ‌with‌ ‌our‌ ‌vision‌ ‌of‌ ‌Hestia‌ ‌because‌‌we‌‌as‌‌a‌‌team‌‌view‌‌it‌‌as‌‌ something‌ ‌that‌ ‌would‌ ‌never‌ ‌be‌ ‌truly‌ ‌finished.‌ ‌There‌ ‌will‌ ‌always‌ ‌be‌ ‌features‌ ‌to‌ ‌add‌ ‌and‌‌ improvements‌ ‌that‌ ‌could‌ ‌be‌ ‌made‌ ‌and‌ ‌the‌ ‌agile‌ ‌framework‌ ‌allows‌ ‌us‌ ‌to‌ ‌keep‌ ‌this‌‌view‌‌of‌‌the‌‌ application‌‌while‌‌still‌‌delivering‌‌a‌‌great‌‌final‌‌product‌‌even‌‌though‌‌it‌‌isn’t‌‌truly‌‌“complete”.‌ ‌ With‌‌the‌‌agile‌‌framework‌‌decided‌‌upon‌‌it‌‌was‌‌now‌‌important‌‌to‌‌understand‌‌how‌‌the‌‌team‌‌ would‌ ‌perform‌ ‌each‌ ‌of‌ ‌the‌ ‌repeating‌ ‌6‌ ‌phases‌ ‌of‌ ‌the‌ ‌agile‌ ‌development‌ ‌process.‌ ‌First,‌ ‌in‌ ‌the‌‌ requirements‌‌phase,‌‌our‌‌team‌‌would‌‌meet‌‌together‌‌to‌‌determine‌‌which‌‌aspect‌‌of‌‌the‌‌application‌‌ should‌‌be‌‌prioritized‌‌whether‌‌that‌‌was‌‌adding‌‌a‌‌new‌‌feature‌‌or‌‌fixing‌‌an‌‌existing‌‌bug‌‌in‌‌the‌‌code.‌‌ Based‌ ‌on‌ ‌these‌ ‌priorities‌ ‌each‌ ‌team‌ ‌member‌ ‌would‌ ‌decide‌ ‌what‌ ‌they‌ ‌would‌ ‌work‌ ‌on‌ ‌for‌ ‌the‌‌ upcoming‌‌week‌‌and‌‌announce‌‌this‌‌decision‌‌to‌‌the‌‌rest‌‌of‌‌the‌‌team.‌‌Then,‌‌the‌‌team‌‌would‌‌move‌‌ ‌ 23‌ ‌ into‌‌the‌‌design‌‌phase‌‌in‌‌which‌‌each‌‌team‌‌member‌‌would‌‌make‌‌decisions‌‌about‌‌how‌‌they‌‌wanted‌ to‌ ‌implement‌ ‌what‌ ‌they‌ ‌had‌ ‌decided‌ ‌to‌ ‌work‌ ‌on‌ ‌in‌ ‌the‌ ‌requirements‌ ‌phases.‌ ‌Then,‌ ‌in‌ ‌the‌‌ development‌ ‌phase,‌ ‌each‌ ‌team‌ ‌member‌ ‌would‌ ‌implement‌ ‌changes‌ ‌to‌ ‌the‌ ‌code‌ ‌based‌ ‌on‌ ‌the‌‌ decisions‌‌made‌‌in‌‌the‌‌design‌‌phase.‌‌Next,‌‌in‌‌the‌‌testing‌‌phase,‌‌the‌‌application‌‌would‌‌be‌‌tested‌‌to‌‌ make‌‌sure‌‌the‌‌code‌‌that‌‌the‌‌team‌‌member‌‌added‌‌or‌‌modified‌‌was‌‌working‌‌as‌‌intended.‌‌After‌‌the‌‌ testing‌ ‌had‌ ‌been‌ ‌done‌ ‌we‌‌as‌‌a‌‌team‌‌combined‌‌the‌‌deployment‌‌and‌‌review‌‌phase.‌‌In‌‌this‌‌phase,‌‌ the‌ ‌code‌ ‌would‌ ‌be‌ ‌reviewed‌ ‌by‌ ‌a‌ ‌fellow‌ ‌team‌ ‌member‌ ‌and‌ ‌if‌ ‌approved‌ ‌the‌ ‌code‌ ‌would‌ ‌be‌‌ deployed‌ ‌and‌ ‌would‌ ‌be‌ ‌permanently‌ ‌made‌ ‌a‌ ‌part‌ ‌of‌ ‌the‌ ‌codebase.‌ ‌After‌‌this,‌‌the‌‌requirements‌‌ would‌‌be‌‌reanalyzed‌‌and‌‌the‌‌cycle‌‌would‌‌continue‌‌again.‌‌ ‌ Another‌ ‌important‌ ‌aspect‌ ‌of‌ ‌our‌ ‌agile‌ ‌approach‌ ‌was‌ ‌that‌ ‌the‌ ‌testing‌ ‌standard‌ ‌for‌ ‌each‌‌ team‌ ‌member‌ ‌was‌ ‌different‌ ‌based‌ ‌on‌ ‌the‌ ‌role‌ ‌they‌ ‌had‌ ‌been‌ ‌assigned.‌ ‌For‌ ‌the‌ ‌front-end‌‌ developers,‌ ‌we‌ ‌as‌ ‌a‌ ‌team‌ ‌decided‌ ‌that‌ ‌manual‌ ‌testing‌ ‌would‌ ‌be‌ ‌enough,‌ ‌meaning‌ ‌that‌ ‌the‌‌ developers‌ ‌would‌ ‌run‌ ‌the‌‌code‌‌and‌‌observe‌‌the‌‌application's‌‌behavior,‌‌and‌‌if‌‌it‌‌was‌‌working‌‌as‌‌ intended‌‌it‌‌was‌‌deemed‌‌to‌‌be‌‌good.‌‌Then,‌‌for‌‌the‌‌backend‌‌developers‌‌the‌‌manual‌‌testing‌‌was‌‌still‌‌ required‌ ‌but‌ ‌so‌ ‌were‌ ‌unit‌ ‌tests‌ ‌which‌ ‌are‌ ‌coded‌ ‌tests‌ ‌that‌ ‌can‌ ‌be‌ ‌run‌ ‌separately‌ ‌from‌ ‌the‌‌ application‌ ‌to‌ ‌test‌ ‌individual‌‌small‌‌portions‌‌of‌‌the‌‌code‌‌to‌‌ensure‌‌it‌‌is‌‌working‌‌correctly.‌‌These‌‌ unit‌ ‌tests‌ ‌were‌ ‌not‌ ‌a‌‌requirement‌‌on‌‌the‌‌frontend‌‌because‌‌they‌‌are‌‌much‌‌harder‌‌to‌‌write‌‌on‌‌the‌‌ frontend‌‌and‌‌not‌‌nearly‌‌as‌‌useful.‌‌Oftentimes,‌‌coded‌‌frontend‌‌unit‌‌tests‌‌will‌‌say‌‌there‌‌is‌‌an‌‌error‌‌ simply‌ ‌due‌ ‌to‌ ‌timing‌ ‌issues‌ ‌and‌ ‌not‌ ‌issues‌ ‌with‌ ‌the‌ ‌code‌ ‌itself‌ ‌but‌ ‌this‌ ‌is‌ ‌not‌ ‌a‌ ‌problem‌ ‌with‌‌ backend‌‌unit‌‌tests‌‌since‌‌they‌‌simply‌‌test‌‌logic‌‌and‌‌therefore‌‌don’t‌‌rely‌‌on‌‌any‌‌specific‌‌timing‌‌to‌‌ work‌‌correctly.‌ ‌ Overall,‌‌our‌‌agile‌‌approach‌‌combined‌‌with‌‌the‌‌roles‌‌assigned‌‌to‌‌each‌‌team‌‌member‌‌made‌‌ our‌ ‌team‌ ‌a‌ ‌very‌ ‌cohesive‌ ‌unit‌ ‌while‌ ‌also‌ ‌allowing‌ ‌each‌ ‌team‌ ‌member‌ ‌to‌ ‌have‌ ‌a‌‌clear‌‌view‌‌of‌‌ ‌ 24‌ ‌ what‌‌they‌‌were‌‌responsible‌‌for.‌‌These‌‌team‌‌dynamics‌‌were‌‌very‌‌helpful‌‌throughout‌‌the‌‌project‌‌to‌‌ help‌ ‌us‌ ‌make‌ ‌consistent‌ ‌progress‌ ‌on‌ ‌the‌ ‌application.‌ ‌These‌ ‌decisions‌ ‌made‌ ‌it‌ ‌so‌ ‌that‌ ‌all‌ ‌team‌‌ members‌‌were‌‌always‌‌very‌‌aware‌‌of‌‌what‌‌was‌‌being‌‌worked‌‌on‌‌and‌‌well‌‌equipped‌‌for‌‌all‌‌tasks‌‌ that‌ ‌they‌ ‌were‌ ‌assigned.‌ ‌This‌ ‌created‌ ‌a‌ ‌smooth‌ ‌development‌ ‌process‌ ‌which‌ ‌is‌ ‌essential‌ ‌for‌‌ creating‌‌a‌‌successful‌‌final‌‌product.‌ ‌ 2.2‌‌ Code‌‌Structure‌‌Decisions‌‌for‌‌Hestia‌ ‌ After‌‌the‌‌team‌‌structure‌‌had‌‌been‌‌decided‌‌it‌‌became‌‌important‌‌to‌‌decide‌‌how‌‌to‌‌structure‌‌ the‌ ‌code‌ ‌so‌ ‌that‌ ‌it‌ ‌could‌ ‌operate‌ ‌as‌ ‌we‌ ‌intended‌ ‌with‌ ‌as‌ ‌few‌ ‌development‌ ‌pains‌ ‌as‌ ‌possible.‌‌ These‌ ‌code‌ ‌structure‌ ‌decisions‌ ‌would‌ ‌involve‌ ‌determining‌ ‌whether‌ ‌or‌ ‌not‌ ‌the‌ ‌front-end‌ ‌and‌‌ back-end‌ ‌should‌ ‌be‌ ‌separated‌ ‌and‌ ‌if‌ ‌so‌ ‌how‌ ‌they‌ ‌should‌ ‌be‌ ‌separated.‌ ‌Then,‌ ‌they‌ ‌would‌ ‌also‌‌ determine‌‌how‌‌we‌‌would‌‌deploy‌‌our‌‌code‌‌so‌‌that‌‌it‌‌is‌‌usable‌‌without‌‌having‌‌to‌‌make‌‌a‌‌user‌‌run‌‌ the‌‌source‌‌code‌‌themselves.‌ ‌ Early‌ ‌on‌ ‌our‌ ‌team‌ ‌decided‌ ‌to‌ ‌completely‌ ‌separate‌ ‌the‌ ‌frontend‌ ‌and‌ ‌backend‌ ‌of‌ ‌the‌‌ application,‌‌even‌‌before‌‌we‌‌had‌‌considered‌‌the‌‌frameworks‌‌we‌‌would‌‌use‌‌for‌‌code‌‌development.‌‌ We‌‌felt‌‌like‌‌the‌‌code‌‌would‌‌be‌‌complex‌‌enough‌‌that‌‌it‌‌was‌‌extremely‌‌necessary‌‌to‌‌separate‌‌these‌‌ components‌‌into‌‌separate‌‌code‌‌bases.‌‌Doing‌‌this‌‌would‌‌help‌‌promote‌‌the‌‌separation‌‌of‌‌concerns‌‌ within‌ ‌our‌‌project‌‌which‌‌would‌‌help‌‌the‌‌development‌‌process‌‌overall.‌‌We‌‌even‌‌took‌‌this‌‌a‌‌step‌‌ further‌ ‌and‌ ‌instead‌ ‌of‌ ‌just‌ ‌simply‌ ‌separating‌ ‌our‌ ‌application‌ ‌into‌ ‌frontend‌ ‌and‌ ‌backend‌ ‌we‌‌ separated‌ ‌it‌ ‌into‌ ‌six‌ ‌different‌ ‌pieces‌ ‌each‌ ‌with‌‌its‌‌concern.‌‌The‌‌six‌‌separate‌‌components‌‌of‌‌the‌‌ application‌ ‌were‌ ‌the‌ ‌main‌ ‌Hestia‌ ‌database,‌ ‌the‌ ‌backend‌ ‌web‌ ‌API,‌‌the‌‌identity‌‌server‌‌database,‌‌ the‌‌identity‌‌server,‌‌the‌‌frontend‌‌web‌‌application,‌‌and‌‌the‌‌frontend‌‌mobile‌‌application.‌‌The‌‌main‌‌ concern‌ ‌of‌ ‌the‌ ‌Hestia‌ ‌database‌ ‌was‌‌to‌‌store‌‌information‌‌about‌‌a‌‌user’s‌‌information,‌‌household,‌‌ budget,‌ ‌to-do‌ ‌list,‌ ‌calendar,‌ ‌meals,‌ ‌recipes,‌ ‌and‌ ‌grocery‌ ‌list.‌ ‌Then,‌ ‌the‌ ‌main‌ ‌concern‌ ‌of‌ ‌the‌‌ ‌ 25‌ ‌ backend‌ ‌web‌ ‌API‌ ‌was‌ ‌to‌ ‌handle‌ ‌retrieving,‌ ‌creating,‌ ‌modifying,‌‌and‌‌deleting‌‌data‌‌in‌‌our‌‌main‌‌ Hestia‌‌database.‌‌Then,‌‌in‌‌order‌‌to‌‌spec‌‌out‌‌endpoints‌‌needed‌‌for‌‌our‌‌API‌‌we‌‌reviewed‌‌the‌‌needs‌‌ of‌‌the‌‌front-end‌‌of‌‌the‌‌Hestia‌‌application‌‌which‌‌would‌‌be‌‌using‌‌the‌‌API.‌‌Next,‌‌the‌‌main‌‌concern‌‌ of‌ ‌the‌ ‌identity‌ ‌server‌ ‌database‌ ‌was‌ ‌to‌ ‌store‌ ‌user‌ ‌login‌ ‌credentials.‌ ‌Then,‌ ‌the‌ ‌identity‌ ‌server,‌‌ which‌ ‌operates‌ ‌as‌ ‌its‌ ‌own‌ ‌web‌ ‌application,‌ ‌had‌ ‌the‌ ‌job‌ ‌of‌ ‌creating‌ ‌Hestia‌ ‌accounts‌ ‌and‌‌ authenticating‌ ‌login‌ ‌attempts‌ ‌by‌ ‌storing‌ ‌data‌ ‌and‌ ‌checking‌ ‌against‌ ‌data‌ ‌stored‌ ‌in‌ ‌the‌ ‌identity‌‌ server‌ ‌database.‌ ‌The‌ ‌frontend‌ ‌web‌ ‌application‌ ‌had‌ ‌the‌ ‌concern‌ ‌of‌ ‌creating‌ ‌everything‌‌the‌‌user‌‌ sees‌ ‌in‌‌the‌‌web‌‌portal‌‌(web‌‌application).‌‌Lastly,‌‌the‌‌frontend‌‌mobile‌‌application‌‌was‌‌concerned‌‌ with‌ ‌creating‌ ‌everything‌ ‌the‌ ‌user‌ ‌sees‌ ‌on‌ ‌the‌ ‌mobile‌ ‌apps.‌ ‌These‌ ‌six‌ ‌separate‌ ‌components‌ ‌all‌‌ would‌‌work‌‌together‌‌to‌‌make‌‌Hestia‌‌operate‌‌exactly‌‌as‌‌intended.‌‌ ‌ The‌‌communication‌‌diagram‌‌documenting‌‌how‌‌each‌‌component‌‌interacts‌‌with‌‌each‌‌other‌‌ to‌‌make‌‌Hestia‌‌work‌‌is‌‌shown‌‌in‌‌Fig.‌‌3.‌‌This‌‌diagram‌‌shows‌‌how‌‌the‌‌components‌‌interact‌‌with‌‌ each‌‌other‌‌for‌‌example‌‌when‌‌logging‌‌in‌‌or‌‌creating‌‌an‌‌account‌‌on‌‌the‌‌web‌‌or‌‌mobile‌‌the‌‌user‌‌is‌‌ automatically‌‌redirected‌‌to‌‌the‌‌Identity‌‌server‌‌which‌‌is‌‌its‌‌stand-alone‌‌application.‌‌Then,‌‌on‌‌the‌‌ identity‌ ‌server,‌ ‌the‌ ‌user‌ ‌will‌ ‌enter‌ ‌in‌ ‌their‌ ‌information‌ ‌to‌ ‌login‌ ‌in‌ ‌or‌ ‌create‌ ‌the‌ ‌account.‌ ‌For‌‌ account‌ ‌creation,‌ ‌the‌ ‌user‌ ‌will‌ ‌enter‌ ‌in‌ ‌their‌ ‌information‌ ‌including‌ ‌an‌ ‌email,‌ ‌username,‌ ‌and‌‌ password.‌ ‌This‌ ‌information‌ ‌is‌ ‌then‌ ‌stored‌ ‌in‌ ‌the‌ ‌identity‌ ‌server’s‌ ‌database‌ ‌encrypted‌ ‌so‌ ‌that‌‌a‌‌ user’s‌ ‌actual‌ ‌password‌ ‌will‌ ‌never‌‌be‌‌exposed.‌‌If‌‌this‌‌account‌‌creation‌‌is‌‌successful‌‌the‌‌Identity‌‌ server‌‌contacts‌‌the‌‌web‌‌API‌‌to‌‌tell‌‌it‌‌to‌‌create‌‌the‌‌user‌‌in‌‌the‌‌main‌‌Hestia‌‌database.‌‌This‌‌finishes‌‌ the‌ ‌account‌ ‌creation‌ ‌process‌ ‌and‌ ‌the‌ ‌user‌ ‌is‌ ‌now‌ ‌logged‌ ‌in‌ ‌and‌ ‌is‌ ‌redirected‌ ‌back‌ ‌to‌ ‌the‌‌ application‌ ‌they‌ ‌came‌ ‌from‌ ‌(web‌ ‌or‌ ‌mobile)‌ ‌with‌ ‌the‌‌user‌‌information‌‌attached‌‌at‌‌which‌‌point‌‌ they‌‌can‌‌start‌‌using‌‌the‌‌app.‌‌If‌‌the‌‌user‌‌already‌‌has‌‌an‌‌account‌‌they‌‌will‌‌use‌‌the‌‌identity‌‌server‌‌to‌‌ log‌‌in.‌‌To‌‌do‌‌this‌‌they‌‌will‌‌enter‌‌their‌‌username‌‌and‌‌password‌‌and‌‌the‌‌password‌‌is‌‌encrypted‌‌and‌‌ ‌ 26‌ ‌ compared‌ ‌to‌‌the‌‌encrypted‌‌password‌‌stored‌‌in‌‌the‌‌Identity‌‌server‌‌database‌‌for‌‌that‌‌username.‌‌If‌‌ these‌‌encrypted‌‌passwords‌‌match‌‌the‌‌login‌‌attempt‌‌is‌‌successful‌‌and‌‌the‌‌Identity‌‌server‌‌requests‌‌ the‌‌web‌‌API‌‌to‌‌retrieve‌‌the‌‌user’s‌‌information.‌‌At‌‌this‌‌point,‌‌the‌‌user‌‌is‌‌logged‌‌in‌‌and‌‌redirected‌‌ back‌‌to‌‌the‌‌application‌‌they‌‌came‌‌from‌‌with‌‌the‌‌user‌‌information‌‌attached‌‌so‌‌they‌‌can‌‌start‌‌using‌‌ the‌ ‌application‌ ‌at‌ ‌which‌ ‌point‌ ‌they‌ ‌can‌ ‌start‌ ‌using‌‌the‌‌app.‌‌Then,‌‌once‌‌logged‌‌in‌‌both‌‌the‌‌web‌‌ and‌‌mobile‌‌applications‌‌operate‌‌in‌‌the‌‌same‌‌way‌‌by‌‌making‌‌requests‌‌to‌‌the‌‌web‌‌API‌‌to‌‌retrieve‌‌ information‌‌about‌‌the‌‌user’s‌‌budgets,‌‌to-do‌‌list,‌‌calendar,‌‌recipes,‌‌meals,‌‌and‌‌grocery‌‌list‌‌that‌‌are‌‌ stored‌‌in‌‌the‌‌database‌‌so‌‌that‌‌these‌‌items‌‌can‌‌be‌‌displayed‌‌on‌‌the‌‌application.‌‌The‌‌user‌‌will‌‌use‌‌ the‌ ‌application‌ ‌to‌ ‌create,‌ ‌modify,‌ ‌or‌ ‌delete‌ ‌data‌ ‌and‌‌each‌‌time‌‌they‌‌do‌‌this‌‌the‌‌application‌‌will‌‌ request‌ ‌the‌‌web‌‌API‌‌create,‌‌modify,‌‌or‌‌delete‌‌data‌‌stored‌‌in‌‌the‌‌database‌‌for‌‌that‌‌user.‌‌The‌‌web‌‌ API‌‌listens‌‌to‌‌these‌‌requests‌‌and‌‌changes‌‌the‌‌data‌‌stored‌‌in‌‌the‌‌database‌‌accordingly.‌‌This‌‌is‌‌how‌‌ the‌ ‌different‌ ‌components‌ ‌of‌ ‌Hestia‌ ‌interact‌ ‌to‌ ‌make‌ ‌the‌ ‌application‌ ‌work.‌ ‌Separating‌ ‌the‌‌ components‌‌in‌‌this‌‌way‌‌was‌‌a‌‌good‌‌route‌‌to‌‌take‌‌because‌‌it‌‌allows‌‌our‌‌identity‌‌(login)‌‌server‌‌to‌‌ be‌ ‌reused‌ ‌if‌ ‌we‌ ‌decided‌ ‌to‌ ‌create‌ ‌more‌ ‌applications‌ ‌under‌ ‌the‌ ‌Hestia‌ ‌brand.‌ ‌Furthermore,‌‌and‌‌ more‌‌importantly,‌‌it‌‌allows‌‌the‌‌mobile‌‌and‌‌web‌‌applications‌‌to‌‌use‌‌the‌‌same‌‌backend‌‌code‌‌thus‌‌ decreasing‌‌the‌‌need‌‌for‌‌code‌‌duplication‌‌in‌‌the‌‌project.‌ ‌ Based‌ ‌on‌ ‌the‌ ‌main‌ ‌concern‌ ‌of‌ ‌each‌ ‌component‌ ‌of‌ ‌the‌ ‌application‌ ‌we‌ ‌divided‌ ‌out‌ ‌who‌‌ would‌ ‌be‌ ‌responsible‌ ‌for‌ ‌which‌ ‌components‌ ‌based‌ ‌on‌ ‌the‌ ‌roles‌ ‌they‌ ‌have‌ ‌been‌ ‌assigned.‌ ‌The‌‌ only‌ ‌components‌ ‌of‌ ‌the‌ ‌application‌ ‌that‌ ‌there‌ ‌was‌ ‌ambiguity‌ ‌about‌ ‌who‌‌should‌‌be‌‌assigned‌‌to‌‌ control‌ ‌of‌ ‌it‌ ‌were‌ ‌the‌ ‌Identity‌ ‌Server‌ ‌and‌ ‌the‌ ‌Identity‌ ‌Server‌ ‌database.‌ ‌These‌ ‌components‌‌ together‌ ‌involved‌ ‌both‌ ‌front-end‌ ‌and‌ ‌back-end‌ ‌tasks‌ ‌and‌ ‌these‌ ‌tasks‌ ‌weren’t‌ ‌large‌ ‌enough‌ ‌to‌‌ assign‌ ‌to‌ ‌multiple‌ ‌developers.‌ ‌Furthermore,‌ ‌it‌ ‌was‌ ‌also‌ ‌decided‌ ‌that‌ ‌whoever‌ ‌developed‌ ‌the‌‌ Identity‌‌server‌‌should‌‌also‌‌control‌‌the‌‌Identity‌‌Server‌‌database‌‌since‌‌they‌‌are‌‌so‌‌closely‌‌related.‌‌ ‌ 27‌ ‌ In‌ ‌the‌ ‌end,‌ ‌Pierce‌ ‌took‌ ‌control‌ ‌of‌ ‌these‌ ‌components‌ ‌of‌‌the‌‌application‌‌because‌‌he‌‌was‌‌the‌‌one‌‌ that‌ ‌knew‌ ‌the‌ ‌most‌ ‌about‌ ‌setting‌ ‌up‌ ‌an‌ ‌Identity‌ ‌server‌ ‌for‌ ‌user‌ ‌authentication.‌ ‌Therefore,‌ ‌the‌‌ following‌‌assignments‌‌were‌‌made‌‌for‌‌each‌‌component:‌‌Thang‌‌would‌‌work‌‌on‌‌the‌‌Hestia‌‌mobile‌‌ application,‌ ‌Liam‌ ‌and‌ ‌Pierce‌ ‌would‌ ‌work‌ ‌on‌ ‌the‌ ‌web‌ ‌application,‌ ‌Pierce‌ ‌would‌ ‌work‌ ‌on‌ ‌the‌‌ Identity‌ ‌server,‌ ‌Pierce‌ ‌would‌ ‌work‌ ‌on‌ ‌the‌ ‌Identity‌ ‌server‌ ‌database,‌ ‌Bridger‌ ‌and‌ ‌myself‌ ‌would‌‌ work‌‌on‌‌the‌‌web‌‌API,‌‌and‌‌I‌‌would‌‌work‌‌on‌‌the‌‌main‌‌Hestia‌‌database.‌ ‌ ‌ Fig.‌‌3‌‌-‌‌Hestia‌‌Communication‌‌Diagram‌ ‌ ‌ 28‌ ‌ Now‌ ‌that‌ ‌we‌ ‌had‌ ‌decided‌ ‌how‌ ‌to‌ ‌divide‌ ‌up‌ ‌our‌ ‌application‌ ‌into‌ ‌these‌ ‌six‌ ‌separate‌‌ components‌ ‌we‌ ‌then‌ ‌decided‌ ‌how‌ ‌to‌ ‌deploy‌ ‌each‌ ‌component.‌ ‌For‌‌this‌‌problem,‌‌we‌‌decided‌‌to‌‌ use‌ ‌Microsoft‌ ‌Azure‌ ‌to‌ ‌deploy‌ ‌everything‌ ‌except‌ ‌the‌ ‌mobile‌ ‌application.‌ ‌We‌ ‌chose‌ ‌to‌ ‌use‌‌ Microsoft‌ ‌Azure‌ ‌because‌ ‌it‌ ‌was‌‌cheaper‌‌than‌‌AWS‌‌and‌‌seemed‌‌like‌‌it‌‌would‌‌be‌‌simpler‌‌to‌‌use‌‌ than‌‌Google‌‌Cloud.‌‌Then,‌‌we‌‌chose‌‌to‌‌deploy‌‌everything‌‌we‌‌could‌‌on‌‌Microsoft‌‌Azure‌‌because‌‌ it‌ ‌made‌ ‌more‌ ‌sense‌ ‌to‌ ‌have‌ ‌everything‌ ‌deployed‌ ‌by‌ ‌the‌ ‌same‌ ‌service‌ ‌than‌ ‌to‌ ‌mix‌ ‌and‌ ‌match‌‌ services.‌ ‌The‌ ‌web‌ ‌API,‌ ‌web‌ ‌application,‌ ‌and‌ ‌Identity‌ ‌server‌ ‌all‌ ‌are‌ ‌deployed‌ ‌as‌ ‌app‌ ‌services‌‌ while‌ ‌the‌‌main‌‌Hestia‌‌database‌‌and‌‌the‌‌Identity‌‌server‌‌database‌‌are‌‌both‌‌deployed‌‌as‌‌Microsoft‌‌ SQL‌‌databases.‌‌The‌‌mobile‌‌application‌‌is‌‌different‌‌from‌‌everything‌‌else‌‌and‌‌cannot‌‌be‌‌hosted‌‌on‌‌ Azure.‌ ‌The‌ ‌only‌ ‌deployment‌ ‌options‌ ‌are‌ ‌to‌ ‌assemble‌ ‌the‌ ‌packages‌ ‌for‌ ‌Android‌ ‌and‌ ‌IOS‌‌ respectively,‌ ‌and‌ ‌put‌‌these‌‌up‌‌for‌‌download‌‌on‌‌the‌‌Google‌‌Play‌‌Store‌‌for‌‌Android‌‌and‌‌the‌‌App‌‌ Store‌‌for‌‌IOS.‌‌Alternatively,‌‌you‌‌can‌‌give‌‌individuals‌‌the‌‌packages‌‌and‌‌let‌‌them‌‌download‌‌them‌‌ on‌ ‌their‌ ‌devices‌ ‌themselves.‌ ‌Currently,‌ ‌we‌ ‌are‌ ‌just‌ ‌giving‌ ‌people‌ ‌the‌ ‌necessary‌‌packages‌‌and‌‌ letting‌ ‌them‌ ‌download‌ ‌the‌ ‌application‌ ‌on‌ ‌their‌ ‌phones‌ ‌themselves‌ ‌because‌ ‌it‌ ‌costs‌ ‌over‌ ‌$100‌‌ total‌‌to‌‌put‌‌the‌‌app‌‌on‌‌the‌‌Google‌‌Play‌‌Store‌‌(Android)‌‌and‌‌the‌‌App‌‌Store‌‌(IOS).‌‌Overall,‌‌these‌‌ deployment‌ ‌options‌ ‌will‌ ‌allow‌ ‌someone‌ ‌to‌ ‌use‌ ‌the‌ ‌web‌ ‌application‌ ‌at‌ ‌any‌ ‌time‌ ‌and‌ ‌use‌ ‌the‌‌ mobile‌‌application‌‌once‌‌they‌‌have‌‌downloaded‌‌it‌‌on‌‌their‌‌device.‌ ‌ 2.3‌‌ Code‌‌Implementation‌‌Decisions‌‌for‌‌Hestia‌ ‌ After‌‌we‌‌had‌‌decided‌‌on‌‌the‌‌code‌‌structure‌‌for‌‌Hestia‌‌we‌‌then‌‌had‌‌to‌‌decide‌‌on‌‌how‌‌we‌‌ would‌ ‌implement‌ ‌the‌ ‌Hestia‌ ‌code.‌‌These‌‌decisions‌‌included‌‌what‌‌frameworks‌‌and‌‌IDEs‌‌would‌‌ be‌ ‌used‌ ‌to‌ ‌develop‌ ‌the‌ ‌mobile‌ ‌application,‌ ‌web‌ ‌application,‌ ‌identity‌ ‌server,‌ ‌and‌ ‌web‌ ‌API‌ ‌and‌‌ what‌‌type‌‌of‌‌database‌‌should‌‌be‌‌used‌‌for‌‌both‌‌databases,‌‌and‌‌if‌‌we‌‌would‌‌take‌‌a‌‌database‌‌first‌‌or‌‌ code‌‌first‌‌approach‌‌for‌‌these‌‌databases.‌‌ ‌ ‌ 29‌ ‌ First,‌‌for‌‌the‌‌web‌‌application,‌‌we‌‌decided‌‌to‌‌use‌‌the‌‌Angular‌‌framework‌‌which‌‌meant‌‌that‌‌ the‌‌coding‌‌language‌‌used‌‌would‌‌be‌‌HTML‌‌and‌‌Javascript.‌‌We‌‌chose‌‌this‌‌framework‌‌because‌‌it‌‌is‌‌ specifically‌ ‌made‌ ‌for‌ ‌designing‌ ‌the‌ ‌frontend‌ ‌of‌ ‌web‌ ‌apps‌ ‌and‌ ‌is‌ ‌good‌ ‌for‌ ‌writing‌ ‌code‌ ‌that‌ ‌is‌‌ easily‌‌readable‌‌and‌‌maintainable‌‌(“Angular”,‌‌n.d.).‌ ‌Additionally,‌‌both‌‌developers‌‌of‌‌the‌‌frontend‌‌ web‌ ‌application,‌ ‌Liam‌ ‌and‌ ‌Pierce,‌ ‌already‌ ‌had‌ ‌extensive‌ ‌experience‌ ‌using‌ ‌the‌ ‌Angular‌‌ framework‌ ‌which‌ ‌made‌ ‌it‌ ‌a‌ ‌clear‌ ‌choice‌ ‌for‌ ‌developing‌ ‌the‌ ‌frontend‌ ‌web‌ ‌application.‌ ‌This‌‌ choice‌‌also‌‌meant‌‌that‌‌we‌‌used‌‌the‌‌Visual‌‌Studio‌‌Code‌‌IDE‌‌for‌‌development‌‌since‌‌it‌‌works‌‌well‌‌ when‌‌developing‌‌in‌‌the‌‌Angular‌‌framework.‌‌ ‌ Next,‌ ‌for‌ ‌the‌ ‌mobile‌ ‌application‌ ‌front-end,‌ ‌we‌ ‌chose‌ ‌to‌ ‌use‌ ‌the‌ ‌NativeScript‌‌ framework‌‌for‌‌development‌‌which‌‌meant‌‌that‌‌the‌‌code‌‌would‌‌be‌‌written‌‌in‌‌JavaScript.‌‌This‌‌is‌‌a‌‌ framework‌‌that‌‌none‌‌of‌‌us‌‌were‌‌familiar‌‌with‌‌before‌‌the‌‌project‌‌started‌‌but‌‌we‌‌decided‌‌to‌‌use‌‌it‌‌ anyway‌‌because‌‌it‌‌was‌‌similar‌‌to‌‌the‌‌Angular‌‌framework‌‌and‌‌by‌‌using‌‌this‌‌framework‌‌we‌‌could‌‌ use‌ ‌the‌ ‌same‌ ‌code‌ ‌for‌ ‌both‌ ‌the‌ ‌IOS‌ ‌and‌ ‌Android‌ ‌application‌ ‌(“NativeScript”,‌ ‌n.d.).‌ ‌Using‌ ‌a‌‌ framework‌‌that‌‌was‌‌similar‌‌to‌‌Angular‌‌was‌‌helpful‌‌because‌‌it‌‌meant‌‌that‌‌if‌‌Thang,‌‌our‌‌developer‌‌ in‌ ‌charge‌ ‌of‌ ‌the‌ ‌mobile‌ ‌application‌ ‌frontend,‌ ‌ran‌ ‌into‌ ‌issues‌ ‌either‌ ‌Liam‌ ‌or‌ ‌Pierce,‌ ‌who‌ ‌are‌‌ experienced‌‌in‌‌Angular,‌‌could‌‌understand‌‌the‌‌code‌‌enough‌‌to‌‌help‌‌him.‌‌Then,‌‌the‌‌bigger‌‌reason‌‌ we‌ ‌chose‌ ‌NativeScript‌ ‌was‌‌that‌‌it‌‌meant‌‌that‌‌we‌‌could‌‌use‌‌the‌‌same‌‌code‌‌for‌‌both‌‌the‌‌IOS‌‌and‌‌ Android‌ ‌applications.‌ ‌Since‌ ‌these‌ ‌are‌ ‌two‌ ‌entirely‌ ‌different‌ ‌operating‌ ‌systems‌ ‌oftentimes‌ ‌you‌‌ must‌ ‌have‌‌completely‌‌different‌‌code‌‌using‌‌entirely‌‌different‌‌frameworks‌‌if‌‌you‌‌want‌‌to‌‌support‌‌ your‌‌application‌‌on‌‌both‌‌platforms.‌‌This‌‌would‌‌lead‌‌to‌‌a‌‌much‌‌slower‌‌development‌‌time‌‌for‌‌the‌‌ mobile‌‌application‌‌and‌‌therefore‌‌since‌‌NativeScript‌‌allows‌‌us‌‌to‌‌avoid‌‌this‌‌we‌‌chose‌‌to‌‌use‌‌it‌‌for‌‌ the‌‌mobile‌‌application‌‌frontend‌‌development.‌‌Because‌‌we‌‌chose‌‌the‌‌NativeScript‌‌framework‌‌we‌‌ were‌ ‌able‌ ‌to‌ ‌use‌ ‌the‌ ‌Visual‌ ‌Studio‌ ‌Code‌ ‌IDE‌ ‌for‌ ‌the‌ ‌development‌ ‌of‌ ‌the‌ ‌mobile‌ ‌application‌‌ ‌ 30‌ ‌ frontend.‌‌Due‌‌to‌‌its‌‌similarities‌‌to‌‌Angular,‌‌this‌‌IDE‌‌also‌‌works‌‌very‌‌well‌‌with‌‌the‌‌NativeScript‌‌ framework‌‌making‌‌it‌‌a‌‌good‌‌choice‌‌to‌‌program‌‌in.‌ ‌ Then,‌ ‌there‌ ‌was‌ ‌the‌ ‌identity‌ ‌server‌ ‌whose‌ ‌main‌ ‌goal‌ ‌was‌ ‌creating‌‌accounts‌‌and‌‌ user‌ ‌authentication.‌ ‌This‌ ‌had‌ ‌a‌ ‌much‌ ‌more‌ ‌focused‌ ‌purpose‌ ‌than‌ ‌all‌ ‌the‌ ‌other‌ ‌components‌ meaning‌‌that‌‌we‌‌were‌‌able‌‌to‌‌choose‌‌a‌‌much‌‌more‌‌focused‌‌framework‌‌for‌‌this‌‌task.‌‌The‌‌task‌‌of‌‌ user‌‌authentication‌‌involves‌‌a‌‌lot‌‌of‌‌security‌‌concerns‌‌to‌‌ensure‌‌that‌‌passwords‌‌cannot‌‌be‌‌stolen‌‌ even‌‌if‌‌the‌‌database‌‌is‌‌compromised‌‌and‌‌therefore‌‌the‌‌main‌‌concerns‌‌of‌‌the‌‌identity‌‌server‌‌were‌‌ security‌ ‌concerns.‌ ‌Thus,‌ ‌the‌ ‌framework‌ ‌we‌ ‌chose‌ ‌to‌ ‌use‌‌was‌‌IdentityServer4‌‌which‌‌is‌‌built‌‌on‌‌ top‌‌of‌‌the‌‌standard‌‌ASP‌‌.NET‌‌Core‌‌framework.‌‌It‌‌implements‌‌the‌‌OpenID‌‌protocol‌‌which‌‌is‌‌the‌‌ latest‌ ‌technology‌ ‌in‌‌security‌‌protection‌‌and‌‌therefore‌‌would‌‌provide‌‌enhanced‌‌security‌‌over‌‌the‌‌ standard‌ ‌ASP.NET‌ ‌Core‌ ‌framework‌ ‌(Allen‌ ‌&‌ ‌Baier,‌ ‌2020)..‌ ‌This‌ ‌decision‌‌meant‌‌that‌‌we‌‌were‌‌ going‌ ‌to‌ ‌create‌ ‌the‌ ‌Identity‌ ‌Server‌ ‌using‌ ‌the‌ ‌C#‌ ‌coding‌ ‌language‌ ‌since‌ ‌that‌ ‌is‌ ‌the‌ ‌language‌‌ associated‌‌with‌‌the‌‌ASP.NET‌‌Core‌‌framework‌‌it‌‌is‌‌built‌‌on‌‌top‌‌of.‌‌Also‌‌because‌‌of‌‌this,‌‌we‌‌used‌‌ the‌ ‌Visual‌ ‌Studio‌ ‌IDE‌ ‌for‌ ‌development‌ ‌because‌ ‌it‌ ‌is‌ ‌the‌ ‌most‌ ‌commonly‌ ‌used‌ ‌IDE‌ ‌when‌‌ developing‌ ‌in‌ ‌the‌ ‌C#‌ ‌language.‌ ‌This‌ ‌decision‌ ‌allows‌ ‌our‌ ‌identity‌ ‌server‌ ‌to‌ ‌use‌ ‌the‌ ‌most‌‌ up-to-date‌ ‌technology‌‌for‌‌protecting‌‌a‌‌user’s‌‌login‌‌information‌‌and‌‌helps‌‌give‌‌our‌‌application‌‌a‌‌ more‌‌professional‌‌feeling‌‌since‌‌it‌‌makes‌‌sure‌‌our‌‌user‌‌data‌‌is‌‌always‌‌secured.‌ ‌ Lastly,‌ ‌we‌‌chose‌‌to‌‌use‌‌the‌‌ASP‌‌.NET‌‌framework‌‌for‌‌our‌‌backend‌‌web‌‌API.‌‌We‌‌ made‌‌this‌‌decision‌‌because‌‌both‌‌of‌‌our‌‌developers‌‌of‌‌this‌‌component,‌‌Bridger‌‌and‌‌myself,‌‌were‌‌ already‌ ‌very‌ ‌familiar‌ ‌with‌ ‌this‌ ‌framework‌ ‌and‌ ‌had‌ ‌already‌ ‌had‌ ‌experience‌ ‌using‌ ‌it‌ ‌to‌ ‌write‌‌ database‌ ‌access‌ ‌code‌ ‌which‌ ‌would‌ ‌be‌ ‌the‌ ‌type‌ ‌of‌‌code‌‌that‌‌would‌‌be‌‌written‌‌for‌‌the‌‌web‌‌API.‌‌ Furthermore,‌ ‌we‌ ‌chose‌ ‌to‌ ‌use‌ ‌this‌ ‌framework‌ ‌due‌ ‌to‌ ‌its‌ ‌incorporation‌ ‌of‌ ‌LINQ‌ ‌(Language‌‌ Integrated‌ ‌Query).‌ ‌LINQ‌ ‌integrates‌ ‌database‌ ‌access‌ ‌query‌ ‌capabilities‌ ‌directly‌ ‌into‌ ‌the‌ ‌C#‌‌ ‌ 31‌ ‌ programming‌‌language‌‌meaning‌‌that‌‌queries‌‌to‌‌the‌‌database‌‌can‌‌be‌‌written‌‌just‌‌like‌‌normal‌‌code‌‌ would‌ ‌instead‌‌of‌‌having‌‌to‌‌write‌‌our‌‌strings‌‌for‌‌every‌‌query‌‌(Wagner,‌‌n.d.).‌‌This‌‌feature‌‌makes‌‌ writing‌ ‌database‌ ‌access‌ ‌code‌ ‌much‌ ‌more‌‌efficient‌‌and‌‌much‌‌less‌‌error-prone‌‌and‌‌was‌‌the‌‌main‌‌ reason‌ ‌we‌ ‌chose‌ ‌to‌ ‌use‌ ‌the‌ ‌ASP‌ ‌.NET‌ ‌framework‌ ‌for‌ ‌our‌ ‌web‌ ‌API.‌ ‌Thus,‌ ‌this‌ ‌decision‌‌ necessitated‌‌that‌‌we‌‌use‌‌the‌‌C#‌‌programming‌‌language‌‌for‌‌the‌‌web‌‌API‌‌and‌‌since‌‌we‌‌were‌‌using‌‌ the‌ ‌C#‌ ‌language‌ ‌Visual‌ ‌Studio‌ ‌was‌ ‌once‌ ‌again‌ ‌the‌ ‌IDE‌ ‌used‌ ‌for‌ ‌development‌ ‌just‌ ‌like‌ ‌it‌ ‌was‌‌ being‌‌used‌‌for‌‌the‌‌development‌‌of‌‌the‌‌Identity‌‌Server.‌‌ ‌ Now‌‌the‌‌only‌‌implementation‌‌decisions‌‌left‌‌to‌‌make‌‌involve‌‌the‌‌main‌‌Hestia‌‌application‌‌ and‌‌identity‌‌server‌‌databases,‌‌the‌‌two‌‌remaining‌‌components‌‌of‌‌the‌‌Hestia‌‌application.‌‌The‌‌main‌‌ decision‌‌to‌‌make‌‌about‌‌these‌‌was‌‌whether‌‌we‌‌wanted‌‌an‌‌SQL‌‌or‌‌NoSQL‌‌database‌‌and‌‌depending‌‌ on‌‌what‌‌we‌‌chose‌‌what‌‌database‌‌engine‌‌to‌‌use.‌‌Ultimately‌‌we‌‌decided‌‌to‌‌use‌‌a‌‌SQL‌‌database‌‌for‌‌ both‌ ‌the‌ ‌main‌ ‌Hestia‌ ‌database‌ ‌and‌ ‌the‌ ‌Identity‌ ‌server‌‌database.‌‌We‌‌chose‌‌to‌‌do‌‌this‌‌because‌‌it‌‌ was‌ ‌the‌ ‌type‌ ‌of‌ ‌database‌ ‌we‌ ‌were‌ ‌all‌ ‌already‌ ‌familiar‌ ‌with‌ ‌and‌ ‌we‌ ‌felt‌ ‌that‌ ‌working‌ ‌with‌ ‌a‌‌ familiar‌ ‌type‌ ‌of‌ ‌database‌ ‌would‌ ‌be‌ ‌very‌ ‌important‌ ‌as‌ ‌we‌ ‌developed‌ ‌the‌ ‌application.‌ ‌Then,‌ ‌as‌‌ previously‌‌mentioned‌‌we‌‌made‌‌both‌‌of‌‌these‌‌databases‌‌a‌‌Microsoft‌‌SQL‌‌database‌‌because‌‌it‌‌was‌‌ the‌‌type‌‌of‌‌SQL‌‌database‌‌that‌‌was‌‌cheapest‌‌to‌‌host‌‌using‌‌Azure‌‌since‌‌Azure‌‌is‌‌also‌‌a‌‌Microsoft‌‌ service.‌‌ ‌ Then,‌‌we‌‌had‌‌to‌‌decide‌‌whether‌‌to‌‌use‌‌a‌‌code‌‌first‌‌or‌‌database‌‌the‌‌first‌‌approach‌‌for‌‌each‌‌ database‌ ‌since‌ ‌they‌ ‌both‌ ‌would‌ ‌operate‌ ‌on‌ ‌the‌ ‌.NET‌ ‌framework.‌ ‌The‌ ‌answer‌ ‌to‌ ‌this‌ ‌question‌‌ differed‌ ‌for‌ ‌the‌ ‌two‌ ‌databases.‌ ‌For‌ ‌the‌ ‌Identity‌ ‌server‌ ‌database,‌ ‌we‌ ‌chose‌ ‌to‌ ‌use‌ ‌a‌ ‌code-first‌‌ approach.‌‌We‌‌did‌‌this‌‌because‌‌this‌‌database‌‌was‌‌much‌‌smaller‌‌meaning‌‌that‌‌it‌‌was‌‌a‌‌manageable‌‌ task‌‌to‌‌create‌‌the‌‌data‌‌models‌‌all‌‌in‌‌the‌‌code‌‌and‌‌then‌‌have‌‌these‌‌models‌‌migrated‌‌into‌‌tables‌‌in‌‌ the‌‌database.‌‌Therefore,‌‌it‌‌was‌‌considered‌‌more‌‌important‌‌to‌‌prioritize‌‌the‌‌speed‌‌of‌‌the‌‌code‌‌first‌‌ ‌ 32‌ ‌ approach‌ ‌over‌ ‌the‌ ‌accuracy‌ ‌of‌ ‌the‌ ‌database‌ ‌first‌‌approach‌‌in‌‌this‌‌case‌‌since‌‌we‌‌were‌‌confident‌‌ we‌‌could‌‌get‌‌all‌‌of‌‌the‌‌models‌‌set‌‌up‌‌correctly‌‌in‌‌code‌‌since‌‌they‌‌weren’t‌‌too‌‌complex.‌‌However,‌‌ for‌ ‌the‌ ‌main‌ ‌Hestia‌ ‌database,‌ ‌we‌‌decided‌‌to‌‌use‌‌a‌‌database‌‌first‌‌approach.‌‌We‌‌did‌‌this‌‌because‌‌ the‌‌main‌‌database‌‌had‌‌to‌‌be‌‌a‌‌complex‌‌network‌‌of‌‌tables‌‌stored‌‌in‌‌a‌‌way‌‌such‌‌that‌‌every‌‌single‌‌ item‌ ‌stored‌ ‌in‌ ‌the‌ ‌database‌ ‌could‌ ‌relate‌ ‌to‌ ‌a‌ ‌user.‌ ‌The‌ ‌main‌ ‌Hestia‌ ‌database‌ ‌had‌ ‌to‌ ‌store‌‌ information‌ ‌about‌ ‌the‌ ‌user‌ ‌itself,‌ ‌their‌ ‌household,‌ ‌budgets,‌ ‌to-dos,‌ ‌recipes,‌ ‌meals,‌ ‌grocery‌ ‌list‌‌ items,‌‌and‌‌their‌‌calendar‌‌events‌‌and‌‌we‌‌felt‌‌like‌‌setting‌‌this‌‌up‌‌all‌‌in‌‌the‌‌code‌‌was‌‌bound‌‌to‌‌cause‌‌ issues‌‌with‌‌us‌‌setting‌‌it‌‌up‌‌incorrectly.‌‌This‌‌was‌‌especially‌‌important‌‌because‌‌small‌‌errors‌‌in‌‌the‌‌ database‌ ‌structure‌ ‌could‌ ‌cascade‌ ‌and‌ ‌cause‌ ‌errors‌ ‌in‌ ‌the‌ ‌entire‌ ‌operation‌ ‌of‌ ‌the‌ ‌applications.‌‌ Therefore‌‌for‌‌the‌‌main‌‌database,‌‌we‌‌used‌‌the‌‌slower‌‌and‌‌more‌‌tedious‌‌database‌‌first‌‌approach‌‌to‌‌ minimize‌‌the‌‌chances‌‌that‌‌there‌‌would‌‌be‌‌errors‌‌in‌‌the‌‌database‌‌structure.‌‌While‌‌it‌‌is‌‌possible‌‌to‌‌ still‌ ‌accomplish‌ ‌all‌ ‌of‌ ‌this‌ ‌using‌ ‌a‌ ‌code-first‌ ‌approach‌ ‌a‌ ‌database‌ ‌first‌ ‌approach‌ ‌is‌ ‌generally‌‌ considered‌ ‌less‌ ‌error-prone‌ ‌and‌ ‌it‌ ‌is‌ ‌what‌ ‌I,‌ ‌the‌ ‌main‌ ‌Hestia‌ ‌database‌ ‌designer,‌ ‌was‌ ‌most‌‌ comfortable‌‌with.‌ ‌ Overall,‌ ‌we‌ ‌made‌ ‌all‌ ‌of‌ ‌these‌ ‌decisions‌ ‌based‌ ‌on‌ ‌what‌ ‌we‌ ‌felt‌ ‌would‌ ‌result‌ ‌in‌ ‌a‌ ‌final‌‌ product‌ ‌for‌ ‌the‌ ‌application‌ ‌that‌‌most‌‌closely‌‌resembled‌‌our‌‌vision‌‌for‌‌the‌‌application‌‌given‌‌the‌‌ time‌‌constraints‌‌we‌‌were‌‌under.‌‌Once‌‌these‌‌decisions‌‌were‌‌made‌‌we‌‌as‌‌a‌‌team,‌‌we‌‌were‌‌able‌‌to‌‌ start‌‌development‌‌work‌‌on‌‌the‌‌application‌‌to‌‌begin‌‌making‌‌Hestia‌‌a‌‌reality.‌ ‌ ‌ 33‌ ‌ 3‌‌TIMELINE‌ ‌ In‌ ‌total,‌ ‌the‌ ‌development‌ ‌of‌ ‌Hestia‌ ‌took‌ ‌place‌ ‌over‌ ‌two‌ ‌semesters‌ ‌at‌ ‌the‌ ‌University‌ ‌of‌‌ Utah.‌ ‌In‌ ‌the‌ ‌first‌ ‌semester‌ ‌(Sprint‌ ‌2021)‌ ‌the‌ ‌team‌ ‌was‌ ‌assembled,‌ ‌and‌ ‌the‌ ‌design‌ ‌decisions‌‌ mentioned‌‌previously‌‌were‌‌made.‌‌Then,‌‌in‌‌the‌‌second‌‌semester‌‌(Fall‌‌2021),‌‌the‌‌focus‌‌was‌‌almost‌‌ entirely‌‌put‌‌on‌‌creating‌‌a‌‌great‌‌final‌‌project‌‌to‌‌show‌‌off‌‌in‌‌the‌‌last‌‌week‌‌of‌‌classes.‌‌In‌‌total,‌‌this‌‌ accounts‌ ‌for‌ ‌30‌ ‌weeks‌ ‌of‌ ‌total‌ ‌development‌‌time‌‌with‌‌15‌‌weeks‌‌in‌‌each‌‌semester.‌‌This‌‌section‌‌ will‌‌give‌‌a‌‌breakdown‌‌of‌‌how‌‌these‌‌30‌‌weeks‌‌were‌‌divided‌‌to‌‌create‌‌our‌‌application.‌ ‌ 3.1‌ Weeks‌‌1-4:‌‌Idea‌‌Pitch‌‌and‌‌Team‌‌Formation‌ ‌ In‌ ‌the‌ ‌first‌ ‌four‌ ‌weeks‌ ‌of‌ ‌the‌ ‌semester,‌ ‌the‌ ‌focus‌ ‌was‌ ‌entirely‌ ‌on‌ ‌pitching‌ ‌ideas‌ ‌and‌‌ forming‌ ‌the‌ ‌teams‌ ‌to‌ ‌complete‌ ‌the‌ ‌capstone‌ ‌project.‌ ‌As‌ ‌a‌ ‌part‌ ‌of‌‌this‌‌process,‌‌everyone‌‌in‌‌the‌‌ class‌‌had‌‌to‌‌release‌‌our‌‌resumes‌‌so‌‌that‌‌other‌‌classmates‌‌could‌‌review‌‌them‌‌and‌‌reach‌‌out‌‌to‌‌you‌‌ if‌ ‌they‌ ‌were‌ ‌interested‌ ‌in‌ ‌adding‌ ‌you‌ ‌to‌ ‌their‌ ‌team.‌ ‌Our‌ ‌team‌ ‌was‌ ‌formed‌ ‌first‌ ‌by‌‌myself‌‌and‌‌ Liam,‌ ‌who‌ ‌knew‌ ‌each‌ ‌other‌ ‌from‌ ‌working‌ ‌as‌ ‌Teacher’s‌ ‌Assistants‌ ‌(TAs)‌ ‌together‌ ‌at‌ ‌the‌‌ University‌ ‌of‌ ‌Utah.‌ ‌Then,‌ ‌we‌ ‌reached‌ ‌out‌ ‌to‌ ‌Pierce‌ ‌based‌ ‌on‌ ‌the‌ ‌extensive‌ ‌web‌ ‌development‌‌ experience‌ ‌present‌ ‌on‌ ‌his‌ ‌resume‌ ‌and‌ ‌added‌ ‌him‌ ‌to‌ ‌our‌ ‌team.‌ ‌Then,‌ ‌Bridger‌‌had‌‌presented‌‌an‌‌ idea‌‌in‌‌class‌‌about‌‌a‌‌home‌‌management‌‌system‌‌that‌‌all‌‌three‌‌of‌‌us‌‌were‌‌interested‌‌in‌‌developing,‌‌ so‌ ‌we‌ ‌reached‌ ‌out‌ ‌to‌ ‌Bridger‌ ‌to‌‌add‌‌him‌‌to‌‌the‌‌team‌‌and‌‌use‌‌his‌‌project‌‌idea.‌‌He‌‌accepted‌‌our‌‌ offer‌ ‌forming‌ ‌our‌ ‌development‌ ‌team‌ ‌that‌ ‌would‌ ‌create‌ ‌the‌‌household‌‌management‌‌system‌‌that‌‌ would‌‌later‌‌be‌‌called‌‌Hestia.‌‌Then,‌‌about‌‌a‌‌week‌‌after‌‌the‌‌four‌‌of‌‌us‌‌had‌‌formed‌‌what‌‌we‌‌thought‌‌ would‌‌be‌‌our‌‌final‌‌development‌‌team,‌‌Thang‌‌reached‌‌out‌‌requesting‌‌to‌‌join.‌‌We‌‌quickly‌‌accepted‌‌ this‌ ‌offer‌ ‌because‌ ‌of‌ ‌his‌ ‌extensive‌ ‌experience‌ ‌with‌ ‌mobile‌ ‌development.‌ ‌Thus,‌ ‌he‌ ‌became‌ ‌the‌‌ primary‌ ‌mobile‌ ‌developer‌ ‌of‌ ‌Hestia.‌ ‌We‌ ‌created‌ ‌our‌‌team‌‌to‌‌get‌‌a‌‌set‌‌of‌‌team‌‌members‌‌with‌‌a‌‌ ‌ 34‌ ‌ diverse‌ ‌skill‌ ‌set‌ ‌so‌ ‌that‌ ‌all‌ ‌aspects‌ ‌of‌ ‌the‌ ‌application‌ ‌could‌ ‌be‌ ‌handled‌ ‌by‌ ‌someone‌ ‌who‌‌ specializes‌‌in‌‌that‌‌type‌‌of‌‌development.‌ ‌ 3.2‌ Weeks‌‌5-8:‌‌Project‌‌Refinement‌ ‌ The‌ ‌next‌ ‌four‌ ‌weeks‌ ‌of‌ ‌the‌ ‌semester‌ ‌were‌ ‌spent‌ ‌researching‌ ‌to‌ ‌try‌ ‌and‌ ‌decide‌‌how‌‌we‌‌ could‌ ‌create‌ ‌our‌ ‌application.‌ ‌During‌ ‌this‌ ‌time‌ ‌frame,‌ ‌we‌ ‌came‌ ‌up‌ ‌with‌ ‌a‌ ‌better‌ ‌idea‌ ‌of‌ ‌the‌‌ features‌‌we‌‌wanted‌‌to‌‌include‌‌in‌‌Hestia‌‌and‌‌researched‌‌how‌‌to‌‌structure‌‌the‌‌application‌‌to‌‌get‌‌it‌‌ to‌ ‌work‌ ‌successfully.‌ ‌During‌ ‌these‌ ‌four‌ ‌weeks,‌ ‌all‌ ‌of‌ ‌the‌ ‌design‌ ‌decisions‌ ‌discussed‌ ‌in‌ ‌the‌‌ previous‌‌section‌‌were‌‌made.‌ ‌ 3.3‌ Weeks‌‌9-15:‌‌Prototype‌‌Development‌ ‌ Next,‌‌in‌‌the‌‌remaining‌‌seven‌‌weeks‌‌of‌‌the‌‌first‌‌semester,‌‌we‌‌began‌‌development‌‌work‌‌on‌‌ the‌ ‌project.‌ ‌The‌ ‌first‌ ‌tasks‌ ‌completed‌ ‌were‌ ‌getting‌ ‌the‌ ‌main‌ ‌Hestia‌ ‌database‌ ‌up‌ ‌and‌ ‌running,‌‌ creating‌‌the‌‌login‌‌functionality‌‌in‌‌the‌‌Identity‌‌server,‌‌and‌‌getting‌‌page‌‌mock-ups‌‌designed‌‌for‌‌the‌‌ web‌ ‌and‌ ‌mobile‌ ‌apps.‌ ‌During‌ ‌this‌ ‌time,‌ ‌the‌ ‌project‌ ‌started‌ ‌to‌ ‌take‌ ‌the‌ ‌shape‌ ‌of‌ ‌a‌ ‌usable‌‌ application.‌‌The‌‌end‌‌goal‌‌of‌‌this‌‌phase‌‌was‌‌to‌‌create‌‌a‌‌prototype‌‌of‌‌the‌‌application‌‌as‌‌a‌‌proof‌‌of‌‌ concept‌ ‌for‌ ‌what‌ ‌we‌ ‌wanted‌ ‌Hestia‌ ‌to‌ ‌be.‌ ‌By‌ ‌the‌ ‌end‌ ‌of‌ ‌this‌ ‌development‌ ‌phase,‌ ‌we‌ ‌had‌‌ accomplished‌‌a‌‌lot‌‌on‌‌our‌‌application.‌‌Our‌‌main‌‌Hestia‌‌database‌‌got‌‌created,‌‌and‌‌all‌‌the‌‌web‌‌API‌‌ endpoints‌‌to‌‌manage‌‌user‌‌information,‌‌budgets,‌‌and‌‌to-dos‌‌had‌‌been‌‌created‌‌as‌‌well.‌‌The‌‌Identity‌‌ server‌ ‌was‌ ‌up‌ ‌and‌ ‌running‌ ‌and‌ ‌could‌ ‌log‌ ‌users‌ ‌in,‌ ‌although‌ ‌it‌ ‌had‌ ‌problems‌ ‌with‌ ‌constantly‌‌ crashing‌‌after‌‌about‌‌an‌‌hour‌‌of‌‌running,‌‌at‌‌which‌‌point‌‌you‌‌couldn’t‌‌log‌‌in‌‌to‌‌the‌‌app.‌‌Many‌‌of‌‌ the‌‌web‌‌application‌‌pages‌‌got‌‌mocked‌‌out‌‌including‌‌the‌‌Budget,‌‌Calendar,‌‌and‌‌To-do‌‌List‌‌pages.‌‌ The‌ ‌to-do‌‌page‌‌on‌‌the‌‌web‌‌application‌‌had‌‌been‌‌developed‌‌and‌‌was‌‌connected‌‌to‌‌the‌‌web‌‌API.‌‌ Furthermore,‌‌the‌‌mobile‌‌budget,‌‌calendar,‌‌and‌‌to-do‌‌pages‌‌had‌‌all‌‌been‌‌designed,‌‌although‌‌only‌‌ the‌‌to-do‌‌page‌‌was‌‌connected‌‌to‌‌the‌‌web‌‌API,‌‌the‌‌other‌‌two‌‌pages‌‌only‌‌showed‌‌mocked-out‌‌data.‌‌ ‌ 35‌ ‌ As‌ ‌a‌ ‌reference,‌ ‌the‌ ‌mocked-out‌ ‌to-do‌ ‌list‌ ‌and‌ ‌calendar‌ ‌pages‌ ‌are‌ ‌shown‌ ‌in‌ ‌Fig.‌ ‌4‌ ‌and‌ ‌Fig.‌ ‌5‌‌ below.‌ ‌ ‌ Fig.‌‌4‌‌-‌‌Mock‌‌Web‌‌Application‌‌To-do‌‌List‌‌Page‌ ‌ ‌ Fig.‌‌5‌‌-‌‌Mock‌‌Web‌‌Application‌‌Calendar‌‌Page‌ ‌ ‌ 36‌ ‌ 3.4‌ Weeks‌‌16-20:‌‌Alpha‌‌Release‌ ‌ After‌ ‌the‌ ‌prototype‌ ‌was‌ ‌completed,‌ ‌and‌ ‌the‌ ‌first‌ ‌semester‌ ‌ended‌‌our‌‌team‌‌took‌‌a‌‌break‌‌ from‌ ‌development‌ ‌during‌ ‌the‌ ‌summer‌ ‌as‌‌all‌‌of‌‌our‌‌team‌‌members‌‌became‌‌busy‌‌with‌‌work‌‌and‌‌ internships.‌ ‌Once‌ ‌back‌ ‌in‌ ‌school‌ ‌at‌ ‌the‌ ‌start‌ ‌of‌ ‌the‌ ‌second‌ ‌semester,‌ ‌the‌ ‌first‌ ‌5‌ ‌weeks‌ ‌were‌‌ devoted‌‌to‌‌getting‌‌back‌‌into‌‌the‌‌development‌‌process‌‌and‌‌beginning‌‌work‌‌for‌‌the‌‌alpha‌‌release.‌‌ The‌ ‌goal‌ ‌of‌ ‌the‌‌alpha‌‌release‌‌was‌‌to‌‌create‌‌an‌‌application‌‌where‌‌all‌‌of‌‌the‌‌basic‌‌features‌‌of‌‌the‌‌ application‌‌had‌‌their‌‌basic‌‌functionality‌‌established.‌‌Furthermore,‌‌at‌‌this‌‌point,‌‌all‌‌these‌‌features‌‌ needed‌ ‌to‌ ‌connect‌ ‌to‌ ‌the‌ ‌backend‌ ‌API.‌ ‌On‌ ‌top‌ ‌of‌ ‌the‌ ‌features‌ ‌we‌ ‌had‌ ‌already‌ ‌added‌ ‌in‌ ‌the‌‌ prototype‌ ‌phase,‌ ‌the‌ ‌alpha‌ ‌release‌ ‌brought‌ ‌with‌ ‌it‌ ‌the‌ ‌refinement‌ ‌of‌ ‌the‌ ‌budget‌ ‌and‌ ‌todo‌‌ endpoints‌ ‌along‌ ‌with‌ ‌the‌ ‌completion‌ ‌of‌ ‌the‌ ‌calendar‌ ‌and‌ ‌household‌‌invitation‌‌endpoints‌‌in‌‌the‌‌ web‌ ‌API.‌ ‌The‌ ‌Identity‌ ‌server‌ ‌was‌ ‌now‌ ‌more‌ ‌stable‌ ‌and‌ ‌could‌ ‌run‌ ‌for‌ ‌multiple‌ ‌days‌ ‌without‌‌ crashing.‌ ‌The‌‌web‌‌application‌‌added‌‌the‌‌ability‌‌to‌‌join‌‌households‌‌and‌‌invite‌‌users‌‌to‌‌join‌‌your‌‌ household,‌ ‌and‌ ‌the‌ ‌calendar‌ ‌feature‌ ‌was‌ ‌added.‌ ‌Then,‌ ‌the‌ ‌mobile‌ ‌app‌‌was‌‌cleaned‌‌up,‌‌and‌‌the‌‌ calendar‌‌feature‌‌was‌‌connected‌‌to‌‌the‌‌web‌‌API‌‌so‌‌it‌‌would‌‌show‌‌data‌‌from‌‌the‌‌database‌‌instead‌‌ of‌‌displaying‌‌mocked-out‌‌data.‌‌Also,‌‌during‌‌this‌‌time,‌‌various‌‌bugs‌‌were‌‌fixed‌‌in‌‌all‌‌components‌‌ of‌‌the‌‌application.‌‌At‌‌the‌‌end‌‌of‌‌these‌‌five‌‌weeks,‌‌we‌‌were‌‌able‌‌to‌‌demo‌‌our‌‌project‌‌to‌‌a‌‌group‌‌of‌‌ alpha‌‌testers‌‌and‌‌who‌‌suggested‌‌improvements‌‌we‌‌could‌‌make‌‌to‌‌the‌‌application.‌ 3.5‌ Weeks‌‌21-24:‌‌Beta‌‌Release‌ ‌ After‌‌the‌‌alpha‌‌release,‌‌the‌‌next‌‌4‌‌weeks‌‌were‌‌devoted‌‌to‌‌developing‌‌the‌‌application‌‌for‌‌a‌‌ beta‌ ‌release.‌ ‌The‌ ‌goal‌ ‌of‌ ‌this‌‌Beta‌‌release‌‌was‌‌to‌‌have‌‌a‌‌fully‌‌functional‌‌application‌‌that‌‌could‌‌ serve‌‌as‌‌a‌‌final‌‌stopping‌‌point‌‌for‌‌development,‌‌the‌‌application‌‌could‌‌still‌‌have‌‌minor‌‌bugs‌‌that‌‌ needed‌‌to‌‌be‌‌fixed,‌‌but‌‌no‌‌major‌‌features‌‌should‌‌be‌‌added‌‌after‌‌the‌‌Beta‌‌release.‌‌We‌‌were‌‌able‌‌to‌‌ reflect‌ ‌on‌ ‌the‌ ‌feedback‌ ‌given‌ ‌by‌‌our‌‌alpha‌‌testers‌‌to‌‌make‌‌the‌‌quality‌‌of‌‌life‌‌improvements‌‌for‌‌ ‌ 37‌ ‌ the‌ ‌application‌ ‌by‌ ‌beta‌ ‌release‌ ‌and‌‌add‌‌on‌‌many‌‌new‌‌features.‌‌On‌‌top‌‌of‌‌the‌‌endpoints‌‌already‌‌ implemented,‌‌the‌‌API‌‌endpoints‌‌for‌‌recipes,‌‌meals,‌‌and‌‌grocery‌‌lists‌‌were‌‌finished.‌‌The‌‌Identity‌‌ server‌ ‌was‌ ‌now‌ ‌completely‌ ‌stable‌ ‌and‌ ‌didn’t‌ ‌have‌ ‌any‌ ‌problems‌ ‌with‌ ‌crashing.‌ ‌The‌ ‌web‌‌ application‌ ‌added‌ ‌the‌ ‌meal‌ ‌planning‌ ‌(recipes,‌ ‌meal,‌ ‌and‌ ‌grocery‌ ‌list‌ ‌features)‌ ‌and‌ ‌budgeting‌‌ features.‌ ‌Then,‌ ‌the‌ ‌mobile‌ ‌app‌ ‌was‌ ‌given‌ ‌the‌ ‌ability‌ ‌to‌ ‌automatically‌ ‌update‌ ‌itself‌ ‌and‌ ‌pull‌‌in‌‌ changes‌‌from‌‌other‌‌family‌‌members‌‌and‌‌the‌‌budget‌‌feature‌‌was‌‌connected‌‌to‌‌the‌‌web‌‌API.‌‌Once‌‌ again,‌ ‌like‌ ‌for‌ ‌the‌ ‌alpha‌ ‌release‌‌in‌‌the‌‌final‌‌week‌‌we‌‌released‌‌a‌‌Beta‌‌version‌‌of‌‌the‌‌application‌‌ and‌‌had‌‌classmates‌‌beta‌‌test‌‌our‌‌application.‌‌These‌‌beta‌‌testers‌‌gave‌‌us‌‌feedback‌‌on‌‌what‌‌should‌‌ be‌‌improved‌‌for‌‌the‌‌final‌‌release.‌ ‌ 3.6‌ Weeks‌‌25-30:‌‌Final‌‌Release‌ ‌ Then,‌‌the‌‌final‌‌six‌‌weeks‌‌of‌‌the‌‌project‌‌were‌‌devoted‌‌to‌‌getting‌‌everything‌‌ready‌‌for‌‌the‌‌ final‌‌release,‌‌which‌‌would‌‌culminate‌‌in‌‌a‌‌demonstration‌‌of‌‌our‌‌application‌‌on‌‌Dec.‌‌10,‌‌2021.‌‌At‌‌ this‌ ‌time,‌ ‌the‌ ‌development‌ ‌focus‌ ‌wasn’t‌ ‌necessarily‌ ‌on‌ ‌adding‌ ‌new‌ ‌features‌ ‌but‌ ‌instead‌ ‌on‌‌ cleaning‌‌up‌‌and‌‌fixing‌‌bugs‌‌that‌‌existed‌‌in‌‌the‌‌current‌‌features.‌‌That‌‌being‌‌said,‌‌a‌‌dashboard‌‌was‌‌ added‌ ‌as‌ ‌a‌ ‌homepage‌ ‌to‌ ‌the‌ ‌web‌ ‌application‌ ‌during‌ ‌this‌ ‌time.‌ ‌Also,‌ ‌in‌ ‌this‌ ‌time‌ ‌frame,‌ ‌we‌‌ developed‌ ‌marketing‌ ‌materials‌ ‌to‌ ‌help‌ ‌show‌ ‌off‌ ‌our‌ ‌project‌ ‌on‌ ‌the‌ ‌demo‌ ‌day.‌ ‌We‌ ‌created‌ ‌a‌‌ public-facing‌‌website‌‌for‌‌Hestia‌‌that‌‌explained‌‌what‌‌it‌‌was‌‌and‌‌provided‌‌links‌‌to‌‌use‌‌to‌‌web‌‌apps‌ or‌ ‌download‌ ‌and‌ ‌use‌ ‌the‌ ‌mobile‌ ‌apps.‌ ‌This‌ ‌website‌ ‌can‌ ‌be‌ ‌found‌ ‌at‌‌ https://linnebach08.github.io/Hestia/.‌ ‌Furthermore,‌ ‌we‌ ‌created‌ ‌a‌ ‌short‌ ‌commercial‌ ‌video‌ ‌that‌‌ shows‌‌off‌‌the‌‌application,‌‌and‌‌we‌‌made‌‌a‌‌poster‌‌to‌‌present‌‌on‌‌demo‌‌day‌‌to‌‌those‌‌in‌‌attendance.‌‌ Overall,‌‌at‌‌the‌‌end‌‌of‌‌all‌‌of‌‌this‌‌work,‌‌we‌‌were‌‌pleased‌‌with‌‌what‌‌we‌‌were‌‌able‌‌to‌‌accomplish.‌ ‌ ‌ 38‌ ‌ 4‌‌RESULTS‌ ‌ With‌ ‌all‌ ‌the‌ ‌development‌ ‌work‌ ‌done,‌ ‌it‌ ‌now‌ ‌was‌ ‌time‌ ‌to‌ ‌show‌ ‌off‌ ‌our‌ ‌results.‌ ‌All‌ ‌the‌‌ work‌ ‌we‌ ‌had‌ ‌put‌ ‌into‌ ‌making‌ ‌design‌ ‌decisions‌ ‌and‌ ‌developing‌ ‌the‌ ‌application‌ ‌has‌ ‌led‌ ‌us‌ ‌to‌‌a‌‌ final‌‌product‌‌which‌‌we‌‌as‌‌a‌‌team‌‌were‌‌pleased‌‌with.‌‌This‌‌section‌‌shows‌‌off‌‌the‌‌final‌‌version‌‌of‌‌ Hestia‌ ‌completed‌ ‌as‌‌our‌‌capstone‌‌project.‌‌The‌‌final‌‌product‌‌is‌‌shown‌‌from‌‌the‌‌perspective‌‌of‌‌a‌‌ user,‌ ‌demonstrating‌ ‌all‌ ‌the‌ ‌features‌ ‌a‌ ‌Hestia‌ ‌user‌ ‌has‌ ‌access‌ ‌to‌ ‌on‌ ‌both‌ ‌the‌ ‌web‌ ‌and‌ ‌mobile‌‌ applications.‌ ‌It‌ ‌also‌ ‌provides‌ ‌an‌ ‌in-depth‌ ‌view‌ ‌of‌ ‌how‌ ‌each‌ ‌feature‌ ‌works‌ ‌with‌ ‌the‌ ‌API‌ ‌to‌‌ function.‌ ‌The‌ ‌features‌ ‌that‌ ‌will‌ ‌be‌ ‌covered‌ ‌are‌ ‌as‌ ‌follows:‌ ‌account‌ ‌creation‌ ‌and‌ ‌login,‌ ‌The‌‌ household‌‌invitation‌‌system‌‌and‌‌household‌‌settings‌‌page,‌‌the‌‌home‌‌page‌‌dashboard,‌‌budgets,‌‌the‌‌ to-do‌‌list,‌‌the‌‌calendar,‌‌the‌‌household‌‌recipe‌‌book‌‌and‌‌meal‌‌planning,‌‌and‌‌the‌‌grocery‌‌list.‌‌ ‌ Before‌ ‌discussing‌ ‌the‌ ‌features‌ ‌themselves,‌‌it‌‌is‌‌important‌‌to‌‌give‌‌more‌‌insight‌‌into‌‌how‌‌ the‌ ‌API‌ ‌works‌ ‌to‌ ‌understand‌ ‌how‌ ‌the‌ ‌features‌ ‌themselves‌ ‌work.‌ ‌As‌‌mentioned‌‌previously,‌‌the‌‌ API‌ ‌will‌ ‌receive‌ ‌requests‌ ‌to‌ ‌create,‌ ‌retrieve,‌ ‌update‌ ‌and‌ ‌delete‌ ‌data‌ ‌stored‌ ‌in‌ ‌the‌ ‌main‌ ‌Hestia‌‌ database.‌ ‌Our‌ ‌API‌ ‌uses‌ ‌four‌ ‌types‌ ‌of‌ ‌requests:‌ ‌GET,‌ ‌POST,‌ ‌PUT,‌ ‌and‌ ‌DELETE.‌ ‌Specifically,‌‌ GET‌ ‌requests‌ ‌retrieve‌ ‌data‌ ‌from‌ ‌the‌ ‌database,‌ ‌POST‌‌requests‌‌create‌‌data‌‌in‌‌the‌‌database,‌‌PUT‌‌ requests‌‌modify‌‌data‌‌in‌‌the‌‌database,‌‌and‌‌DELETE‌‌requests‌‌delete‌‌data‌‌in‌‌the‌‌database.‌‌Each‌‌of‌‌ these‌‌requests‌‌contains‌‌a‌‌URL‌‌and‌‌a‌‌request‌‌body.‌‌The‌‌requested‌‌URL‌‌operates‌‌just‌‌like‌‌a‌‌URL‌‌ in‌ ‌your‌ ‌web‌‌browser;‌‌it‌‌directs‌‌you‌‌to‌‌a‌‌specific‌‌page,‌‌in‌‌this‌‌case,‌‌it‌‌gets‌‌directed‌‌to‌‌a‌‌specific‌‌ API‌‌request,‌‌which‌‌tells‌‌the‌‌API‌‌which‌‌data‌‌in‌‌the‌‌database‌‌should‌‌get‌‌manipulated.‌‌To‌‌form‌‌this‌‌ URL‌ ‌the‌ ‌site‌ ‌URL‌ ‌that‌ ‌the‌ ‌web‌ ‌API‌ ‌is‌‌deployed‌‌to,‌‌which‌‌I‌‌will‌‌call‌‌HestiaURL,‌‌is‌‌combined‌‌ with‌ ‌the‌ ‌route‌ ‌to‌ ‌the‌ ‌API‌ ‌request.‌ ‌Thus,‌ ‌for‌ ‌the‌ ‌GET‌ ‌/budgets/{userID}‌ ‌endpoint,‌ ‌which‌ ‌gets‌‌ used‌ ‌to‌ ‌retrieve‌ ‌a‌ ‌user’s‌ ‌budgets,‌ ‌a‌ ‌GET‌ ‌request‌ ‌would‌ ‌be‌ ‌sent‌ ‌to‌ ‌the‌‌ HestiaURL/budgets/{userID}‌‌endpoint.‌‌However,‌‌this‌‌still‌‌is‌‌not‌‌a‌‌valid‌‌request‌‌because‌‌anytime‌‌ ‌ 39‌ ‌ something‌‌is‌‌inside‌‌brackets‌‌like‌‌{userID}‌‌it‌‌is‌‌a‌‌variable‌‌that‌‌needs‌‌to‌‌be‌‌replaced.‌‌In‌‌this‌‌case,‌‌ this‌‌variable‌‌tells‌‌the‌‌API‌‌which‌‌user‌‌it‌‌should‌‌retrieve‌‌the‌‌budgets‌‌for,‌‌so‌‌if‌‌the‌‌goal‌‌is‌‌to‌‌retrieve‌‌ the‌ ‌budgets‌ ‌for‌ ‌the‌ ‌user‌‌with‌‌an‌‌ID‌‌of‌‌42‌‌then,‌‌the‌‌HestiaURL/budgets/42‌‌URL‌‌would‌‌be‌‌used‌‌ for‌‌the‌‌GET‌‌request.‌‌URL‌‌variables‌‌are‌‌one‌‌way‌‌in‌‌which‌‌information‌‌is‌‌passed‌‌to‌‌the‌‌API‌‌to‌‌tell‌‌ it‌‌what‌‌exactly‌‌to‌‌do,‌‌and‌‌it‌‌is‌‌commonly‌‌used‌‌in‌‌the‌‌GET‌‌and‌‌DELETE‌‌requests.‌‌The‌‌other‌‌way‌‌ variables‌ ‌get‌ ‌sent‌ ‌to‌ ‌the‌ ‌API‌ ‌is‌ ‌through‌‌the‌‌request‌‌body,‌‌which‌‌is‌‌just‌‌a‌‌section‌‌of‌‌the‌‌request‌‌ after‌ ‌the‌ ‌URL‌ ‌that‌ ‌every‌ ‌request‌ ‌has,‌ ‌even‌‌if‌‌it‌‌is‌‌left‌‌empty.‌‌For‌‌POST‌‌and‌‌PUT‌‌requests,‌‌the‌‌ method‌ ‌body‌ ‌often‌ ‌contains‌ ‌information‌ ‌about‌ ‌what‌ ‌data‌ ‌should‌ ‌be‌ ‌created‌ ‌or‌‌modified‌‌in‌‌the‌ database.‌ ‌For‌‌example,‌‌let’s‌‌say‌‌you‌‌wanted‌‌to‌‌create‌‌a‌‌new‌‌budget‌‌for‌‌a‌‌user‌‌with‌‌an‌‌ID‌‌of‌‌42‌‌ and‌‌that‌‌the‌‌budget’s‌‌name‌‌would‌‌be‌‌December’s‌‌budget,‌‌and‌‌it‌‌would‌‌have‌‌a‌‌start‌‌date‌‌of‌‌Dec.‌‌1‌‌ and‌ ‌would‌ ‌end‌ ‌on‌ ‌Dec.‌ ‌30.‌ ‌To‌ ‌do‌ ‌this‌ ‌a‌ ‌POST‌ ‌request‌ ‌to‌ ‌the‌ ‌/budget‌ ‌endpoint‌ ‌would‌‌be‌‌sent‌‌ which‌ ‌means‌ ‌you‌ ‌would‌ ‌send‌ ‌a‌ ‌post‌ ‌request‌ ‌to‌ ‌the‌ ‌HestiaURL/budget‌ ‌endpoint.‌ ‌Then,‌ ‌the‌‌ request‌‌body‌‌would‌‌contain‌‌the‌‌information‌‌that‌‌says‌‌the‌‌userId‌‌for‌‌the‌‌user‌‌creating‌‌the‌‌budget‌‌ is‌ ‌42,‌‌its‌‌name‌‌is‌‌“December’s‌‌budget”,‌‌its‌‌startDate‌‌is‌‌Dec.‌‌1,‌‌and‌‌its‌‌endDate‌‌is‌‌Dec.‌‌30.‌‌The‌‌ API‌‌will‌‌take‌‌this‌‌information‌‌and‌‌create‌‌the‌‌budget‌‌in‌‌the‌‌database‌‌according‌‌to‌‌the‌‌information‌‌ provided‌‌in‌‌the‌‌request‌‌body.‌‌This‌‌is‌‌the‌‌process‌‌the‌‌front-end‌‌uses‌‌to‌‌make‌‌requests‌‌to‌‌the‌‌API‌‌ to‌ ‌manipulate‌ ‌the‌ ‌data‌ ‌stored‌ ‌in‌ ‌the‌ ‌main‌ ‌Hestia‌ ‌database.‌ ‌It‌ ‌is‌ ‌important‌ ‌to‌ ‌understand‌ ‌this‌‌ concept‌ ‌because‌ ‌it‌ ‌is‌ ‌essential‌ ‌for‌ ‌understanding‌ ‌the‌ ‌explanations‌ ‌given‌ ‌for‌ ‌how‌ ‌each‌ ‌of‌ ‌the‌‌ features‌ ‌works.‌ ‌Now‌ ‌that‌‌this‌‌has‌‌been‌‌covered,‌‌the‌‌rest‌‌of‌‌this‌‌section‌‌will‌‌discuss‌‌each‌‌of‌‌the‌‌ features‌ ‌of‌ ‌the‌ ‌Hestia‌ ‌application‌ ‌and‌ ‌explain‌ ‌how‌ ‌they‌ ‌work‌ ‌with‌ ‌the‌ ‌API‌ ‌to‌‌make‌‌the‌‌entire‌‌ application‌‌function‌‌properly.‌‌All‌‌of‌‌the‌‌API‌‌endpoints‌‌that‌‌were‌‌created‌‌for‌‌the‌‌application‌‌are‌‌ listed‌‌and‌‌their‌‌uses‌‌are‌‌given‌‌in‌‌the‌‌API‌‌endpoint‌‌specs‌‌shown‌‌in‌‌Appendix‌‌1.‌ ‌ ‌ ‌ 40‌ ‌ 4.1‌‌ Account‌‌Creation‌‌and‌‌Log‌‌In‌ ‌ When‌‌first‌‌navigating‌‌to‌‌the‌‌Hestia‌‌application,‌‌the‌‌user‌‌is‌‌greeted‌‌with‌‌the‌‌startup‌‌ screen‌‌for‌‌the‌‌application.‌‌The‌‌startup‌‌page‌‌for‌‌the‌‌web‌‌application‌‌is‌‌shown‌‌in‌‌Fig.‌‌6,‌‌while‌‌the‌‌ startup‌‌page‌‌for‌‌the‌‌mobile‌‌application‌‌is‌‌shown‌‌in‌‌Fig.‌‌7.‌‌By‌‌clicking‌‌on‌‌the‌‌“Login”‌‌button‌‌on‌‌ web‌ ‌or‌ ‌the‌ ‌“Get‌ ‌Started”‌ ‌button‌ ‌on‌ ‌mobile‌ ‌the‌ ‌user‌ ‌will‌ ‌be‌ ‌automatically‌ ‌redirected‌ ‌to‌ ‌the‌‌ Identity‌ ‌server‌ ‌shown‌ ‌in‌ ‌Fig.‌ ‌8.‌ ‌On‌ ‌this‌ ‌page,‌ ‌the‌ ‌user‌ ‌can‌ ‌either‌ ‌enter‌ ‌their‌ ‌username‌ ‌and‌‌ password‌‌and‌‌click‌‌login,‌‌create‌‌a‌‌new‌‌account,‌‌or‌‌reset‌‌their‌‌password‌‌if‌‌they‌‌have‌‌forgotten‌‌it.‌ ‌ If‌ ‌the‌ ‌user‌ ‌enters‌ ‌their‌ ‌username‌ ‌and‌ ‌password‌ ‌and‌ ‌selects‌ ‌"login",‌ ‌the‌ ‌Identity‌‌ Server‌‌will‌‌compare‌‌these‌‌login‌‌credentials‌‌against‌‌the‌‌login‌‌credentials‌‌stored‌‌in‌‌its‌‌database.‌‌To‌‌ do‌‌this,‌‌it‌‌will‌‌encrypt‌‌the‌‌password‌‌in‌‌the‌‌same‌‌way‌‌it‌‌encrypted‌‌the‌‌password‌‌when‌‌the‌‌account‌‌ was‌‌created,‌‌and‌‌if‌‌the‌‌newly‌‌encrypted‌‌password‌‌matches‌‌the‌‌encrypted‌‌password‌‌stored‌‌in‌‌the‌‌ Identity‌ ‌server’s‌ ‌database‌ ‌for‌ ‌that‌ ‌username‌ ‌the‌ ‌login‌ ‌attempt‌ ‌is‌ ‌successful.‌ ‌In‌ ‌this‌ ‌case,‌ ‌the‌‌ Identity‌‌Server‌‌retrieves‌‌the‌‌user’s‌‌credentials,‌‌including‌‌their‌‌userID,‌‌using‌‌the‌‌web‌‌API.‌‌Then,‌‌ the‌ ‌user‌ ‌gets‌ ‌redirected‌ ‌back‌ ‌to‌ ‌the‌ ‌web‌‌or‌‌mobile‌‌application‌‌depending‌‌on‌‌which‌‌application‌‌ they‌‌came‌‌from,‌‌now‌‌they‌‌are‌‌logged‌‌in‌‌and‌‌can‌‌start‌‌using‌‌the‌‌app.‌‌Otherwise,‌‌if‌‌the‌‌encrypted‌‌ password‌‌does‌‌not‌‌match‌‌the‌‌encrypted‌‌password‌‌stored‌‌for‌‌that‌‌username,‌‌then‌‌the‌‌login‌‌attempt‌‌ is‌‌unsuccessful.‌‌The‌‌user‌‌gets‌‌notified‌‌that‌‌the‌‌attempt‌‌was‌‌unsuccessful‌‌and‌‌must‌‌continue‌‌using‌‌ the‌‌Identity‌‌server‌‌to‌‌try‌‌and‌‌log‌‌in.‌‌ ‌ The‌ ‌next‌ ‌thing‌ ‌a‌‌user‌‌can‌‌do‌‌once‌‌on‌‌the‌‌Identity‌‌server‌‌is‌‌create‌‌a‌‌new‌‌account‌‌ by‌ ‌clicking‌ ‌on‌ ‌“Sign‌ ‌Up”‌ ‌as‌ ‌shown‌ ‌in‌ ‌Fig.‌ ‌8.‌ ‌Doing‌ ‌this‌ ‌will‌ ‌direct‌ ‌the‌ ‌user‌ ‌to‌ ‌the‌ ‌account‌‌ creation‌‌page,‌‌shown‌‌in‌‌Fig.‌‌9,‌‌on‌‌which‌‌they‌‌will‌‌enter‌‌the‌‌email,‌‌username,‌‌and‌‌password‌‌for‌‌ their‌ ‌new‌ ‌account.‌ ‌After‌ ‌entering‌ ‌this‌ ‌information‌ ‌and‌ ‌clicking‌ ‌on‌ ‌the‌ ‌submit‌ ‌button,‌ ‌the‌‌ username,‌‌email,‌‌and‌‌encrypted‌‌password‌‌get‌‌stored‌‌in‌‌the‌‌Identity‌‌Server’s‌‌database.‌‌Then,‌‌the‌‌ ‌ 41‌ ‌ Identity‌ ‌server‌ ‌uses‌ ‌the‌ ‌API‌ ‌to‌ ‌create‌ ‌the‌ ‌new‌ ‌user‌ ‌in‌ ‌the‌ ‌main‌ ‌Hestia‌ ‌database,‌ ‌and‌ ‌the‌ ‌new‌‌ user's‌‌ID‌‌gets‌‌returned.‌‌After‌‌this,‌‌the‌‌user‌‌gets‌‌redirected‌‌back‌‌to‌‌the‌‌login‌‌page,‌‌where‌‌they‌‌can‌‌ use‌‌their‌‌newly‌‌created‌‌credentials‌‌to‌‌log‌‌in‌‌and‌‌get‌‌redirected‌‌to‌‌the‌‌application‌‌they‌‌came‌‌from.‌ ‌ Then,‌ ‌the‌ ‌final‌ ‌thing‌ ‌you‌ ‌can‌ ‌do‌ ‌on‌ ‌the‌ ‌Identity‌ ‌server‌ ‌is‌‌initiate‌‌the‌‌process‌‌of‌‌ resetting‌‌your‌‌forgotten‌‌password.‌‌To‌‌do‌‌this,‌‌a‌‌user‌‌clicks‌‌on‌‌“Forgot‌‌Password”‌‌shown‌‌in‌‌Fig.‌‌8‌‌ and‌ ‌then‌ ‌enters‌ ‌the‌ ‌email‌ ‌associated‌‌with‌‌their‌‌account.‌‌Once‌‌this‌‌email‌‌has‌‌been‌‌submitted‌‌an‌‌ email‌‌is‌‌sent‌‌to‌‌the‌‌email‌‌account‌‌specified,‌‌and‌‌the‌‌user‌‌can‌‌log‌‌in‌‌to‌‌their‌‌email‌‌account‌‌and‌‌use‌‌ the‌‌email‌‌to‌‌reset‌‌their‌‌Hestia‌‌password.‌‌Once‌‌completed,‌‌the‌‌user‌‌can‌‌use‌‌this‌‌new‌‌password‌‌to‌‌ sign‌ ‌into‌ ‌their‌ ‌Hestia‌ ‌account‌ ‌on‌ ‌the‌ ‌Identity‌ ‌Server‌ ‌and‌ ‌get‌‌redirected‌‌back‌‌to‌‌the‌‌application‌‌ they‌‌came‌‌from.‌ ‌ ‌ ‌ ‌ ‌ Fig.‌‌6‌‌Hestia‌‌Web‌‌Application‌‌Startup‌‌Page‌ ‌ ‌ 42‌ ‌ ‌ Fig‌‌7‌‌-‌‌Hestia‌‌Mobile‌‌Application‌‌Startup‌‌Page‌ ‌ ‌ ‌ Fig.‌‌8‌‌-‌‌Identity‌‌Server‌‌Login‌‌Page‌ ‌ ‌ 43‌ ‌ ‌ Fig‌‌9‌‌-‌‌Identity‌‌Server‌‌create‌‌new‌‌account‌‌page‌ ‌ 4.2‌ The‌‌Household‌‌Invitation‌‌System‌‌and‌‌Household‌‌Settings‌‌Page‌ ‌ Now,‌‌the‌‌user‌‌is‌‌logged‌‌in,‌‌which‌‌means‌‌they‌‌almost‌‌have‌‌full‌‌access‌‌to‌‌the‌‌entire‌‌Hestia‌‌ application.‌ ‌If‌ ‌it's‌ ‌the‌ ‌user’s‌ ‌first‌ ‌login,‌ ‌they‌ ‌must‌ ‌join‌ ‌an‌ ‌existing‌ ‌household‌ ‌or‌ ‌create‌ ‌a‌ ‌new‌‌ household‌ ‌before‌ ‌using‌ ‌the‌ ‌application.‌ ‌This‌ ‌is‌‌a‌‌requirement‌‌because‌‌everyone‌‌within‌‌the‌‌app‌‌ must‌ ‌be‌ ‌part‌ ‌of‌ ‌a‌ ‌household,‌ ‌even‌ ‌if‌ ‌it‌ ‌is‌ ‌a‌ ‌household‌‌of‌‌one.‌‌Therefore,‌‌if‌‌the‌‌user‌‌is‌‌not‌‌in‌‌a‌‌ household‌ ‌after‌ ‌they‌ ‌log‌‌in‌‌they‌‌will‌‌see‌‌the‌‌page‌‌shown‌‌in‌‌Fig.‌‌10‌‌on‌‌the‌‌web‌‌application‌‌and‌‌ the‌‌page‌‌shown‌‌in‌‌Fig.‌‌12‌‌on‌‌the‌‌mobile‌‌application.‌‌These‌‌pages‌‌allow‌‌the‌‌user‌‌to‌‌either‌‌create‌‌ their‌ ‌new‌ ‌household‌ ‌or‌ ‌accept‌ ‌an‌ ‌invitation‌ ‌to‌ ‌join‌ ‌an‌ ‌existing‌ ‌household.‌ ‌To‌ ‌create‌ ‌a‌ ‌new‌‌ household‌‌on‌‌web‌‌or‌‌mobile‌‌the‌‌user‌‌will‌‌type‌‌in‌‌their‌‌new‌‌household’s‌‌name‌‌in‌‌the‌‌text‌‌box‌‌and‌‌ click‌ ‌submit.‌ ‌After‌ ‌this,‌ ‌a‌ ‌request‌ ‌is‌ ‌sent‌ ‌to‌ ‌the‌ ‌API‌ ‌to‌ ‌create‌ ‌the‌ ‌new‌ ‌household‌ ‌and‌‌ ‌ 44‌ ‌ automatically‌‌add‌‌the‌‌user.‌‌The‌‌endpoint‌‌will‌‌send‌‌back‌‌the‌‌ID‌‌for‌‌the‌‌new‌‌household.‌‌Now‌‌that‌‌ this‌‌process‌‌is‌‌completed,‌‌the‌‌user‌‌can‌‌use‌‌the‌‌rest‌‌of‌‌the‌‌application.‌‌ However,‌ ‌as‌ ‌mentioned‌ ‌previously,‌ ‌creating‌ ‌a‌ ‌new‌ ‌household‌‌is‌‌not‌‌the‌‌only‌‌option‌‌for‌‌ joining‌ ‌a‌ ‌household.‌ ‌A‌ ‌user‌ ‌can‌ ‌also‌ ‌accept‌ ‌an‌ ‌invitation‌ ‌to‌ ‌join‌ ‌an‌ ‌existing‌ ‌household.‌ ‌The‌‌ applications‌ ‌will‌ ‌use‌ ‌the‌‌API‌‌to‌‌retrieve‌‌all‌‌of‌‌the‌‌user’s‌‌household‌‌invitations.‌‌If‌‌a‌‌user‌‌has‌‌an‌‌ existing‌‌household‌‌invitation‌‌it‌‌will‌‌show‌‌up‌‌in‌‌their‌‌invitations‌‌inbox‌‌on‌‌web‌‌shown‌‌in‌‌Fig.‌‌11‌‌ or‌ ‌above‌ ‌the‌ ‌option‌ ‌to‌ ‌create‌ ‌a‌ ‌new‌ ‌household‌‌on‌‌mobile,‌‌shown‌‌in‌‌Fig.‌‌12.‌‌In‌‌both‌‌cases,‌‌the‌‌ user‌‌michael_linnebach‌‌has‌‌been‌‌invited‌‌to‌‌join‌‌the‌‌household‌‌"unique9’s‌‌Family"‌‌by‌‌a‌‌user‌‌with‌‌ the‌ ‌username‌ ‌"unique10".‌‌On‌‌the‌‌web‌‌app,‌‌you‌‌can‌‌hover‌‌over‌‌the‌‌invitation‌‌and‌‌select‌‌accept,‌‌ and‌‌on‌‌mobile,‌‌you‌‌can‌‌click‌‌the‌‌green‌‌check‌‌icon‌‌to‌‌accept‌‌the‌‌invitation.‌‌When‌‌this‌‌occurs,‌‌the‌‌ application‌ ‌sends‌ ‌a‌ ‌request‌ ‌to‌ ‌the‌ ‌API‌ ‌to‌ ‌accept‌ ‌the‌ ‌invitation,‌ ‌which‌ ‌adds‌ ‌the‌ ‌user‌ ‌to‌ ‌the‌‌ household‌‌the‌‌invitation‌‌invites‌‌them‌‌to.‌‌Once‌‌they‌‌get‌‌added‌‌to‌‌the‌‌household,‌‌the‌‌user‌‌can‌‌start‌‌ using‌‌the‌‌rest‌‌of‌‌the‌‌application.‌‌ ‌ The‌‌user‌‌also‌‌can‌‌reject‌‌the‌‌invitation‌‌by‌‌selecting‌‌reject‌‌in‌‌the‌‌web‌‌app‌‌or‌‌clicking‌‌on‌‌the‌‌ red‌ ‌x‌ ‌icon‌ ‌in‌ ‌the‌ ‌mobile‌ ‌app.‌ ‌When‌ ‌a‌‌user‌‌does‌‌this,‌‌the‌‌application‌‌tells‌‌the‌‌API‌‌to‌‌delete‌‌the‌‌ invitation‌‌from‌‌the‌‌user’s‌‌inbox.‌‌After‌‌this‌‌has‌‌been‌‌completed‌‌the‌‌user‌‌then‌‌will‌‌have‌‌to‌‌accept‌‌ another‌‌invitation‌‌or‌‌create‌‌a‌‌new‌‌household‌‌to‌‌use‌‌the‌‌Hestia‌‌application.‌ ‌ Thus,‌‌since‌‌it‌‌is‌‌possible‌‌to‌‌send‌‌an‌‌invitation‌‌to‌‌allow‌‌someone‌‌to‌‌join‌‌your‌‌household,‌‌it‌‌ is‌‌important‌‌to‌‌explain‌‌how‌‌to‌‌do‌‌this.‌‌When‌‌a‌‌user‌‌is‌‌already‌‌in‌‌a‌‌household‌‌they‌‌have‌‌access‌‌to‌‌ the‌ ‌Household’s‌ ‌settings‌ ‌page.‌ ‌The‌ ‌household‌ ‌settings‌ ‌web‌ ‌page‌ ‌is‌ ‌shown‌ ‌in‌ ‌Fig.‌‌13,‌‌and‌‌the‌‌ household‌‌settings‌‌mobile‌‌page‌‌is‌‌shown‌‌in‌‌Fig.‌‌14.‌‌On‌‌this‌‌page,‌‌the‌‌user‌‌can‌‌see‌‌their‌‌current‌‌ household‌ ‌members,‌ ‌leave‌ ‌their‌ ‌household,‌ ‌and‌ ‌invite‌ ‌new‌ ‌users‌ ‌to‌ ‌join‌ ‌their‌ ‌household.‌ ‌The‌‌ applications‌‌retrieve‌‌the‌‌household‌‌members‌‌using‌‌the‌‌web‌‌API.‌ ‌ ‌ 45‌ ‌ To‌ ‌leave‌‌a‌‌household‌‌the‌‌user‌‌can‌‌select‌‌the‌‌leave‌‌household‌‌button‌‌on‌‌this‌‌page.‌‌When‌‌ they‌ ‌do‌ ‌this‌ ‌the‌ ‌application‌ ‌sends‌ ‌a‌ ‌request‌ ‌to‌ ‌the‌ ‌API‌ ‌to‌ ‌remove‌ ‌them‌ ‌from‌ ‌their‌ ‌current‌‌ household,‌‌leaving‌‌them‌‌without‌‌a‌‌household.‌‌Once‌‌this‌‌occurs,‌‌the‌‌user‌‌once‌‌again‌‌will‌‌have‌‌to‌‌ join‌‌a‌‌new‌‌household‌‌or‌‌create‌‌their‌‌household‌‌before‌‌using‌‌the‌‌rest‌‌of‌‌the‌‌application‌‌again.‌ ‌ Then,‌‌the‌‌final‌‌use‌‌for‌‌this‌‌page‌‌is‌‌to‌‌invite‌‌new‌‌users‌‌to‌‌join‌‌your‌‌household.‌‌To‌‌do‌‌this,‌‌ you‌‌can‌‌type‌‌the‌‌user’s‌‌username‌‌into‌‌the‌‌text‌‌box‌‌on‌‌the‌‌page‌‌and‌‌click‌‌on‌‌the‌‌submit‌‌button‌‌on‌‌ web‌ ‌or‌ ‌the‌ ‌send‌ ‌button‌ ‌on‌ ‌mobile.‌ ‌Doing‌ ‌this‌ ‌will‌ ‌trigger‌ ‌a‌ ‌request‌ ‌to‌ ‌an‌ ‌API‌ ‌endpoint‌ ‌that‌‌ handles‌ ‌the‌ ‌creation‌ ‌of‌‌the‌‌invitation.‌‌Once‌‌sent,‌‌the‌‌user‌‌that‌‌received‌‌the‌‌invitation‌‌can‌‌either‌‌ accept‌‌the‌‌invitation‌‌and‌‌join‌‌the‌‌household‌‌or‌‌reject‌‌the‌‌invitation‌‌and‌‌not‌‌join‌‌the‌‌household.‌ ‌ ‌ ‌ ‌ Fig.‌‌10‌‌-‌‌User‌‌Without‌‌a‌‌Household‌‌Hestia‌‌Web‌‌Application‌‌Page‌ ‌ ‌ 46‌ ‌ ‌ Fig.‌‌11‌‌-‌‌Hestia‌‌Web‌‌Household‌‌Invitation‌ ‌ ‌ Fig‌‌12‌‌-‌‌User‌‌Without‌‌a‌‌Household‌‌Hestia‌‌Mobile‌‌Application‌‌Page‌ ‌ ‌ 47‌ ‌ ‌ Fig‌‌13‌‌-‌‌Hestia‌‌Web‌‌Application‌‌Household‌‌Settings‌‌Page‌ ‌ ‌ Fig‌‌14‌‌-‌‌Hestia‌‌Mobile‌‌Application‌‌Household‌‌Settings‌‌Page‌ ‌ ‌ 48‌ ‌ 4.3‌ The‌‌Home‌‌Page‌‌Dashboard‌ ‌ Then,‌ ‌now‌ ‌that‌ ‌a‌‌user‌‌is‌‌logged‌‌in‌‌and‌‌is‌‌in‌‌a‌‌household‌‌they‌‌can‌‌use‌‌all‌‌the‌‌features‌‌in‌‌ the‌ ‌application.‌‌The‌‌first‌‌feature‌‌I‌‌am‌‌going‌‌to‌‌cover‌‌is‌‌a‌‌web‌‌application‌‌exclusive‌‌feature,‌‌the‌‌ home‌‌page‌‌dashboard‌‌shown‌‌in‌‌Fig.‌‌15.‌‌This‌‌feature‌‌gives‌‌the‌‌user‌‌a‌‌brief‌‌overview‌‌of‌‌all‌‌their‌‌ uncompleted‌ ‌tasks,‌ ‌upcoming‌ ‌meals,‌ ‌upcoming‌ ‌calendar‌ ‌events,‌ ‌and‌ ‌current‌ ‌budgets.‌ ‌It‌ ‌is‌ ‌a‌‌ web-exclusive‌‌feature‌‌because‌‌there‌‌is‌‌not‌‌enough‌‌room‌‌to‌‌show‌‌all‌‌this‌‌information‌‌on‌‌a‌‌single‌‌ page‌‌for‌‌a‌‌mobile‌‌phone.‌‌The‌‌application‌‌uses‌‌various‌‌API‌‌endpoints‌‌to‌‌get‌‌information‌‌about‌‌a‌‌ user’s‌‌incomplete‌‌tasks,‌‌upcoming‌‌meals,‌‌upcoming‌‌calendar‌‌events,‌‌and‌‌current‌‌budgets‌‌that‌‌are‌ displayed‌ ‌on‌ ‌this‌ ‌page.‌ ‌Furthermore,‌ ‌a‌ ‌user‌ ‌can‌ ‌click‌‌the‌‌view‌‌details‌‌button‌‌on‌‌any‌‌section‌‌to‌‌ automatically‌‌get‌‌redirected‌‌to‌‌that‌‌page‌‌on‌‌the‌‌application.‌‌If‌‌there‌‌were‌‌any‌‌current‌‌budgets‌‌or‌‌ upcoming‌‌calendar‌‌events,‌‌those‌‌sections‌‌would‌‌also‌‌have‌‌a‌‌view‌‌details‌‌button.‌ ‌ ‌ ‌ Fig.‌‌15‌‌-‌‌Hestia‌‌Web‌‌Application‌‌dashboard‌ ‌ ‌ ‌ 49‌ ‌ 4.4‌ Budgets‌ ‌ The‌ ‌three‌ ‌features‌ ‌I‌ ‌will‌ ‌be‌ ‌covering‌ ‌next‌ ‌are‌ ‌supported‌ ‌on‌ ‌both‌ ‌the‌ ‌web‌ ‌and‌ ‌mobile‌‌ applications.‌ ‌First,‌‌let’s‌‌start‌‌with‌‌the‌‌budgeting‌‌feature.‌‌This‌‌feature‌‌allows‌‌the‌‌user‌‌to‌‌create‌‌a‌‌ budget‌ ‌and‌ ‌control‌ ‌who‌‌has‌‌access‌‌to‌‌each‌‌budget.‌‌Also,‌‌in‌‌each‌‌budget,‌‌they‌‌can‌‌add‌‌incomes‌‌ and‌ ‌categorize‌ ‌their‌ ‌expenses‌ ‌to‌ ‌help‌ ‌keep‌ ‌their‌ ‌budget‌ ‌organized‌ ‌and‌ ‌finances‌ ‌in‌ ‌check.‌ ‌The‌‌ budget‌ ‌page‌ ‌on‌ ‌web‌ ‌is‌ ‌shown‌ ‌in‌ ‌Fig.‌ ‌16,‌ ‌and‌ ‌the‌ ‌budget‌ ‌page‌ ‌on‌ ‌mobile‌ ‌is‌‌shown‌‌in‌‌Fig.‌‌17.‌‌ Both‌ ‌of‌ ‌these‌ ‌pages‌ ‌use‌ ‌an‌ ‌API‌ ‌endpoint‌ ‌to‌ ‌retrieve‌ ‌the‌ ‌information‌ ‌to‌ ‌display‌ ‌about‌ ‌every‌‌ budget‌ ‌the‌ ‌user‌ ‌can‌ ‌access.‌ ‌In‌ ‌the‌ ‌web‌ ‌application,‌ ‌expenses‌ ‌are‌ ‌shown‌ ‌by‌ ‌category,‌ ‌and‌ ‌the‌‌ charts‌‌show‌‌you‌‌how‌‌much‌‌money‌‌you‌‌have‌‌left‌‌in‌‌each‌‌category.‌‌Then.‌‌for‌‌incomes,‌‌this‌‌page‌‌ shows‌ ‌the‌ ‌user‌ ‌what‌ ‌percentage‌ ‌of‌‌each‌‌income‌‌makes‌‌up‌‌their‌‌total‌‌income.‌‌Then,‌‌on‌‌mobile,‌‌ the‌‌budget's‌‌incomes‌‌and‌‌expenses‌‌are‌‌shown‌‌using‌‌the‌‌cards‌‌at‌‌the‌‌bottom.‌‌Incomes‌‌get‌‌shown‌‌ in‌ ‌green,‌ ‌and‌ ‌expenses‌ ‌in‌ ‌red.‌ ‌On‌‌these‌‌pages,‌‌the‌‌user‌‌can‌‌select‌‌which‌‌budget‌‌to‌‌work‌‌on‌‌by‌‌ selecting‌‌a‌‌budget‌‌on‌‌mobile,‌‌and‌‌clicking‌‌on‌‌your‌‌desired‌‌budget‌‌on‌‌the‌‌web‌‌app.‌ ‌ To‌‌create‌‌a‌‌new‌‌budget‌‌on‌‌web,‌‌the‌‌user‌‌can‌‌click‌‌on‌‌'create‌‌new‌‌budget'.‌‌After‌‌this,‌‌they‌‌ will‌‌enter‌‌the‌‌budget's‌‌name,‌‌start‌‌date,‌‌and‌‌end‌‌date.‌‌Budgets‌‌can‌‌also‌‌be‌‌created‌‌on‌‌mobile‌‌by‌‌ selecting‌‌“choose‌‌a‌‌budget”‌‌and‌‌clicking‌‌on‌‌the‌‌plus‌‌sign.‌‌After‌‌this,‌‌a‌‌user‌‌will‌‌click‌‌on‌‌a‌‌button‌‌ saying‌‌'create‌‌the‌‌budget',‌‌which‌‌will‌‌send‌‌a‌‌request‌‌to‌‌the‌‌necessary‌‌API‌‌endpoint‌‌to‌‌create‌‌the‌‌ budget.‌‌Once‌‌created,‌‌a‌‌user‌‌can‌‌control‌‌which‌‌household‌‌members‌‌have‌‌access‌‌to‌‌the‌‌budget‌‌by‌‌ clicking‌‌on‌‌the‌‌people‌‌icon‌‌next‌‌to‌‌choose‌‌a‌‌budget‌‌on‌‌mobile‌‌and‌‌clicking‌‌on‌‌the‌‌pen‌‌and‌‌paper‌‌ icon‌ ‌on‌ ‌the‌ ‌web.‌ ‌Here‌ ‌you‌ ‌can‌ ‌grant‌ ‌household‌ ‌members‌ ‌access‌ ‌to‌ ‌the‌ ‌budget‌ ‌and‌ ‌remove‌‌ household‌‌member's‌‌access‌‌to‌‌the‌‌budget.‌‌When‌‌access‌‌is‌‌removed‌‌or‌‌granted,‌‌requests‌‌are‌‌made‌‌ to‌‌the‌‌API‌‌to‌‌save‌‌these‌‌changes.‌ ‌ ‌ 50‌ ‌ Furthermore,‌‌when‌‌a‌‌budget‌‌is‌‌selected,‌‌a‌‌user‌‌can‌‌add‌‌incomes,‌‌categories,‌‌and‌‌expenses‌‌ to‌ ‌that‌ ‌budget.‌‌On‌‌mobile,‌‌all‌‌of‌‌these‌‌can‌‌be‌‌added‌‌by‌‌clicking‌‌on‌‌the‌‌card‌‌with‌‌a‌‌plus‌‌icon‌‌at‌‌ the‌‌bottom‌‌of‌‌a‌‌page.‌‌Then,‌‌on‌‌web‌‌the‌‌user‌‌does‌‌this‌‌by‌‌typing‌‌in‌‌the‌‌name‌‌and‌‌associated‌‌value‌‌ amount‌ ‌in‌ ‌the‌ ‌correct‌ ‌area‌ ‌of‌ ‌the‌ ‌page‌ ‌depending‌ ‌on‌ ‌whether‌ ‌they‌ ‌want‌ ‌to‌ ‌create‌ ‌an‌ ‌income,‌‌ category,‌ ‌or‌ ‌expense.‌ ‌All‌ ‌of‌ ‌these‌ ‌items‌ ‌get‌‌created‌‌using‌‌various‌‌API‌‌endpoints.‌‌Additionally,‌‌ you‌ ‌can‌ ‌delete‌ ‌these‌ ‌same‌ ‌items‌ ‌by‌ ‌clicking‌ ‌on‌ ‌the‌ ‌minus‌ ‌icon‌ ‌next‌ ‌to‌ ‌them‌ ‌in‌ ‌the‌ ‌web‌‌ application‌‌and‌‌clicking‌‌the‌‌x‌‌icon‌‌on‌‌the‌‌cards‌‌in‌‌the‌‌mobile‌‌application.‌‌Doing‌‌this‌‌causes‌‌the‌ application‌‌to‌‌send‌‌requests‌‌to‌‌API‌‌endpoints‌‌which‌‌remove‌‌the‌‌item‌‌from‌‌the‌‌budget.‌‌Therefore,‌ by‌ ‌using‌ ‌the‌ ‌budgeting‌ ‌feature,‌ ‌a‌ ‌user‌ ‌can‌ ‌easily‌ ‌manage‌ ‌their‌ ‌finances‌ ‌using‌ ‌the‌ ‌Hestia‌‌ application.‌ ‌ ‌ ‌ ‌ Fig.‌‌16‌‌-‌‌Hestia‌‌Web‌‌Application‌‌budget‌‌page‌ ‌ 51‌ ‌ ‌ Fig.‌‌17‌‌-‌‌Hestia‌‌Mobile‌‌Application‌‌Budget‌‌Page‌ ‌ 4.5‌ The‌‌To-do‌‌List‌ ‌ Next,‌ ‌the‌ ‌to-do‌ ‌list‌ ‌feature,‌ ‌also‌ ‌known‌ ‌as‌ ‌the‌ ‌tasks‌ ‌feature.‌ ‌This‌ ‌feature‌ ‌serves‌ ‌as‌ ‌a‌‌ household‌‌to-do‌‌list‌‌where‌‌any‌‌family‌‌member‌‌can‌‌see‌‌the‌‌tasks‌‌on‌‌the‌‌to-do‌‌list‌‌and‌‌mark‌‌them‌‌ as‌‌completed‌‌or‌‌incomplete.‌‌The‌‌to-do‌‌list‌‌page‌‌for‌‌mobile‌‌is‌‌shown‌‌in‌‌Fig.‌‌18‌‌and‌‌the‌‌to-do‌‌list‌‌ page‌‌for‌‌web‌‌is‌‌shown‌‌in‌‌Fig.‌‌19.‌‌These‌‌two‌‌designs‌‌are‌‌very‌‌similar‌‌across‌‌both‌‌platforms.‌‌Both‌‌ get‌‌the‌‌tasks‌‌to‌‌display‌‌from‌‌an‌‌endpoint‌‌that‌‌will‌‌retrieve‌‌all‌‌of‌‌the‌‌tasks‌‌for‌‌the‌‌household.‌‌To‌‌ create‌‌a‌‌task,‌‌the‌‌user‌‌can‌‌type‌‌in‌‌the‌‌task‌‌name‌‌in‌‌the‌‌text‌‌box‌‌and‌‌then‌‌click‌‌the‌‌+‌‌icon,‌‌which‌‌ will‌‌trigger‌‌a‌‌request‌‌to‌‌create‌‌the‌‌task‌‌in‌‌the‌‌database.‌ ‌ ‌ 52‌ ‌ Then,‌ ‌with‌ ‌the‌ ‌created‌ ‌tasks,‌ ‌the‌ ‌user‌ ‌can‌ ‌check‌ ‌them‌ ‌off‌ ‌or‌ ‌uncheck‌ ‌them‌ ‌using‌ ‌the‌‌ checkbox‌ ‌located‌‌beside‌‌each‌‌task.‌‌When‌‌this‌‌box‌‌is‌‌clicked,‌‌a‌‌request‌‌gets‌‌sent‌‌to‌‌an‌‌endpoint‌‌ that‌‌toggles‌‌its‌‌completion‌‌status.‌‌An‌‌unchecked‌‌task‌‌gets‌‌moved‌‌back‌‌to‌‌the‌‌tasks‌‌section‌‌in‌‌the‌‌ app,‌‌while‌‌a‌‌checked-off‌‌task‌‌moves‌‌to‌‌the‌‌completed‌‌section.‌‌Additionally,‌‌a‌‌user‌‌can‌‌click‌‌the‌‌x‌‌ icon‌‌on‌‌each‌‌task‌‌to‌‌delete‌‌it.‌‌When‌‌this‌‌happens,‌‌the‌‌application‌‌will‌‌send‌‌a‌‌request‌‌to‌‌delete‌‌the‌‌ task.‌‌Through‌‌this‌‌feature,‌‌the‌‌user‌‌has‌‌an‌‌easy-to-use‌‌household‌‌to-do‌‌list‌‌within‌‌Hestia‌‌that‌‌can‌‌ help‌‌them‌‌keep‌‌track‌‌of‌‌every‌‌task‌‌they‌‌need‌‌to‌‌complete.‌ ‌ ‌ Fig.‌‌18‌‌-‌‌Hestia‌‌Mobile‌‌Application‌‌To-do‌‌List‌‌Page‌ ‌ ‌ 53‌ ‌ ‌ Fig.‌‌19‌‌-‌‌Hestia‌‌Web‌‌Application‌‌To-do‌‌List‌‌Page‌ ‌ 4.6‌ The‌‌Calendar‌ ‌ Then,‌ ‌the‌ ‌final‌ ‌feature‌ ‌supported‌ ‌on‌ ‌both‌ ‌the‌ ‌web‌‌and‌‌mobile‌‌platforms‌‌is‌‌the‌‌calendar‌‌ feature.‌‌This‌‌feature‌‌should‌‌help‌‌users‌‌manage‌‌their‌‌lives‌‌by‌‌allowing‌‌them‌‌to‌‌schedule‌‌events‌‌on‌‌ their‌‌calendar‌‌so‌‌they‌‌know‌‌what‌‌they‌‌have‌‌to‌‌do‌‌at‌‌each‌‌time‌‌of‌‌the‌‌day‌‌and‌‌at‌‌which‌‌points‌‌of‌‌ the‌‌day‌‌they‌‌have‌‌free‌‌time‌‌to‌‌schedule‌‌something‌‌else‌‌or‌‌just‌‌take‌‌a‌‌break.‌‌The‌‌calendar‌‌page‌‌on‌‌ mobile‌ ‌is‌ ‌shown‌ ‌in‌ ‌Fig.‌ ‌20,‌ ‌and‌ ‌the‌ ‌calendar‌‌page‌‌on‌‌the‌‌web‌‌application‌‌is‌‌shown‌‌in‌‌Fig.‌‌21.‌‌ Both‌‌of‌‌the‌‌applications‌‌use‌‌the‌‌same‌‌endpoint‌‌to‌‌retrieve‌‌the‌‌calendar‌‌events‌‌for‌‌all‌‌users‌‌in‌‌the‌‌ household.‌ ‌These‌ ‌events‌ ‌get‌ ‌displayed‌ ‌on‌ ‌the‌ ‌calendar‌ ‌of‌ ‌both‌ ‌applications.‌‌Then,‌‌within‌‌both‌‌ applications,‌‌a‌‌user‌‌can‌‌create‌‌new‌‌events.‌‌On‌‌mobile,‌‌a‌‌user‌‌creates‌‌a‌‌new‌‌event‌‌by‌‌clicking‌‌on‌‌ the‌‌add‌‌event‌‌button‌‌and‌‌entering‌‌the‌‌necessary‌‌information‌‌for‌‌the‌‌event.‌‌To‌‌do‌‌the‌‌same‌‌thing‌‌ on‌‌web,‌‌a‌‌user‌‌can‌‌click‌‌anywhere‌‌on‌‌the‌‌calendar‌‌and‌‌fill‌‌out‌‌the‌‌information.‌‌At‌‌this‌‌point,‌‌the‌‌ apps‌‌send‌‌a‌‌request‌‌to‌‌an‌‌endpoint‌‌which‌‌creates‌‌the‌‌calendar‌‌event.‌ ‌ Once‌‌these‌‌events‌‌are‌‌created,‌‌a‌‌user‌‌can‌‌modify‌‌an‌‌event‌‌by‌‌clicking‌‌on‌‌it.‌‌When‌‌a‌‌user‌‌ clicks‌‌on‌‌an‌‌event‌‌they‌‌can‌‌change‌‌the‌‌event's‌‌scheduled‌‌time,‌‌the‌‌color‌‌it‌‌is‌‌displayed‌‌in,‌‌or‌‌the‌‌ people‌ ‌assigned‌ ‌to‌ ‌the‌ ‌event.‌ ‌These‌ ‌changes‌ ‌get‌ ‌saved‌‌through‌‌an‌‌API‌‌request.‌‌Additionally,‌‌a‌‌ ‌ 54‌ ‌ user‌ ‌can‌ ‌delete‌ ‌an‌ ‌event‌‌by‌‌clicking‌‌on‌‌it.‌‌Then,‌‌instead‌‌of‌‌clicking‌‌the‌‌submit‌‌button,‌‌the‌‌user‌‌ will‌ ‌click‌ ‌the‌‌'Delete‌‌Event'‌‌button,‌‌which‌‌triggers‌‌an‌‌API‌‌call‌‌to‌‌delete‌‌the‌‌event.‌‌Overall,‌‌this‌‌ feature‌ ‌should‌ ‌make‌ ‌it‌ ‌much‌ ‌easier‌ ‌for‌ ‌users‌ ‌to‌ ‌plan‌ ‌out‌ ‌their‌ ‌day‌ ‌and‌ ‌keep‌ ‌on‌ ‌top‌ ‌of‌ ‌their‌‌ schedules.‌‌This‌‌calendar‌‌makes‌‌overall‌‌life‌‌management‌‌easier,‌‌therefore‌‌it‌‌will‌‌help‌‌anyone‌‌stay‌‌ on‌‌top‌‌of‌‌the‌‌events‌‌in‌‌their‌‌life.‌ ‌ ‌ Fig.‌‌20‌‌-‌‌Hestia‌‌Mobile‌‌Application‌‌Calendar‌‌Page‌ ‌ ‌ 55‌ ‌ ‌ Fig.‌‌21‌‌-‌‌Hestia‌‌Web‌‌Application‌‌Calendar‌‌Page‌ ‌ 4.7‌ The‌‌Household‌‌Recipe‌‌Book‌‌and‌‌Meal‌‌Planning‌ ‌ Then,‌ ‌the‌ ‌last‌ ‌two‌ ‌features‌ ‌once‌‌again‌‌are‌‌web‌‌application‌‌exclusives.‌‌This‌‌time‌‌ instead‌‌of‌‌the‌‌feature‌‌being‌‌infeasible‌‌to‌‌create‌‌on‌‌mobile,‌‌these‌‌became‌‌web-only‌‌features‌‌due‌‌to‌‌ time‌‌constraints.‌‌Because‌‌our‌‌team‌‌decided‌‌to‌‌have‌‌two‌‌full-time‌‌web‌‌application‌‌developers‌‌and‌‌ only‌ ‌one‌‌full-time‌‌mobile‌‌application‌‌developer,‌‌we‌‌accomplished‌‌more‌‌on‌‌the‌‌web‌‌application‌‌ simply‌‌because‌‌of‌‌the‌‌extra‌‌developer‌‌assigned‌‌to‌‌it.‌‌ ‌ The‌ ‌first‌ ‌of‌ ‌these‌ ‌two‌ ‌features‌ ‌is‌ ‌the‌ ‌household‌ ‌recipe‌ ‌book‌ ‌and‌ ‌meal‌ ‌planning‌‌ page.‌ ‌This‌ ‌feature‌ ‌allows‌ ‌users‌ ‌to‌ ‌create‌ ‌recipes‌ ‌and‌ ‌add‌ ‌them‌‌to‌‌their‌‌household‌‌recipe‌‌book.‌‌ Then,‌‌the‌‌user‌‌can‌‌schedule‌‌a‌‌meal‌‌by‌‌selecting‌‌a‌‌recipe‌‌and‌‌choosing‌‌the‌‌specific‌‌day‌‌they‌‌want‌‌ to‌ ‌make‌ ‌that‌ ‌recipe.‌ ‌The‌ ‌Recipe‌‌Book‌‌Page‌‌is‌‌shown‌‌in‌‌Fig.‌‌22,‌‌and‌‌the‌‌recipes‌‌it‌‌displays‌‌get‌‌ retrieved‌ ‌through‌ ‌the‌ ‌API.‌ ‌Then,‌ ‌the‌ ‌user‌ ‌can‌ ‌select‌ ‌the‌ ‌+‌ ‌icon‌ ‌next‌ ‌to‌ ‌the‌ ‌Recipes‌ ‌header‌ ‌to‌‌ create‌‌a‌‌new‌‌recipe‌‌to‌‌add‌‌to‌‌the‌‌household‌‌recipe‌‌book.‌‌When‌‌the‌‌user‌‌clicks‌‌this‌‌icon,‌‌they‌‌can‌‌ make‌ ‌a‌ ‌new‌ ‌recipe‌ ‌that‌ ‌has‌‌a‌‌name,‌‌instructions,‌‌and‌‌a‌‌list‌‌of‌‌ingredients.‌‌Then,‌‌when‌‌the‌‌user‌‌ ‌ 56‌ ‌ clicks‌ ‌the‌ ‌submit‌ ‌button‌‌the‌‌web‌‌application‌‌sends‌‌a‌‌request‌‌to‌‌the‌‌web‌‌API‌‌to‌‌save‌‌this‌‌newly‌‌ created‌‌recipe.‌ ‌ Once‌ ‌a‌ ‌recipe‌ ‌gets‌ ‌created,‌ ‌a‌ ‌user‌ ‌can‌ ‌click‌ ‌on‌‌it‌‌to‌‌see‌‌it‌‌in‌‌the‌‌recipe‌‌view.‌‌In‌ Fig.‌‌22,‌‌you‌‌can‌‌see‌‌that‌‌the‌‌spaghetti‌‌recipe‌‌is‌‌currently‌‌selected.‌‌Then,‌‌using‌‌the‌‌buttons‌‌in‌‌the‌‌ upper‌ ‌right‌ ‌corner,‌ ‌a‌ ‌user‌ ‌can‌ ‌update‌ ‌or‌ ‌delete‌ ‌the‌ ‌recipe.‌ ‌If‌ ‌they‌ ‌click‌ ‌on‌ ‌the‌ ‌delete‌ ‌button‌ ‌a‌‌ request‌‌is‌‌made‌‌to‌‌delete‌‌the‌‌recipe.‌‌Then,‌‌if‌‌the‌‌user‌‌selects‌‌the‌‌update‌‌button‌‌they‌‌can‌‌change‌‌ the‌‌name‌‌and‌‌instructions‌‌for‌‌the‌‌recipe‌‌and‌‌delete‌‌or‌‌add‌‌ingredients‌‌to‌‌the‌‌recipe.‌‌Once‌‌the‌‌user‌‌ is‌‌done‌‌editing‌‌the‌‌recipe‌‌they‌‌click‌‌submit‌‌to‌‌save‌‌their‌‌changes.‌‌When‌‌they‌‌do‌‌this,‌‌requests‌‌are‌‌ sent‌ ‌to‌ ‌various‌ ‌endpoints‌ ‌to‌ ‌ensure‌ ‌that‌ ‌the‌ ‌saved‌‌recipe‌‌matches‌‌the‌‌modified‌‌recipe.‌‌Overall,‌‌ this‌ ‌allows‌ ‌a‌ ‌household‌ ‌to‌ ‌create‌ ‌and‌ ‌maintain‌ ‌their‌ ‌family‌ ‌recipe‌ ‌book‌ ‌within‌ ‌the‌ ‌Hestia‌‌ application.‌ ‌ Then,‌ ‌the‌ ‌household‌ ‌can‌ ‌plan‌ ‌meals‌ ‌based‌ ‌on‌ ‌their‌ ‌recipe‌ ‌book‌ ‌by‌ ‌scheduling‌‌ meals‌ ‌from‌ ‌it‌ ‌for‌ ‌breakfast,‌ ‌lunch,‌ ‌or‌ ‌dinner‌ ‌on‌ ‌specific‌ ‌days.‌ ‌The‌ ‌web‌ ‌application’s‌ ‌meal‌‌ planning‌ ‌page‌ ‌is‌ ‌shown‌ ‌in‌ ‌Fig.‌ ‌23,‌ ‌and‌ ‌the‌ ‌meals‌ ‌it‌ ‌shows‌ ‌are‌ ‌retrieved‌ ‌by‌ ‌a‌ ‌different‌ ‌API‌‌ endpoint.‌‌To‌‌create‌‌a‌‌recipe,‌‌a‌‌user‌‌will‌‌select‌‌the‌‌+‌‌icon‌‌next‌‌to‌‌means‌‌and‌‌choose‌‌the‌‌recipe‌‌to‌‌ schedule,‌ ‌the‌ ‌date‌ ‌to‌ ‌schedule‌ ‌it‌‌for,‌‌and‌‌the‌‌meal‌‌type‌‌(breakfast,‌‌lunch,‌‌or‌‌dinner)‌‌and‌‌hit‌‌the‌‌ submit‌‌button.‌‌Doing‌‌this‌‌sends‌‌a‌‌request‌‌to‌‌the‌‌API,‌‌which‌‌handles‌‌the‌‌creation‌‌of‌‌the‌‌meal.‌ ‌ Once‌‌a‌‌meal‌‌is‌‌created,‌‌it‌‌can‌‌be‌‌selected‌‌by‌‌clicking‌‌on‌‌it,‌‌which‌‌shows‌‌it‌‌on‌‌the‌‌ right‌ ‌side‌ ‌of‌ ‌the‌ ‌page‌ ‌like‌ ‌in‌ ‌Fig.‌ ‌23.‌ ‌In‌ ‌Fig.‌ ‌23,‌ ‌we‌ ‌can‌ ‌see‌ ‌that‌ ‌there‌ ‌is‌ ‌a‌ ‌Spaghetti‌ ‌dinner‌‌ planned‌ ‌for‌ ‌December‌ ‌9th,‌ ‌and‌ ‌having‌ ‌it‌ ‌selected‌ ‌will‌ ‌show‌ ‌us‌ ‌the‌ ‌recipe‌ ‌for‌‌the‌‌meal,‌‌which‌‌ should‌‌help‌‌the‌‌user‌‌when‌‌that‌‌day‌‌arrives.‌‌Furthermore,‌‌when‌‌a‌‌meal‌‌is‌‌selected,‌‌you‌‌can‌‌delete‌‌ the‌‌meal‌‌by‌‌clicking‌‌on‌‌the‌‌delete‌‌button‌‌in‌‌the‌‌upper‌‌right-hand‌‌corner‌‌of‌‌the‌‌page.‌‌Once‌‌again,‌‌ ‌ 57‌ ‌ this‌ ‌will‌ ‌send‌‌a‌‌request‌‌to‌‌the‌‌backend‌‌API‌‌to‌‌handle‌‌the‌‌deletion.‌‌This‌‌feature,‌‌in‌‌tandem‌‌with‌‌ the‌‌recipe‌‌book,‌‌should‌‌make‌‌meal‌‌planning‌‌a‌‌breeze‌‌for‌‌any‌‌Hestia‌‌household.‌ ‌ ‌ ‌ Fig.‌‌22‌‌-‌‌Hestia‌‌Web‌‌Application‌‌Household‌‌Recipe‌‌Book‌‌Page‌ ‌ ‌ ‌ ‌ Fig.‌‌23‌‌-‌‌Hestia‌‌Web‌‌Application‌‌Meal‌‌Planning‌‌Page‌ ‌ ‌ 58‌ ‌ 4.8‌ The‌‌Grocery‌‌List‌ ‌ Then,‌‌the‌‌final‌‌feature‌‌of‌‌Hestia‌‌is‌‌the‌‌grocery‌‌list‌‌feature,‌‌which‌‌goes‌‌hand‌‌in‌‌hand‌‌with‌‌ the‌ ‌meal‌ ‌planning‌ ‌feature‌ ‌discussed‌ ‌previously.‌ ‌This‌ ‌feature‌ ‌is‌ ‌designed‌‌to‌‌help‌‌users‌‌plan‌‌out‌‌ their‌‌grocery‌‌list‌‌based‌‌on‌‌the‌‌meals‌‌scheduled.‌‌The‌‌web‌‌application's‌‌grocery‌‌list‌‌page‌‌is‌‌shown‌‌ in‌‌Fig.‌‌24.‌‌On‌‌this‌‌page,‌‌a‌‌user‌‌can‌‌manage‌‌a‌‌grocery‌‌list‌‌that‌‌they‌‌can‌‌use‌‌when‌‌they‌‌are‌‌at‌‌the‌‌ store‌ ‌when‌ ‌buying‌ ‌their‌ ‌groceries.‌ ‌The‌ ‌grocery‌ ‌list‌ ‌is‌ ‌shown‌ ‌per‌ ‌household‌ ‌to‌ ‌ensure‌ ‌that‌‌ multiple‌ ‌family‌ ‌members‌ ‌don’t‌ ‌buy‌ ‌the‌ ‌same‌ ‌groceries.‌ ‌All‌ ‌the‌ ‌grocery‌ ‌list‌ ‌items‌ ‌shown‌ ‌are‌‌ retrieved‌ ‌via‌ ‌a‌ ‌specific‌ ‌API‌ ‌endpoint.‌ ‌The‌ ‌user‌ ‌can‌ ‌manually‌ ‌add‌ ‌items‌ ‌to‌ ‌the‌ ‌grocery‌ ‌list‌ ‌by‌‌ giving‌ ‌an‌ ‌item‌ ‌a‌ ‌name,‌ ‌quantity,‌ ‌and‌ ‌unit‌ ‌of‌ ‌measurement‌ ‌and‌ ‌clicking‌ ‌the‌ ‌add‌ ‌button.‌ ‌This‌‌ action‌‌triggers‌‌a‌‌call‌‌to‌‌an‌‌endpoint‌‌which‌‌adds‌‌this‌‌new‌‌item‌‌to‌‌the‌‌household's‌‌grocery‌‌list.‌‌An‌‌ interesting‌‌feature‌‌of‌‌this‌‌endpoint‌‌is‌‌that‌‌if‌‌two‌‌items‌‌on‌‌the‌‌grocery‌‌list‌‌have‌‌the‌‌same‌‌name‌‌and‌‌ their‌ ‌units‌ ‌are‌ ‌compatible,‌ ‌the‌ ‌two‌ ‌items‌ ‌automatically‌ ‌get‌ ‌converted‌ ‌into‌ ‌a‌ ‌single‌‌grocery‌‌list‌‌ item.‌ ‌This‌ ‌feature‌ ‌means‌ ‌if‌ ‌one‌ ‌family‌ ‌member‌ ‌adds‌ ‌1‌ ‌lb.‌ ‌of‌ ‌ground‌ ‌beef‌ ‌and‌ ‌another‌ ‌family‌‌ member‌‌adds‌‌8‌‌oz.‌‌of‌‌ground‌‌beef,‌‌the‌‌grocery‌‌list‌‌will‌‌automatically‌‌combine‌‌these‌‌entries‌‌into‌‌ 1.5‌‌lbs.‌‌of‌‌ground‌‌beef.‌‌ ‌ Then,‌‌once‌‌grocery‌‌list‌‌items‌‌are‌‌created,‌‌they‌‌can‌‌easily‌‌be‌‌deleted‌‌by‌‌clicking‌‌on‌‌the‌‌x‌‌ icon‌ ‌for‌ ‌each‌ ‌item.‌ ‌As‌ ‌usual,‌ ‌this‌ ‌will‌ ‌send‌ ‌a‌ ‌request‌ ‌to‌ ‌an‌ ‌API‌ ‌endpoint‌ ‌that‌ ‌permanently‌‌ removes‌ ‌the‌ ‌item‌ ‌from‌ ‌the‌ ‌grocery‌ ‌list.‌ ‌Then,‌ ‌while‌ ‌at‌ ‌the‌ ‌store,‌ ‌a‌ ‌user‌ ‌can‌ ‌check‌ ‌off‌ ‌each‌‌ grocery‌‌list‌‌item‌‌as‌‌they‌‌pick‌‌it‌‌up‌‌by‌‌clicking‌‌on‌‌the‌‌checkbox‌‌next‌‌to‌‌each‌‌item‌‌which‌‌will‌‌help‌‌ a‌‌user‌‌keep‌‌track‌‌of‌‌what‌‌items‌‌they‌‌still‌‌need‌‌to‌‌get.‌‌Clicking‌‌this‌‌check‌‌box‌‌sends‌‌a‌‌request‌‌to‌‌ an‌ ‌endpoint‌ ‌that‌ ‌will‌ ‌either‌ ‌check‌ ‌or‌ ‌uncheck‌‌a‌‌grocery‌‌list‌‌item‌‌based‌‌on‌‌if‌‌it‌‌was‌‌checked‌‌or‌‌ unchecked‌‌before.‌ ‌ ‌ 59‌ ‌ However,‌ ‌these‌ ‌features‌ ‌are‌ ‌good,‌ ‌but‌ ‌they‌ ‌are‌ ‌not‌ ‌the‌ ‌main‌ ‌draw‌ ‌of‌ ‌this‌ ‌grocery‌ ‌list‌‌ feature‌‌as‌‌a‌‌whole.‌‌That‌‌draw‌‌is‌‌the‌‌export‌‌meals‌‌feature‌‌implemented‌‌into‌‌the‌‌grocery‌‌list.‌‌This‌‌ feature‌ ‌allows‌ ‌a‌ ‌user‌ ‌to‌ ‌automatically‌ ‌generate‌ ‌their‌ ‌grocery‌ ‌list‌ ‌based‌‌on‌‌the‌‌meals‌‌they‌‌have‌‌ scheduled‌ ‌in‌ ‌the‌ ‌date‌ ‌range‌ ‌they‌ ‌select.‌ ‌The‌ ‌user‌ ‌will‌ ‌click‌ ‌export‌ ‌meals‌ ‌to‌ ‌start‌ ‌this‌ ‌process‌‌ which‌ ‌will‌‌call‌‌an‌‌endpoint‌‌that‌‌will‌‌automatically‌‌remove‌‌previously‌‌generated‌‌items‌‌and‌‌then‌‌ look‌‌at‌‌all‌‌meals‌‌scheduled‌‌in‌‌the‌‌time‌‌frame‌‌and‌‌add‌‌their‌‌ingredients‌‌to‌‌the‌‌shopping‌‌list.‌‌Once‌‌ again,‌‌this‌‌will‌‌combine‌‌ingredients‌‌that‌‌have‌‌the‌‌same‌‌name‌‌and‌‌compatible‌‌units‌‌into‌‌a‌‌single‌‌ grocery‌ ‌list‌ ‌item.‌ ‌Overall,‌ ‌this‌ ‌integration‌ ‌with‌‌the‌‌meal‌‌planning‌‌feature‌‌makes‌‌it‌‌much‌‌easier‌‌ for‌‌a‌‌user‌‌to‌‌create‌‌their‌‌grocery‌‌list‌‌in‌‌no‌‌time‌‌at‌‌all,‌‌which‌‌makes‌‌home‌‌management‌‌as‌‌a‌‌whole‌‌ much‌‌easier‌‌because‌‌putting‌‌together‌‌a‌‌grocery‌‌list‌‌can‌‌take‌‌a‌‌surprisingly‌‌long‌‌amount‌‌of‌‌time.‌ ‌ ‌ ‌ ‌ Fig‌‌24‌‌-‌‌Hestia‌‌Web‌‌Application‌‌Grocery‌‌List‌‌Page‌ ‌ ‌ 60‌ ‌ 5‌‌INDIVIDUAL‌‌CONTRIBUTIONS‌ ‌ Overall,‌‌our‌‌team‌‌is‌‌extremely‌‌happy‌‌with‌‌how‌‌the‌‌application‌‌turned‌‌out.‌‌Furthermore,‌‌I‌‌ feel‌‌like‌‌I‌‌was‌‌able‌‌to‌‌substantially‌‌contribute‌‌to‌‌the‌‌team's‌‌success.‌‌In‌‌this‌‌section,‌‌I‌‌will‌‌cover‌‌ the‌ ‌contributions‌ ‌I‌ ‌made‌ ‌to‌ ‌the‌ ‌project‌ ‌and‌ ‌explain‌ ‌how‌ ‌I‌ ‌accomplished‌ ‌everything‌ ‌that‌ ‌I‌‌was‌ responsible‌ ‌for.‌ ‌Throughout‌ ‌the‌ ‌project,‌ ‌I‌ ‌served‌ ‌in‌ ‌four‌ ‌different‌ ‌roles‌‌for‌‌the‌‌team.‌‌I‌‌was‌‌the‌‌ database‌‌designer‌‌and‌‌maintainer‌‌for‌‌our‌‌main‌‌Hestia‌‌database,‌‌one‌‌of‌‌two‌‌developers‌‌in‌‌charge‌‌ of‌ ‌the‌ ‌backend‌ ‌web‌ ‌API,‌ ‌the‌ ‌quality‌ ‌engineer‌ ‌for‌ ‌the‌ ‌web‌ ‌API,‌ ‌the‌ ‌'about‌ ‌Hestia'‌ ‌website‌‌ designer.‌ ‌I‌ ‌will‌ ‌explain‌ ‌what‌ ‌I‌ ‌accomplished‌ ‌in‌ ‌each‌ ‌of‌ ‌these‌ ‌roles‌ ‌and‌ ‌explain‌ ‌how‌ ‌my‌‌ contributions‌‌helped‌‌contribute‌‌to‌‌the‌‌overall‌‌success‌‌of‌‌the‌‌project.‌ ‌ 5.1‌ Designer‌‌and‌‌Maintainer‌‌of‌‌the‌‌Main‌‌Hestia‌‌Database‌ ‌ Firstly,‌ ‌I‌ ‌served‌ ‌as‌ ‌the‌ ‌designer‌ ‌and‌ ‌maintainer‌ ‌of‌ ‌the‌ ‌main‌‌Hestia‌‌database.‌‌This‌‌main‌‌ Hestia‌‌database‌‌is‌‌the‌‌database‌‌that‌‌the‌‌backend‌‌web‌‌API‌‌connects‌‌to‌‌that‌‌stores‌‌all‌‌information‌‌ needed‌ ‌for‌ ‌the‌ ‌mobile‌ ‌and‌ ‌web‌ ‌applications‌ ‌to‌‌function.‌‌This‌‌single‌‌database‌‌has‌‌to‌‌store‌‌user,‌‌ household,‌ ‌recipe,‌ ‌meal,‌ ‌grocery‌ ‌list,‌ ‌to-do,‌ ‌calendar,‌ ‌and‌ ‌budget‌ ‌information‌ ‌to‌ ‌ensure‌‌ everything‌ ‌a‌ ‌user‌ ‌does‌ ‌on‌ ‌the‌ ‌application‌ ‌would‌ ‌still‌ ‌exist‌ ‌the‌ ‌next‌ ‌time‌ ‌they‌ ‌log‌ ‌in.‌ ‌As‌ ‌the‌‌ database‌‌designer,‌‌it‌‌was‌‌my‌‌job‌‌to‌‌create‌‌a‌‌database‌‌that‌‌would‌‌allow‌‌all‌‌of‌‌this‌‌to‌‌happen.‌‌For‌‌ starters,‌‌I‌‌had‌‌to‌‌find‌‌somewhere‌‌to‌‌host‌‌the‌‌database,‌‌and‌‌since‌‌the‌‌rest‌‌of‌‌our‌‌project‌‌was‌‌hosted‌‌ using‌ ‌Microsoft‌ ‌Azure,‌ ‌I‌ ‌felt‌ ‌that‌ ‌it‌ ‌would‌ ‌be‌ ‌a‌ ‌good‌ ‌idea‌ ‌to‌ ‌host‌ ‌the‌ ‌database‌ ‌on‌ ‌Microsoft‌‌ Azure‌‌also.‌‌To‌‌create‌‌the‌‌database‌‌on‌‌Microsoft‌‌Azure,‌‌I‌‌made‌‌the‌‌database‌‌server,‌‌which‌‌is‌‌the‌‌ web‌ ‌address‌ ‌that‌ ‌the‌ ‌database‌ ‌would‌ ‌be‌ ‌located‌ ‌at.‌ ‌Then,‌ ‌I‌ ‌created‌ ‌the‌ ‌database‌ ‌itself‌ ‌using‌‌ Microsoft‌ ‌Azure.‌ ‌A‌ ‌helpful‌ ‌feature‌ ‌about‌ ‌doing‌ ‌this‌ ‌using‌ ‌Azure,‌ ‌along‌ ‌with‌ ‌almost‌ ‌any‌‌ third-party‌‌hosting‌‌services,‌‌is‌‌that‌‌I‌‌could‌‌up‌‌a‌‌firewall‌‌to‌‌restrict‌‌what‌‌IP‌‌addresses‌‌have‌‌access‌‌ to‌‌the‌‌database.‌‌Every‌‌computer‌‌has‌‌an‌‌IP‌‌address‌‌dependent‌‌on‌‌its‌‌location,‌‌so‌‌doing‌‌this‌‌helps‌‌ ‌ 61‌ ‌ us‌‌limit‌‌who‌‌can‌‌access‌‌our‌‌database.‌‌Another‌‌cool‌‌feature‌‌of‌‌this‌‌firewall‌‌is‌‌that‌‌we‌‌can‌‌set‌‌it‌‌to‌‌ automatically‌‌allow‌‌Azure‌‌web‌‌apps‌‌to‌‌connect‌‌(which‌‌is‌‌what‌‌the‌‌backend‌‌API‌‌would‌‌be).‌‌With‌‌ this‌‌in‌‌place,‌‌if‌‌someone‌‌was‌‌using‌‌our‌‌backend‌‌web‌‌API‌‌to‌‌access‌‌the‌‌database,‌‌we‌‌did‌‌not‌‌have‌‌ to‌‌check‌‌their‌‌IP‌‌address‌‌since‌‌they‌‌would‌‌be‌‌using‌‌an‌‌Azure‌‌web‌‌app‌‌to‌‌connect‌‌to‌‌the‌‌database.‌‌ I‌ ‌decided‌ ‌to‌ ‌host‌ ‌the‌ ‌database‌ ‌in‌ ‌the‌ ‌US‌ ‌West‌‌region‌‌because‌‌this‌‌was‌‌the‌‌data‌‌center‌‌location‌‌ with‌‌the‌‌lowest‌‌latency‌‌(delay)‌‌when‌‌trying‌‌to‌‌connect‌‌to‌‌it‌‌in‌‌Utah.‌‌A‌‌data‌‌center‌‌is‌‌a‌‌physical‌‌ system‌‌that‌‌the‌‌database‌‌is‌‌deployed‌‌on.‌‌Since‌‌we‌‌were‌‌using‌‌a‌‌Microsoft‌‌service,‌‌this‌‌was‌‌a‌‌data‌‌ center‌ ‌run‌ ‌and‌ ‌operated‌ ‌by‌ ‌Microsoft.‌ ‌Using‌ ‌all‌ ‌of‌ ‌this,‌ ‌I‌ ‌created‌‌our‌‌Microsoft‌‌SQL‌‌database‌‌ using‌‌Azure‌‌with‌‌a‌‌firewall‌‌set‌‌up‌‌so‌‌user‌‌data‌‌is‌‌protected.‌ ‌ Next,‌ ‌since‌‌I‌‌decided‌‌to‌‌use‌‌a‌‌database-first‌‌approach‌‌to‌‌building‌‌the‌‌database,‌‌I‌‌created‌‌ an‌‌ER‌‌diagram‌‌to‌‌aid‌‌in‌‌the‌‌creation‌‌process.‌‌The‌‌original‌‌incarnation‌‌of‌‌the‌‌ER‌‌diagram‌‌of‌‌the‌‌ main‌ ‌Hestia‌ ‌database‌ ‌is‌ ‌shown‌ ‌in‌ ‌Fig.‌ ‌25.‌ ‌This‌ ‌complete‌ ‌diagram‌ ‌is‌ ‌way‌ ‌too‌ ‌big‌ ‌to‌ ‌try‌ ‌and‌‌ interpret‌ ‌all‌ ‌at‌ ‌once.‌ ‌This‌ ‌diagram‌ ‌is‌ ‌included‌ ‌to‌ ‌give‌ ‌an‌ ‌idea‌ ‌of‌ ‌the‌ ‌scope‌ ‌of‌ ‌the‌ ‌database.‌‌ Additionally,‌ ‌things‌ ‌in‌ ‌the‌ ‌database‌ ‌have‌ ‌changed‌ ‌since‌‌this‌‌ER‌‌diagram‌‌was‌‌created.‌‌A‌‌major‌‌ feature‌ ‌of‌ ‌the‌ ‌application,‌ ‌the‌ ‌grocery‌ ‌list,‌ ‌isn’t‌ ‌on‌ ‌the‌ ‌diagram‌ ‌at‌ ‌all.‌ ‌This‌ ‌feature‌ ‌is‌ ‌missing‌‌ because‌ ‌we‌ ‌decided‌ ‌to‌ ‌add‌ ‌this‌ ‌feature‌ ‌later‌ ‌on‌ ‌in‌ ‌development,‌ ‌meaning‌ ‌it‌ ‌was‌ ‌not‌ ‌in‌ ‌the‌‌ original‌ ‌plan‌ ‌for‌‌the‌‌application.‌‌Using‌‌this‌‌diagram,‌‌I‌‌created‌‌the‌‌first‌‌iteration‌‌of‌‌the‌‌database‌‌ by‌ ‌converting‌‌the‌‌ER‌‌diagram‌‌into‌‌Transact-SQL‌‌create‌‌table‌‌queries‌‌which‌‌is‌‌the‌‌type‌‌of‌‌SQL‌‌ language‌‌that‌‌a‌‌Microsoft‌‌SQL‌‌database‌‌supports.‌‌ ‌ To‌ ‌aid‌ ‌in‌ ‌explaining‌ ‌how‌ ‌I‌ ‌converted‌ ‌this‌ ‌diagram‌ ‌into‌ ‌create‌ ‌table‌ ‌queries‌ ‌I‌ ‌have‌‌ included‌‌Fig.‌‌26,‌‌which‌‌is‌‌the‌‌ER‌‌diagram‌‌for‌‌just‌‌the‌‌budget‌‌portion‌‌of‌‌the‌‌application.‌‌This‌‌ER‌‌ diagram‌‌for‌‌the‌‌budgets‌‌has‌‌been‌‌simplified‌‌and‌‌has‌‌removed‌‌everything‌‌that‌‌relates‌‌the‌‌budget‌‌ to‌ ‌a‌ ‌user,‌ ‌but‌ ‌it‌ ‌is‌ ‌still‌ ‌helpful‌ ‌in‌ ‌explaining‌ ‌how‌‌the‌‌complete‌‌ER‌‌diagram‌‌can‌‌be‌‌interpreted.‌‌ ‌ 62‌ ‌ The‌ ‌ER‌ ‌diagram‌ ‌documents‌ ‌the‌ ‌relationship‌ ‌between‌ ‌entities‌ ‌in‌ ‌the‌ ‌database,‌ ‌so‌ ‌what‌‌this‌‌ER‌‌ diagram‌‌means‌‌is‌‌that‌‌inside‌‌of‌‌the‌‌database,‌‌there‌‌should‌‌be‌‌a‌‌budget,‌‌and‌‌that‌‌budget‌‌consists‌‌ of‌‌any‌‌number‌‌of‌‌incomes‌‌and‌‌budget‌‌categories.‌‌Each‌‌budget‌‌needs‌‌to‌‌have‌‌a‌‌name,‌‌startDate,‌‌ and‌ ‌endDate.‌ ‌Each‌ ‌income‌ ‌must‌ ‌be‌ ‌contained‌ ‌inside‌ ‌of‌ ‌exactly‌ ‌one‌ ‌budget‌ ‌and‌ ‌must‌ ‌have‌ ‌a‌‌ name,‌ ‌amount,‌ ‌and‌ ‌the‌ ‌date‌ ‌it‌ ‌got‌ ‌added.‌ ‌Each‌ ‌budget‌ ‌category‌ ‌must‌ ‌be‌ ‌a‌ ‌part‌ ‌of‌ ‌exactly‌‌one‌‌ budget‌ ‌and‌ ‌must‌ ‌contain‌ ‌a‌ ‌name,‌ ‌color,‌ ‌and‌ ‌percentage‌ ‌goal.‌ ‌Then,‌ ‌each‌ ‌budget‌ ‌category‌ ‌can‌‌ contain‌ ‌any‌ ‌number‌ ‌of‌ ‌expenses‌ ‌grouped‌ ‌within‌ ‌it.‌ ‌The‌ ‌expenses‌ ‌are‌ ‌contained‌ ‌in‌ ‌one‌ ‌budget‌‌ category‌‌(and‌‌therefore‌‌one‌‌budget),‌‌and‌‌each‌‌of‌‌them‌‌must‌‌have‌‌a‌‌name,‌‌amount,‌‌and‌‌the‌‌date‌‌it‌‌ was‌ ‌added.‌ ‌Therefore,‌ ‌based‌ ‌on‌ ‌this‌ ‌ER‌ ‌diagram,‌‌each‌‌component‌‌must‌‌be‌‌a‌‌separate‌‌entity‌‌in‌‌ the‌ ‌database,‌ ‌thus‌ ‌there‌ ‌should‌ ‌be‌ ‌a‌ ‌Budgets,‌ ‌Incomes,‌ ‌BudgetCategories,‌ ‌and‌ ‌Expenses‌ ‌table‌‌ within‌‌the‌‌database.‌‌ ‌ Then,‌ ‌using‌ ‌the‌ ‌budget‌ ‌ER‌ ‌diagram‌ ‌and‌ ‌the‌ ‌interpretation‌ ‌I‌ ‌just‌ ‌described,‌ ‌I‌ ‌was‌ ‌then‌ ‌able‌ ‌to‌‌ create‌‌the‌‌Transact-SQL‌‌create‌‌table‌‌queries‌‌needed‌‌to‌‌make‌‌each‌‌of‌‌these‌‌tables‌‌in‌‌the‌‌database.‌‌ In‌ ‌total‌ ‌there‌ ‌are‌ ‌four‌ ‌created‌ ‌table‌ ‌queries‌ ‌for‌ ‌the‌ ‌Budgets‌ ‌ER‌ ‌diagram‌ ‌(one‌ ‌for‌ ‌each‌ ‌table‌‌ getting‌ ‌created),‌ ‌and‌ ‌the‌ ‌queries‌ ‌must‌ ‌be‌‌run‌‌in‌‌the‌‌order‌‌given‌‌due‌‌to‌‌the‌‌references‌‌that‌‌exist‌‌ between‌‌the‌‌tables.‌‌The‌‌four‌‌queries‌‌made‌‌from‌‌this‌‌budget‌‌ER‌‌diagram‌‌are:‌ ‌ 1. CREATE‌‌TABLE‌‌Budgets‌‌(BudgetID‌‌int‌‌not‌‌null‌‌identity(1,1),‌‌Name‌‌varchar(255)‌‌not‌‌ null,‌‌StartDate‌‌date‌‌not‌‌null,‌‌EndDate‌‌date‌‌not‌‌null,‌‌PRIMARY‌‌KEY(BudgetID),‌‌ UNIQUE(Name,‌‌StartDate,‌‌EndDate))‌ ‌ 2. CREATE‌‌TABLE‌‌Incomes(IncomeID‌‌int‌‌not‌‌null‌‌identity(1,1),‌‌BudgetID‌‌int‌‌not‌‌null,‌‌ Name‌‌varchar(255)‌‌not‌‌null,‌‌DateAdded‌‌date‌‌not‌‌null,‌‌Amount‌‌double‌‌not‌‌null,‌‌ PRIMARY‌‌KEY(IncomeID),‌‌UNIQUE(BudgetID,‌‌Name,‌‌DateAdded),‌‌FOREIGN‌‌KEY‌‌ (BudgetID)‌‌references‌‌Budgets(BudgetID))‌ ‌ ‌ 63‌ ‌ 3. CREATE‌‌TABLE‌‌BudgetCategories(BudgetCategoryID‌‌int‌‌not‌‌null‌‌identity(1,1),‌‌ BudgetID‌‌int‌‌not‌‌null,‌‌Name‌‌varchar(255)‌‌not‌‌null,‌‌PercentGoal‌‌int‌‌not‌‌null,‌‌Color‌‌ varchar(255)‌‌not‌‌null,‌‌PRIMARY‌‌KEY(BudgetCategoryID),‌‌UNIQUE(BudgetID,‌‌ Name),‌‌FOREIGN‌‌KEY‌‌(BudgetID)‌‌references‌‌Budgets(BudgetID))‌ 4. CREATE‌‌TABLE‌‌Expenses(ExpenseID‌‌int‌‌not‌‌null‌‌identity(1,1),‌‌BudgetCategoryID‌‌int‌‌ not‌‌null,‌‌Name‌‌varchar(255)‌‌not‌‌null,‌‌DateAdded‌‌date‌‌not‌‌null,‌‌Amount‌‌double‌‌not‌‌null,‌‌ PRIMARY‌‌KEY(ExpenseID),‌‌UNIQUE(BudgetCategoryID,‌‌Name,‌‌DateAdded),‌‌ FOREIGN‌‌KEY‌‌(BudgetCategoryID)‌‌references‌‌BudgetCategories(BudgetCategoryID))‌ ‌ ‌ These‌‌are‌‌the‌‌create‌‌table‌‌queries‌‌I‌‌would‌‌use‌‌to‌‌create‌‌the‌‌tables‌‌in‌‌the‌‌database‌‌based‌‌on‌‌ the‌ ‌information‌ ‌given‌ ‌in‌ ‌the‌‌budget‌‌ER‌‌diagram.‌‌All‌‌of‌‌these‌‌queries‌‌first‌‌start‌‌with‌‌the‌‌phrase‌‌ CREATE‌ ‌TABLE‌ ‌<TableName>,‌ ‌which‌ ‌instructs‌ ‌the‌ ‌database‌ ‌operating‌ ‌system‌ ‌that‌ ‌when‌‌ executed,‌‌these‌‌queries‌‌should‌‌create‌‌a‌‌table‌‌in‌‌the‌‌database‌‌with‌‌the‌‌name‌‌given‌‌(“Create‌‌table”,‌‌ 2021).‌ ‌Then‌ ‌they‌ ‌open‌ ‌parentheses‌ ‌and‌ ‌start‌ ‌naming‌ ‌off‌ ‌the‌ ‌columns‌ ‌that‌ ‌will‌ ‌be‌ ‌in‌‌the‌‌table.‌‌ Each‌‌of‌‌these‌‌columns‌‌includes‌‌the‌‌column‌‌name,‌‌the‌‌type‌‌of‌‌data‌‌stored‌‌in‌‌the‌‌column,‌‌and‌‌the‌‌ special‌‌properties‌‌the‌‌column‌‌has.‌‌The‌‌data‌‌types‌‌included‌‌in‌‌these‌‌queries‌‌are‌‌int,‌‌varchar(255),‌‌ date,‌ ‌and‌ ‌double.‌ ‌The‌ ‌int‌ ‌data‌ ‌type‌ ‌represents‌ ‌an‌ ‌integer‌ ‌value,‌ ‌the‌ ‌varchar(255)‌ ‌data‌ ‌type‌‌ represents‌ ‌a‌ ‌variable-length‌ ‌set‌ ‌of‌ ‌characters‌ ‌with‌ ‌at‌ ‌most‌ ‌255,‌ ‌the‌ ‌date‌ ‌data‌‌type‌‌represents‌‌a‌‌ calendar‌‌date,‌‌and‌‌the‌‌double‌‌data‌‌type‌‌represents‌‌a‌‌value‌‌similar‌‌to‌‌an‌‌integer‌‌except‌‌it‌‌can‌‌also‌‌ be‌‌decimal‌‌valued‌‌numbers‌‌(“Data‌‌types”,‌‌2021).‌‌Then,‌‌there‌‌are‌‌the‌‌special‌‌properties‌‌given‌‌to‌‌ each‌‌column.‌‌In‌‌this‌‌case,‌‌the‌‌only‌‌two‌‌special‌‌features‌‌used‌‌were‌‌not‌‌null‌‌and‌‌identity(1,1).‌‌The‌‌ not‌‌null‌‌characteristic‌‌means‌‌that‌‌a‌‌value‌‌for‌‌that‌‌column‌‌must‌‌be‌‌included‌‌to‌‌create‌‌a‌‌row‌‌in‌‌the‌‌ table,‌ ‌meaning‌ ‌a‌ ‌budget‌ ‌cannot‌ ‌be‌ ‌created‌ ‌without‌ ‌giving‌ ‌it‌ ‌a‌ ‌name.‌ ‌Then,‌ ‌the‌ ‌identity(1,1)‌‌ ‌ 64‌ ‌ feature‌ ‌means‌ ‌that‌ ‌this‌ ‌column's‌ ‌value‌ ‌does‌ ‌not‌ ‌have‌ ‌to‌ ‌be‌ ‌explicitly‌ ‌provided‌ ‌and‌ ‌if‌ ‌it‌ ‌is‌ ‌not‌‌ provided‌‌it‌‌will‌‌get‌‌an‌‌auto-generated‌‌value‌‌which‌‌starts‌‌itself‌‌at‌‌1‌‌and‌‌increments‌‌its‌‌value‌‌by‌‌1‌‌ every‌‌time‌‌a‌‌new‌‌value‌‌must‌‌be‌‌generated.‌‌These‌‌statements‌‌create‌‌every‌‌column‌‌for‌‌each‌‌table‌‌ in‌‌the‌‌database.‌‌After‌‌this‌‌comes‌‌the‌‌table‌‌constraints‌‌in‌‌the‌‌query.‌‌The‌‌table‌‌constraints‌‌used‌‌in‌‌ these‌‌queries‌‌were‌‌primary‌‌key,‌‌unique,‌‌and‌‌foreign‌‌key.‌‌The‌‌primary‌‌key‌‌constraint‌‌establishes‌‌ the‌‌primary‌‌key‌‌for‌‌the‌‌table,‌‌which‌‌are‌‌column(s)‌‌used‌‌to‌‌uniquely‌‌identify‌‌that‌‌row‌‌in‌‌the‌‌table‌‌ (“Primary‌‌Keys”,‌‌n.d.).‌‌A‌‌primary‌‌key‌‌is‌‌like‌‌an‌‌ISBN‌‌for‌‌a‌‌book‌‌since‌‌each‌‌book‌‌has‌‌an‌‌ISBN‌‌ that‌ ‌is‌ ‌different‌ ‌from‌ ‌all‌ ‌other‌ ‌books,‌ ‌and‌ ‌you‌ ‌can‌ ‌use‌ ‌a‌ ‌book's‌ ‌ISBN‌ ‌to‌ ‌look‌‌it‌‌up.‌‌Then,‌‌the‌‌ unique‌‌constraint‌‌means‌‌that‌‌in‌‌addition‌‌to‌‌the‌‌primary‌‌key‌‌being‌‌unique‌‌in‌‌the‌‌table,‌‌the‌‌set‌‌of‌‌ these‌‌columns‌‌for‌‌all‌‌the‌‌rows‌‌must‌‌also‌‌be‌‌unique.‌‌In‌‌the‌‌Incomes‌‌table,‌‌each‌‌income‌‌must‌‌have‌‌ a‌ ‌unique‌ ‌set‌ ‌of‌‌BudgetId,‌‌Name,‌‌and‌‌DateAdded.‌‌This‌‌unique‌‌constraint‌‌means‌‌that‌‌no‌‌income‌‌ within‌ ‌a‌ ‌budget‌ ‌can‌ ‌have‌ ‌the‌ ‌same‌ ‌combination‌ ‌of‌ ‌name‌ ‌and‌ ‌date‌ ‌added‌ ‌as‌ ‌any‌ ‌other‌‌income‌‌ within‌ ‌the‌ ‌same‌ ‌budget.‌ ‌Then,‌ ‌the‌ ‌final‌ ‌constraint‌ ‌used‌ ‌in‌ ‌these‌ ‌queries‌ ‌is‌ ‌the‌ ‌foreign‌ ‌key‌‌ constraint,‌ ‌which‌ ‌is‌ ‌a‌ ‌column‌ ‌in‌ ‌one‌ ‌table‌ ‌that‌ ‌links‌ ‌to‌ ‌a‌ ‌column‌ ‌in‌ ‌the‌ ‌other‌‌table‌‌to‌‌act‌‌as‌‌a‌‌ cross-reference‌‌between‌‌the‌‌two‌‌tables‌‌(“Foreign‌‌key”,‌‌n.d.).‌‌Thus,‌‌for‌‌the‌‌foreign‌‌key‌‌constraint‌‌ in‌‌the‌‌income‌‌table,‌‌its‌‌BudgetID‌‌column‌‌must‌‌match‌‌some‌‌value‌‌in‌‌the‌‌Budgets‌‌table‌‌BudgetID‌‌ column.‌‌Therefore,‌‌if‌‌a‌‌Budget‌‌with‌‌an‌‌ID‌‌of‌‌2‌‌does‌‌not‌‌exist‌‌in‌‌the‌‌Budgets‌‌table,‌‌there‌‌cannot‌‌ be‌ ‌any‌ ‌incomes‌ ‌linked‌ ‌to‌ ‌a‌ ‌budget‌ ‌with‌ ‌an‌ ‌ID‌ ‌of‌ ‌2.‌ ‌These‌ ‌foreign‌ ‌key‌ ‌constraints‌ ‌form‌‌ relationships‌ ‌between‌ ‌the‌ ‌tables‌ ‌in‌‌the‌‌database‌‌and‌‌are‌‌the‌‌primary‌‌reason‌‌that‌‌SQL‌‌databases‌‌ get‌ ‌referred‌ ‌to‌ ‌as‌ ‌relational‌ ‌databases.‌ ‌I‌ ‌used‌ ‌the‌ ‌ER‌ ‌diagram‌ ‌that‌ ‌I‌ ‌created‌ ‌to‌ ‌create‌‌a‌‌'create‌‌ table'‌‌query‌‌for‌‌every‌‌table‌‌in‌‌the‌‌database‌‌and‌‌used‌‌Microsoft‌‌SQL‌‌Server‌‌Management‌‌Studio‌‌ (SSMS)‌ ‌to‌ ‌run‌ ‌these‌ ‌queries‌ ‌on‌‌the‌‌database‌‌and‌‌create‌‌the‌‌tables.‌‌SSMS‌‌is‌‌just‌‌an‌‌application‌‌ that‌‌allows‌‌you‌‌to‌‌easily‌‌connect‌‌to‌‌and‌‌run‌‌queries‌‌on‌‌your‌‌Microsoft‌‌SQL‌‌database.‌ ‌ ‌ 65‌ ‌ The‌ ‌other‌ ‌part‌ ‌of‌ ‌this‌ ‌job‌ ‌was‌ ‌database‌ ‌maintenance‌ ‌which‌ ‌involved‌ ‌updating‌ ‌the‌‌ database‌‌tables‌‌as‌‌necessary.‌‌As‌‌we‌‌reevaluated‌‌the‌‌requirements‌‌for‌‌our‌‌application,‌‌there‌‌were‌‌ occasionally‌ ‌points‌ ‌in‌ ‌time‌ ‌that‌ ‌we‌ ‌realized‌ ‌that‌ ‌we‌ ‌needed‌ ‌to‌ ‌modify‌ ‌the‌ ‌existing‌ ‌database‌‌ structure.‌‌My‌‌job‌‌as‌‌the‌‌database‌‌maintainer‌‌meant‌‌that‌‌when‌‌we‌‌recognized‌‌the‌‌need‌‌to‌‌modify‌‌ the‌ ‌database,‌ ‌I‌ ‌was‌ ‌in‌ ‌charge‌ ‌of‌ ‌performing‌ ‌the‌ ‌modification.‌ ‌Throughout‌ ‌the‌ ‌project,‌ ‌many‌‌ aspects‌ ‌of‌ ‌the‌ ‌original‌ ‌database‌ ‌design‌ ‌were‌ ‌changed.‌ ‌The‌ ‌largest‌ ‌change‌ ‌was‌ ‌adding‌ ‌the‌‌ database‌ ‌tables‌ ‌to‌ ‌support‌ ‌the‌ ‌grocery‌ ‌list‌‌feature.‌‌In‌‌the‌‌original‌‌database‌‌design,‌‌we‌‌were‌‌not‌‌ even‌ ‌planning‌ ‌on‌ ‌implementing‌ ‌this‌ ‌feature,‌ ‌thus‌ ‌in‌ ‌the‌ ‌original‌ ‌design,‌ ‌there‌ ‌were‌ ‌no‌ ‌tables‌‌ associated‌‌with‌‌the‌‌grocery‌‌list.‌‌Other‌‌changes‌‌involved‌‌running‌‌simple‌‌alter‌‌table‌‌queries‌‌to‌‌add‌‌ or‌ ‌remove‌ ‌columns‌ ‌from‌ ‌a‌ ‌table‌‌and‌‌adding‌‌an‌‌ON‌‌DELETE‌‌CASCADE‌‌feature‌‌to‌‌all‌‌foreign‌‌ keys‌ ‌in‌ ‌the‌ ‌database.‌ ‌This‌ ‌ON‌ ‌DELETE‌ ‌CASCADE‌ ‌feature‌ ‌makes‌ ‌it‌ ‌so‌ ‌that‌ ‌if‌ ‌a‌ ‌budget‌ ‌is‌‌ deleted‌‌all‌‌the‌‌data‌‌that‌‌referenced‌‌that‌‌budget‌‌will‌‌get‌‌automatically‌‌deleted‌‌as‌‌well.‌‌Therefore,‌ when‌ ‌a‌ ‌budget‌ ‌gets‌ ‌deleted‌ ‌all‌ ‌the‌ ‌incomes,‌ ‌categories,‌ ‌and‌ ‌expenses‌ ‌associated‌ ‌with‌ ‌it‌ ‌get‌‌ automatically‌‌deleted‌‌too.‌‌ ‌ Overall,‌‌through‌‌this‌‌work,‌‌I‌‌created‌‌a‌‌database‌‌that‌‌satisfied‌‌all‌‌the‌‌requirements‌‌for‌‌our‌‌ application.‌ ‌This‌ ‌database‌ ‌creation‌ ‌was‌ ‌an‌ ‌important‌ ‌step‌ ‌during‌ ‌the‌ ‌development‌ ‌process‌‌ because‌ ‌our‌‌backend‌‌was‌‌very‌‌database‌‌focused‌‌meaning‌‌a‌‌small‌‌mistake‌‌in‌‌the‌‌database‌‌could‌‌ cause‌‌major‌‌problems‌‌in‌‌the‌‌application‌‌behavior.‌‌In‌‌the‌‌end,‌‌after‌‌all‌‌the‌‌database‌‌creation‌‌and‌‌ maintenance,‌‌our‌‌database‌‌contained‌‌25‌‌tables.‌‌These‌‌tables‌‌store‌‌all‌‌the‌‌information‌‌about‌‌users,‌‌ households,‌ ‌budgets,‌ ‌to-dos,‌ ‌recipes,‌ ‌meals,‌ ‌grocery‌ ‌lists,‌ ‌and‌ ‌calendar‌ ‌events‌ ‌to‌ ‌store‌ ‌all‌ ‌the‌‌ necessary‌‌data‌‌for‌‌the‌‌application.‌‌Furthermore,‌‌all‌‌of‌‌the‌‌tables‌‌have‌‌foreign‌‌key‌‌constraints‌‌set‌‌ up‌‌to‌‌establish‌‌the‌‌necessary‌‌table‌‌relationships‌‌to‌‌ensure‌‌data‌‌integrity‌‌gets‌‌upheld‌‌to‌‌ensure‌‌the‌‌ correct‌‌operation‌‌of‌‌the‌‌Hestia‌‌application.‌ ‌ ‌ 66‌ ‌ ‌ Fig.‌‌25‌‌-‌‌Original‌‌ER‌‌diagram‌‌for‌‌Hestia‌ ‌ ‌ Fig.‌‌26‌‌-‌‌Hestia‌‌Budget‌‌ER‌‌diagram‌ ‌ ‌ 67‌ ‌ 5.2‌ Backend‌‌Web‌‌API‌‌Developer‌ ‌ Then,‌‌the‌‌next‌‌role‌‌on‌‌the‌‌team‌‌that‌‌I‌‌performed‌‌was‌‌acting‌‌as‌‌one‌‌of‌‌the‌‌two‌‌developers‌‌ working‌‌on‌‌the‌‌backend‌‌web‌‌API.‌‌In‌‌this‌‌role,‌‌it‌‌was‌‌my‌‌job‌‌to‌‌write‌‌the‌‌API‌‌endpoints‌‌so‌‌that‌‌ the‌ ‌frontend‌ ‌could‌ ‌use‌ ‌them‌ ‌to‌ ‌access‌ ‌the‌ ‌needed‌ ‌information‌ ‌stored‌ ‌in‌ ‌the‌ ‌database.‌ ‌Every‌‌ endpoint‌‌consists‌‌of‌‌two‌‌main‌‌components:‌‌the‌‌code‌‌that‌‌handles‌‌the‌‌request‌‌routing‌‌and‌‌sending‌‌ back‌‌a‌‌response‌‌and‌‌the‌‌code‌‌that‌‌takes‌‌care‌‌of‌‌accessing‌‌the‌‌database.‌‌ ‌ To‌‌make‌‌the‌‌API‌‌endpoints‌‌as‌‌easy‌‌to‌‌use‌‌as‌‌possible‌‌for‌‌the‌‌frontend‌‌Bridger,‌‌my‌‌fellow‌‌ backend‌‌web‌‌API‌‌developer‌‌and‌‌myself‌‌tried‌‌to‌‌standardize‌‌the‌‌routing‌‌and‌‌responses‌‌as‌‌much‌‌as‌‌ possible.‌‌The‌‌routing‌‌refers‌‌to‌‌the‌‌actual‌‌creation‌‌of‌‌the‌‌endpoints,‌‌which‌‌ensures‌‌that‌‌sending‌‌a‌‌ request‌‌to‌‌the‌‌GET‌‌/budgets/{userID}‌‌endpoint‌‌will‌‌route‌‌the‌‌correct‌‌method‌‌to‌‌retrieve‌‌a‌‌user’s‌‌ endpoints.‌ ‌Within‌ ‌the‌ ‌.NET‌ ‌framework,‌ ‌we‌ ‌were‌ ‌working‌ ‌in‌ ‌this‌ ‌was‌ ‌done‌ ‌by‌ ‌adding‌ ‌in‌ ‌the‌‌ following‌ ‌line‌ ‌of‌ ‌code‌ ‌above‌ ‌the‌ ‌method‌ ‌that‌ ‌retrieved‌ ‌the‌ ‌budgets‌‌ [HttpGet(“budgets/{userID}”)]‌‌which‌‌tells‌‌it‌‌that‌‌when‌‌that‌‌URL‌‌gets‌‌called‌‌with‌‌a‌‌get‌‌request,‌‌ use‌‌this‌‌method‌‌to‌‌handle‌‌the‌‌request.‌‌We‌‌standardized‌‌these‌‌routes‌‌by‌‌making‌‌each‌‌of‌‌them‌‌be‌‌ CRUD‌ ‌operations.‌ ‌POST‌ ‌requests‌ ‌would‌ ‌be‌ ‌creation‌ ‌operations,‌ ‌GETs‌ ‌requests‌ ‌would‌ ‌be‌‌ retrieval‌‌operations,‌‌PUT‌‌requests‌‌would‌‌be‌‌update‌‌operations,‌‌and‌‌DELETE‌‌requests‌‌would‌‌be‌‌ delete‌‌operations.‌‌All‌‌of‌‌these‌‌operations‌‌would‌‌get‌‌performed‌‌on‌‌the‌‌main‌‌Hestia‌‌database.‌‌We‌‌ organized‌ ‌our‌ ‌endpoints‌ ‌in‌‌this‌‌so‌‌the‌‌frontend‌‌developers‌‌always‌‌knew‌‌what‌‌type‌‌of‌‌operation‌‌ would‌ ‌get‌ ‌performed‌ ‌based‌ ‌on‌ ‌the‌ ‌request‌ ‌type.‌ ‌Additionally,‌ ‌this‌ ‌section‌ ‌of‌ ‌the‌ ‌code‌ ‌also‌ handles‌‌sending‌‌the‌‌response‌‌back‌‌to‌‌the‌‌caller‌‌of‌‌the‌‌endpoint.‌‌Each‌‌response‌‌contains‌‌two‌‌main‌‌ components:‌‌a‌‌status‌‌code‌‌dictating‌‌the‌‌successfulness‌‌of‌‌the‌‌operation‌‌and‌‌a‌‌response‌‌body‌‌that‌‌ contains‌‌the‌‌data‌‌to‌‌get‌‌sent‌‌back‌‌to‌‌the‌‌code‌‌that‌‌requested‌‌the‌‌endpoint.‌‌We‌‌also‌‌made‌‌sure‌‌to‌‌ standardize‌ ‌the‌ ‌status‌ ‌codes‌ ‌in‌ ‌the‌ ‌API‌ ‌so‌ ‌every‌ ‌endpoint‌ ‌in‌‌the‌‌API‌‌could‌‌return‌‌one‌‌of‌‌three‌‌ ‌ 68‌ ‌ status‌‌codes.‌‌A‌‌400‌‌Bad‌‌Request‌‌status‌‌code‌‌means‌‌there‌‌was‌‌a‌‌problem‌‌with‌‌the‌‌request‌‌being‌‌ made,‌‌such‌‌as‌‌a‌‌negative‌‌ID‌‌value‌‌getting‌‌provided‌‌since‌‌all‌‌IDs‌‌must‌‌be‌‌positive.‌‌A‌‌500‌‌Internal‌‌ Server‌‌Error‌‌status‌‌code‌‌occurs‌‌if‌‌the‌‌request‌‌was‌‌valid‌‌but‌‌the‌‌operation‌‌was‌‌not‌‌performed‌‌on‌‌ the‌‌database‌‌due‌‌to‌‌an‌‌error‌‌in‌‌the‌‌API‌‌itself,‌‌such‌‌as‌‌losing‌‌connection‌‌to‌‌the‌‌database.‌‌Lastly,‌‌a‌‌ 200‌‌Ok‌‌status‌‌code‌‌gets‌‌returned‌‌if‌‌the‌‌operation‌‌gets‌‌completed‌‌successfully.‌‌ ‌ Then,‌ ‌the‌ ‌response‌ ‌bodies‌ ‌of‌ ‌the‌ ‌method‌ ‌also‌ ‌were‌ ‌typically‌ ‌standardized‌‌based‌‌on‌‌the‌‌ request‌ ‌types.‌ ‌There‌ ‌are‌ ‌a‌ ‌few‌ ‌exceptions‌ ‌with‌ ‌the‌ ‌complex‌ ‌endpoints‌ ‌that‌ ‌perform‌ ‌multiple‌‌ operations,‌‌such‌‌as‌‌exporting‌‌meals‌‌to‌‌a‌‌grocery‌‌list,‌‌but‌‌this‌‌is‌‌the‌‌standard‌‌that‌‌was‌‌used‌‌for‌‌the‌‌ response‌‌body‌‌in‌‌a‌‌majority‌‌of‌‌the‌‌endpoints.‌‌If‌‌the‌‌request‌‌was‌‌unsuccessful‌‌for‌‌whatever‌‌reason‌‌ (a‌ ‌400‌ ‌or‌ ‌500‌ ‌status),‌ ‌then‌ ‌an‌ ‌explanatory‌ ‌error‌ ‌message‌ ‌was‌ ‌provided‌ ‌in‌ ‌the‌ ‌response‌ ‌body‌‌ otherwise,‌ ‌the‌ ‌content‌ ‌of‌ ‌the‌ ‌response‌ ‌body‌ ‌depends‌ ‌on‌ ‌the‌ ‌type‌ ‌of‌ ‌request‌ ‌that‌‌was‌‌received.‌‌ Response‌‌bodies‌‌to‌‌GET‌‌requests‌‌contain‌‌all‌‌the‌‌data‌‌related‌‌to‌‌the‌‌entity‌‌that‌‌gets‌‌retrieved‌‌from‌‌ the‌‌database‌‌in‌‌a‌‌JSON‌‌format.‌‌JSON‌‌is‌‌a‌‌string‌‌formatting‌‌system‌‌used‌‌to‌‌pass‌‌objects‌‌as‌‌plain‌‌ text.‌ ‌For‌ ‌example,‌ ‌if‌ ‌a‌ ‌budget‌‌that‌‌gets‌‌retrieved‌‌has‌‌the‌‌name‌‌“December”‌‌then‌‌somewhere‌‌in‌‌ the‌ ‌JSON‌ ‌formatted‌ ‌response‌ ‌would‌ ‌be‌ ‌the‌ ‌line‌ ‌“Name”:‌ ‌“December”‌ ‌to‌ ‌document‌ ‌that‌ ‌the‌‌ budget’s‌ ‌name‌ ‌is‌ ‌December.‌ ‌Then,‌ ‌POST‌ ‌requests‌ ‌return‌ ‌a‌ ‌JSON‌ ‌formatted‌ ‌ID‌ ‌value‌ ‌for‌ ‌the‌‌ entity‌ ‌that‌ ‌gets‌ ‌created‌ ‌by‌ ‌the‌ ‌operation.‌ ‌Lastly,‌ ‌PUT‌ ‌and‌ ‌DELETE‌ ‌requests‌ ‌return‌ ‌an‌ ‌empty‌‌ response‌‌body‌‌if‌‌the‌‌operation‌‌was‌‌successful.‌‌Overall‌‌this‌‌standardized‌‌way‌‌of‌‌constructing‌‌the‌‌ endpoints‌ ‌made‌ ‌them‌ ‌much‌ ‌easier‌ ‌for‌ ‌the‌ ‌frontend‌ ‌developers‌ ‌to‌ ‌use.‌ ‌This‌ ‌standard‌ ‌of‌‌ development‌‌allowed‌‌them‌‌to‌‌always‌‌understand‌‌the‌‌operation‌‌getting‌‌performed,‌‌and‌‌the‌‌type‌‌of‌‌ response‌‌they‌‌should‌‌receive‌‌depending‌‌on‌‌the‌‌type‌‌of‌‌request‌‌made.‌ ‌ Then,‌‌the‌‌second‌‌part‌‌of‌‌the‌‌Web‌‌API‌‌code‌‌was‌‌the‌‌database‌‌access‌‌code.‌‌This‌‌part‌‌of‌‌the‌‌ code‌ ‌handles‌ ‌performing‌ ‌operations‌ ‌on‌ ‌the‌ ‌database.‌ ‌These‌ ‌operations‌ ‌match‌ ‌the‌ ‌operation‌‌ ‌ 69‌ ‌ requested‌‌based‌‌on‌‌the‌‌endpoint‌‌that‌‌got‌‌called.‌‌We‌‌wrote‌‌the‌‌database‌‌access‌‌code‌‌using‌‌LINQ,‌‌ which‌‌was‌‌mentioned‌‌earlier‌‌in‌‌the‌‌document.‌‌LINQ‌‌allowed‌‌us‌‌to‌‌write‌‌queries‌‌on‌‌the‌‌database‌‌ to‌ ‌perform‌ ‌these‌ ‌operations‌ ‌using‌ ‌C#‌ ‌code‌ ‌instead‌ ‌of‌ ‌requiring‌ ‌these‌ ‌queries‌ ‌in‌ ‌a‌ ‌string‌‌form.‌‌ Using‌ ‌LINQ‌ ‌saved‌ ‌us‌ ‌a‌‌lot‌‌of‌‌development‌‌time‌‌since‌‌it‌‌makes‌‌the‌‌database‌‌access‌‌code‌‌much‌‌ simpler‌‌to‌‌write‌‌and‌‌much‌‌less‌‌error-prone‌‌than‌‌typing‌‌out‌‌the‌‌queries‌‌yourself.‌‌ ‌ All‌ ‌the‌ ‌code‌ ‌for‌ ‌the‌ ‌web‌ ‌API‌ ‌got‌ ‌written‌ ‌using‌ ‌the‌ ‌C#‌ ‌language‌ ‌and‌ ‌the‌ ‌.NET‌‌ Framework.‌ ‌C#‌ ‌is‌ ‌my‌ ‌preferred‌ ‌language‌ ‌and,‌‌therefore‌‌I‌‌was‌‌able‌‌to‌‌work‌‌very‌‌quickly‌‌when‌‌ developing‌ ‌the‌ ‌API‌ ‌endpoints.‌ ‌In‌ ‌all,‌ ‌I‌‌was‌‌the‌‌primary‌‌developer‌‌for‌‌the‌‌user,‌‌households‌‌and‌‌ household‌‌invitation‌‌system,‌‌to-do,‌‌grocery‌‌list,‌‌and‌‌budget‌‌endpoints.‌‌These‌‌endpoints‌‌allowed‌‌ the‌ ‌user‌ ‌creation‌‌and‌‌household‌‌joining‌‌features‌‌to‌‌work‌‌as‌‌intended.‌‌Then,‌‌the‌‌other‌‌endpoints‌‌ helped‌ ‌power‌‌the‌‌to-do‌‌list,‌‌grocery‌‌list,‌‌and‌‌budget‌‌features‌‌of‌‌the‌‌applications.‌‌Additionally,‌‌I‌‌ have‌ ‌created‌ ‌endpoints‌ ‌that,‌ ‌while‌ ‌not‌ ‌in‌ ‌use‌‌yet,‌‌will‌‌overhaul‌‌the‌‌to-do‌‌list‌‌feature‌‌and‌‌allow‌‌ to-dos‌ ‌to‌ ‌be‌ ‌assigned‌ ‌to‌ ‌specific‌ ‌individuals‌ ‌or‌ ‌the‌ ‌entire‌ ‌family‌ ‌for‌ ‌these‌ ‌to-dos‌ ‌to‌ ‌be‌‌ categorized.‌ ‌In‌ ‌all,‌ ‌I‌ ‌was‌ ‌the‌ ‌primary‌ ‌developer‌ ‌for‌ ‌over‌ ‌fifty‌‌endpoints‌‌in‌‌our‌‌API,‌‌which‌‌the‌‌ front-end‌ ‌developers‌ ‌were‌ ‌able‌ ‌to‌ ‌use‌ ‌to‌ ‌make‌ ‌the‌ ‌applications‌ ‌a‌ ‌great‌ ‌tool‌ ‌for‌ ‌helping‌ ‌a‌‌user‌‌ manage‌‌their‌‌household‌‌and‌‌their‌‌lives‌‌in‌‌general.‌ ‌ 5.3‌ Quality‌‌Engineer‌‌(QE)‌‌for‌‌the‌‌Backend‌‌Web‌‌API‌ ‌ Then,‌ ‌in‌ ‌addition‌ ‌to‌ ‌being‌ ‌a‌ ‌developer‌ ‌for‌ ‌the‌‌backend‌‌web‌‌API,‌‌I‌‌was‌‌also‌‌the‌‌quality‌‌ engineer‌‌for‌‌the‌‌API.‌‌This‌‌role‌‌means‌‌that‌‌I‌‌was‌‌responsible‌‌for‌‌reviewing‌‌the‌‌code‌‌and‌‌ensuring‌‌ that‌ ‌the‌ ‌API‌ ‌endpoints‌ ‌got‌ ‌released‌ ‌to‌ ‌the‌ ‌front-end‌ ‌developers‌ ‌with‌ ‌little‌ ‌to‌ ‌no‌ ‌bugs‌ ‌in‌ ‌their‌‌ code.‌ ‌To‌ ‌aid‌ ‌in‌ ‌this‌ ‌process,‌ ‌I‌ ‌wrote‌ ‌an‌ ‌entire‌ ‌testing‌ ‌suite‌ ‌that‌ ‌Bridger‌ ‌and‌ ‌I‌ ‌could‌ ‌use‌‌when‌‌ making‌ ‌changes.‌ ‌This‌ ‌suite‌ ‌would‌ ‌ensure‌ ‌the‌‌code‌‌worked‌‌as‌‌intended‌‌by‌‌testing‌‌every‌‌part‌‌of‌‌ the‌ ‌code‌ ‌directly‌ ‌relevant‌ ‌to‌ ‌the‌ ‌API‌ ‌endpoints.‌ ‌I‌‌wrote‌‌unit‌‌tests‌‌to‌‌verify‌‌that‌‌every‌‌endpoint‌‌ ‌ 70‌ ‌ returned‌‌a‌‌400‌‌status‌‌code‌‌when‌‌it‌‌received‌‌a‌‌bad‌‌request,‌‌a‌‌500‌‌status‌‌code‌‌when‌‌an‌‌exception‌‌ occurred‌ ‌while‌ ‌operating,‌ ‌and‌ ‌a‌ ‌200‌ ‌status‌ ‌code‌ ‌when‌ ‌the‌ ‌operation‌ ‌completed‌ ‌successfully.‌‌ Furthermore,‌ ‌the‌ ‌larger‌ ‌portion‌ ‌of‌ ‌the‌ ‌testing‌ ‌suite‌ ‌involved‌ ‌testing‌ ‌the‌ ‌database‌ ‌access‌ ‌code.‌‌ These‌ ‌set‌ ‌up‌ ‌an‌ ‌in-memory‌ ‌database‌ ‌meaning‌ ‌that‌ ‌an‌ ‌identically‌ ‌structured‌ ‌database‌ ‌is‌‌ configured‌ ‌in‌ ‌the‌ ‌memory‌ ‌of‌ ‌the‌ ‌computer‌ ‌the‌ ‌tests‌ ‌are‌ ‌run‌ ‌on.‌ ‌Then‌ ‌the‌ ‌operations‌ ‌are‌‌ performed‌ ‌on‌ ‌this‌ ‌in-memory‌ ‌database.‌ ‌This‌ ‌testing‌ ‌structure‌ ‌allows‌ ‌these‌ ‌tests‌ ‌to‌ ‌test‌ ‌the‌‌ database‌ ‌access‌ ‌code‌ ‌without‌ ‌modifying‌ ‌the‌ ‌existing‌ ‌data‌ ‌already‌ ‌stored‌‌in‌‌the‌‌database.‌‌Once‌‌ the‌ ‌operation‌ ‌completes‌ ‌these‌ ‌unit‌ ‌tests‌ ‌examine‌ ‌the‌ ‌contents‌ ‌of‌ ‌the‌ ‌in-memory‌ ‌database‌ ‌to‌‌ ensure‌‌that‌‌the‌‌database‌‌operation‌‌was‌‌successful.‌‌These‌‌tests‌‌help‌‌provide‌‌a‌‌foundation‌‌to‌‌detect‌‌ bugs‌‌in‌‌the‌‌code‌‌before‌‌the‌‌code‌‌changes‌‌get‌‌released‌‌to‌‌developers.‌ ‌ The‌‌process‌‌for‌‌using‌‌the‌‌testing‌‌suite‌‌to‌‌detect‌‌bugs‌‌is‌‌that‌‌first,‌‌you‌‌will‌‌make‌‌your‌‌code‌‌ changes.‌ ‌Then,‌ ‌before‌ ‌deploying‌ ‌your‌ ‌changes,‌ ‌you‌ ‌will‌ ‌run‌ ‌the‌ ‌test‌ ‌suite,‌ ‌which‌ ‌will‌ ‌run‌ ‌all‌‌ 200+‌‌unit‌‌tests‌‌that‌‌I‌‌created.‌‌A‌‌“passing”‌‌test‌‌means‌‌that‌‌the‌‌code‌‌is‌‌working‌‌as‌‌intended‌‌for‌‌that‌‌ test‌ ‌and‌ ‌a‌‌“failing”‌‌test‌‌means‌‌that‌‌a‌‌bug‌‌exists‌‌in‌‌the‌‌code.‌‌Therefore,‌‌if‌‌any‌‌unit‌‌tests‌‌fail,‌‌we‌‌ know‌ ‌that‌ ‌the‌ ‌changes‌ ‌we‌ ‌made‌ ‌caused‌‌a‌‌bug‌‌and‌‌must‌‌review‌‌the‌‌code‌‌and‌‌eliminate‌‌the‌‌bug‌‌ before‌ ‌deploying‌ ‌the‌ ‌changes.‌ ‌Overall,‌ ‌this‌ ‌work‌ ‌as‌ ‌a‌ ‌quality‌ ‌engineer‌ ‌and‌ ‌establishing‌ ‌the‌‌ testing‌ ‌suite‌ ‌helps‌ ‌make‌ ‌our‌ ‌development‌ ‌process‌ ‌on‌ ‌the‌ ‌API‌ ‌much‌ ‌less‌ ‌error-prone‌ ‌since‌ ‌it‌‌ allows‌‌bugs‌‌to‌‌be‌‌automatically‌‌detected‌‌since‌‌they‌‌should‌‌cause‌‌a‌‌test‌‌to‌‌fail.‌ ‌ 5.4‌ About‌‌Hestia‌‌Website‌‌Designer‌ ‌ Then,‌‌the‌‌final‌‌role‌‌I‌‌served‌‌during‌‌the‌‌project‌‌was‌‌being‌‌our‌‌public-facing‌‌'About‌‌Hestia'‌‌ website‌ ‌designer.‌ ‌Before‌ ‌the‌ ‌final‌ ‌demonstration‌ ‌of‌ ‌our‌ ‌project,‌ ‌we‌ ‌needed‌‌to‌‌create‌‌a‌‌website‌‌ that‌ ‌would‌‌describe‌‌what‌‌our‌‌project/application‌‌was‌‌and‌‌how‌‌we‌‌accomplished‌‌developing‌‌the‌‌ application.‌ ‌In‌ ‌this‌ ‌role,‌ ‌I‌ ‌designed‌ ‌this‌ ‌public-facing‌ ‌website‌ ‌for‌ ‌Hestia,‌ ‌which‌ ‌is‌ ‌located‌ ‌at:‌‌ ‌ 71‌ ‌ https://linnebach08.github.io/Hestia/.‌ ‌Designing‌ ‌the‌ ‌website‌ ‌was‌ ‌the‌ ‌only‌ ‌frontend‌ ‌work‌ ‌I‌ ‌did‌‌ during‌ ‌the‌ ‌entire‌ ‌duration‌ ‌of‌ ‌the‌ ‌project‌ ‌since‌ ‌I‌‌was‌‌a‌‌backend‌‌developer.‌‌I‌‌picked‌‌up‌‌this‌‌task‌‌ because‌ ‌at‌ ‌the‌ ‌end‌ ‌of‌ ‌the‌ ‌project‌ ‌cycle,‌ ‌all‌ ‌of‌ ‌our‌ ‌backend‌ ‌development‌ ‌was‌ ‌completed.‌‌ Therefore,‌‌I‌‌had‌‌the‌‌time‌‌available‌‌to‌‌create‌‌our‌‌website.‌‌To‌‌create‌‌the‌‌website,‌‌I‌‌downloaded‌‌a‌‌ template‌‌from‌‌Wix‌‌and‌‌modified‌‌the‌‌images‌‌and‌‌text‌‌displayed‌‌to‌‌make‌‌it‌‌themed‌‌to‌‌Hestia.‌‌The‌‌ website's‌‌home‌‌page‌‌is‌‌shown‌‌in‌‌Fig.‌‌24‌‌below.‌‌The‌‌hope‌‌for‌‌this‌‌website‌‌is‌‌that‌‌it‌‌will‌‌provide‌‌ greater‌ ‌visibility‌ ‌for‌ ‌Hestia‌‌and‌‌make‌‌the‌‌Hestia‌‌project‌‌appear‌‌more‌‌professional‌‌when‌‌we‌‌are‌‌ giving‌‌our‌‌demonstration.‌ ‌ ‌ Fig.‌‌24‌‌-‌‌“About‌‌Hestia”‌‌Website‌‌Homepage‌ ‌ ‌ 72‌ ‌ 6‌‌ANALYSIS‌ ‌ Now‌ ‌that‌ ‌the‌ ‌entire‌ ‌project‌ ‌was‌ ‌complete,‌ ‌it‌ ‌is‌ ‌important‌ ‌to‌ ‌look‌ ‌back‌ ‌at‌ ‌the‌ ‌original‌‌ design‌‌decisions‌‌that‌‌were‌‌made‌‌to‌‌examine‌‌what‌‌worked‌‌well‌‌and‌‌what‌‌didn’t.‌‌By‌‌doing‌‌this‌‌a‌‌ developer‌ ‌can‌ ‌reflect‌ ‌on‌ ‌their‌ ‌project‌ ‌and‌ ‌learn‌ ‌from‌ ‌both‌ ‌their‌ ‌successes‌ ‌and‌ ‌mistakes‌ ‌when‌‌ making‌ ‌design‌ ‌decisions‌ ‌on‌ ‌future‌ ‌projects.‌ ‌While‌ ‌our‌ ‌team‌ ‌is‌ ‌generally‌ ‌happy‌ ‌with‌ ‌our‌‌ development‌ ‌process,‌ ‌there‌ ‌were‌ ‌some‌ ‌mistakes‌ ‌made‌ ‌along‌‌the‌‌way.‌‌This‌‌section‌‌will‌‌discuss‌‌ these‌‌mistakes‌‌along‌‌with‌‌what‌‌design‌‌decisions‌‌worked‌‌perfectly.‌‌It‌‌will‌‌examine‌‌all‌‌the‌‌design‌‌ decisions‌ ‌made‌ ‌before‌ ‌development‌ ‌began‌ ‌and‌ ‌discuss‌ ‌how‌ ‌they‌ ‌affected‌ ‌the‌ ‌development‌‌ process‌‌in‌‌terms‌‌of‌‌team‌‌structure,‌‌code‌‌structure,‌‌and‌‌code‌‌implementation‌‌decisions.‌ ‌ 6.1‌ Team‌‌Structure‌‌Decisions‌‌Retrospective‌ ‌ Our‌‌team‌‌made‌‌two‌‌primary‌‌team‌‌structure‌‌decisions‌‌for‌‌the‌‌development‌‌of‌‌Hestia.‌‌We‌‌ decided‌ ‌that‌ ‌our‌ ‌team‌ ‌would‌ ‌be‌ ‌divided‌ ‌into‌ ‌two‌ ‌backend‌ ‌developers‌ ‌and‌ ‌three‌ ‌frontend‌‌ developers‌ ‌and‌ ‌that‌ ‌we‌ ‌would‌ ‌develop‌ ‌the‌ ‌application‌ ‌using‌ ‌the‌ ‌agile‌ ‌methodology.‌ ‌For‌ ‌the‌‌ breakdown‌‌of‌‌two‌‌backend‌‌developers‌‌and‌‌three‌‌frontend‌‌developers,‌‌this‌‌ended‌‌up‌‌being‌‌a‌‌great‌‌ breakdown‌ ‌for‌ ‌the‌ ‌development‌ ‌process.‌ ‌We‌ ‌were‌ ‌correct‌ ‌in‌‌our‌‌original‌‌assessment‌‌that‌‌there‌‌ would‌ ‌be‌ ‌slightly‌ ‌more‌ ‌frontend‌ ‌work‌ ‌to‌ ‌do‌ ‌on‌‌the‌‌application‌‌than‌‌backend‌‌work‌‌but‌‌that‌‌the‌‌ work‌ ‌would‌ ‌still‌‌be‌‌relatively‌‌balanced‌‌between‌‌the‌‌two.‌‌Therefore‌‌this‌‌2:3‌‌ratio‌‌of‌‌frontend‌‌to‌‌ backend‌‌developers‌‌was‌‌a‌‌great‌‌decision‌‌for‌‌the‌‌project.‌‌This‌‌decision‌‌also‌‌made‌‌it‌‌possible‌‌for‌‌ everyone‌ ‌on‌ ‌our‌ ‌team‌ ‌to‌ ‌specialize‌ ‌in‌ ‌a‌ ‌certain‌ ‌area‌ ‌of‌ ‌the‌ ‌application‌ ‌they‌ ‌were‌ ‌already‌‌ proficient‌‌at,‌‌which‌‌made‌‌development‌‌work‌‌go‌‌much‌‌quicker‌‌overall.‌‌ ‌ However,‌ ‌this‌ ‌decision‌ ‌was‌ ‌not‌ ‌perfect,‌ ‌we‌ ‌also‌ ‌decided‌ ‌to‌ ‌break‌ ‌the‌ ‌front-end‌‌ developers‌ ‌down‌ ‌into‌ ‌one‌ ‌mobile‌ ‌developer‌ ‌and‌ ‌two‌ ‌web‌ ‌developers.‌ ‌This‌ ‌breakdown‌‌did‌‌not‌‌ end‌ ‌up‌ ‌lining‌‌up‌‌with‌‌the‌‌actual‌‌work‌‌that‌‌needed‌‌to‌‌get‌‌done‌‌on‌‌the‌‌web‌‌and‌‌mobile‌‌frontend.‌‌ ‌ 73‌ ‌ This‌‌meant‌‌that‌‌our‌‌mobile‌‌developer‌‌Thang‌‌had‌‌a‌‌lot‌‌of‌‌work‌‌to‌‌do‌‌and‌‌couldn’t‌‌keep‌‌up‌‌with‌‌ the‌‌development‌‌speed‌‌we‌‌produced‌‌on‌‌the‌‌web‌‌application.‌‌This‌‌incorrect‌‌split‌‌caused‌‌the‌‌meal‌‌ planning‌‌and‌‌grocery‌‌list‌‌features‌‌to‌‌be‌‌cut‌‌on‌‌the‌‌mobile‌‌application‌‌since‌‌there‌‌was‌‌not‌‌enough‌‌ time‌ ‌to‌ ‌develop‌ ‌them.‌ ‌One‌ ‌thing‌ ‌that‌ ‌we‌ ‌failed‌ ‌to‌ ‌account‌ ‌for‌ ‌when‌ ‌estimating‌‌the‌‌number‌‌of‌‌ developers‌ ‌we‌ ‌needed‌ ‌for‌ ‌web‌ ‌and‌ ‌mobile‌ ‌was‌ ‌that‌ ‌both‌ ‌our‌ ‌web‌ ‌developers‌ ‌were‌ ‌already‌‌ familiar‌ ‌with‌ ‌the‌‌Angular‌‌framework‌‌we‌‌were‌‌using,‌‌but‌‌our‌‌mobile‌‌developer‌‌was‌‌not‌‌already‌‌ familiar‌‌with‌‌the‌‌Nativescript‌‌framework‌‌that‌‌we‌‌chose‌‌to‌‌use.‌‌Therefore,‌‌a‌‌lot‌‌of‌‌time‌‌got‌‌spent‌‌ figuring‌ ‌out‌ ‌how‌ ‌to‌ ‌work‌ ‌with‌ ‌the‌ ‌Nativescript‌ ‌framework,‌‌which‌‌made‌‌development‌‌work‌‌on‌‌ mobile‌‌take‌‌longer‌‌than‌‌expected.‌‌This‌‌is‌‌something‌‌that‌‌I‌‌will‌‌need‌‌to‌‌make‌‌sure‌‌to‌‌take‌‌notice‌‌ of‌ ‌to‌ ‌avoid‌ ‌duplicating‌ ‌this‌ ‌error‌ ‌in‌ ‌future‌ ‌projects.‌ ‌A‌ ‌better‌ ‌breakdown‌ ‌of‌ ‌the‌ ‌frontend‌‌ developers‌ ‌would‌ ‌have‌ ‌been‌ ‌to‌ ‌have‌ ‌one‌ ‌web‌ ‌developer,‌ ‌one‌ ‌mobile‌ ‌developer,‌ ‌and‌ ‌one‌‌ developer‌‌working‌‌on‌‌both‌‌web‌‌and‌‌mobile.‌‌The‌‌actual‌‌amount‌‌of‌‌development‌‌work‌‌necessary‌‌ was‌‌fairly‌‌even‌‌between‌‌the‌‌web‌‌and‌‌mobile‌‌applications.‌‌Thus,‌‌it‌‌would‌‌have‌‌been‌‌a‌‌lot‌‌better‌‌ for‌ ‌our‌ ‌frontend‌ ‌developer‌ ‌breakdown‌ ‌to‌ ‌reflect‌ ‌this.‌ ‌It‌ ‌would‌ ‌not‌ ‌have‌ ‌been‌ ‌too‌ ‌much‌ ‌of‌ ‌a‌‌ learning‌‌curve‌‌to‌‌have‌‌one‌‌of‌‌our‌‌developers‌‌also‌‌work‌‌on‌‌mobile‌‌because‌‌both‌‌the‌‌Angular‌‌and‌‌ Nativescript‌‌frameworks‌‌use‌‌the‌‌JavaScript‌‌language.‌‌This‌‌similarity‌‌means‌‌it‌‌would‌‌have‌‌been‌‌ relatively‌ ‌simple‌ ‌for‌ ‌a‌ ‌single‌ ‌developer‌ ‌to‌ ‌work‌ ‌on‌ ‌both‌ ‌the‌ ‌web‌ ‌and‌ ‌mobile‌ ‌applications‌‌ simultaneously.‌ ‌Other‌ ‌than‌ ‌this‌ ‌error,‌ ‌I‌ ‌feel‌ ‌like‌ ‌our‌ ‌team‌ ‌developer‌ ‌breakdown‌ ‌ended‌ ‌up‌‌ working‌‌great‌‌during‌‌the‌‌development‌‌process.‌ ‌ Then,‌ ‌the‌ ‌other‌ ‌team‌ ‌structure‌ ‌decision‌ ‌that‌ ‌we‌ ‌made‌ ‌was‌ ‌choosing‌ ‌to‌ ‌use‌ ‌the‌‌ Agile‌‌methodology‌‌instead‌‌of‌‌the‌‌waterfall‌‌methodology‌‌for‌‌development.‌‌I‌‌believe‌‌this‌‌was‌‌the‌‌ correct‌ ‌decision‌ ‌and‌ ‌made‌ ‌for‌ ‌the‌ ‌smoothest‌ ‌development‌ ‌process‌ ‌possible.‌ ‌The‌ ‌Agile‌‌ methodology‌‌allowed‌‌our‌‌team‌‌to‌‌be‌‌very‌‌flexible‌‌with‌‌changing‌‌requirements‌‌of‌‌the‌‌project‌‌as‌‌ ‌ 74‌ ‌ we‌‌decided‌‌to‌‌modify,‌‌add,‌‌or‌‌remove‌‌features‌‌we‌‌planned‌‌on‌‌implementing.‌‌This‌‌flexibility‌‌was‌‌ useful‌ ‌because‌ ‌we‌ ‌always‌ ‌viewed‌ ‌Hestia‌ ‌as‌ ‌a‌ ‌work‌ ‌in‌ ‌progress‌ ‌project,‌ ‌there‌ ‌are‌ ‌almost‌ ‌an‌‌ unlimited‌ ‌number‌ ‌of‌ ‌features‌ ‌that‌ ‌could‌ ‌be‌‌added‌‌to‌‌the‌‌application‌‌because‌‌there‌‌are‌‌so‌‌many‌‌ things‌‌that‌‌go‌‌into‌‌home‌‌management.‌‌Therefore,‌‌the‌‌main‌‌goal‌‌during‌‌the‌‌development‌‌process‌‌ was‌‌implementing‌‌as‌‌many‌‌features‌‌as‌‌we‌‌could‌‌conceivably‌‌get‌‌done‌‌in‌‌the‌‌two‌‌semesters.‌‌This‌‌ goal‌ ‌made‌ ‌the‌ ‌Agile‌ ‌methodology‌ ‌the‌ ‌perfect‌ ‌choice,‌ ‌and‌ ‌the‌ ‌only‌ ‌problem‌ ‌with‌ ‌this‌‌decision‌‌ was‌‌that‌‌our‌‌team‌‌was‌‌not‌‌always‌‌great‌‌at‌‌following‌‌the‌‌methodology.‌‌There‌‌were‌‌points‌‌during‌‌ the‌ ‌semester‌ ‌where‌ ‌development‌ ‌got‌ ‌rushed,‌ ‌and‌ ‌to‌ ‌save‌ ‌time‌ ‌code‌ ‌was‌ ‌released‌ ‌before‌ ‌the‌‌ review‌ ‌process‌‌got‌‌completed,‌‌and‌‌we‌‌didn’t‌‌even‌‌implement‌‌a‌‌review‌‌process‌‌until‌‌the‌‌second‌‌ semester.‌ ‌Thus,‌ ‌for‌ ‌the‌ ‌development‌ ‌of‌ ‌the‌‌prototype,‌‌we‌‌skipped‌‌over‌‌the‌‌review‌‌phase‌‌in‌‌the‌‌ Agile‌ ‌framework,‌ ‌which‌ ‌led‌ ‌to‌ ‌more‌ ‌bugs‌‌getting‌‌released,‌‌and‌‌overall‌‌probably‌‌cost‌‌our‌‌team‌‌ more‌ ‌development‌ ‌time‌ ‌than‌ ‌it‌ ‌saved‌ ‌by‌ ‌skipping‌ ‌this‌ ‌step.‌‌Other‌‌than‌‌this‌‌blip,‌‌our‌‌team‌‌was‌‌ very‌‌diligent‌‌in‌‌following‌‌the‌‌Agile‌‌methodology‌‌during‌‌our‌‌development,‌‌and‌‌it‌‌ended‌‌up‌‌being‌‌ a‌‌great‌‌decision‌‌for‌‌the‌‌project.‌ ‌ 6.2‌‌ Code‌‌Structure‌‌Decisions‌‌Retrospective‌ ‌ The‌ ‌next‌ ‌design‌ ‌decisions‌ ‌we‌ ‌made‌ ‌that‌ ‌must‌ ‌be‌ ‌analyzed‌ ‌are‌ ‌the‌ ‌code‌ ‌structure‌‌ decisions.‌ ‌With‌ ‌these,‌ ‌our‌ ‌team‌ ‌decided‌ ‌that‌ ‌Hestia‌ ‌would‌ ‌be‌ ‌divided‌ ‌up‌ ‌into‌ ‌six‌ ‌distinct‌‌ components:‌ ‌the‌ ‌front-end‌ ‌mobile,‌ ‌the‌ ‌front-end‌ ‌web,‌ ‌the‌ ‌Identity‌ ‌Server,‌ ‌the‌ ‌Identity‌ ‌Server‌‌ database,‌ ‌the‌ ‌back‌ ‌web‌ ‌API,‌ ‌and‌ ‌the‌ ‌main‌ ‌Hestia‌ ‌database.‌ ‌We‌ ‌also‌ ‌decided‌ ‌that‌ ‌we‌ ‌would‌‌ deploy‌‌all‌‌components‌‌of‌‌our‌‌application‌‌using‌‌Microsoft‌‌Azure.‌ ‌ The‌ ‌decision‌ ‌to‌ ‌divide‌‌Hestia‌‌into‌‌six‌‌separate‌‌applications‌‌was‌‌undoubtedly‌‌the‌‌ correct‌ ‌decision.‌ ‌This‌ ‌decision‌ ‌kept‌ ‌each‌ ‌of‌ ‌our‌ ‌codebases‌ ‌at‌ ‌a‌ ‌very‌ ‌maintainable‌ ‌size,‌ ‌which‌‌ made‌ ‌bugs‌ ‌relatively‌ ‌easy‌ ‌to‌ ‌detect.‌ ‌Tracking‌ ‌down‌ ‌bugs‌ ‌as‌ ‌quickly‌ ‌as‌ ‌possible‌ ‌is‌ ‌always‌‌ ‌ 75‌ ‌ important‌ ‌during‌ ‌the‌‌development‌‌process‌‌as‌‌you‌‌are‌‌developing‌‌a‌‌large-scale‌‌software‌‌system,‌‌ bugs‌ ‌will‌ ‌inevitably‌ ‌appear‌ ‌and‌ ‌need‌ ‌fixing.‌ ‌Furthermore,‌ ‌this‌ ‌decision‌ ‌also‌ ‌worked‌‌very‌‌well‌‌ with‌ ‌our‌ ‌team‌ ‌breakdown‌ ‌we‌ ‌decided‌ ‌on‌ ‌with‌ ‌two‌ ‌backend‌ ‌developers‌ ‌and‌ ‌three‌ ‌frontend‌‌ developers.‌ ‌By‌ ‌separating‌ ‌the‌ ‌application‌ ‌into‌ ‌six‌ ‌separate‌ ‌components‌ ‌it‌ ‌allowed‌ ‌each‌ ‌of‌ ‌our‌‌ developers‌‌to‌‌only‌‌be‌‌concerned‌‌with‌‌a‌‌few‌‌components‌‌of‌‌the‌‌application.‌‌This‌‌separation‌‌saved‌‌ development‌‌time‌‌because‌‌it‌‌decreased‌‌the‌‌amount‌‌of‌‌code‌‌that‌‌each‌‌developer‌‌must‌‌understand.‌‌ It‌‌meant‌‌that‌‌the‌‌frontend‌‌developers‌‌don’t‌‌need‌‌to‌‌know‌‌how‌‌backend‌‌Web‌‌API‌‌works.‌‌Instead,‌‌ they‌‌can‌‌learn‌‌how‌‌to‌‌use‌‌the‌‌endpoints,‌‌which‌‌is‌‌much‌‌simpler.‌ ‌ Furthermore,‌ ‌besides‌ ‌saving‌ ‌development‌ ‌time,‌ ‌this‌ ‌division‌ ‌of‌ ‌the‌ ‌application‌‌ was‌ ‌also‌ ‌a‌ ‌great‌ ‌decision‌ ‌because‌ ‌it‌ ‌makes‌ ‌Hestia‌ ‌a‌ ‌much‌ ‌more‌ ‌scalable‌ ‌application‌ ‌if‌ ‌we‌‌ develop‌‌it‌‌further‌‌after‌‌this‌‌semester.‌‌The‌‌way‌‌we‌‌have‌‌it‌‌broken‌‌down‌‌allows‌‌each‌‌component‌‌to‌‌ be‌‌developed‌‌separately.‌‌This‌‌separation‌‌means‌‌that‌‌we‌‌can‌‌add‌‌endpoints‌‌to‌‌the‌‌API‌‌or‌‌pages‌‌to‌‌ the‌ ‌frontend‌‌without‌‌changing‌‌the‌‌behavior‌‌of‌‌the‌‌rest‌‌of‌‌the‌‌application‌‌in‌‌any‌‌way,‌‌as‌‌long‌‌as‌‌ we‌‌don’t‌‌break‌‌the‌‌existing‌‌code‌‌behavior.‌‌This‌‌behavior‌‌is‌‌important‌‌because‌‌it‌‌allows‌‌our‌‌team‌‌ to‌‌develop‌‌multiple‌‌portions‌‌of‌‌the‌‌application‌‌simultaneously.‌‌Then,‌‌this‌‌split‌‌also‌‌allowed‌‌both‌‌ of‌‌our‌‌front-ends‌‌to‌‌use‌‌the‌‌same‌‌backend‌‌for‌‌the‌‌application,‌‌which‌‌ensures‌‌that‌‌consistency‌‌is‌‌ maintained‌ ‌between‌ ‌both‌ ‌the‌ ‌web‌ ‌and‌ ‌mobile‌ ‌applications‌ ‌because‌ ‌both‌ ‌must‌ ‌work‌ ‌using‌ ‌the‌‌ same‌‌set‌‌of‌‌API‌‌endpoints‌‌for‌‌their‌‌features.‌‌Furthermore,‌‌separating‌‌the‌‌Identity‌‌Server‌‌for‌‌user‌‌ authentication‌ ‌and‌ ‌account‌ ‌creation‌ ‌allows‌ ‌us‌ ‌to‌ ‌completely‌ ‌reuse‌ ‌this‌ ‌server‌ ‌for‌ ‌the‌ ‌same‌‌ purpose‌‌if‌‌we‌‌want‌‌to‌‌turn‌‌Hestia‌‌into‌‌a‌‌brand‌‌with‌‌multiple‌‌apps‌‌under‌‌its‌‌umbrella.‌‌Therefore,‌‌ for‌ ‌all‌ ‌these‌ ‌reasons,‌ ‌I‌ ‌feel‌ ‌like‌ ‌the‌ ‌division‌ ‌of‌ ‌the‌ ‌Hestia‌ ‌application‌ ‌into‌ ‌six‌ ‌separate‌‌ components‌ ‌was‌ ‌the‌ ‌perfect‌ ‌decision,‌ ‌which‌ ‌sets‌ ‌our‌ ‌team‌‌up‌‌well‌‌if‌‌we‌‌decide‌‌to‌‌develop‌‌the‌‌ application‌‌further.‌ ‌ ‌ 76‌ ‌ Then,‌‌the‌‌other‌‌decision‌‌that‌‌we‌‌made‌‌in‌‌this‌‌area‌‌was‌‌to‌‌use‌‌Microsoft‌‌Azure‌‌to‌‌ deploy‌ ‌all‌ ‌of‌ ‌the‌ ‌components‌ ‌of‌ ‌the‌ ‌application‌ ‌except‌ ‌mobile.‌ ‌Overall,‌ ‌this‌ ‌ended‌ ‌up‌‌being‌‌a‌‌ good‌ ‌decision‌ ‌as‌ ‌Azure‌ ‌has‌ ‌been‌ ‌an‌ ‌easy‌‌service‌‌to‌‌work‌‌with‌‌and‌‌therefore‌‌has‌‌decreased‌‌the‌‌ amount‌ ‌of‌ ‌time‌ ‌we‌ ‌needed‌ ‌to‌ ‌spend‌ ‌worrying‌ ‌about‌ ‌how‌ ‌to‌ ‌deploy‌ ‌the‌ ‌project.‌ ‌But,‌ ‌I‌ ‌still‌‌ wouldn’t‌ ‌go‌ ‌as‌ ‌far‌‌as‌‌to‌‌say‌‌it‌‌was‌‌the‌‌perfect‌‌decision‌‌because‌‌we‌‌could‌‌have‌‌gotten‌‌the‌‌same‌‌ results‌ ‌if‌ ‌we‌ ‌used‌ ‌AWS‌ ‌or‌ ‌Google‌ ‌Cloud‌ ‌over‌ ‌Microsoft‌ ‌Azure.‌ ‌Therefore,‌ ‌I‌ ‌feel‌ ‌like‌ ‌using‌‌ Azure‌‌was‌‌a‌‌good‌‌decision‌‌but‌‌any‌‌other‌‌choice‌‌of‌‌deployment‌‌would‌‌have‌‌worked‌‌just‌‌as‌‌well.‌‌ The‌ ‌primary‌ ‌part‌ ‌of‌ ‌this‌ ‌choice‌ ‌that‌ ‌was‌ ‌important‌ ‌was‌ ‌using‌ ‌the‌ ‌same‌ ‌service‌ ‌for‌ ‌all‌‌ deployments,‌ ‌which‌ ‌was‌ ‌important‌ ‌to‌ ‌ensure‌ ‌deployments‌ ‌were‌ ‌consistent‌ ‌and‌ ‌easy‌ ‌to‌ ‌access.‌‌ Then,‌‌for‌‌mobile‌‌deployment,‌‌there‌‌isn’t‌‌much‌‌to‌‌discuss‌‌because‌‌the‌‌decision‌‌to‌‌give‌‌users‌‌the‌‌ packages‌‌to‌‌download‌‌until‌‌the‌‌app‌‌is‌‌released‌‌on‌‌the‌‌Google‌‌Play‌‌Store‌‌and‌‌Apple‌‌App‌‌Store‌‌is‌‌ the‌‌only‌‌option.‌ ‌ Therefore,‌ ‌I‌ ‌feel‌ ‌like‌ ‌we‌ ‌made‌ ‌amazing‌ ‌code‌ ‌structure‌ ‌decisions‌ ‌that‌ ‌set‌ ‌our‌‌ application‌‌up‌‌well‌‌for‌‌the‌‌future.‌‌The‌‌decision‌‌to‌‌divide‌‌up‌‌the‌‌application‌‌into‌‌six‌‌components‌‌ allowed‌‌us‌‌to‌‌save‌‌a‌‌large‌‌amount‌‌of‌‌development‌‌time‌‌and‌‌allows‌‌Hestia‌‌to‌‌be‌‌very‌‌scalable‌‌for‌‌ future‌ ‌development.‌ ‌Then,‌ ‌our‌ ‌choice‌ ‌of‌ ‌Microsoft‌ ‌Azure‌ ‌for‌ ‌deployment‌ ‌was‌ ‌also‌ ‌a‌ ‌good‌‌ decision‌ ‌because‌ ‌it‌ ‌allowed‌ ‌us‌ ‌to‌ ‌deploy‌ ‌all‌ ‌aspects‌ ‌of‌ ‌the‌ ‌application‌ ‌using‌‌the‌‌same‌‌service,‌‌ which‌‌was‌‌important‌‌so‌‌that‌‌the‌‌deployment‌‌process‌‌could‌‌be‌‌more‌‌easily‌‌managed.‌‌ ‌ 6.3‌ Code‌‌Implementation‌‌Decisions‌‌Retrospective‌ ‌ Then,‌ ‌the‌ ‌final‌ ‌set‌ ‌of‌ ‌decisions‌ ‌we‌ ‌made‌ ‌before‌ ‌beginning‌ ‌development‌ ‌work‌ ‌was‌ ‌the‌‌ code‌ ‌structure‌ ‌decisions.‌ ‌These‌ ‌decisions‌ ‌included‌ ‌what‌ ‌frameworks‌ ‌and‌ ‌subsequently,‌‌ programming‌ ‌languages‌ ‌to‌ ‌use‌ ‌for‌ ‌each‌ ‌non-database‌ ‌component‌ ‌and‌‌what‌‌type‌‌of‌‌database‌‌to‌‌ use‌ ‌for‌ ‌both‌ ‌databases.‌ ‌Furthermore,‌ ‌with‌ ‌the‌ ‌databases,‌ ‌we‌ ‌also‌ ‌had‌ ‌to‌ ‌decide‌ ‌whether‌ ‌we‌‌ ‌ 77‌ ‌ should‌ ‌use‌ ‌a‌ ‌database‌ ‌first‌ ‌or‌ ‌a‌ ‌code-first‌ ‌approach‌ ‌when‌ ‌creating‌ ‌the‌ ‌databases.‌ ‌The‌‌ frontend-web‌ ‌application‌ ‌uses‌ ‌the‌ ‌Angular‌ ‌framework‌ ‌and‌ ‌the‌ ‌Javascript‌ ‌language.‌ ‌The‌‌ frontend-mobile‌ ‌application‌ ‌uses‌ ‌the‌ ‌NativeScript‌ ‌framework‌ ‌and‌ ‌the‌ ‌Javascript‌ ‌programming‌‌ language.‌ ‌The‌ ‌Identity‌ ‌Server‌ ‌uses‌ ‌the‌ ‌IdentityServer4‌ ‌framework‌ ‌and‌ ‌the‌ ‌C#‌ ‌programming‌‌ language.‌ ‌Then,‌ ‌the‌ ‌backend‌ ‌web‌ ‌API‌ ‌uses‌ ‌the‌ ‌.NET‌ ‌framework‌ ‌and‌ ‌the‌ ‌C#‌ ‌programming‌‌ language.‌ ‌Then,‌‌we‌‌made‌‌both‌‌our‌‌databases‌‌SQL‌‌databases‌‌and‌‌used‌‌a‌‌code-first‌‌approach‌‌for‌‌ the‌‌Identity‌‌Server‌‌database‌‌and‌‌a‌‌database‌‌first‌‌approach‌‌for‌‌the‌‌main‌‌Hestia‌‌database.‌‌Overall,‌‌ these‌‌ended‌‌up‌‌being‌‌great‌‌decisions‌‌that‌‌helped‌‌make‌‌the‌‌development‌‌of‌‌the‌‌Hestia‌‌application‌‌ much‌ ‌easier‌ ‌with‌ ‌one‌ ‌major‌ ‌exception,‌ ‌which‌ ‌I‌ ‌would‌ ‌recommend‌ ‌changing‌ ‌our‌ ‌decision‌ ‌on‌‌ were‌‌we‌‌to‌‌redo‌‌the‌‌project.‌ ‌ Our‌‌decision‌‌to‌‌use‌‌the‌‌Angular‌‌framework‌‌for‌‌the‌‌web‌‌application‌‌frontend‌‌worked‌‌out‌‌ exactly‌‌as‌‌intended.‌‌We‌‌made‌‌this‌‌decision‌‌due‌‌to‌‌our‌‌previous‌‌familiarity‌‌with‌‌the‌‌framework‌‌as‌‌ both‌ ‌Liam‌ ‌and‌ ‌Pierce,‌ ‌our‌ ‌frontend‌ ‌web‌ ‌developers,‌ ‌were‌‌very‌‌experienced‌‌with‌‌it.‌‌Therefore,‌‌ this‌ ‌experience‌ ‌with‌ ‌the‌ ‌framework‌ ‌allowed‌ ‌frontend‌ ‌web‌ ‌development‌ ‌work‌ ‌to‌ ‌go‌ ‌very‌‌ smoothly.‌ ‌Furthermore,‌ ‌it‌ ‌was‌ ‌a‌ ‌great‌ ‌choice‌ ‌of‌ ‌framework‌ ‌because‌ ‌our‌ ‌web‌ ‌application‌ ‌is‌‌ single-page‌ ‌based,‌ ‌where‌ ‌each‌ ‌feature‌ ‌of‌‌the‌‌application‌‌is‌‌essentially‌‌its‌‌page‌‌on‌‌the‌‌web‌‌app.‌‌ This‌ ‌is‌ ‌the‌ ‌type‌ ‌of‌ ‌application‌ ‌that‌ ‌the‌ ‌angular‌ ‌framework‌ ‌specializes‌ ‌in.‌ ‌Therefore,‌ ‌using‌ ‌the‌‌ Angular‌‌framework‌‌allowed‌‌us‌‌to‌‌build‌‌a‌‌great‌‌single-page‌‌structured‌‌web‌‌application.‌‌Thus,‌‌we‌‌ feel‌‌like‌‌this‌‌was‌‌the‌‌perfect‌‌framework‌‌to‌‌use‌‌for‌‌this‌‌component‌‌of‌‌the‌‌application.‌ ‌ We‌‌decided‌‌to‌‌use‌‌the‌‌Nativescript‌‌framework‌‌for‌‌frontend-mobile‌‌development.‌‌Overall,‌‌ this‌‌was‌‌not‌‌a‌‌great‌‌decision,‌‌and‌‌it‌‌made‌‌development‌‌work‌‌on‌‌the‌‌mobile‌‌application‌‌frontend‌‌ much‌ ‌harder.‌ ‌The‌ ‌primary‌ ‌reason‌ ‌we‌ ‌chose‌ ‌to‌ ‌use‌ ‌this‌ ‌framework‌ ‌since‌ ‌it‌ ‌would‌ ‌allow‌ ‌us‌ ‌to‌‌ develop‌‌the‌‌application‌‌on‌‌IOS‌‌and‌‌Android‌‌using‌‌the‌‌same‌‌code.‌‌However,‌‌we‌‌failed‌‌to‌‌realize‌‌ ‌ 78‌ ‌ a‌‌major‌‌drawback‌‌with‌‌this‌‌approach‌‌is‌‌that‌‌while‌‌it‌‌saves‌‌time‌‌in‌‌not‌‌having‌‌to‌‌develop‌‌separate‌‌ applications‌‌for‌‌both‌‌platforms‌‌it‌‌makes‌‌development‌‌on‌‌both‌‌of‌‌these‌‌applications‌‌much‌‌harder.‌‌ Furthermore,‌‌we‌‌did‌‌not‌‌consider‌‌many‌‌other‌‌cross-platform‌‌frameworks‌‌meaning‌‌we‌‌may‌‌have‌‌ missed‌‌out‌‌on‌‌using‌‌a‌‌cross-platform‌‌framework‌‌that‌‌may‌‌have‌‌worked‌‌better.‌ ‌When‌‌developing‌‌ using‌‌the‌‌NativeScript‌‌framework,‌‌its‌‌ability‌‌to‌‌use‌‌the‌‌same‌‌code‌‌for‌‌both‌‌applications‌‌can‌‌limit‌‌ the‌ ‌complexity‌ ‌of‌‌the‌‌application‌‌since‌‌the‌‌code‌‌written‌‌must‌‌be‌‌compatible‌‌to‌‌be‌‌compiled‌‌for‌‌ both‌ ‌platforms.‌ ‌Additionally‌ ‌with‌ ‌Nativescript,‌ ‌even‌ ‌with‌ ‌the‌ ‌same‌ ‌code‌ ‌running‌ ‌on‌ ‌IOS‌ ‌and‌‌ Android‌‌can‌‌have‌‌different‌‌behaviors,‌‌you‌‌may‌‌have‌‌bugs‌‌on‌‌Android‌‌or‌‌IOS‌‌which‌‌are‌‌not‌‌bugs‌‌ on‌‌the‌‌other‌‌operating‌‌system.‌‌This‌‌differing‌‌behavior‌‌makes‌‌bugs‌‌much‌‌harder‌‌to‌‌detect‌‌and‌‌fix‌‌ and‌‌makes‌‌the‌‌entire‌‌development‌‌process‌‌harder‌‌overall.‌‌These‌‌restrictive‌‌factors‌‌mean‌‌that‌‌we‌‌ regret‌ ‌our‌ ‌decision‌ ‌about‌ ‌using‌ ‌the‌‌NativeScript‌‌framework‌‌for‌‌the‌‌mobile‌‌application.‌‌Even‌‌if‌‌ this‌ ‌meant‌ ‌we‌ ‌could‌ ‌only‌ ‌support‌ ‌the‌ ‌mobile‌ ‌application‌ ‌on‌ ‌one‌ ‌platform‌ ‌by‌ ‌the‌ ‌end‌ ‌of‌ ‌the‌‌ project,‌ ‌a‌ ‌different‌ ‌choice‌ ‌of‌ ‌framework‌ ‌would‌ ‌have‌ ‌been‌ ‌preferable.‌‌We‌‌believe‌‌that‌‌it‌‌would‌‌ have‌ ‌been‌ ‌better‌ ‌to‌ ‌have‌ ‌a‌ ‌single,‌ ‌amazing‌ ‌custom-built‌ ‌app‌ ‌on‌ ‌one‌ ‌platform‌ ‌that‌ ‌is‌ ‌easy‌ ‌to‌‌ develop‌‌further,‌‌than‌‌a‌‌lesser‌‌app‌‌on‌‌both‌‌platforms‌‌that‌‌is‌‌limited‌‌by‌‌the‌‌framework‌‌and‌‌hard‌‌to‌‌ develop‌‌more.‌‌For‌‌these‌‌reasons,‌‌were‌‌we‌‌to‌‌restart‌‌the‌‌project‌‌from‌‌scratch‌‌again,‌‌we‌‌would‌‌not‌‌ use‌ ‌the‌ ‌NativeScript‌ ‌framework‌ ‌for‌ ‌frontend-mobile‌ ‌development.‌ ‌Instead,‌ ‌we‌ ‌would‌ ‌use‌ ‌the‌‌ more‌ ‌standard‌ ‌Android‌ ‌Studio‌ ‌framework‌ ‌for‌ ‌Android‌ ‌development‌ ‌and‌ ‌Swift‌ ‌framework‌ ‌for‌‌ IOS‌ ‌development‌ ‌or‌ ‌a‌ ‌more‌ ‌common‌ ‌cross-platform‌ ‌framework‌ ‌like‌ ‌React‌ ‌Native.‌ ‌In‌ ‌the‌‌ scenario‌ ‌that‌ ‌we‌ ‌chose‌ ‌to‌‌separate‌‌the‌‌Android‌‌and‌‌IOS‌‌application‌‌using‌‌a‌‌non-cross-platform‌‌ framework,‌‌we‌‌would‌‌prioritize‌‌the‌‌IOS‌‌application‌‌first‌‌because‌‌all‌‌of‌‌our‌‌team‌‌members‌‌have‌‌ Iphones‌‌and‌‌therefore‌‌could‌‌use‌‌the‌‌IOS‌‌application.‌ ‌ ‌ 79‌ ‌ For‌ ‌the‌ ‌Identity‌ ‌Server,‌ ‌we‌ ‌chose‌ ‌to‌ ‌use‌ ‌the‌ ‌IdentityServer4‌ ‌framework‌ ‌because‌ ‌it‌‌ provides‌ ‌access‌ ‌to‌ ‌the‌‌latest‌‌security‌‌technology‌‌with‌‌the‌‌OpenID‌‌protocol.‌‌This‌‌protocol‌‌helps‌‌ ensure‌‌that‌‌our‌‌user's‌‌login‌‌information‌‌will‌‌be‌‌secured,‌‌which‌‌is‌‌essential‌‌for‌‌creating‌‌a‌‌trusted‌‌ brand.‌‌However,‌‌this‌‌decision‌‌made‌‌development‌‌work‌‌on‌‌the‌‌login‌‌functionality‌‌tough‌‌because‌‌ this‌‌is‌‌a‌‌difficult‌‌framework‌‌to‌‌work‌‌with.‌‌Despite‌‌this,‌‌we‌‌are‌‌happy‌‌with‌‌this‌‌decision,‌‌and‌‌we‌‌ are‌‌confident‌‌that‌‌it‌‌is‌‌the‌‌best‌‌decision‌‌we‌‌could‌‌have‌‌made.‌‌Eventually,‌‌we‌‌would‌‌have‌‌needed‌‌ to‌ ‌make‌ ‌an‌ ‌Identity‌ ‌Server,‌ ‌so‌ ‌implementing‌ ‌it‌ ‌at‌ ‌the‌ ‌start‌ ‌of‌ ‌the‌ ‌application’s‌ ‌life‌ ‌cycle‌ ‌was‌‌ important.‌‌Furthermore,‌‌we‌‌feel‌‌like‌‌the‌‌security‌‌enhancements‌‌this‌‌framework‌‌provides‌‌greatly‌‌ outweigh‌ ‌the‌ ‌development‌ ‌hassle‌ ‌it‌ ‌caused,‌ ‌therefore‌ ‌in‌ ‌retrospect,‌ ‌we‌ ‌would‌ ‌still‌ ‌choose‌ ‌this‌‌ framework‌‌if‌‌we‌‌started‌‌developing‌‌the‌‌application‌‌from‌‌scratch‌‌again.‌ ‌ Then,‌‌the‌‌final‌‌component‌‌of‌‌the‌‌project‌‌that‌‌involves‌‌direct‌‌programming‌‌is‌‌the‌‌backend‌‌ web‌‌API,‌‌for‌‌which‌‌we‌‌chose‌‌to‌‌use‌‌the‌‌.NET‌‌framework.‌‌We‌‌chose‌‌this‌‌framework‌‌because‌‌of‌‌ our‌ ‌backend‌ ‌developers,‌ ‌Bridger‌ ‌and‌ ‌myself,‌ ‌familiarity‌ ‌with‌ ‌the‌ ‌framework,‌ ‌and‌ ‌the‌ ‌C#‌‌ language‌ ‌it‌ ‌uses.‌ ‌Another‌ ‌primary‌ ‌reason‌ ‌we‌ ‌chose‌ ‌to‌ ‌use‌ ‌.NET‌ ‌was‌ ‌that‌ ‌it‌ ‌allows‌ ‌us‌ ‌to‌ ‌use‌‌ LINQ,‌‌which‌‌makes‌‌the‌‌database‌‌access‌‌code‌‌it‌‌was‌‌responsible‌‌for‌‌much‌‌easier‌‌to‌‌write.‌‌At‌‌the‌‌ end‌ ‌of‌ ‌the‌ ‌project,‌ ‌I‌ ‌still‌ ‌felt‌ ‌like‌ ‌this‌ ‌was‌ ‌the‌ ‌best‌ ‌decision‌ ‌possible.‌ ‌Our‌ ‌familiarity‌ ‌with‌‌the‌‌ framework‌ ‌made‌ ‌development‌ ‌work‌‌go‌‌very‌‌smoothly.‌‌Then,‌‌having‌‌access‌‌to‌‌LINQ‌‌made‌‌our‌‌ database‌ ‌access‌ ‌code‌ ‌much‌ ‌quicker‌ ‌to‌ ‌write‌ ‌and‌ ‌a‌ ‌lot‌ ‌less‌ ‌buggy‌ ‌to‌ ‌write‌ ‌since‌ ‌the‌‌ language-integrated‌ ‌queries‌ ‌are‌ ‌much‌ ‌easier‌ ‌to‌ ‌debug‌ ‌than‌ ‌query‌ ‌strings.‌ ‌Thus,‌‌in‌‌retrospect,‌‌I‌‌ would‌ ‌not‌ ‌change‌ ‌anything‌ ‌about‌ ‌the‌ ‌code‌ ‌implementation‌‌decisions‌‌we‌‌made‌‌for‌‌the‌‌backend‌‌ web‌‌API.‌ ‌ The‌ ‌final‌ ‌code‌ ‌implementation‌ ‌decisions‌ ‌were‌ ‌how‌ ‌to‌ ‌handle‌ ‌the‌ ‌databases‌ ‌our‌‌ application‌‌would‌‌use.‌‌In‌‌the‌‌end,‌‌we‌‌chose‌‌to‌‌make‌‌both‌‌databases‌‌SQL‌‌databases‌‌and‌‌to‌‌use‌‌a‌‌ ‌ 80‌ ‌ code-first‌ ‌approach‌ ‌for‌ ‌the‌ ‌Identity‌ ‌Server‌‌Database‌‌and‌‌a‌‌database‌‌first‌‌approach‌‌for‌‌the‌‌main‌‌ Hestia‌ ‌database.‌ ‌We‌ ‌chose‌ ‌to‌ ‌make‌ ‌both‌ ‌databases‌ ‌SQL‌ ‌databases‌ ‌because‌ ‌it‌ ‌was‌ ‌the‌ ‌type‌ ‌of‌‌ database‌ ‌everyone‌ ‌on‌ ‌the‌ ‌team‌ ‌was‌ ‌familiar‌ ‌with.‌ ‌By‌ ‌choosing‌ ‌a‌ ‌database‌ ‌type‌ ‌that‌ ‌everyone‌‌ understood,‌ ‌work‌ ‌on‌ ‌the‌ ‌database‌‌was‌‌much‌‌easier‌‌since‌‌every‌‌team‌‌member‌‌could‌‌understand‌‌ how‌‌the‌‌database‌‌worked‌‌and‌‌therefore‌‌knew‌‌what‌‌data‌‌models‌‌we‌‌could‌‌create‌‌in‌‌our‌‌database.‌‌ Then,‌‌for‌‌the‌‌Identity‌‌Server,‌‌we‌‌chose‌‌to‌‌use‌‌a‌‌code-first‌‌approach‌‌to‌‌creating‌‌the‌‌data‌‌models‌‌in‌‌ the‌‌database,‌‌which‌‌was‌‌also‌‌the‌‌correct‌‌decision‌‌because‌‌the‌‌models‌‌could‌‌be‌‌easily‌‌made‌‌in‌‌the‌‌ code‌ ‌using‌ ‌the‌ ‌IdentityServer4‌ ‌framework‌ ‌and‌ ‌then‌ ‌imported‌ ‌into‌ ‌the‌ ‌database.‌ ‌Lastly,‌‌for‌‌the‌‌ main‌ ‌Hestia‌ ‌database,‌ ‌we‌ ‌chose‌ ‌to‌ ‌use‌ ‌a‌ ‌database‌ ‌first‌ ‌approach,‌ ‌and‌ ‌therefore‌ ‌create‌ ‌all‌ ‌the‌‌ models‌‌in‌‌the‌‌database‌‌first‌‌and‌‌then‌‌import‌‌them‌‌into‌‌the‌‌code‌‌using‌‌a‌‌scaffolding‌‌tool.‌‌This‌‌was‌‌ the‌ ‌correct‌ ‌decision‌ ‌because‌ ‌the‌ ‌main‌ ‌Hestia‌ ‌database’s‌ ‌data‌ ‌models‌ ‌are‌ ‌significantly‌ ‌more‌‌ complex‌ ‌than‌ ‌the‌ ‌Identity‌ ‌Server‌ ‌models‌ ‌meaning‌ ‌creating‌ ‌them‌ ‌within‌ ‌the‌ ‌code‌ ‌would‌ ‌have‌‌ been‌‌much‌‌more‌‌difficult‌‌without‌‌causing‌‌many‌‌errors‌‌in‌‌the‌‌database.‌‌Therefore,‌‌it‌‌was‌‌the‌‌right‌‌ decision‌‌to‌‌prioritize‌‌the‌‌accuracy‌‌of‌‌the‌‌database‌‌first‌‌approach‌‌over‌‌the‌‌speed‌‌of‌‌the‌‌code‌‌first‌‌ approach‌ ‌for‌ ‌the‌ ‌main‌ ‌Hestia‌ ‌database.‌ ‌Thus,‌ ‌overall‌ ‌we‌ ‌were‌ ‌pleased‌ ‌with‌ ‌the‌ ‌decisions‌ ‌we‌‌ made‌‌for‌‌our‌‌databases,‌‌and‌‌if‌‌we‌‌could‌‌go‌‌back,‌‌we‌‌would‌‌not‌‌change‌‌any‌‌of‌‌the‌‌decisions‌‌made‌‌ about‌‌them.‌ ‌ Overall,‌ ‌we‌ ‌feel‌ ‌like‌ ‌almost‌ ‌all‌ ‌of‌ ‌our‌ ‌pre-developmental‌ ‌design‌ ‌decisions‌ ‌were‌ ‌good‌‌ choices.‌ ‌The‌ ‌number‌ ‌of‌ ‌good‌ ‌design‌ ‌decisions‌ ‌that‌ ‌our‌ ‌team‌ ‌made‌ ‌allowed‌ ‌the‌ ‌development‌‌ process‌‌to‌‌go‌‌smoothly.‌‌The‌‌one‌‌exception‌‌to‌‌the‌‌rule‌‌was‌‌choosing‌‌the‌‌NativeScript‌‌framework‌‌ for‌ ‌the‌ ‌frontend‌ ‌mobile‌ ‌app‌ ‌development,‌ ‌and‌ ‌if‌ ‌we‌ ‌could‌ ‌go‌ ‌back‌ ‌in‌ ‌time‌ ‌and‌ ‌remake‌ ‌our‌‌ decision,‌ ‌it‌ ‌would‌ ‌have‌ ‌been‌ ‌much‌ ‌better‌ ‌to‌ ‌use‌ ‌one‌ ‌of‌ ‌the‌ ‌more‌ ‌common‌ ‌Android‌ ‌and‌ ‌IOS‌‌ application‌ ‌frameworks‌ ‌using‌ ‌the‌ ‌Android‌ ‌Studio‌ ‌and‌ ‌Swift‌ ‌frameworks‌ ‌respectively,‌ ‌or‌‌use‌‌a‌‌ ‌ 81‌ ‌ more‌‌common‌‌cross-platform‌‌mobile‌‌application‌‌framework‌‌like‌‌React‌‌Native.‌‌Despite‌‌this,‌‌we‌‌ are‌ ‌still‌ ‌proud‌ ‌of‌ ‌the‌ ‌mobile‌ ‌application‌ ‌we‌ ‌developed,‌ ‌but‌ ‌doing‌ ‌this‌ ‌would‌ ‌have‌ ‌made‌ ‌the‌‌ development‌ ‌process‌ ‌much‌ ‌smoother.‌ ‌Our‌ ‌pre-development‌ ‌design‌ ‌decisions‌ ‌were‌ ‌essential‌ ‌in‌‌ developing‌ ‌an‌ ‌application‌ ‌that‌ ‌matched‌ ‌our‌ ‌vision‌ ‌for‌ ‌Hestia.‌ ‌By‌ ‌getting‌ ‌the‌‌majority‌‌of‌‌these‌‌ decisions‌‌correct,‌‌we‌‌created‌‌a‌‌final‌‌product‌‌that‌‌closely‌‌resembled‌‌what‌‌we‌‌envisioned.‌ ‌ ‌ 82‌ ‌ 7‌‌FUTURE‌‌DEVELOPMENT‌ ‌ We‌‌created‌‌an‌‌application‌‌that‌‌we‌‌feel‌‌anyone‌‌could‌‌gain‌‌value‌‌from‌‌since‌‌it‌‌allows‌‌them‌‌ to‌ ‌better‌ ‌manage‌ ‌their‌ ‌life.‌ ‌In‌ ‌this‌ ‌final‌‌product,‌‌we‌‌accomplished‌‌everything‌‌we‌‌set‌‌out‌‌to‌‌do,‌‌ which‌‌is‌‌very‌‌rewarding‌‌to‌‌see.‌‌Now‌‌that‌‌the‌‌capstone‌‌project‌‌is‌‌coming‌‌to‌‌a‌‌close,‌‌it‌‌is‌‌time‌‌to‌‌ decide‌ ‌what‌ ‌the‌ ‌future‌ ‌of‌ ‌the‌ ‌Hestia‌ ‌application‌ ‌should‌ ‌be.‌ ‌For‌ ‌this‌ ‌question‌ ‌we‌ ‌had‌ ‌three‌‌ choices:‌‌we‌‌could‌‌release‌‌the‌‌application‌‌and‌‌consistently‌‌update‌‌it‌‌with‌‌new‌‌versions,‌‌we‌‌could‌‌ make‌‌the‌‌project‌‌open-sourced,‌‌or‌‌we‌‌could‌‌let‌‌the‌‌project‌‌go‌‌dormant‌‌and‌‌go‌‌unreleased‌‌for‌‌the‌‌ time‌ ‌being.‌ ‌As‌ ‌a‌ ‌team,‌ ‌we‌ ‌incorrectly‌ ‌assumed‌ ‌that‌ ‌making‌ ‌the‌ ‌project‌ ‌open-sourced‌ ‌would‌‌ relinquish‌‌all‌‌our‌‌personal‌‌ownership‌‌licenses‌‌of‌‌the‌‌code‌‌and‌‌therefore‌‌we‌‌eliminated‌‌that‌‌as‌‌an‌‌ option‌ ‌right‌ ‌away.‌ ‌Ultimately,‌ ‌we‌ ‌decided‌ ‌to‌‌choose‌‌the‌‌third‌‌option‌‌for‌‌the‌‌future‌‌of‌‌Hestia‌‌at‌‌ this‌‌current‌‌point‌‌in‌‌time‌‌meaning‌‌it‌‌will‌‌not‌‌be‌‌released‌‌on‌‌Android’s‌‌Google‌‌Play‌‌store‌‌or‌‌the‌‌ IOS‌‌App‌‌store‌‌and‌‌the‌‌web‌‌application‌‌will‌‌be‌‌shut‌‌down‌‌for‌‌the‌‌time‌‌being.‌‌ ‌ We‌ ‌didn’t‌ ‌make‌ ‌this‌ ‌decision‌ ‌to‌ ‌allow‌ ‌the‌ ‌application‌ ‌to‌ ‌go‌ ‌dormant‌ ‌because‌ ‌we‌ ‌are‌‌ unhappy‌‌with‌‌what‌‌we‌‌have‌‌developed‌‌in‌‌any‌‌way.‌‌We‌‌decided‌‌to‌‌let‌‌the‌‌application‌‌lie‌‌dormant‌‌ for‌ ‌now‌ ‌because‌ ‌we‌ ‌know‌ ‌that‌ ‌as‌ ‌a‌ ‌team‌ ‌we‌ ‌don’t‌ ‌have‌ ‌the‌ ‌time‌ ‌available‌ ‌to‌ ‌release‌ ‌the‌‌ application‌ ‌currently.‌ ‌We‌ ‌know‌ ‌when‌ ‌the‌ ‌application‌ ‌gets‌ ‌released,‌ ‌the‌ ‌developers‌ ‌(us)‌ ‌must‌‌ maintain‌ ‌and‌ ‌update‌ ‌it,‌ ‌or‌ ‌else‌ ‌it‌ ‌will‌ ‌be‌ ‌doomed‌ ‌to‌ ‌fail.‌ ‌All‌ ‌of‌ ‌our‌ ‌team‌ ‌members‌ ‌plan‌ ‌on‌‌ working‌ ‌in‌ ‌the‌ ‌industry‌‌right‌‌after‌‌graduation,‌‌which‌‌means‌‌we‌‌do‌‌not‌‌have‌‌the‌‌necessary‌‌time‌‌ available‌ ‌to‌ ‌maintain‌ ‌and‌ ‌update‌ ‌the‌ ‌application‌ ‌if‌ ‌it‌ ‌was‌ ‌released‌ ‌right‌ ‌now.‌ ‌Even‌ ‌if‌ ‌it‌ ‌had‌ ‌a‌‌ successful‌ ‌initial‌ ‌release,‌ ‌over‌ ‌time,‌ ‌if‌ ‌it‌ ‌was‌‌not‌‌constantly‌‌being‌‌maintained‌‌and‌‌improved,‌‌it‌ would‌ ‌die‌ ‌out.‌ ‌An‌ ‌early‌ ‌release‌ ‌would‌ ‌be‌ ‌a‌ ‌death‌ ‌nail‌ ‌in‌ ‌the‌ ‌coffin‌ ‌of‌ ‌the‌ ‌Hestia‌ ‌application,‌‌ which‌‌it‌‌could‌‌never‌‌recover‌‌from,‌‌and‌‌therefore‌‌we‌‌decided‌‌against‌‌a‌‌release‌‌at‌‌this‌‌moment‌‌in‌‌ time.‌ ‌Furthermore,‌ ‌the‌ ‌agile‌ ‌framework‌ ‌which‌ ‌we‌ ‌used‌ ‌to‌ ‌develop‌ ‌Hestia‌ ‌requires‌ ‌active‌‌ ‌ 83‌ ‌ participation‌ ‌from‌ ‌team‌ ‌members‌ ‌to‌ ‌work‌ ‌effectively,‌ ‌meaning‌ ‌that‌ ‌we‌ ‌must‌ ‌have‌ ‌at‌ ‌least‌ ‌a‌‌ majority‌ ‌of‌ ‌team‌ ‌members‌ ‌bought‌ ‌in‌ ‌to‌ ‌continue‌ ‌development‌ ‌to‌ ‌release‌ ‌the‌ ‌application‌ ‌and‌‌ consistently‌ ‌improve‌ ‌it.‌ ‌We‌‌currently‌‌do‌‌not‌‌have‌‌this,‌‌but‌‌in‌‌the‌‌future,‌‌there‌‌is‌‌a‌‌good‌‌chance‌‌ that‌ ‌we‌‌will,‌‌and‌‌it‌‌is‌‌at‌‌this‌‌time‌‌that‌‌Hestia‌‌will‌‌get‌‌released.‌‌Therefore,‌‌we‌‌are‌‌confident‌‌that‌‌ keeping‌‌Hestia‌‌dormant‌‌and‌‌unreleased‌‌for‌‌the‌‌time‌‌being‌‌is‌‌the‌‌right‌‌decision‌‌for‌‌our‌‌team‌‌and‌‌ the‌‌future‌‌of‌‌Hestia‌‌as‌‌a‌‌whole.‌‌ ‌ This‌ ‌does‌ ‌not‌ ‌mean‌ ‌Hestia‌ ‌is‌ ‌dead,‌ ‌we‌ ‌are‌ ‌doing‌ ‌this‌ ‌to‌ ‌ensure‌ ‌it‌ ‌has‌ ‌the‌ ‌foundation‌‌ required‌ ‌to‌ ‌be‌ ‌successful‌ ‌when‌ ‌released.‌ ‌Our‌ ‌team‌ ‌plans‌ ‌on‌ ‌continuing‌ ‌development‌ ‌work‌ ‌on‌‌ Hestia‌ ‌as‌ ‌soon‌ ‌as‌ ‌it‌ ‌is‌ ‌feasibly‌ ‌possible.‌ ‌When‌ ‌Hestia‌ ‌is‌ ‌released,‌ ‌not‌ ‌only‌ ‌will‌ ‌it‌ ‌include‌ ‌all‌‌ features‌‌currently‌‌discussed‌‌and‌‌implemented,‌‌but‌‌it‌‌will‌‌also‌‌include‌‌more‌‌features‌‌that‌‌our‌‌team‌‌ has‌ ‌already‌ ‌discussed‌ ‌adding‌ ‌to‌ ‌the‌ ‌application‌ ‌in‌ ‌the‌ ‌future.‌ ‌Some‌ ‌of‌ ‌the‌ ‌features‌ ‌we‌ ‌have‌‌ discussed‌‌adding‌‌are‌‌the‌‌following:‌ ‌ ● Overhauling‌‌the‌‌to-do‌‌list‌‌feature‌‌so‌‌that‌‌each‌‌household‌‌member‌‌can‌‌have‌‌a‌‌separate‌‌ to-do‌‌list‌‌and‌‌to-dos‌‌can‌‌be‌‌assigned‌‌to‌‌individual‌‌household‌‌members‌ ‌ ● Adding‌‌the‌‌ability‌‌to‌‌interact‌‌and‌‌connect‌‌with‌‌other‌‌households‌‌ ‌ ● Adding‌‌real-time‌‌updating‌‌to‌‌pages‌‌by‌‌using‌‌WebSockets,‌‌so‌‌a‌‌user‌‌doesn’t‌‌have‌‌to‌‌ refresh‌‌the‌‌page‌‌to‌‌see‌‌new‌‌information‌‌added‌‌by‌‌other‌‌household‌‌members‌ ‌ ● Implementing‌‌a‌‌push‌‌notification‌‌system‌‌to‌‌remind‌‌a‌‌user‌‌about‌‌upcoming‌‌tasks,‌‌meals,‌‌ and‌‌events‌‌and‌‌to‌‌notify‌‌users‌‌when‌‌they‌‌are‌‌added‌‌to‌‌an‌‌event‌‌or‌‌granted‌‌access‌‌to‌‌a‌‌ budget‌ ‌ ● Adding‌‌in‌‌the‌‌ability‌‌to‌‌import‌‌recipes‌‌found‌‌online‌‌into‌‌Hestia‌‌by‌‌using‌‌web‌‌scraping‌ ‌ ● Adding‌‌the‌‌ability‌‌to‌‌export‌‌your‌‌shopping‌‌list‌‌as‌‌a‌‌printable‌‌pdf‌ ‌ ‌ 84‌ ‌ ● Adding‌‌in‌‌an‌‌entertainment‌‌page‌‌to‌‌recommend‌‌movies,‌‌books,‌‌or‌‌other‌‌activities‌‌for‌‌ family‌‌nights‌ ‌ ● Adding‌‌in‌‌the‌‌ability‌‌for‌‌a‌‌user‌‌to‌‌create‌‌their‌‌customizable‌‌home‌‌page‌‌in‌‌the‌‌web‌‌ application‌ ‌ ‌ Keep‌ ‌an‌ ‌eye‌‌out‌‌for‌‌being‌‌able‌‌to‌‌use‌‌Hestia‌‌on‌‌your‌‌mobile‌‌phone‌‌or‌‌laptop‌‌soon.‌‌Our‌‌ team‌ ‌plans‌ ‌on‌ ‌continuing‌ ‌the‌ ‌development‌ ‌of‌ ‌Hestia‌ ‌and‌ ‌getting‌ ‌it‌ ‌released‌ ‌as‌ ‌soon‌ ‌as‌ ‌we‌‌ possibly‌ ‌can.‌ ‌We‌ ‌hope‌ ‌you‌ ‌can‌ ‌find‌ ‌this‌ ‌application‌ ‌useful‌ ‌and‌ ‌helpful‌ ‌in‌ ‌managing‌‌your‌‌life.‌‌ Once‌‌released,‌‌we‌‌plan‌‌on‌‌implementing‌‌a‌‌system‌‌so‌‌that‌‌users‌‌can‌‌recommend‌‌things‌‌about‌‌the‌‌ application‌ ‌that‌ ‌our‌ ‌team‌ ‌should‌ ‌improve,‌ ‌or‌ ‌new‌ ‌features‌ ‌that‌ ‌we‌ ‌should‌ ‌add.‌ ‌Hestia‌ ‌got‌‌ designed‌‌to‌‌take‌‌care‌‌of‌‌all‌‌your‌‌home‌‌and‌‌life‌‌management‌‌needs.‌‌Therefore,‌‌we‌‌will‌‌ensure‌‌it‌‌ upholds‌‌this‌‌promise‌‌by‌‌making‌‌it‌‌responsive‌‌to‌‌user‌‌input.‌ ‌ ‌ 85‌ ‌ 8‌‌CONCLUSION‌ ‌ Overall,‌ ‌our‌ ‌team‌ ‌is‌ ‌very‌ ‌proud‌ ‌of‌ ‌what‌ ‌we‌ ‌have‌ ‌accomplished‌ ‌over‌ ‌these‌ ‌last‌ ‌two‌‌ semesters‌ ‌creating‌ ‌the‌ ‌Hestia‌ ‌application.‌ ‌We‌ ‌designed‌ ‌a‌ ‌multi-functional‌ ‌large-scale‌ ‌software‌‌ system‌‌entirely‌‌from‌‌the‌‌ground‌‌up,‌‌which‌‌is‌‌an‌‌amazing‌‌accomplishment.‌‌When‌‌we‌‌started‌‌this‌‌ project,‌‌none‌‌of‌‌our‌‌team‌‌members‌‌had‌‌designed‌‌a‌‌software‌‌application‌‌even‌‌close‌‌to‌‌the‌‌size‌‌of‌‌ Hestia.‌‌Most‌‌of‌‌our‌‌previous‌‌programming‌‌experience‌‌was‌‌limited‌‌to‌‌the‌‌classroom‌‌in‌‌which‌‌you‌‌ get‌ ‌given‌ ‌assignments‌ ‌or‌ ‌a‌ ‌project,‌ ‌and‌ ‌you‌ ‌would‌ ‌have‌ ‌a‌ ‌week‌ ‌or‌ ‌at‌ ‌most‌ ‌two‌ ‌months‌ ‌to‌‌ complete‌ ‌it,‌ ‌usually‌ ‌by‌ ‌yourself‌ ‌or‌ ‌in‌ ‌a‌ ‌team‌ ‌of‌ ‌two.‌ ‌In‌ ‌these‌ ‌scenarios,‌ ‌almost‌ ‌every‌ ‌design‌‌ decision‌ ‌had‌‌already‌‌gotten‌‌made‌‌for‌‌you,‌‌or‌‌at‌‌most,‌‌you‌‌had‌‌one‌‌or‌‌two‌‌design‌‌decisions‌‌you‌‌ had‌ ‌to‌ ‌make.‌ ‌For‌ ‌Hestia,‌ ‌we‌ ‌were‌ ‌able‌ ‌to‌ ‌make‌ ‌every‌ ‌design‌ ‌decision‌ ‌ourselves‌ ‌pertaining‌ ‌to‌‌ what‌ ‌it‌ ‌should‌ ‌do,‌ ‌how‌ ‌it‌ ‌should‌ ‌be‌ ‌structured,‌ ‌and‌ ‌how‌ ‌we‌ ‌should‌ ‌develop‌‌the‌‌application‌‌to‌‌ align‌‌with‌‌our‌‌goals‌‌and‌‌vision.‌‌Our‌‌team‌‌was‌‌able‌‌to‌‌take‌‌Hestia‌‌from‌‌the‌‌brainstorming‌‌phase‌‌ to‌ ‌the‌ ‌final‌ ‌product‌ ‌after‌ ‌two‌ ‌semesters‌ ‌of‌ ‌development‌ ‌work.‌ ‌This‌ ‌process‌ ‌was‌‌an‌‌invaluable‌‌ learning‌‌experience‌‌for‌‌us,‌‌and‌‌during‌‌the‌‌development‌‌process,‌‌I‌‌believe‌‌that‌‌we‌‌became‌‌much‌‌ better‌ ‌overall‌ ‌developers.‌ ‌We‌ ‌are‌ ‌very‌ ‌satisfied‌ ‌with‌ ‌what‌ ‌we‌ ‌accomplished‌‌in‌‌this‌‌time‌‌frame‌‌ and‌‌believe‌‌that‌‌we‌‌have‌‌developed‌‌an‌‌application‌‌anyone‌‌could‌‌use‌‌to‌‌make‌‌home‌‌management‌‌ easier‌‌for‌‌any‌‌user.‌ ‌ At‌ ‌the‌ ‌start‌ ‌of‌ ‌this‌ ‌process,‌ ‌we‌ ‌realized‌ ‌that‌ ‌we‌ ‌would‌ ‌have‌ ‌to‌ ‌make‌ ‌design‌ ‌decisions‌‌ about‌ ‌the‌ ‌application‌ ‌before‌ ‌development‌ ‌work‌ ‌began.‌‌In‌‌all,‌‌we‌‌learned‌‌that‌‌we‌‌divided‌‌these‌‌ decisions‌ ‌into‌ ‌the‌ ‌team‌ ‌structure,‌ ‌code‌ ‌structure,‌ ‌and‌ ‌code‌‌implementation‌‌decisions.‌‌All‌‌these‌‌ decisions‌ ‌had‌ ‌to‌ ‌be‌ ‌specifically‌ ‌tailored‌ ‌for‌ ‌Hestia‌ ‌and‌ ‌that‌ ‌these‌ ‌decisions‌ ‌could‌ ‌lead‌ ‌to‌ ‌the‌‌ overall‌ ‌success‌ ‌or‌ ‌failure‌ ‌of‌ ‌the‌ ‌project.‌ ‌For‌ ‌team‌ ‌structure‌ ‌decisions,‌ ‌we‌‌needed‌‌to‌‌determine‌‌ how‌ ‌to‌ ‌divide‌ ‌our‌ ‌team‌ ‌members‌ ‌into‌ ‌different‌ ‌roles‌ ‌for‌ ‌the‌ ‌project‌ ‌and‌ ‌what‌ ‌development‌‌ ‌ 86‌ ‌ methodology,‌‌agile‌‌or‌‌waterfall,‌‌we‌‌should‌‌use‌‌for‌‌development‌‌and‌‌team‌‌organization.‌‌The‌‌code‌‌ structure‌ ‌decisions‌ ‌involved‌ ‌if‌ ‌and‌ ‌how‌ ‌we‌ ‌wanted‌ ‌to‌ ‌separate‌ ‌the‌ ‌application‌ ‌into‌ ‌different‌‌ components.‌ ‌If‌ ‌we‌ ‌did‌ ‌decide‌ ‌to‌ ‌separate‌ ‌them,‌ ‌we‌ ‌also‌ ‌needed‌ ‌to‌ ‌determine‌ ‌how‌ ‌they‌‌would‌‌ interact‌ ‌with‌ ‌one‌ ‌another.‌ ‌Also,‌ ‌deciding‌ ‌how‌ ‌to‌ ‌deploy‌ ‌our‌‌code‌‌to‌‌make‌‌it‌‌available‌‌to‌‌users‌‌ was‌‌a‌‌part‌‌of‌‌the‌‌code‌‌structure‌‌decisions‌‌that‌‌our‌‌team‌‌made.‌‌Then,‌‌for‌‌the‌‌code‌‌implementation‌‌ decisions,‌ ‌we‌ ‌had‌ ‌to‌ ‌determine‌ ‌what‌ ‌frameworks‌ ‌to‌ ‌use‌ ‌for‌ ‌each‌ ‌separate‌ ‌component‌ ‌of‌ ‌our‌‌ application.‌ ‌Additionally,‌‌as‌‌a‌‌part‌‌of‌‌the‌‌code‌‌structure‌‌decisions,‌‌our‌‌team‌‌had‌‌to‌‌decide‌‌what‌‌ type‌ ‌of‌ ‌databases‌ ‌to‌ ‌use‌ ‌and‌ ‌whether‌ ‌we‌ ‌should‌ ‌take‌ ‌a‌ ‌code-first‌‌or‌‌database-first‌‌approach‌‌to‌‌ database‌‌design.‌‌These‌‌decisions‌‌were‌‌made‌‌specifically‌‌for‌‌the‌‌application‌‌we‌‌were‌‌developing,‌‌ which‌‌we‌‌decided‌‌to‌‌name‌‌Hestia‌‌after‌‌the‌‌Greek‌‌goddess‌‌of‌‌hearth‌‌and‌‌home.‌‌Our‌‌team‌‌noticed‌‌ that‌ ‌there‌ ‌are‌ ‌many‌‌budgeting,‌‌calendar,‌‌to-do‌‌list,‌‌and‌‌meal‌‌planning‌‌applications‌‌available‌‌on‌‌ the‌‌market.‌‌But,‌‌having‌‌to‌‌keep‌‌track‌‌of‌‌items‌‌between‌‌multiple‌‌applications‌‌can‌‌be‌‌a‌‌hassle‌‌that‌‌ makes‌ ‌home‌ ‌management‌ ‌much‌ ‌more‌ ‌difficult.‌ ‌Therefore,‌ ‌with‌ ‌Hestia,‌ ‌we‌ ‌wanted‌ ‌to‌ ‌create‌‌ something‌ ‌that‌ ‌combined‌ ‌all‌ ‌of‌ ‌these‌ ‌features‌‌into‌‌one‌‌convenient,‌‌easy-to-use‌‌application.‌‌We‌‌ decided‌‌that‌‌in‌‌Hestia,‌‌a‌‌user‌‌should‌‌be‌‌able‌‌to‌‌create‌‌and‌‌manage‌‌a‌‌household‌‌calendar,‌‌a‌‌to-do‌‌ list,‌‌budgets,‌‌recipes,‌‌meals,‌‌and‌‌grocery‌‌lists‌‌all‌‌in‌‌one‌‌single‌‌app.‌‌The‌‌goal‌‌of‌‌this‌‌project‌‌was‌‌ to‌‌create‌‌an‌‌app‌‌that‌‌would‌‌make‌‌home‌‌management‌‌much‌‌easier‌‌for‌‌any‌‌user.‌ ‌ Based‌‌on‌‌the‌‌idea‌‌we‌‌had‌‌for‌‌the‌‌Hestia‌‌application,‌‌we‌‌then‌‌made‌‌the‌‌pre-development‌‌ design‌‌decisions‌‌for‌‌it.‌‌For‌‌our‌‌team‌‌structure,‌‌we‌‌decided‌‌to‌‌have‌‌two‌‌backend‌‌developers‌‌and‌‌ three‌ ‌frontend‌ ‌developers,‌ ‌with‌ ‌two‌ ‌of‌ ‌these‌ ‌developers‌ ‌working‌ ‌on‌ ‌the‌ ‌frontend‌ ‌for‌ ‌the‌ ‌web‌‌ application‌ ‌and‌ ‌one‌ ‌of‌ ‌them‌ ‌working‌ ‌on‌ ‌the‌ ‌frontend‌ ‌for‌ ‌the‌ ‌mobile‌ ‌application.‌ ‌Then,‌ ‌we‌‌ decided‌ ‌that‌ ‌we‌ ‌would‌ ‌develop‌ ‌the‌ ‌application‌ ‌and‌ ‌organize‌ ‌our‌ ‌team’s‌ ‌communication‌‌ according‌‌to‌‌the‌‌agile‌‌methodology‌‌for‌‌development.‌‌As‌‌for‌‌our‌‌code’s‌‌structure,‌‌we‌‌decided‌‌that‌‌ ‌ 87‌ ‌ we‌ ‌would‌ ‌divide‌ ‌the‌ ‌application‌ ‌up‌ ‌into‌ ‌six‌ ‌separate‌ ‌components:‌ ‌the‌ ‌frontend‌ ‌of‌ ‌the‌ ‌web‌‌ application,‌ ‌the‌ ‌frontend‌ ‌of‌ ‌the‌ ‌mobile‌ ‌application,‌ ‌the‌ ‌Identity‌ ‌Server,‌ ‌the‌ ‌Identity‌ ‌server’s‌‌ database,‌ ‌the‌ ‌backend‌ ‌web‌ ‌API,‌ ‌and‌ ‌the‌ ‌main‌ ‌Hestia‌ ‌database.‌ ‌Both‌ ‌frontend‌ ‌portions‌ ‌of‌ ‌the‌‌ applications‌‌would‌‌work‌‌with‌‌the‌‌Identity‌‌server‌‌through‌‌redirects,‌‌and‌‌this‌‌Identity‌‌server‌‌would‌‌ directly‌ ‌communicate‌ ‌with‌ ‌its‌ ‌database‌ ‌to‌ ‌store‌ ‌user‌ ‌login‌ ‌information‌ ‌for‌ ‌Hestia.‌ ‌Then,‌ ‌the‌‌ Identity‌‌server‌‌and‌‌both‌‌frontend‌‌applications‌‌would‌‌communicate‌‌with‌‌the‌‌application‌‌backend‌‌ by‌‌sending‌‌requests‌‌to‌‌the‌‌API‌‌endpoints‌‌it‌‌established,‌‌which‌‌allow‌‌these‌‌components‌‌to‌‌request‌‌ operations‌ ‌get‌ ‌performed‌ ‌on‌ ‌the‌ ‌main‌ ‌Hestia‌ ‌database.‌ ‌Then,‌ ‌the‌ ‌backend‌ ‌web‌ ‌API‌ ‌would‌‌ directly‌ ‌communicate‌ ‌with‌ ‌the‌ ‌main‌ ‌Hestia‌ ‌database‌ ‌to‌ ‌perform‌ ‌these‌ ‌operations.‌ ‌All‌ ‌of‌ ‌these‌‌ components,‌ ‌except‌ ‌the‌ ‌frontend‌ ‌of‌ ‌the‌ ‌mobile‌ ‌application,‌ ‌would‌ ‌be‌ ‌deployed‌ ‌using‌ ‌the‌‌ Microsoft‌‌Azure‌‌service.‌‌Then,‌‌the‌‌mobile‌‌application‌‌frontend‌‌would‌‌be‌‌deployed‌‌by‌‌allowing‌‌a‌‌ user‌‌to‌‌download‌‌it‌‌on‌‌the‌‌Google‌‌Play‌‌Store‌‌or‌‌IOS‌‌App‌‌store‌‌once‌‌the‌‌application‌‌got‌‌released.‌‌ Lastly,‌ ‌for‌ ‌the‌ ‌code‌ ‌implementation‌ ‌decisions,‌ ‌we‌ ‌decided‌ ‌that‌ ‌the‌ ‌frontend‌ ‌of‌ ‌the‌ ‌web‌ application‌ ‌would‌ ‌use‌ ‌the‌ ‌Angular‌ ‌framework‌ ‌and‌ ‌Javascript‌ ‌programming‌ ‌language.‌ ‌The‌‌ frontend‌ ‌of‌ ‌the‌ ‌mobile‌ ‌application‌ ‌would‌ ‌use‌ ‌the‌ ‌NativeScript‌ ‌framework‌ ‌and‌ ‌the‌ ‌Javascript‌‌ programming‌ ‌language.‌ ‌The‌ ‌Identity‌ ‌Server‌ ‌would‌ ‌use‌ ‌the‌ ‌IdentityServer4‌ ‌framework‌ ‌and‌‌the‌‌ C#‌‌language.‌‌Then,‌‌the‌‌backend‌‌web‌‌API‌‌would‌‌use‌‌the‌‌.NET‌‌framework‌‌and‌‌the‌‌C#‌‌language.‌‌ Then,‌ ‌both‌ ‌of‌ ‌our‌ ‌databases‌ ‌would‌ ‌be‌ ‌SQL‌ ‌databases,‌ ‌and‌ ‌because‌ ‌we‌ ‌were‌ ‌using‌ ‌Microsoft‌‌ Azure‌ ‌services‌ ‌for‌‌deployment,‌‌we‌‌made‌‌them‌‌Microsoft‌‌SQL‌‌databases.‌‌Lastly,‌‌we‌‌decided‌‌to‌‌ use‌‌a‌‌code-first‌‌approach‌‌for‌‌the‌‌development‌‌of‌‌the‌‌Identity‌‌Server‌‌database‌‌and‌‌a‌‌database-first‌‌ approach‌ ‌for‌ ‌the‌ ‌development‌ ‌of‌ ‌the‌ ‌main‌ ‌Hestia‌ ‌database.‌ ‌These‌ ‌design‌ ‌decisions‌ ‌gave‌ ‌us‌ ‌a‌‌ foundation‌‌to‌‌start‌‌the‌‌development‌‌of‌‌Hestia.‌‌ ‌ ‌ 88‌ ‌ The‌‌development‌‌of‌‌Hestia‌‌took‌‌place‌‌over‌‌two‌‌semesters‌‌at‌‌the‌‌University‌‌of‌‌Utah‌‌in‌‌the‌‌ Spring‌ ‌and‌ ‌Fall‌ ‌of‌ ‌2021.‌ ‌In‌ ‌the‌ ‌first‌ ‌semester,‌ ‌we‌ ‌brainstormed‌ ‌ideas‌ ‌for‌‌the‌‌capstone‌‌project,‌‌ came‌ ‌up‌ ‌with‌ ‌the‌ ‌idea‌ ‌for‌ ‌Hestia,‌ ‌made‌ ‌the‌ ‌design‌ ‌decisions‌ ‌for‌ ‌the‌ ‌Hestia‌ ‌application,‌ ‌and‌‌ developed‌ ‌a‌ ‌proof‌ ‌of‌ ‌concept‌‌prototype‌‌for‌‌Hestia.‌‌Then,‌‌in‌‌the‌‌second‌‌semester,‌‌we‌‌continued‌‌ development‌ ‌work‌ ‌on‌ ‌the‌ ‌application‌ ‌and‌ ‌had‌ ‌an‌‌alpha,‌‌beta,‌‌and‌‌final‌‌project‌‌release.‌‌All‌‌this‌‌ work‌‌culminated‌‌in‌‌a‌‌presentation‌‌given‌‌on‌‌Dec.‌‌10,‌‌2021.‌‌ ‌ Over‌ ‌these‌ ‌two‌ ‌semesters‌ ‌of‌ ‌development,‌ ‌our‌ ‌team‌ ‌created‌ ‌a‌ ‌final‌ ‌application‌ ‌that‌‌ closely‌ ‌aligned‌ ‌with‌ ‌our‌ ‌original‌ ‌vision‌ ‌for‌ ‌Hestia.‌ ‌The‌ ‌final‌ ‌application‌ ‌contained‌ ‌login‌ ‌and‌‌ account‌ ‌creation,‌ ‌household‌‌management,‌‌dashboard,‌‌budgeting,‌‌to-do‌‌list,‌‌calendar,‌‌recipe‌‌and‌‌ meal‌ ‌planning,‌ ‌and‌ ‌grocery‌ ‌list‌ ‌features.‌ ‌The‌ ‌Identity‌ ‌Server‌ ‌we‌ ‌created‌ ‌handles‌ ‌user‌‌ authentication‌‌and‌‌account‌‌creation.‌‌Then,‌‌all‌‌the‌‌features‌‌worked‌‌by‌‌having‌‌the‌‌frontend‌‌of‌‌the‌‌ applications‌ ‌or‌ ‌the‌ ‌Identity‌ ‌Server‌ ‌make‌ ‌requests‌ ‌to‌ ‌the‌ ‌backend‌ ‌web‌ ‌API,‌ ‌telling‌ ‌it‌ ‌what‌‌ operations‌‌to‌‌perform‌‌on‌‌the‌‌main‌‌Hestia‌‌database‌‌depending‌‌on‌‌what‌‌the‌‌user‌‌was‌‌doing‌‌inside‌‌ the‌‌application.‌‌ ‌ Overall,‌‌looking‌‌retrospectively‌‌at‌‌the‌‌design‌‌decisions‌‌we‌‌made,‌‌I‌‌am‌‌very‌‌pleased‌‌with‌‌ the‌‌majority‌‌of‌‌them.‌‌In‌‌total,‌‌I‌‌would‌‌only‌‌change‌‌two‌‌decisions‌‌were‌‌we‌‌to‌‌go‌‌back‌‌in‌‌time‌‌and‌‌ make‌‌these‌‌design‌‌Decisions‌‌again.‌‌First,‌‌I‌‌would‌‌recommend‌‌having‌‌a‌‌frontend‌‌web‌‌application‌‌ developer,‌‌a‌‌frontend‌‌mobile‌‌developer,‌‌and‌‌a‌‌developer‌‌that‌‌works‌‌on‌‌both‌‌the‌‌frontend‌‌of‌‌web‌‌ and‌‌mobile‌‌applications,‌‌as‌‌opposed‌‌to‌‌the‌‌two‌‌frontend‌‌web‌‌developers‌‌and‌‌one‌‌frontend‌‌mobile‌‌ developer‌ ‌breakdown‌ ‌we‌ ‌used.‌ ‌Second,‌ ‌I‌ ‌would‌ ‌recommend‌ ‌against‌ ‌using‌ ‌the‌ ‌NativeScript‌‌ framework.‌ ‌Instead,‌ ‌I‌‌would‌‌recommend‌‌using‌‌the‌‌Xamarin‌‌framework‌‌for‌‌the‌‌mobile‌‌Android‌‌ application‌‌and‌‌the‌‌Swift‌‌framework‌‌for‌‌the‌‌IOS‌‌application.‌‌Other‌‌than‌‌these‌‌two‌‌decisions,‌‌all‌‌ ‌ 89‌ ‌ the‌‌other‌‌design‌‌decisions‌‌were‌‌perfect‌‌for‌‌the‌‌Hestia‌‌application.‌‌They‌‌made‌‌development‌‌work‌‌ on‌‌the‌‌application‌‌very‌‌smooth‌‌and‌‌allowed‌‌us‌‌to‌‌produce‌‌a‌‌great‌‌final‌‌product.‌ ‌ Currently,‌ ‌Hestia‌ ‌will‌ ‌not‌ ‌get‌ ‌released‌ ‌after‌ ‌this‌ ‌semester.‌ ‌Our‌ ‌team‌ ‌of‌ ‌developers‌ ‌is‌‌ pretty‌ ‌burnt‌ ‌out‌ ‌and‌ ‌will‌ ‌be‌ ‌starting‌ ‌work‌‌in‌‌the‌‌industry‌‌after‌‌this‌‌semester.‌‌Thus,‌‌we‌‌will‌‌not‌‌ have‌‌the‌‌time‌‌required‌‌to‌‌maintain‌‌and‌‌improve‌‌the‌‌application‌‌once‌‌we‌‌release‌‌it‌‌at‌‌this‌‌moment‌‌ in‌ ‌time.‌ ‌Therefore,‌ ‌we‌ ‌have‌ ‌decided‌‌that‌‌it‌‌would‌‌be‌‌best‌‌not‌‌to‌‌release‌‌Hestia‌‌right‌‌now‌‌since‌‌ any‌ ‌good‌‌application‌‌requires‌‌constant‌‌maintenance‌‌and‌‌improvement‌‌to‌‌stay‌‌relevant.‌‌Because‌‌ we‌‌could‌‌not‌‌provide‌‌this‌‌support‌‌we‌‌feel‌‌that‌‌releasing‌‌Hestia‌‌right‌‌now‌‌would‌‌make‌‌it‌‌doomed‌‌ to‌‌fail.‌‌However,‌‌we‌‌plan‌‌on‌‌continuing‌‌development‌‌work‌‌on‌‌Hestia‌‌sometime‌‌in‌‌the‌‌future‌‌and‌‌ releasing‌‌the‌‌application‌‌once‌‌this‌‌occurs.‌‌Additionally,‌‌this‌‌released‌‌version‌‌will‌‌be‌‌even‌‌better‌‌ than‌‌the‌‌current‌‌iteration‌‌of‌‌the‌‌Hestia‌‌application‌‌as‌‌we‌‌have‌‌a‌‌list‌‌of‌‌features‌‌we‌‌plan‌‌on‌‌adding‌‌ to‌‌Hestia‌‌when‌‌we‌‌start‌‌developing‌‌Hestia‌‌again.‌ ‌ Overall,‌‌my‌‌fellow‌‌team‌‌members‌‌and‌‌I‌‌are‌‌extremely‌‌happy‌‌with‌‌how‌‌Hestia‌‌turned‌‌out.‌‌ We‌‌created‌‌an‌‌application‌‌that‌‌aligned‌‌with‌‌the‌‌vision‌‌we‌‌had.‌‌I‌‌feel‌‌like‌‌anyone‌‌could‌‌use‌‌Hestia‌‌ to‌ ‌help‌‌better‌‌manage‌‌their‌‌home,‌‌and‌‌overall‌‌anyone‌‌would‌‌benefit‌‌from‌‌being‌‌a‌‌Hestia‌‌user.‌‌I‌‌ would‌‌like‌‌to‌‌end‌‌by‌‌thanking‌‌my‌‌fellow‌‌team‌‌members‌‌(Bridger,‌‌Liam,‌‌Pierce,‌‌and‌‌Thang)‌‌for‌‌ all‌‌the‌‌hard‌‌work‌‌they‌‌put‌‌in‌‌to‌‌develop‌‌this‌‌project.‌‌All‌‌of‌‌us‌‌were‌‌essential‌‌in‌‌the‌‌development‌‌ process,‌ ‌and‌ ‌removing‌ ‌any‌ ‌one‌ ‌of‌ ‌us‌ ‌from‌ ‌the‌‌time‌‌would‌‌have‌‌made‌‌the‌‌resulting‌‌application‌‌ much‌‌worse‌‌overall.‌‌Additionally,‌‌I‌‌would‌‌like‌‌to‌‌thank‌‌our‌‌professor‌‌for‌‌the‌‌class,‌‌Scott‌‌Brown,‌‌ who‌‌helped‌‌advise‌‌us‌‌and‌‌served‌‌as‌‌our‌‌manager‌‌during‌‌the‌‌project.‌‌He‌‌was‌‌great‌‌in‌‌making‌‌sure‌‌ our‌ ‌team‌ ‌stayed‌ ‌focused‌ ‌and‌ ‌on‌ ‌track‌ ‌and‌ ‌was‌ ‌extremely‌ ‌helpful‌ ‌during‌ ‌the‌ ‌entire‌ ‌process‌ ‌of‌‌ creating‌ ‌Hestia.‌ ‌Keep‌ ‌an‌ ‌eye‌ ‌out‌ ‌for‌‌the‌‌future‌‌release‌‌of‌‌the‌‌Hestia‌‌application,‌‌your‌‌one-stop‌‌ shop‌‌for‌‌all‌‌your‌‌home‌‌management‌‌needs.‌ ‌ ‌ 90‌ ‌ 9‌‌REFERENCES‌ ‌ Allen,‌‌B.,‌‌&‌‌Baier,‌‌D.‌‌(2020).‌W ‌ elcome‌‌to‌‌IdentityServer4‌‌(latest)‌.‌‌IdentityServer4.‌‌Retrieved‌‌ December‌‌2,‌‌2021,‌‌from‌‌https://identityserver4.readthedocs.io/en/latest/.‌‌ ‌ Angular.‌‌(n.d.).‌‌Retrieved‌‌December‌‌2,‌‌2021,‌‌from‌‌https://angular.io/.‌‌ ‌ Christensson,‌‌P.‌‌(2011,‌‌September‌‌23).‌P ‌ rogramming‌‌Language‌‌Definition‌.‌‌Retrieved‌‌2021,‌‌Dec‌‌ 1,‌‌from‌‌https://techterms.com/definition/programming_language.‌‌ ‌ Christensson,‌‌P.‌‌(2013,‌‌March‌‌7).‌F ‌ ramework‌‌Definition‌.‌‌Retrieved‌‌2021,‌‌Dec‌‌1,‌‌from‌‌ https://techterms.com/definition/framework‌‌ ‌ Create‌‌table‌‌(transact-SQL)‌.‌‌Microsoft‌‌Docs.‌‌(2021,‌‌September‌‌21).‌‌Retrieved‌‌December‌‌3,‌‌ 2021,‌‌from‌‌ https://docs.microsoft.com/en-us/sql/t-sql/statements/create-table-transact-sql?view=sql-s‌ erver-ver15.‌‌ ‌ Data‌‌types‌‌(transact-SQL)‌.‌‌Microsoft‌‌Docs.‌‌(2021,‌‌March‌‌19).‌‌Retrieved‌‌December‌‌3,‌‌2021,‌‌ from‌‌ https://docs.microsoft.com/en-us/sql/t-sql/data-types/data-types-transact-sql?view=sql-ser‌ ver-ver15.‌‌ ‌ DB-Engines‌‌Ranking‌.‌‌DB-ENGINES.‌‌(2021,‌‌December).‌‌Retrieved‌‌December‌‌1,‌‌2021,‌‌from‌‌ https://db-engines.com/en/ranking.‌‌ ‌ Foreign‌‌key‌‌(referential)‌‌constraints‌.‌‌IBM.‌‌(n.d.).‌‌Retrieved‌‌December‌‌3,‌‌2021,‌‌from‌‌ https://www.ibm.com/docs/en/db2/11.5?topic=constraints-foreign-key-referential.‌‌ ‌ Harvey,‌‌C.‌‌(2021,‌‌August‌‌14).‌A ‌ WS‌‌vs.‌‌Azure‌‌vs.‌‌Google‌‌Cloud:‌‌Top‌‌cloud‌‌providers‌‌2021‌.‌‌ Datamation.‌‌Retrieved‌‌November‌‌30,‌‌2021,‌‌from‌‌ https://www.datamation.com/cloud/aws-vs-azure-vs-google-cloud/.‌‌ ‌ ‌ 91‌ ‌ Hestia‌‌::‌‌Greek‌‌goddess‌‌of‌‌the‌‌hearth‌.‌‌Greek‌‌Mythology.‌‌(n.d.).‌‌Retrieved‌‌December‌‌1,‌‌2021,‌‌ from‌‌https://www.greekmythology.com/Olympians/Hestia/hestia.html.‌‌ ‌ Hughey,‌‌D.‌‌(2009).‌‌Waterfall‌‌method‌.‌‌umsl.‌‌Retrieved‌‌December‌‌1,‌‌2021,‌‌from‌‌ https://www.umsl.edu/~hugheyd/is6840/waterfall.html.‌‌ ‌ IBM‌‌Cloud‌‌Education.‌‌(2020,‌‌August‌‌19).‌W ‌ hat‌‌is‌‌an‌‌application‌‌programming‌‌interface‌‌(API)‌.‌‌ IBM.‌‌Retrieved‌‌November‌‌30,‌‌2021,‌‌from‌‌https://www.ibm.com/cloud/learn/api.‌‌ ‌ Jeremiah,‌‌J.‌‌(2019,‌‌February‌‌5).‌‌Survey:‌‌Is‌‌agile‌‌the‌‌new‌‌norm?‌‌‌TechBeacon.‌‌Retrieved‌‌ November‌‌30,‌‌2021,‌‌from‌‌ https://techbeacon.com/app-dev-testing/survey-agile-new-norm.‌‌ ‌ Lotz,‌‌M.‌‌(2018,‌‌July‌‌5).‌W ‌ aterfall‌‌vs.‌‌agile:‌‌Which‌‌methodology‌‌is‌‌right‌‌for‌‌your‌‌project?‌‌‌Segue‌‌ Technologies.‌‌Retrieved‌‌November‌‌30,‌‌2021,‌‌from‌‌ https://www.seguetech.com/waterfall-vs-agile-methodology/.‌‌ ‌ Makabee,‌‌H.‌‌(2012,‌‌February‌‌5).‌S‌ eparation‌‌of‌‌concerns‌.‌‌Effective‌‌Software‌‌Design.‌‌Retrieved‌‌ November‌‌30,‌‌2021,‌‌from‌‌ https://effectivesoftwaredesign.com/2012/02/05/separation-of-concerns/.‌‌ ‌ NativeScript.‌‌(n.d.).‌‌Retrieved‌‌December‌‌2,‌‌2021,‌‌from‌‌https://docs.nativescript.org/.‌‌ ‌ NoSQL‌‌vs‌‌SQL‌‌databases‌.‌‌MongoDB.‌‌(n.d.).‌‌Retrieved‌‌December‌‌1,‌‌2021,‌‌from‌‌ https://www.mongodb.com/nosql-explained/nosql-vs-sql.‌‌ ‌ Okeke,‌‌N.‌‌(2021).‌A ‌ gile‌‌Framework‌‌Diagram‌.‌‌TargetTrend.‌‌Retrieved‌‌December‌‌1,‌‌2021,‌‌from‌‌ https://targettrend.com/agile-methodology-meaning-advantages-disadvantages-more/.‌‌ ‌ Perepa,‌‌S.‌‌(n.d.).‌W ‌ hat‌‌is‌‌cloud‌‌hosting‌.‌‌IBM.‌‌Retrieved‌‌December‌‌13,‌‌2021,‌‌from‌‌ https://www.ibm.com/cloud/learn/what-is-cloud-hosting.‌‌ ‌ ‌ ‌ 92‌ ‌ Primary‌‌Keys‌.‌‌IBM.‌‌(n.d.).‌‌Retrieved‌‌December‌‌3,‌‌2021,‌‌from‌‌ https://www.ibm.com/docs/en/iodg/11.3?topic=reference-primary-keys.‌‌ ‌ Richardson,‌‌C.‌‌(n.d.).‌‌Microservices‌‌pattern:‌‌Monolithic‌‌Architecture‌‌Pattern‌.‌‌microservices.io.‌‌ Retrieved‌‌from‌‌https://microservices.io/patterns/monolithic.html.‌‌ ‌ Santos,‌‌J.‌‌M.‌‌D.‌‌(2021,‌‌August‌‌23).‌A ‌ gile‌‌vs.‌‌Waterfall:‌‌Software‌‌Development‌‌Methodologies‌.‌‌ project-managment.com.‌‌Retrieved‌‌November‌‌30,‌‌2021,‌‌from‌‌ https://project-management.com/agile-vs-waterfall/.‌‌ ‌ Stack‌‌Overflow‌‌Developer‌‌Survey‌‌2020‌.‌‌Stack‌‌Overflow.‌‌(n.d.).‌‌Retrieved‌‌November‌‌30,‌‌2021,‌‌ from‌‌ https://insights.stackoverflow.com/survey/2020#developer-profile-developer-type-all-resp‌ ondent.‌‌ ‌ U.S.‌‌Bureau‌‌of‌‌Labor‌‌Statistics.‌‌(2020).‌‌Average‌‌hours‌‌per‌‌day‌‌spent‌‌in‌‌selected‌‌household‌‌ activities‌.‌‌U.S.‌‌Bureau‌‌of‌‌Labor‌‌Statistics.‌‌Retrieved‌‌December‌‌1,‌‌2021,‌‌from‌‌ https://www.bls.gov/charts/american-time-use/activity-by-hldh.htm.‌‌ ‌ Wade.‌‌(2021,‌‌June‌‌26).‌C ‌ ode‌‌first‌‌VS‌‌database‌‌first‌‌VS‌‌model‌‌first‌‌-‌‌entityframework‌‌approaches‌‌ explained‌.‌‌.NET‌‌Core‌‌Tutorials.‌‌Retrieved‌‌December‌‌2,‌‌2021,‌‌from‌‌ https://dotnetcoretutorials.com/2021/06/26/code-first-vs-database-first-vs-model-first-enti‌ tyframework-approaches-explained/.‌‌ ‌ Wagner,‌‌B.‌‌(n.d.).‌L ‌ anguage-integrated‌‌query‌‌(LINQ)‌‌(C#)‌.‌‌Language-Integrated‌‌Query‌‌(LINQ)‌‌ (C#)‌‌|‌‌Microsoft‌‌Docs.‌‌Retrieved‌‌December‌‌13,‌‌2021,‌‌from‌‌ https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/.‌ ‌ ‌ ‌ 93‌ ‌ Wales,‌‌M.‌‌(2020,‌‌December‌‌8).‌F ‌ ront-end‌‌vs‌‌back-end‌‌vs‌‌full‌‌stack‌‌web‌‌developers‌.‌‌Udacity.‌‌ Retrieved‌‌November‌‌30,‌‌2021,‌‌from‌‌ https://www.udacity.com/blog/2020/12/front-end-vs-back-end-vs-full-stack-web-develop‌ ers.html‌ ‌ Wang,‌‌T.‌‌X.,‌‌&‌‌McLarty,‌‌M.‌‌(2021,‌‌April‌‌13).‌A ‌ pis‌‌aren't‌‌just‌‌for‌‌Tech‌‌Companies‌.‌‌Harvard‌‌ Business‌‌Review.‌‌Retrieved‌‌December‌‌7,‌‌2021,‌‌from‌‌ https://hbr.org/2021/04/apis-arent-just-for-tech-companies.‌‌ ‌ What‌‌is‌‌a‌‌database?‌‌‌Oracle.‌‌(n.d.).‌‌Retrieved‌‌November‌‌30,‌‌2021,‌‌from‌‌ https://www.oracle.com/database/what-is-database/.‌‌ ‌ What‌‌is‌‌Entity‌‌Relationship‌‌Diagram‌‌(ERD)‌.‌‌Visual‌‌Paradigm.‌‌(n.d.).‌‌Retrieved‌‌December‌‌2,‌‌ 2021,‌‌from‌‌ https://www.visual-paradigm.com/guide/data-modeling/what-is-entity-relationship-diagra‌ m/.‌‌ ‌ Wintemute,‌‌D.‌‌(2021,‌‌October‌‌11).‌1‌ 1‌‌Most‌‌Popular‌‌Web‌‌Frameworks‌.‌‌BestColleges.com.‌‌ Retrieved‌‌December‌‌1,‌‌2021,‌‌from‌‌ https://www.bestcolleges.com/bootcamps/guides/most-popular-web-frameworks/.‌‌ ‌ ‌ 94‌ ‌ 10‌‌Appendix‌ ‌ 10.1‌‌API‌‌Endpoints‌‌Spec‌ ‌ Type‌ ‌ Route‌ ‌ Request‌‌Body‌‌Parameters‌ ‌ Use‌ ‌ GET‌ ‌ /user/{username}‌ ‌ None‌ ‌ Retrieve‌‌a‌‌user’s‌‌information‌ ‌ POST‌ ‌ /user‌ ‌ userName,‌‌firstName,‌‌ lastName‌ ‌ Create‌‌a‌‌Hestia‌‌user‌ PUT‌ ‌ /user/{userID}‌ ‌ firstName,‌‌lastName‌ ‌ Modify‌‌a‌‌user’s‌‌information‌ ‌ PUT‌ ‌ /user/{userID}/leave-household‌ ‌ None‌ ‌ Remove‌‌a‌‌user‌‌from‌‌their‌‌ existing‌‌household‌ ‌ DELETE‌ ‌ /user/{userID}‌ ‌ None‌ ‌ Delete‌‌a‌‌Hestia‌‌user‌ GET‌ ‌ /household/{householdID}/me‌ mbers‌ ‌ None‌ ‌ Retrieve‌‌the‌‌information‌‌for‌‌all‌‌ members‌‌in‌‌the‌‌household‌ ‌ POST‌ ‌ /household/{householdName}/‌ {username}‌ ‌ None‌ ‌ Create‌‌a‌‌new‌‌household‌‌and‌‌ add‌‌the‌‌user‌‌with‌‌the‌‌specified‌‌ username‌‌to‌‌the‌‌household‌ ‌ GET‌ ‌ /notification/invitations/{userId‌ }‌ ‌ None‌ ‌ Retrieve‌‌all‌‌the‌‌household‌‌ invitations‌‌for‌‌a‌‌user‌ ‌ POST‌ ‌ /notification‌ ‌ Type,‌‌creatorID,‌‌ assigneeUsername‌ ‌ Invite‌‌a‌‌pre-existing‌‌user‌‌to‌‌the‌‌ current‌‌users‌‌household‌ ‌ POST‌ ‌ /notification/invitation/{notific‌ ationID}/accept‌ ‌ None‌ ‌ Accept‌‌an‌‌invitation,‌‌add‌‌the‌‌ user‌‌to‌‌the‌‌household‌‌they‌‌were‌‌ invited‌‌to‌‌then‌‌delete‌‌the‌‌ invitation‌ ‌ DELETE‌ ‌ /notification/{notificationID}‌ ‌ None‌ ‌ Reject‌‌an‌‌invitation,‌‌delete‌‌the‌‌ household‌‌invitation‌ ‌ GET‌ ‌ /budgets/{userID}‌ ‌ None‌ ‌ Retrieve‌‌a‌‌user’s‌‌budgets‌ ‌ POST‌ ‌ /budget‌ ‌ userID,‌‌name,‌‌ ‌ startDate,‌‌endDate‌ ‌ Create‌‌a‌‌budget‌ ‌ PUT‌ ‌ /budget/{budgetID}‌ ‌ name,‌‌startDate,‌‌ ‌ endDate‌ ‌ Modify‌‌an‌‌existing‌‌budget‌ ‌ DELETE‌ ‌ /budget/{budgetID}‌ ‌ None‌ ‌ Delete‌‌an‌‌existing‌‌budget‌ ‌ POST‌ ‌ /budgetaccess‌ ‌ userId,‌ ‌ budgetId‌ ‌ Grant‌‌a‌‌user‌‌access‌‌to‌‌a‌‌budget‌ ‌ DELETE‌ ‌ /budgetaccess‌ ‌ userId,‌ ‌ budgetId‌ ‌ Remove‌‌a‌‌user’s‌‌access‌‌to‌‌a‌‌ budget‌ ‌ ‌ 95‌ ‌ POST‌ ‌ PUT‌ ‌ /budgetcategory‌ ‌ budgetId‌ ‌ budgetCategoryName,‌‌color,‌‌ idealAmount‌ ‌ Create‌‌a‌‌budget‌‌category‌‌to‌‌ categorize‌‌expenses‌ ‌ /budgetcategory/{categoryID}‌ ‌ budgetCategoryName,‌‌color,‌‌ idealAmount‌ ‌ Modify‌‌an‌‌existing‌‌budget‌‌ category‌ ‌ DELETE‌ ‌ /budgetcategory/{categoryID}‌ ‌ None‌ ‌ Delete‌‌an‌‌existing‌‌budget‌‌ category‌ ‌ POST‌ ‌ /income‌ ‌ userId,‌‌budgetId,‌‌amount,‌‌ name‌ ‌ Create‌‌an‌‌income‌‌within‌‌a‌‌ budget‌ ‌ PUT‌ ‌ /income/{incomeID}‌ ‌ amount,‌‌name‌ ‌ Modify‌‌an‌‌existing‌‌income‌‌ within‌‌a‌‌budget‌ ‌ DELETE‌ ‌ /income/{incomeID}‌ ‌ None‌ ‌ Delete‌‌an‌‌existing‌‌income‌‌ within‌‌a‌‌budget‌ ‌ POST‌ ‌ /expense‌ ‌ budgetCategoryId,‌‌name,‌‌ amount,‌‌userId‌ Create‌‌an‌‌expense‌‌within‌‌a‌‌ budget‌‌category‌ ‌ PUT‌ ‌ /expense/{expenseID}‌ ‌ budgetCategoryId,‌‌name,‌‌ amount‌ ‌ Modify‌‌an‌‌existing‌‌expense‌‌ within‌‌a‌‌budget‌ ‌ DELETE‌ ‌ /expense/{expenseID}‌ ‌ None‌ ‌ Delete‌‌an‌‌existing‌‌expense‌‌ within‌‌a‌‌budget‌ ‌ GET‌ ‌ /tasks/{householdId}‌ ‌ None‌ ‌ Retrieve‌‌all‌‌the‌‌To-dos‌‌(tasks)‌‌ for‌‌a‌‌household‌ ‌ POST‌ ‌ /tasks‌ ‌ householdId,‌‌description‌ ‌ Create‌‌a‌‌household‌‌to-do‌‌(task)‌ ‌ PUT‌ ‌ /tasks‌ ‌ taskId,‌‌description‌ ‌ Modify‌‌an‌‌existing‌‌to-do‌‌(task)‌ ‌ PUT‌ ‌ /tasks/{taskId}/update/complet‌ ed‌ ‌ None‌ ‌ Update‌‌a‌‌to-do’s‌‌(tasks’s)‌‌ completion‌‌status,‌‌if‌‌it‌‌was‌‌ previously‌‌incomplete‌‌change‌‌it‌‌ to‌‌complete‌‌and‌‌vise‌‌versa‌ ‌ DELETE‌ ‌ /tasks/{taskId}‌ ‌ None‌ ‌ Delete‌‌an‌‌existing‌‌to-do‌‌(task)‌ ‌ GET‌ ‌ /event/{userID}/{householdID‌ }‌ ‌ None‌ ‌ Retrieves‌‌the‌‌events‌‌for‌‌all‌‌the‌‌ users‌‌household‌‌members,‌‌ including‌‌themselves‌ ‌ POST‌ ‌ /event‌ ‌ assignees,‌‌householdId,‌‌ creatorId,‌‌start,‌‌end,‌‌title,‌‌ description,‌‌color,‌‌allDay‌ ‌ Create‌‌a‌‌calendar‌‌event‌‌and‌‌ include‌‌users‌‌in‌‌the‌‌calendar‌‌ event‌‌getting‌‌created‌ ‌ PUT‌ ‌ /event‌ ‌ assignees,‌‌start,‌‌end,‌‌title,‌‌ description,‌‌color,‌‌allDay‌ ‌ Modify‌‌an‌‌existing‌‌calendar‌‌ event‌‌and‌‌change‌‌what‌‌users‌‌ are‌‌included‌‌in‌‌the‌‌event‌ ‌ DELETE‌ ‌ /event‌ ‌ None‌ ‌ Delete‌‌an‌‌existing‌‌calendar‌‌ ‌ 96‌ ‌ event‌ ‌ GET‌ ‌ /recipes/{householdId}‌ ‌ None‌ ‌ Retrieve‌‌all‌‌recipes‌‌for‌‌a‌‌ household‌ ‌ POST‌ ‌ /recipes‌ ‌ recipeName,‌‌instructions,‌‌ householdId,‌‌Ingredients‌ ‌ Create‌‌a‌‌recipe‌‌for‌‌a‌‌household‌ ‌ PUT‌ ‌ /recipes‌ ‌ reipeId,‌‌recipeName,‌‌ instructions‌ ‌ Modify‌‌an‌‌existing‌‌household‌‌ recipe‌ ‌ DELETE‌ ‌ /recipes‌ ‌ None‌ ‌ Delete‌‌an‌‌existing‌‌household‌‌ recipe‌ ‌ POST‌ ‌ /ingredients‌ ‌ recipeId,‌‌amount,‌‌ unitOfMeasurement,‌‌ foodName‌ ‌ Add‌‌an‌‌ingredient‌‌to‌‌an‌‌existing‌‌ recipe‌ ‌ PUT‌ ‌ /ingredients‌ ‌ recipeIngredientsId,‌‌amount,‌‌ foodName,‌‌ unitOfMeasurement‌ ‌ Modify‌‌an‌‌existing‌‌recipe‌‌ ingredient‌ ‌ DELETE‌ ‌ /ingredients‌ ‌ None‌ ‌ Delete‌‌an‌‌existing‌‌recipe‌‌ ingredient‌ ‌ GET‌ ‌ /meals/{householdId}‌ ‌ None‌ ‌ Retrieve‌‌all‌‌scheduled‌‌meals‌‌for‌‌ a‌‌household‌ ‌ POST‌ ‌ /meals‌ ‌ recipeId,‌‌scheduledDate,‌‌ mealType,‌‌householdId,‌‌ multiplyRecipe,‌‌ ‌ Schedule‌‌a‌‌household‌‌recipe‌‌for‌‌ a‌‌specific‌‌day‌‌making‌‌it‌‌a‌‌meal‌ ‌ PUT‌ ‌ /meals‌ ‌ mealId,‌‌scheduledDate,‌‌ mealType,‌‌multiplyRecipe‌ ‌ Modify‌‌an‌‌existing‌‌meal‌ ‌ DELETE‌ ‌ /meals‌ ‌ None‌ ‌ Delete‌‌an‌‌existing‌‌meal‌ ‌ GET‌ ‌ /grocerylist/{householdId}‌ ‌ None‌ ‌ Get‌‌a‌‌household’s‌‌grocery‌‌list‌ ‌ POST‌ ‌ /grocerylist/item‌ ‌ householdId,‌‌name,‌‌ createdBy,‌‌quantity,‌‌ unitOfMeasurement‌ ‌ Add‌‌an‌‌item‌‌to‌‌a‌‌household’s‌‌ grocery‌‌list,‌‌automatically‌‌ combining‌‌items‌‌if‌‌necessary‌ ‌ PUT‌ ‌ /grocerylist/item/{itemId}‌ ‌ name,‌‌quantity,‌‌ unitOfMeasurement‌ ‌ Modify‌‌an‌‌existing‌‌grocery‌‌list‌‌ item‌ ‌ DELETE‌ ‌ /grocerylist/item/{itemId}‌ ‌ None‌ ‌ Delete‌‌and‌‌existing‌‌grocery‌‌list‌‌ item‌ ‌ POST‌ ‌ /grocerylist/{householdId}/gen‌ erate/{startDate}/{endDate}/{u‌ serId}‌ ‌ None‌ ‌ Automatically‌‌delete‌‌all‌‌ previously‌‌generated‌‌grocery‌‌ list‌‌items‌‌and‌‌generate‌‌new‌‌ items‌‌for‌‌the‌‌household’s‌‌ grocery‌‌list‌‌based‌‌on‌‌the‌‌meals‌‌ scheduled‌‌between‌‌and‌‌ ‌ 97‌ ‌ included‌‌the‌‌startDate‌‌and‌‌ endDate‌ ‌ DELETE‌ ‌ /grocerylist/{householdId}‌ ‌ None‌ ‌ Remove‌‌all‌‌items‌‌from‌‌a‌‌ household’s‌‌grocery‌‌list‌ ‌ GET‌ ‌ /todos/{userID}‌ ‌ None‌ ‌ Not‌‌currently‌‌Used‌ ‌ Retrieve‌‌a‌‌user’s‌‌to-dos‌ ‌ POST‌ ‌ /todo‌ ‌ userID,‌‌name,‌‌description,‌‌ everyoneCompletes,‌‌ accomplishBy‌ ‌ Not‌‌currently‌‌Used‌ ‌ Create‌‌a‌‌new‌‌to-do‌‌item‌ ‌ PUT‌ ‌ /todo/{todoID}‌ ‌ name,‌‌description,‌‌ accomplishBy‌ ‌ Not‌‌currently‌‌Used‌ ‌ Modify‌‌an‌‌existing‌‌to-do‌ ‌ DELETE‌ ‌ /todo/{todoID}‌ ‌ None‌ ‌ Not‌‌currently‌‌Used‌ ‌ Delete‌‌an‌‌existing‌‌to-do‌ ‌ GET‌ ‌ /todocategories/{userID}‌ ‌ None‌ ‌ Not‌‌currently‌‌Used‌ ‌ Retrieve‌‌a‌‌user’s‌‌to-do‌‌ categories‌ ‌ POST‌ ‌ /todocategory‌ ‌ userID,‌‌name,‌‌color‌ ‌ Not‌‌currently‌‌Used‌ ‌ Create‌‌a‌‌to-do‌‌category‌‌for‌‌a‌‌ user‌ ‌ PUT‌ ‌ /todocategory/{categoryID}‌ ‌ name,‌‌color‌ ‌ Not‌‌currently‌‌Used‌ ‌ Modify‌‌an‌‌existing‌‌to-do‌‌ category‌ ‌ DELETE‌ ‌ /todocategory/{categoryID}‌ ‌ None‌ ‌ Not‌‌currently‌‌Used‌ ‌ Delete‌‌an‌‌existing‌‌to-do‌‌ category‌ ‌ POST‌ ‌ /todoassignment‌ ‌ userID,‌‌todoID,‌‌categoryID,‌‌ everyoneCompletes‌ ‌ Not‌‌currently‌‌Used‌ ‌ Assign‌‌a‌‌to-do‌‌to‌‌a‌‌specific‌‌user‌ ‌ PUT‌ ‌ /todoassignment/{assignmentI‌ D}‌ ‌ categoryID‌ ‌ Not‌‌currently‌‌Used‌ ‌ Switch‌‌an‌‌existing‌‌to-do‌‌ assignment’s‌‌category‌ ‌ PUT‌ ‌ /completetodo/{assignmentID}‌ ‌ None‌ ‌ Not‌‌currently‌‌Used‌ ‌ Modify‌‌a‌‌to-do’s‌‌completion‌‌ status‌‌to‌‌the‌‌opposite‌‌value,‌‌if‌‌it‌‌ was‌‌incomplete‌‌change‌‌it‌‌to‌‌ complete‌‌or‌‌vise‌‌versa‌ ‌ DELETE‌ ‌ /todoassignment‌ ‌ None‌ ‌ Not‌‌currently‌‌Used‌ ‌ Remove‌‌a‌‌to-do‌‌assignment‌‌for‌‌ a‌‌user.‌ ‌ ‌ ‌ ‌ 98‌ ‌ 10.2‌‌Original‌‌Hestia‌‌Design‌‌Document‌ ‌ Hestia‌ ‌ Family‌‌Management‌‌System‌ ‌ ‌ Team‌‌Homely‌ ‌ Pierce‌‌Bringhurst,‌‌Michael‌‌Linnebach,‌‌Thang‌‌Nguyen,‌‌Bridger‌‌Peterson,‌‌Liam‌‌Zhou‌ ‌ 4/7/2021‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ Table‌‌of‌‌Contents‌ ‌ 1.‌‌Executive‌‌Summary…………………………………………....……………………………….1‌ ‌ 2.‌‌Background‌‌and‌‌Technical‌‌Requirements……………………….....…......………………….2-5‌ ‌ 3.‌‌Requirements‌‌Analysis……………………………………...……….….…..….….….….....5-11‌ ‌ 4.‌‌Software‌‌Engineering‌‌Tools‌‌and‌‌Techniques…………….….….………………………….11-12‌ 5.‌‌Timeline…………………...……………………………………….….….………………..12-15‌ ‌ 6.‌‌Appendix‌‌A:‌‌UI‌‌Sketches………………………...……………………...……..………….16-18‌ ‌ 7.‌‌Appendix‌‌B:‌‌Use‌‌Cases……………...………………………………..….………………..19-20‌ ‌ 99‌ ‌ 1.‌‌Executive‌‌Summary‌ ‌ Hestia‌ ‌is‌ ‌an‌ ‌all-inclusive,‌ ‌multi-functional‌ ‌household‌ ‌and‌ ‌life‌ ‌management‌ ‌system.‌‌ Named‌ ‌after‌ ‌the‌ ‌Greek‌ ‌Goddess‌ ‌of‌ ‌hearth‌ ‌and‌ ‌home,‌ ‌Hestia‌ ‌will‌ ‌be‌ ‌your‌ ‌most‌ ‌versatile‌ ‌and‌‌ reliable‌ ‌tool‌ ‌as‌ ‌you‌ ‌organize‌ ‌and‌ ‌grow‌ ‌the‌ ‌home‌ ‌you’ve‌ ‌always‌ ‌wanted.‌ ‌Whether‌ ‌you‌ ‌live‌‌on‌‌ your‌ ‌own,‌ ‌with‌‌roommates,‌‌or‌‌have‌‌a‌‌handful‌‌of‌‌kids,‌‌Hestia‌‌will‌‌help‌‌you‌‌take‌‌charge‌‌of‌‌your‌‌ life.‌ ‌ There‌ ‌are‌ ‌many‌ ‌different‌‌household‌‌management,‌‌family‌‌calendar,‌‌budgeting,‌‌and‌‌to‌‌do‌‌ list‌ ‌apps‌ ‌on‌ ‌the‌ ‌market‌ ‌today.‌ ‌While‌ ‌many‌ ‌of‌ ‌these‌ ‌apps‌ ‌are‌ ‌useful,‌ ‌the‌ ‌problem‌ ‌is‌‌that‌‌many‌‌ apps‌‌are‌‌required‌‌to‌‌completely‌‌organize‌‌and‌‌structure‌‌the‌‌various‌‌aspects‌‌of‌‌your‌‌schedules‌‌and‌‌ to‌‌do’s‌‌coherently.‌‌The‌‌purpose‌‌of‌‌Hestia‌‌is‌‌to‌‌combine‌‌all‌‌the‌‌apps‌‌and‌‌tools‌‌you‌‌currently‌‌use‌‌ to‌‌thrive‌‌in‌‌a‌‌modern‌‌world‌‌into‌‌a‌‌single‌‌platform‌‌that‌‌is‌‌functional,‌‌flexible,‌‌and‌‌suited‌‌to‌‌all‌‌of‌‌ your‌‌needs.‌‌ Hestia‌‌is‌‌designed‌‌to‌‌dynamically‌‌allow‌‌for‌‌various‌‌household‌‌situations.‌‌You‌‌don’t‌‌need‌‌ to‌ ‌have‌ ‌a‌ ‌family‌ ‌in‌ ‌order‌ ‌for‌ ‌Hestia‌ ‌to‌ ‌work,‌ ‌you‌ ‌don’t‌ ‌even‌ ‌need‌ ‌to‌ ‌live‌ ‌with‌ ‌other‌ ‌people.‌‌ Hestia‌‌is‌‌easily‌‌adjustable‌‌to‌‌work‌‌for‌‌any‌‌kind‌‌of‌‌family‌‌you‌‌have.‌‌Hestia‌‌will‌‌allow‌‌the‌‌user‌‌to‌‌ manage‌ ‌shared‌ ‌and‌ ‌individual‌ ‌calendars,‌ ‌create‌ ‌and‌ ‌manage‌ ‌to‌ ‌do‌ ‌lists‌ ‌and‌ ‌projects,‌ ‌make‌‌ assignments‌ ‌to‌ ‌those‌ ‌in‌ ‌your‌ ‌household,‌ ‌and‌ ‌even‌ ‌walk‌ ‌you‌ ‌through‌ ‌a‌ ‌comprehensive‌ ‌weekly‌‌ planning‌‌process‌‌so‌‌that‌‌you’re‌‌always‌‌prepared‌‌for‌‌what‌‌lies‌‌ahead.‌‌ ‌ You‌ ‌will‌‌also‌‌be‌‌able‌‌to‌‌manage‌‌recipes,‌‌meal‌‌planning,‌‌and‌‌grocery‌‌lists‌‌within‌‌Hestia,‌‌ as‌‌well‌‌as‌‌your‌‌budget,‌‌which‌‌can‌‌be‌‌shared‌‌as‌‌a‌‌household‌‌or‌‌used‌‌individually‌‌per‌‌user.‌‌Hestia‌‌ will‌ ‌help‌ ‌you‌ ‌maintain‌ ‌a‌ ‌clean,‌ ‌comfortable‌‌home‌‌by‌‌offering‌‌suggestions‌‌on‌‌the‌‌best‌‌cleaning‌‌ and‌‌home‌‌maintenance‌‌schedule‌‌for‌‌your‌‌or‌‌your‌‌family’s‌‌individual‌‌living‌‌situation.‌‌Hestia‌‌will‌‌ even‌ ‌help‌ ‌you‌ ‌set‌ ‌SMART‌ ‌goals‌ ‌and‌ ‌track‌ ‌habits‌ ‌and‌ ‌routines‌ ‌as‌ ‌you‌ ‌work‌ ‌to‌ ‌create‌‌and‌‌live‌‌ your‌ ‌best‌ ‌life.‌ ‌With‌ ‌so‌ ‌many‌ ‌features,‌ ‌Hestia‌ ‌will‌ ‌give‌‌you‌‌the‌‌comfort‌‌of‌‌feeling‌‌in‌‌charge‌‌of‌‌ your‌ ‌life‌ ‌and‌ ‌will‌‌leave‌‌you‌‌with‌‌time‌‌to‌‌do‌‌what‌‌you‌‌want‌‌to‌‌do‌‌without‌‌worrying‌‌about‌‌what‌‌ you‌‌have‌‌to‌‌do.‌ ‌ ‌ ‌ ‌ ‌ ‌ 100‌ ‌ 2.‌‌Background‌‌and‌‌Technical‌‌Requirements‌ ‌ Idea‌‌Space‌ ‌ Most‌‌family‌‌management/organizer‌‌apps‌‌on‌‌the‌‌market‌‌don’t‌‌have‌‌the‌‌budgeting‌‌feature‌‌ integrated‌ ‌within‌ ‌them‌ ‌and‌ ‌no‌ ‌interconnection‌ ‌between‌ ‌features.‌ ‌Since‌ ‌a‌ ‌family's‌ ‌budget‌ ‌is‌‌an‌‌ important‌ ‌aspect‌‌and‌‌dictates‌‌how‌‌the‌‌family‌‌spending‌‌lifestyle‌‌will‌‌be,‌‌we‌‌believe‌‌the‌‌solution‌‌ that‌‌we‌‌provide‌‌will‌‌fill‌‌in‌‌this‌‌missing‌‌gap.‌‌Hence,‌‌it‌‌will‌‌solve‌‌the‌‌family‌‌management‌‌problem‌‌ better‌‌and‌‌with‌‌ease.‌ ‌ As‌ ‌mentioned‌ ‌the‌ ‌main‌ ‌thing‌ ‌that‌ ‌sets‌ ‌our‌ ‌application‌ ‌apart‌ ‌from‌ ‌other‌ ‌family‌‌ management‌ ‌applications‌ ‌is‌ ‌the‌ ‌budgeting‌ ‌feature‌ ‌while‌ ‌still‌ ‌remaining‌ ‌family‌ ‌oriented.‌ ‌Our‌‌ budgeting‌ ‌feature‌ ‌will‌ ‌be‌ ‌fairly‌ ‌simple‌ ‌and‌ ‌will‌ ‌rely‌ ‌on‌ ‌user‌ ‌input‌ ‌for‌ ‌the‌ ‌budget‌ ‌instead‌ ‌of‌‌ connecting‌ ‌to‌ ‌a‌ ‌user’s‌ ‌bank‌ ‌account‌ ‌mainly‌ ‌due‌ ‌to‌ ‌security‌ ‌concerns.‌ ‌Then,‌ ‌to‌ ‌stay‌ ‌family‌‌ oriented‌‌every‌‌user‌‌will‌‌be‌‌a‌‌part‌‌of‌‌a‌‌family‌‌(even‌‌if‌‌it’s‌‌a‌‌family‌‌of‌‌1)‌‌and‌‌each‌‌family‌‌will‌‌have‌‌ admins‌ ‌who‌ ‌have‌ ‌more‌ ‌control‌ ‌on‌ ‌what‌ ‌they‌ ‌can‌ ‌do‌ ‌in‌ ‌the‌ ‌application.‌ ‌For‌‌example,‌‌with‌‌the‌‌ calendar‌‌feature‌‌each‌‌user‌‌will‌‌have‌‌their‌‌own‌‌separate‌‌calendar‌‌and‌‌they‌‌can‌‌add‌‌events‌‌to‌‌their‌‌ own‌‌calendar‌‌but‌‌an‌‌admin‌‌can‌‌add‌‌“family”‌‌events‌‌which‌‌will‌‌show‌‌up‌‌on‌‌everyone’s‌‌calendar‌‌ and‌‌they‌‌can‌‌also‌‌assign‌‌events‌‌to‌‌specific‌‌users.‌‌For‌‌example‌‌a‌‌parent‌‌could‌‌add‌‌a‌‌childs‌‌piano‌‌ lessons‌‌to‌‌their‌‌calendar.‌‌All‌‌features‌‌will‌‌have‌‌a‌‌similar‌‌structure‌‌to‌‌ensure‌‌family‌‌connectedness‌‌ while‌ ‌ensuring‌ ‌that‌ ‌it‌ ‌is‌ ‌still‌ ‌valuable‌ ‌for‌ ‌each‌ ‌individual‌ ‌user‌ ‌as‌ ‌well.‌ ‌Furthermore,‌‌an‌‌admin‌‌ could‌‌see‌‌each‌‌member‌‌of‌‌the‌‌families‌‌schedule,‌‌todo‌‌list,‌‌and‌‌budget.‌‌Another‌‌thing‌‌that‌‌sets‌‌our‌‌ app‌ ‌apart‌ ‌is‌ ‌the‌ ‌meal‌ ‌planning‌ ‌feature‌ ‌which‌ ‌will‌ ‌allow‌ ‌families‌ ‌to‌ ‌develop‌ ‌their‌ ‌own‌‌“recipe‌‌ book”‌ ‌and‌ ‌they‌ ‌can‌ ‌schedule‌ ‌family‌ ‌meals‌ ‌on‌ ‌specific‌ ‌days.‌ ‌Then,‌ ‌a‌ ‌button‌ ‌on‌ ‌the‌ ‌app‌ ‌will‌‌ generate‌‌the‌‌printable‌‌shopping‌‌list‌‌for‌‌the‌‌week‌‌based‌‌on‌‌the‌‌meals‌‌that‌‌have‌‌been‌‌planned.‌ ‌ ‌ Tech‌‌Stack‌ ‌ I. Angular‌ ‌ We‌ ‌chose‌ ‌Angular‌ ‌because‌ ‌it's‌ ‌a‌ ‌powerful‌ ‌framework‌ ‌to‌ ‌create‌‌an‌‌efficient‌‌single-page‌‌ web‌ ‌app.‌ ‌It‌ ‌solves‌ ‌a‌ ‌lot‌ ‌of‌ ‌problems‌ ‌in‌ ‌writing‌ ‌a‌ ‌single-page‌ ‌web‌ ‌app‌ ‌with‌ ‌Vanilla‌‌ JavaScript.‌‌In‌‌addition,‌‌both‌‌Pierce‌‌and‌‌Liam‌‌have‌‌previous‌‌experience‌‌in‌‌Angular.‌ ‌ ‌ 101‌ ‌ II. NativeScript‌ ‌ NativeScript‌‌allows‌‌us‌‌to‌‌write‌‌cross-platform‌‌applications‌‌using‌‌JavaScript,‌‌so‌‌we‌‌don't‌‌ need‌‌to‌‌put‌‌extra‌‌efforts‌‌in‌‌learning‌‌native‌‌mobile‌‌development.‌‌In‌‌addition,‌‌NativeScript‌‌ is‌‌well‌‌integrated‌‌with‌‌Angular,‌‌which‌‌enables‌‌the‌‌web‌‌app‌‌and‌‌mobile‌‌app‌‌to‌‌share‌‌one‌‌ code‌‌base.‌ ‌ III. IdentityServer4‌ ‌ We‌ ‌chose‌ ‌to‌ ‌use‌ ‌the‌ ‌IdentityServer4‌ ‌framework‌ ‌to‌ ‌establish‌‌an‌‌Identity‌‌Provider‌‌server‌‌ because‌ ‌the‌ ‌protocol‌ ‌it‌ ‌implements,‌ ‌OpenID,‌ ‌is‌ ‌the‌ ‌latest‌ ‌technology‌ ‌and‌ ‌will‌ ‌provide‌‌ enhanced‌ ‌security‌ ‌over‌ ‌just‌ ‌using‌‌something‌‌like‌‌ASP.NET‌‌Identity‌‌in‌‌conjunction‌‌with‌‌ our‌ ‌API‌ ‌server.‌ ‌Furthermore,‌ ‌it‌ ‌provides‌ ‌a‌ ‌separation‌ ‌of‌ ‌concerns:‌ ‌user‌ ‌credentials‌ ‌and‌‌ CRUD‌ ‌for‌ ‌user‌ ‌credentials‌ ‌are‌ ‌all‌ ‌found‌ ‌in‌ ‌one‌ ‌place,‌‌and‌‌if‌‌we‌‌were‌‌to‌‌create‌‌another‌‌ application,‌ ‌the‌ ‌said‌ ‌application‌ ‌could‌ ‌also‌ ‌use‌ ‌this‌ ‌Identity‌ ‌Provider‌‌for‌‌authentication‌‌ and‌ ‌authorization‌ ‌services.‌ ‌Lastly,‌ ‌although‌ ‌this‌ ‌has‌‌been‌‌the‌‌most‌‌time-consuming‌‌and‌‌ high-tech‌‌route‌‌we‌‌could‌‌have‌‌taken‌‌for‌‌user‌‌authentication,‌‌establishing‌‌a‌‌Hestia‌‌Identity‌‌ Server‌ ‌will‌ ‌give‌ ‌our‌ ‌app‌ ‌a‌ ‌professional‌ ‌appeal‌ ‌and‌ ‌provide‌ ‌our‌ ‌team‌ ‌with‌ ‌a‌ ‌valuable‌‌ learning‌‌experience.‌ ‌ IV. RESTful‌‌API‌‌with‌‌ASP‌‌.NET‌ ‌ We‌ ‌chose‌ ‌to‌ ‌develop‌ ‌a‌ ‌RESTful‌ ‌API‌ ‌for‌ ‌our‌‌backend‌‌because‌‌this‌‌allowed‌‌us‌‌to‌‌create‌‌ one‌ ‌common‌ ‌backend‌ ‌that‌‌both‌‌our‌‌web‌‌application‌‌and‌‌mobile‌‌application‌‌could‌‌make‌‌ use‌ ‌of‌ ‌through‌ ‌AJAX‌ ‌requests.‌ ‌This‌ ‌also‌ ‌meant‌ ‌that‌ ‌backend‌ ‌changes‌‌would‌‌not‌‌affect‌‌ the‌‌frontend‌‌web‌‌and‌‌mobile‌‌applications‌‌unless‌‌the‌‌API‌‌endpoints‌‌were‌‌modified‌‌which‌‌ promotes‌ ‌separation‌ ‌of‌ ‌concerns.‌ ‌To‌ ‌implement‌ ‌our‌ ‌RESTful‌ ‌API‌ ‌are‌ ‌using‌ ‌the‌ ‌ASP‌‌ .NET‌‌Framework‌‌meaning‌‌are‌‌C#‌‌for‌‌coding‌‌purposes.‌‌We‌‌chose‌‌this‌‌framework‌‌because‌‌ it‌‌has‌‌direct‌‌support‌‌for‌‌developing‌‌RESTful‌‌APIs‌‌and‌‌both‌‌of‌‌our‌‌backend‌‌designers‌‌are‌‌ very‌‌comfortable‌‌with‌‌the‌‌C#‌‌language.‌‌ ‌ ‌ 102‌ ‌ V. Azure‌ ‌ Since‌ ‌both‌ ‌Azure‌ ‌and‌‌ASP‌‌.NET‌‌are‌‌products‌‌by‌‌Microsoft.‌‌Azure‌‌has‌‌the‌‌best‌‌support‌‌ for‌ ‌ASP‌ ‌.NET‌ ‌applications.‌ ‌The‌ ‌deployment‌ ‌process‌ ‌is‌ ‌very‌ ‌effortless.‌ ‌In‌ ‌the‌ ‌future,‌‌ Azure‌‌will‌‌keep‌‌track‌‌of‌‌our‌‌Github‌‌repo‌‌and‌‌keep‌‌the‌‌production‌‌server‌‌up‌‌to‌‌date.‌ ‌ VI. Microsoft‌‌SQL‌‌Server‌ ‌ Microsoft‌ ‌SQL‌ ‌Server‌ ‌lends‌ ‌itself‌ ‌really‌ ‌well‌ ‌to‌ ‌our‌ ‌application‌ ‌requirements.‌ ‌The‌‌ structure‌ ‌of‌ ‌our‌ ‌application‌ ‌data‌ ‌relates‌ ‌back‌‌to‌‌a‌‌user‌‌that‌‌is‌‌signed‌‌in‌‌meaning‌‌that‌‌an‌‌ entity-relationship‌‌model‌‌works‌‌great‌‌for‌‌storing‌‌our‌‌data.‌‌This‌‌meant‌‌that‌‌we‌‌needed‌‌an‌‌ SQL‌‌server‌‌for‌‌our‌‌database‌‌and‌‌ultimately‌‌we‌‌chose‌‌to‌‌use‌‌Microsoft‌‌SQL‌‌Server.‌‌Since‌‌ we‌‌are‌‌deploying‌‌using‌‌Azure‌‌it‌‌made‌‌sense‌‌to‌‌host‌‌our‌‌database‌‌using‌‌Azure‌‌as‌‌well‌‌and‌‌ the‌ ‌cheapest‌ ‌option‌ ‌for‌ ‌this‌ ‌was‌ ‌Azure‌ ‌SQL‌ ‌Databases‌ ‌which‌ ‌use‌ ‌a‌ ‌Microsoft‌ ‌SQL‌‌ Server.‌ ‌ Software/Hardware‌‌Requirements‌ ‌ I. Web‌‌App‌ ‌ We‌‌are‌‌planning‌‌to‌‌support‌‌the‌‌latest‌‌versions‌‌of‌‌the‌‌following‌‌web‌‌browsers:‌ ‌ ● Google‌‌Chrome‌ ‌ ● Mozilla‌‌Firefox‌ ‌ ● Apple‌‌Safari‌ ‌ ● Microsoft‌‌Edge‌ ‌ Please‌‌note‌‌that‌‌this‌‌information‌‌does‌‌not‌‌apply‌‌to‌‌mobile‌‌web‌‌browsers,‌‌If‌‌you‌‌are‌‌using‌‌ Hestia‌‌on‌‌mobile,‌‌we‌‌recommend‌‌using‌‌our‌‌Hestia‌‌iOS‌‌or‌‌Android‌‌app.‌‌ ‌ II. Mobile‌‌App‌ ‌ We‌ ‌support‌ ‌only‌ ‌mobile‌ ‌operating‌ ‌systems‌ ‌that‌ ‌are‌ ‌still‌ ‌being‌ ‌supported‌ ‌by‌ ‌the‌ ‌phone‌‌ manufacturers:‌ ‌ ● iPhone‌‌6S‌‌and‌‌above.‌ ‌ ● Android‌‌5+‌‌devices.‌ ‌ ‌ 103‌ ‌ This‌ ‌is‌ ‌meant‌ ‌to‌ ‌keep‌ ‌the‌ ‌app‌ ‌stable‌ ‌and‌ ‌secured‌ ‌since‌ ‌unsupported‌ ‌mobile‌ ‌operating‌‌ systems‌‌usually‌‌lack‌‌security‌‌features‌‌and‌‌native‌‌components‌‌to‌‌run‌‌the‌‌app.‌ 3.‌‌Requirements‌‌Analysis‌ ‌ System‌‌Architecture‌ ‌ The‌‌system‌‌consists‌‌of‌‌multiple‌‌components‌‌across‌‌various‌‌platforms.‌‌In‌‌total‌‌these‌ ‌components‌‌ form‌‌four‌‌main‌‌sections‌‌which‌‌make‌‌up‌‌our‌‌system‌‌architecture.‌‌Firstly,‌‌there‌‌is‌‌a‌‌Identity‌‌server‌‌ which‌ ‌will‌ ‌be‌ ‌used‌ ‌for‌ ‌user‌‌authentication‌‌made‌‌using‌‌ASP‌‌.NET.‌‌Then,‌‌there‌‌are‌‌the‌‌web‌‌and‌‌ mobile‌‌(Android‌‌and‌‌iOS)‌‌clients‌‌made‌‌using‌‌Angular‌‌and‌‌Nativescript‌‌respectively‌‌which‌‌form‌‌ our‌‌application‌‌frontend.‌‌Third,‌‌there‌‌is‌‌our‌‌ASP.‌‌Net‌‌Web‌‌API‌‌which‌‌is‌‌a‌‌RESTful‌‌API‌‌for‌‌our‌‌ frontend‌‌to‌‌use‌‌to‌‌access‌‌the‌‌database.‌‌Lastly,‌‌there‌‌is‌‌our‌‌Microsoft‌‌SQL‌‌Hestia‌‌database‌‌which‌‌ will‌‌store‌‌all‌‌necessary‌‌information‌‌needed‌‌for‌‌our‌‌application‌‌to‌‌run‌‌effectively.This‌‌completes‌‌ the‌ ‌architecture‌ ‌of‌ ‌our‌ ‌system‌ ‌which‌ ‌is‌ ‌shown‌ ‌in‌ ‌Figure‌ ‌1.‌ ‌There‌ ‌are‌ ‌some‌ ‌common‌ ‌modules‌‌ shared‌‌between‌‌these‌‌components‌‌so‌‌that‌‌logic‌‌and‌‌code‌‌can‌‌be‌‌recycled‌‌and‌‌reused‌‌as‌‌much‌‌as‌‌ possible‌‌(i.e.‌‌Angular‌‌framework‌‌for‌‌frontend‌‌designing).‌‌These‌‌components‌‌can‌‌be‌‌categorized‌‌ into‌ ‌three‌ ‌parts‌ ‌of‌ ‌a‌ ‌typical‌ ‌full-stack‌ ‌scope:‌ ‌Application‌ ‌Frontend,‌ ‌Application‌ ‌Backend,‌ ‌and‌‌ Database‌‌operations.‌‌Then,‌‌the‌‌identity‌‌server‌‌will‌‌be‌‌used‌‌by‌‌both‌‌the‌‌backend‌‌and‌‌frontend‌‌for‌‌ user‌‌authentication.‌ ‌ A. Application‌‌Frontend:‌ ‌ The‌‌first‌‌component‌‌of‌‌our‌‌full-stack‌‌scope‌‌is‌‌the‌‌frontend‌‌design‌‌consisting‌‌of‌‌both‌‌the‌‌ web‌‌and‌‌mobile‌‌applications.‌‌Both‌‌of‌‌them‌‌consist‌‌of‌‌many‌‌different‌‌modules‌‌which‌‌will‌‌ be‌ ‌discussed‌ ‌in‌ ‌detail.‌‌They‌‌are‌‌separated‌‌into‌‌different‌‌categories:‌‌the‌‌modules‌‌that‌‌the‌‌ web‌‌and‌‌mobile‌‌apps‌‌will‌‌share‌‌and‌‌the‌‌modules‌‌that‌‌they‌‌will‌‌develop‌‌separately.‌ ‌ ‌ Common‌‌modules:‌ ‌ For‌ ‌starters‌ ‌both‌ ‌will‌ ‌use‌ ‌pre-existing‌ ‌angular‌ ‌components‌ ‌and‌ ‌routing‌ ‌frameworks‌ ‌to‌‌ recycle‌‌code‌‌and‌‌move‌‌between‌‌components‌‌with‌‌ease.‌‌This‌‌will‌‌allow‌‌code‌‌structure‌‌to‌‌ look‌ ‌similar‌ ‌on‌ ‌both‌ ‌the‌ ‌web‌ ‌and‌ ‌mobile‌ ‌application‌ ‌which‌ ‌will‌ ‌help‌ ‌our‌ ‌teams‌ ‌code‌‌ development‌‌process.‌ ‌ Additionally,‌ ‌both‌ ‌will‌ ‌use‌ ‌an‌ ‌IdentityServer4‌ ‌authentication‌ ‌module‌ ‌made‌ ‌up‌ ‌of‌‌ pre-existing‌ ‌packages‌ ‌with‌ ‌personal‌ ‌tweaks.‌ ‌This‌ ‌provides‌ ‌an‌ ‌effective‌ ‌authentication‌‌ framework‌ ‌for‌ ‌ASP.NET‌ ‌Core‌ ‌that‌ ‌is‌ ‌OpenID‌ ‌certified‌ ‌with‌ ‌many‌ ‌security‌ ‌features‌‌ ‌ 104‌ ‌ including‌ ‌JWT,‌ ‌ID‌ ‌tokens‌ ‌in‌ ‌order‌ ‌to‌ ‌make‌‌a‌‌well-rounded‌‌secured‌‌system‌‌for‌‌both‌‌the‌‌ user‌‌and‌‌API‌‌endpoints.‌‌It‌‌can‌‌also‌‌be‌‌used‌‌to‌‌support‌‌other‌‌well-known‌‌third‌‌party‌‌logins‌‌ (i.e‌‌Google,‌‌Facebook,‌‌Microsoft).‌‌This‌‌will‌‌serve‌‌as‌‌the‌‌backbone‌‌of‌‌our‌‌app‌‌security‌‌to‌‌ make‌ ‌sure‌ ‌only‌ ‌those‌ ‌will‌ ‌accounts‌ ‌are‌ ‌able‌ ‌to‌ ‌access‌ ‌the‌ ‌information‌ ‌that‌ ‌they‌ ‌are‌‌ allowed‌‌access‌‌to.‌ ‌ Lastly,‌ ‌both‌ ‌will‌ ‌use‌ ‌pre-existing‌ ‌SendGrid‌ ‌packages‌ ‌for‌ ‌password‌ ‌reset‌ ‌and‌ ‌email‌‌ verification.‌ ‌This‌ ‌will‌ ‌ensure‌ ‌that‌ ‌we‌ ‌can‌ ‌trust‌ ‌all‌ ‌users‌ ‌who‌ ‌sign‌ ‌up‌ ‌due‌ ‌to‌ ‌the‌ ‌email‌‌ verification‌‌and‌‌ensures‌‌that‌‌a‌‌user‌‌will‌‌not‌‌be‌‌locked‌‌out‌‌of‌‌their‌‌account‌‌forever‌‌due‌‌to‌‌a‌‌ forgotten‌‌password.‌ ‌ Separate‌‌Modules‌ ‌ Along‌ ‌with‌ ‌these‌ ‌shared‌ ‌modules‌ ‌the‌ ‌mobile‌ ‌and‌ ‌web‌ ‌application‌ ‌will‌ ‌have‌ ‌their‌ ‌own‌‌ separate‌ ‌modules.‌ ‌These‌ ‌modules‌ ‌are‌ ‌separate‌ ‌in‌ ‌that‌ ‌they‌ ‌will‌ ‌not‌ ‌interact‌ ‌with‌ ‌each‌‌ other‌‌in‌‌any‌‌way.‌‌However,‌‌the‌‌functionality‌‌of‌‌both‌‌will‌‌remain‌‌relatively‌‌similar‌‌in‌‌both‌‌ the‌‌web‌‌and‌‌mobile‌‌applications‌‌with‌‌slight‌‌variations‌‌on‌‌the‌‌page‌‌layouts‌‌for‌‌each.‌‌All‌‌of‌‌ these‌ ‌modules‌ ‌are‌ ‌somewhat‌ ‌self‌ ‌developed‌ ‌in‌ ‌the‌ ‌sense‌ ‌that‌ ‌they‌ ‌will‌ ‌all‌ ‌be‌ ‌designed‌‌ specifically‌‌for‌‌our‌‌Hestia‌‌app‌‌but‌‌pre-existing‌‌packages‌‌will‌‌be‌‌used‌‌and‌‌built‌‌on‌‌when‌‌ available.‌ ‌For‌ ‌example‌ ‌all‌ ‌of‌ ‌the‌ ‌mobile‌ ‌modules‌ ‌make‌ ‌use‌ ‌of‌ ‌the‌‌NativeScript‌‌Pro‌‌UI‌‌ package.‌ ‌ The‌‌first‌‌thing‌‌available‌‌that‌‌both‌‌will‌‌have‌‌are‌‌their‌‌own‌‌modules‌‌for‌‌is‌‌a‌‌tasks‌‌feature.‌‌ This‌‌will‌‌allow‌‌the‌‌user‌‌to‌‌manage‌‌tasks‌‌in‌‌their‌‌family‌‌that‌‌need‌‌to‌‌be‌‌done‌‌by‌‌a‌‌certain‌‌ day.‌ ‌Every‌ ‌member‌ ‌in‌ ‌the‌ ‌family‌ ‌can‌ ‌create‌ ‌a‌ ‌task‌ ‌for‌ ‌their‌ ‌family‌ ‌and‌ ‌everyone‌ ‌else‌ would‌ ‌be‌‌able‌‌to‌‌see‌‌it.‌‌Additionally‌‌there‌‌can‌‌be‌‌tasks‌‌assigned‌‌to‌‌individual‌‌users‌‌that‌‌ they‌‌themselves‌‌have‌‌to‌‌complete.‌‌This‌‌will‌‌form‌‌the‌‌to‌‌do‌‌list‌‌part‌‌of‌‌our‌‌application.‌ ‌ Another‌ ‌feature‌ ‌that‌ ‌the‌ ‌web‌ ‌and‌ ‌mobile‌ ‌application‌ ‌will‌ ‌have‌ ‌their‌ ‌own‌‌module‌‌for‌‌is‌‌ their‌ ‌budgeting‌ ‌feature.‌ ‌This‌ ‌will‌ ‌allow‌ ‌the‌ ‌user‌ ‌to‌ ‌manage‌ ‌and‌ ‌display‌ ‌their‌ ‌budgets‌‌ (Budgets‌‌that‌‌have‌‌the‌‌user‌‌in‌‌the‌‌access‌‌list‌‌or‌‌as‌‌the‌‌owner).‌‌This‌‌will‌‌allow‌‌them‌‌to‌‌add‌‌ and‌ ‌view‌ ‌incomes‌ ‌and‌ ‌categorized‌ ‌expenses‌ ‌for‌ ‌the‌ ‌budget.‌ ‌It‌ ‌utilizes‌ ‌charts‌ ‌and‌ ‌goal‌‌ rings‌‌to‌‌do‌‌bookkeeping,‌‌budget‌‌calculations‌‌and‌‌to‌‌be‌‌budget‌‌manager.‌‌This‌‌will‌‌help‌‌the‌‌ user‌‌see‌‌how‌‌close‌‌they‌‌are‌‌to‌‌their‌‌budgetary‌‌goals.‌ ‌ Furthermore‌‌both‌‌the‌‌web‌‌and‌‌mobile‌‌applications‌‌will‌‌have‌‌a‌‌meals‌‌feature‌‌that‌ ‌will‌‌be‌‌ self‌‌developed.‌‌This‌‌will‌‌display‌‌the‌‌recipes‌‌that‌‌a‌‌family‌‌has‌‌in‌‌their‌‌own‌‌“recipe‌‌book”.‌‌ ‌ 105‌ ‌ Then‌‌from‌‌this‌‌book‌‌family‌‌meals‌‌can‌‌be‌‌planned‌‌for‌‌the‌‌entire‌‌family‌‌and‌‌scheduled‌‌on‌‌ a‌‌specific‌‌day‌‌(integrating‌‌with‌‌the‌‌calendar‌‌feature).‌‌Then‌‌you‌‌can‌‌automatically‌‌create‌‌a‌‌ shopping/grocery‌ ‌list‌ ‌based‌ ‌on‌ ‌the‌ ‌meals‌ ‌that‌ ‌have‌ ‌been‌ ‌scheduled.‌ ‌This‌ ‌may‌ ‌also‌ ‌be‌‌ integrated‌ ‌with‌ ‌the‌ ‌budgeting‌ ‌feature‌ ‌to‌ ‌add‌ ‌this‌ ‌grocery‌ ‌list‌ ‌expenses‌ ‌to‌‌the‌‌budget‌‌as‌‌ well.‌ ‌ Then,‌ ‌the‌ ‌final‌ ‌separate‌ ‌module‌ ‌will‌ ‌be‌ ‌one‌ ‌for‌ ‌the‌ ‌calendar‌‌feature.‌‌Both‌‌the‌‌web‌‌and‌‌ mobile‌‌applications‌‌will‌‌build‌‌on‌‌pre-existing‌‌calendar‌‌packages‌‌and‌‌integrate‌‌these‌‌into‌‌ the‌‌application.‌‌For‌‌the‌‌web‌‌application‌‌it‌‌will‌‌build‌‌on‌‌the‌‌FullCalendar‌‌module‌‌and‌‌the‌‌ mobile‌ ‌application‌ ‌will‌ ‌build‌ ‌on‌ ‌the‌ ‌Pro-UI‌ ‌Calendar.‌ ‌By‌ ‌building‌‌on‌‌these‌‌preexisting‌‌ calendars‌ ‌this‌ ‌calendar‌ ‌contains‌ ‌information‌ ‌about‌ ‌all‌ ‌Events‌ ‌in‌ ‌the‌ ‌family‌ ‌and‌ ‌they‌ displayed‌ ‌on‌ ‌a‌ ‌calendar‌ ‌(The‌ ‌pre-existing‌ ‌modules‌ ‌are‌ ‌used‌ ‌for‌ ‌this‌ ‌calendar‌ ‌display).‌‌ Each‌ ‌calendar‌ ‌Event‌ ‌is‌ ‌essentially‌ ‌a‌ ‌Task‌ ‌with‌ ‌additional‌ ‌information‌ ‌like‌ ‌a‌ ‌start‌ ‌time,‌‌ end‌ ‌time,‌ ‌location‌‌or‌‌any‌‌other‌‌necessary‌‌additional‌‌information.‌‌Furthermore‌‌there‌‌will‌‌ be‌‌dates‌‌associated‌‌with‌‌budgets‌‌and‌‌tasks‌‌as‌‌well‌‌meaning‌‌that‌‌the‌‌calendar‌‌will‌‌display‌‌ these‌ ‌items‌ ‌as‌ ‌well.‌ ‌This‌ ‌will‌ ‌make‌ ‌keeping‌ ‌track‌ ‌of‌ ‌the‌ ‌family‌ ‌much‌ ‌easier‌ ‌as‌ ‌it‌ ‌will‌‌ allow‌‌a‌‌user‌‌to‌‌see‌‌what‌‌each‌‌family‌‌member‌‌has‌‌scheduled‌‌every‌‌day.‌ ‌ ‌ B. Application‌‌Backend‌ ‌ The‌ ‌next‌ ‌major‌ ‌portion‌ ‌of‌ ‌our‌ ‌full-stack‌ ‌development‌ ‌is‌ ‌the‌ ‌application‌ ‌backend‌ ‌for‌‌ which‌ ‌the‌ ‌mobile‌ ‌and‌ ‌web‌ ‌application‌ ‌will‌ ‌each‌ ‌have‌ ‌separate‌‌modules‌‌to‌‌function‌‌but‌‌ will‌ ‌both‌ ‌follow‌ ‌very‌ ‌similar‌ ‌design‌ ‌and‌ ‌model‌ ‌structure.‌ ‌Each‌ ‌of‌ ‌them‌‌will‌‌have‌‌their‌‌ own‌ ‌self‌ ‌developed‌ ‌models‌ ‌in‌ ‌order‌ ‌to‌ ‌store‌ ‌information‌ ‌received‌ ‌from‌ ‌queries‌ ‌to‌ ‌our‌‌ restful‌ ‌API.‌ ‌This‌ ‌will‌ ‌serve‌ ‌as‌ ‌the‌ ‌backend‌ ‌for‌ ‌how‌ ‌user‌ ‌information‌ ‌is‌ ‌stored‌ ‌in‌ ‌the‌‌ application‌ ‌so‌ ‌that‌ ‌the‌ ‌RESTful‌ ‌API‌ ‌will‌ ‌not‌ ‌have‌ ‌to‌‌be‌‌called‌‌repeatedly‌‌to‌‌obtain‌‌the‌‌ same‌‌information.‌ ‌ Along‌ ‌with‌ ‌this‌ ‌both‌ ‌the‌ ‌web‌ ‌and‌ ‌mobile‌ ‌will‌ ‌implement‌ ‌their‌ ‌own‌ ‌completely‌‌ self-developed‌‌lazy‌‌loading‌‌routine.‌‌This‌‌will‌‌load‌‌all‌‌data‌‌between‌‌features‌‌at‌‌once‌‌and‌‌ will‌ ‌be‌ ‌accomplished‌ ‌by‌ ‌using‌ ‌a‌ ‌connection‌ ‌subscription‌ ‌to‌ ‌synchronize‌ ‌data‌ ‌after‌ ‌the‌‌ user‌ ‌is‌ ‌logged‌ ‌in.‌ ‌This‌ ‌will‌ ‌help‌ ‌create‌ ‌an‌ ‌enjoyable‌ ‌and‌ ‌seamless‌ ‌user‌ ‌experience‌‌ because‌‌it‌‌will‌‌allow‌‌the‌‌application‌‌to‌‌run‌‌much‌‌smoother‌‌and‌‌faster.‌‌ ‌ ‌ 106‌ ‌ As‌ ‌for‌ ‌requesting‌ ‌information‌ ‌from‌ ‌the‌ ‌RESTful‌ ‌API‌ ‌both‌ ‌the‌ ‌web‌ ‌and‌ ‌mobile‌‌ application‌ ‌will‌ ‌use‌ ‌a‌ ‌self‌ ‌developed‌ ‌Single‌ ‌page‌ ‌application‌ ‌pattern.‌ ‌These‌ ‌will‌ ‌use‌‌ AJAX‌ ‌function‌ ‌calls‌ ‌to‌ ‌manipulate‌ ‌user‌ ‌data‌ ‌(as‌ ‌well‌ ‌as‌ ‌data‌‌stored‌‌in‌‌the‌‌database)‌‌to‌‌ update‌ ‌the‌ ‌page‌ ‌display‌ ‌without‌ ‌needing‌ ‌to‌ ‌do‌ ‌a‌ ‌manual‌ ‌refresh‌ ‌once‌ ‌again‌ ‌enhancing‌‌ user‌‌experience.‌ ‌ Then,‌ ‌the‌ ‌final‌ ‌module‌ ‌in‌‌our‌‌backend‌‌application‌‌is‌‌a‌‌mobile‌‌exclusive‌‌module.‌‌It‌‌will‌‌ be‌ ‌an‌ ‌external‌ ‌push‌ ‌notification‌ ‌system‌ ‌using‌ ‌pre-existing‌ ‌packages.‌ ‌This‌ ‌will‌ ‌allow‌ ‌a‌‌ user‌ ‌to‌ ‌subscribe‌ ‌to‌ ‌detect‌ ‌changes‌ ‌from‌ ‌the‌ ‌database‌ ‌and‌ ‌send‌ ‌notifications‌ ‌to‌ ‌mobile‌‌ devices.‌ ‌Additionally,‌ ‌this‌ ‌can‌ ‌be‌ ‌used‌ ‌to‌ ‌remind‌ ‌users‌ ‌of‌ ‌upcoming‌ ‌tasks(todos)‌ ‌and‌‌ events‌‌as‌‌they‌‌approach.‌ ‌ C. Database‌‌Operations‌ ‌ The‌ ‌final‌ ‌portion‌ ‌of‌ ‌our‌ ‌full-stack‌ ‌development‌ ‌are‌ ‌the‌ ‌database‌ ‌operations‌‌themselves‌‌ which‌ ‌handle‌ ‌all‌ ‌long-term‌ ‌storage‌ ‌of‌ ‌application‌ ‌information.‌ ‌This‌ ‌part‌ ‌of‌ ‌the‌ ‌stack‌‌ consists‌ ‌of‌ ‌the‌ ‌database‌ ‌itself‌ ‌as‌‌well‌‌as‌‌the‌‌RESTful‌‌API‌‌which‌‌allows‌‌a‌‌user‌‌to‌‌query‌‌ the‌‌database‌‌as‌‌needed.‌‌With‌‌this‌‌being‌‌said‌‌the‌‌best‌‌place‌‌to‌‌start‌‌would‌‌be‌‌to‌‌discuss‌‌the‌‌ self‌‌developed‌‌RESTful‌‌API‌‌which‌‌will‌‌perform‌‌the‌‌backend‌‌database‌‌operations.‌ ‌ The‌ ‌RESTful‌ ‌API‌‌is‌‌a‌‌middle‌‌module‌‌between‌‌the‌‌database‌‌and‌‌everything‌‌else.‌‌It‌‌uses‌‌ LINQ‌ ‌queries‌ ‌integrated‌ ‌into‌ ‌the‌ ‌C#‌ ‌Entity‌ ‌Framework‌ ‌to‌ ‌communicate‌ ‌with‌ ‌the‌‌ database.‌‌This‌‌allows‌‌the‌‌backend‌‌of‌‌the‌‌web‌‌and‌‌mobile‌‌applications‌‌to‌‌retrieve,‌‌update,‌‌ modify,‌ ‌and‌ ‌delete‌ ‌data‌ ‌in‌ ‌the‌ ‌database‌ ‌without‌ ‌communicating‌ ‌directly‌ ‌with‌ ‌the‌‌ database.‌ ‌This‌‌secures‌‌the‌‌database‌‌by‌‌limiting‌‌user‌‌operations’‌‌scope‌‌with‌‌the‌‌database‌ and‌ ‌also‌‌allows‌‌the‌‌web‌‌and‌‌mobile‌‌application‌‌to‌‌use‌‌the‌‌same‌‌backend‌‌component‌‌for‌‌ communicating‌‌with‌‌the‌‌database‌‌.‌ ‌ As‌ ‌part‌ ‌of‌ ‌this‌ ‌RESTful‌ ‌API‌ ‌it‌ ‌will‌ ‌also‌ ‌implement‌ ‌pre-existing‌ ‌WebSocket‌ ‌packages.‌‌ This‌‌will‌‌handle‌‌the‌‌data‌‌synchronization‌‌between‌‌devices‌‌making‌‌sure‌‌that‌‌concurrency‌‌ is‌ ‌enabled‌ ‌without‌ ‌having‌ ‌to‌ ‌explicitly‌ ‌query‌ ‌the‌ ‌database‌ ‌to‌ ‌retrieve‌ ‌new‌‌information.‌‌ The‌ ‌way‌ ‌this‌ ‌will‌ ‌work‌ ‌is‌ ‌every‌ ‌time‌ ‌a‌ ‌change‌ ‌is‌ ‌made‌ ‌to‌ ‌the‌ ‌database‌ ‌(something‌ ‌is‌‌ modified,‌‌deleted,‌‌added)‌‌all‌‌the‌‌users‌‌with‌‌access‌‌to‌‌this‌‌information‌‌are‌‌notified‌‌of‌‌the‌‌ change‌‌through‌‌a‌‌WebSocket‌‌ensuring‌‌they‌‌have‌‌the‌‌most‌‌up‌‌to‌‌date‌‌state‌‌of‌‌the‌‌database.‌ ‌ Then,‌‌the‌‌database‌‌itself‌‌is‌‌hosted‌‌on‌‌a‌‌Microsoft‌‌SQL‌‌server‌‌using‌‌Azure‌‌and‌‌therefore‌‌ will‌‌make‌‌use‌‌of‌‌the‌‌pre-existing‌‌Microsoft‌‌SQL‌‌packages.‌‌This‌‌will‌‌handle‌‌all‌‌storage‌‌of‌‌ ‌ 107‌ ‌ user‌‌data‌‌with‌‌relationships‌‌among‌‌tables‌‌to‌‌promote‌‌better‌‌data‌‌management‌‌as‌‌integrity.‌‌ Overall,‌ ‌this‌ ‌will‌ ‌secure‌‌all‌‌user‌‌information‌‌and‌‌ensure‌‌that‌‌data‌‌is‌‌not‌‌lost‌‌once‌‌a‌‌user‌‌ logs‌‌out‌‌of‌‌the‌‌application.‌ ‌ ‌ Figure‌‌1:‌‌‌Hestia‌‌System‌‌Architecture‌‌Diagram‌ ‌ Personnel‌ ‌ Pierce‌‌Bringhurst‌‌‌-‌‌Has‌‌experience‌‌in‌‌.NET‌‌stack‌‌and‌‌Angular‌ ‌ ● DevOps:‌‌deploys‌‌authentication,‌‌frontend‌‌and‌‌backend‌‌servers‌‌for‌‌the‌‌web‌‌platform‌‌with‌‌ Azure.‌ ‌ ● Frontend‌ ‌development‌ ‌(works‌ ‌with‌ ‌Liam‌ ‌Zhou):‌ ‌design‌ ‌and‌ ‌implement‌ ‌user‌‌ operations/interactions‌‌with‌‌the‌‌application.‌‌ ‌ Liam‌‌Zhou‌‌‌-‌‌Has‌‌experience‌‌in‌‌Figma,‌‌Angular‌‌and‌‌full‌‌stack‌‌web‌‌development‌ ‌ ● Designs‌‌the‌‌application’s‌‌pages‌‌using‌‌web‌‌designing‌‌tools‌‌such‌‌as‌‌Figma‌‌that‌‌can‌‌provide‌‌ CSS‌‌and‌‌HTML‌‌styling‌‌code.‌ ‌ ● Frontend‌ ‌development‌ ‌(works‌ ‌with‌ ‌Pierce‌ ‌Bringhurst):‌ ‌design‌ ‌and‌ ‌implement‌ ‌user‌‌ operations/interactions‌‌with‌‌the‌‌application.‌ ‌ ‌ 108‌ ‌ Michael‌ ‌Linnebach‌ ‌-‌ ‌Has‌ ‌had‌ ‌experience‌ ‌in‌ ‌database‌ ‌design‌ ‌and‌ ‌writing‌ ‌code‌ ‌that‌ ‌retrieves,‌‌ updates,‌‌modifies,‌‌and‌‌deletes‌‌data‌‌stored‌‌in‌‌a‌‌database‌‌using‌‌LINQ‌ ‌ ● Designs‌‌the‌‌database‌‌schemas‌‌and‌‌relationships‌‌among‌‌them.‌ ‌ ● Creates‌ ‌RESTful‌ ‌APIs‌ ‌and‌ ‌plans‌ ‌data‌ ‌operations‌ ‌with‌ ‌multiple‌ ‌HTTP‌ ‌requesting‌‌ methods.‌ ‌ ● Backend‌ ‌development‌ ‌(works‌ ‌with‌ ‌Bridger‌‌Peterson):‌‌implement‌‌application’s‌‌features’‌‌ logic‌‌following‌‌the‌‌MVC‌‌pattern.‌ ‌ Bridger‌ ‌Peterson‌ ‌-‌ ‌Experience‌ ‌in‌ ‌designing‌ ‌and‌ ‌developing‌ ‌mobile‌ ‌and‌ ‌web‌ ‌software‌‌ applications,‌‌designing‌‌and‌‌implementing‌‌databases,‌‌and‌‌API‌‌work‌ ‌ ● Suggests‌‌and‌‌innovates‌‌new‌‌ideas‌‌to‌‌the‌‌application.‌ ‌ ● Designs‌‌the‌‌application’s‌‌feature‌‌and‌‌typographic‌‌layouts.‌ ‌ ● Backend‌ ‌development‌ ‌(works‌ ‌with‌ ‌Michael‌ ‌Linnebach):‌ ‌implement‌ ‌application’s‌‌ features’‌‌logic‌‌following‌‌the‌‌MVC‌‌pattern.‌ ‌ Thang‌ ‌Nguyen‌ ‌-‌ ‌Has‌ ‌had‌ ‌experience‌ ‌developing‌ ‌an‌ ‌application‌ ‌with‌‌fullstack‌‌scope:‌‌frontend,‌‌ backend‌‌on‌‌both‌‌web‌‌and‌‌mobile‌‌platforms‌‌using‌‌JavaScript‌‌frameworks‌‌and‌‌Firebase‌‌database.‌ ‌ ● Mobile‌ ‌app‌ ‌design‌ ‌and‌ ‌development:‌ ‌handles‌ ‌the‌ ‌user’s‌ ‌interactions‌ ‌and‌ ‌implements‌‌ micro‌‌interactions‌‌that‌‌help‌‌with‌‌the‌‌user’s‌‌experience‌‌on‌‌mobile.‌ ‌ System‌‌Features‌ ‌ Rank‌‌1‌‌-‌‌Bare‌‌Essentials‌:‌ ‌ ● Budgeting‌‌feature‌‌on‌‌web‌‌and‌‌mobile.‌ ‌ ● Todos‌‌feature‌‌on‌‌web‌‌and‌‌mobile.‌ ‌ ● Calendar‌‌feature‌‌on‌‌web‌‌and‌‌mobile‌‌.‌ ‌ ● Family‌‌recipe‌‌book‌‌(meals)‌‌on‌‌web‌‌and‌‌mobile.‌ ‌ ● Have‌‌the‌‌ability‌‌to‌‌make‌‌and‌‌view‌‌grocery/shopping‌‌lists‌‌on‌‌web‌‌and‌‌mobile.‌ ‌ ● Adding‌‌in‌‌ability‌‌to‌‌schedule‌‌meals‌‌on‌‌specific‌‌days.‌ ‌ ● Data‌‌integrity‌‌in‌‌the‌‌database.‌ ‌ ● Ensure‌‌our‌‌backend‌‌API‌‌isn’t‌‌vulnerable‌‌to‌‌request‌‌from‌‌unverified‌‌users/sources.‌ ‌ ● Identity‌‌server‌‌functional‌‌for‌‌sign‌‌in.‌ ‌ ‌ Rank‌‌2‌‌-‌‌Planned‌‌Features‌:‌ ‌ ‌ 109‌ ‌ ● Interconnection‌ ‌between‌ ‌core‌ ‌features‌ ‌of‌ ‌the‌ ‌application‌ ‌so‌ ‌that‌ ‌the‌ ‌user‌ ‌can‌ ‌include‌ ‌a‌‌ Budget‌‌with‌‌their‌‌calendar‌‌Event,‌‌add‌‌Meals‌‌to‌‌the‌‌Task‌‌list,‌‌etc.‌ ‌ ● Push‌‌notification‌‌system‌‌to‌‌notify‌‌the‌‌user‌‌where‌‌modifications‌‌related‌‌to‌‌their‌‌data‌‌have‌‌ been‌‌made.and‌‌to‌‌give‌‌them‌‌reminders‌‌about‌‌todos/events‌‌they‌‌have‌‌scheduled.‌ ‌ ● Enable‌‌third‌‌party‌‌sign‌‌in‌‌with‌‌google‌‌or‌‌facebook.‌ ‌ ● Use‌ ‌web‌ ‌sockets‌ ‌to‌‌enable‌‌concurrency‌‌with‌‌multiple‌‌people‌‌updating‌‌the‌‌same‌‌budget,‌‌ todo,‌‌etc.‌‌so‌‌that‌‌everyone‌‌will‌‌always‌‌have‌‌the‌‌most‌‌up‌‌to‌‌date‌‌information.‌ ‌ ● Add‌‌in‌‌the‌‌ability‌‌to‌‌scale‌‌a‌‌certain‌‌meal‌‌based‌‌on‌‌how‌‌much‌‌needs‌‌to‌‌be‌‌made/‌ ‌ ● Add‌ ‌in‌ ‌the‌ ‌ability‌ ‌to‌ ‌auto‌ ‌generate‌ ‌a‌ ‌shopping‌ ‌list‌ ‌based‌ ‌on‌ ‌the‌ ‌meals‌ ‌a‌ ‌user‌ ‌has‌‌ scheduled.‌ ‌ ‌ Rank‌‌3‌‌-‌‌Bells‌‌and‌‌Whistles‌:‌ ‌ ● Extra‌ ‌family‌ ‌features‌ ‌such‌ ‌as‌ ‌Entertainment‌ ‌to‌ ‌recommend‌ ‌movies‌ ‌or‌‌books‌‌for‌‌family‌‌ nights.‌ ‌ ● Functionality‌‌expansion‌‌of‌‌the‌‌core‌‌features.‌ ‌ ● Modern‌ ‌and‌ ‌fancy‌ ‌user‌ ‌interactions,‌ ‌animations‌ ‌such‌ ‌as‌‌biometrics‌‌authentication,‌‌drag‌‌ and‌‌drop,‌‌timeline‌‌drawing,‌‌etc.‌ ‌ ● Implement‌ ‌web‌ ‌scraping‌ ‌to‌ ‌allow‌ ‌users‌ ‌to‌ ‌import‌ ‌an‌ ‌online‌ ‌recipe‌ ‌into‌ ‌their‌ ‌family’s‌‌ recipe‌‌book.‌ ‌ ● Have‌‌the‌‌ability‌‌to‌‌share‌‌recipes,‌‌events,‌‌etc.‌‌with‌‌other‌‌families.‌ ‌ 4.‌‌Software‌‌Engineering‌‌Tools‌‌and‌‌Techniques‌ ‌ Throughout‌‌this‌‌process‌‌we‌‌plan‌‌to‌‌use‌‌many‌‌tools‌‌and‌‌software‌‌engineering‌‌techniques‌‌to‌‌keep‌‌ us‌ ‌on‌ ‌track‌ ‌for‌ ‌the‌‌project.‌‌This‌‌section‌‌gives‌‌a‌‌brief‌‌rundown‌‌and‌‌the‌‌tools‌‌and‌‌techniques‌‌we‌‌ have‌‌utilized‌‌and‌‌plan‌‌on‌‌utilizing‌‌in‌‌the‌‌future.‌ ‌ ‌ Code‌‌sharing‌‌and‌‌versioning‌:‌ ‌ ● GitHub‌‌to‌‌publish‌‌our‌‌code‌‌since‌‌it‌‌is‌‌the‌‌defacto‌‌standard‌‌in‌‌version‌‌control‌‌and‌‌it‌‌does‌‌ that‌ ‌efficiently.‌ ‌There‌ ‌is‌ ‌a‌ ‌Project‌ ‌feature‌ ‌within‌ ‌GitHub‌ ‌repositories‌ ‌that‌ ‌allows‌ ‌team‌‌ members‌‌to‌‌create,‌‌plan‌‌and‌‌assign‌‌todo‌‌tasks.‌ ‌ ‌ ‌ 110‌ ‌ Team‌‌meetings‌‌and‌‌conferences‌:‌ ‌ ● Discord‌ ‌is‌ ‌the‌ ‌service‌ ‌that‌ ‌we‌ ‌chose‌ ‌to‌ ‌communicate‌ ‌and‌ ‌hold‌ ‌conferences.‌ ‌It‌ ‌has‌ ‌a‌‌ variety‌‌of‌‌functionalities‌‌that‌‌assist‌‌us‌‌with‌‌the‌‌project’s‌‌logistics.‌ ‌ Code‌‌development‌:‌ ‌ ● Visual‌‌Studio‌‌Code‌‌with‌‌installed‌‌plugins‌‌that‌‌have‌‌intellisense‌‌for‌‌faster,‌‌more‌‌efficient‌‌ coding‌‌experience‌‌and‌‌the‌‌ability‌‌to‌‌create‌‌an‌‌organized‌‌file‌‌structure‌‌for‌‌the‌‌project.‌ ‌ Unit‌‌Testing‌:‌ ● We‌ ‌will‌ ‌use‌ ‌unit‌ ‌testing‌ ‌to‌ ‌ensure‌ ‌the‌ ‌correctness‌ ‌of‌ ‌our‌ ‌RESTful‌ ‌API.‌ ‌Using‌ ‌Visual‌‌ Studio‌ ‌we‌ ‌will‌ ‌developed‌ ‌unit‌ ‌tests‌ ‌which‌ ‌manipulate‌ ‌a‌ ‌mock‌ ‌local‌ ‌database‌ ‌to‌ ‌ensure‌‌ that‌‌the‌‌database‌‌is‌‌updated‌‌correctly‌‌when‌‌the‌‌API‌‌endpoints‌‌are‌‌called‌‌ ‌ Database‌‌Design‌:‌ ‌ ● Draw.io‌ ‌to‌ ‌create‌ ‌an‌ ‌ER‌ ‌diagram‌ ‌for‌ ‌the‌ ‌database.‌ ‌This‌ ‌has‌ ‌all‌ ‌necessary‌ ‌features‌ ‌to‌‌ design‌‌a‌‌clean‌‌and‌‌correct‌‌ER‌‌diagram‌‌that‌‌can‌‌be‌‌updated‌‌as‌‌needed.‌ ‌ ● Microsoft‌ ‌SQL‌ ‌Server‌ ‌Management‌ ‌Studio‌ ‌for‌ ‌creating‌‌and‌‌updating‌‌database‌‌schemas‌‌ and‌‌updating‌‌logins‌‌for‌‌who‌‌has‌‌database‌‌access.‌‌Also‌‌used‌‌for‌‌testing‌‌purposes‌‌to‌‌see‌‌if‌‌ the‌‌database‌‌is‌‌updated‌‌correctly‌‌after‌‌Post‌‌Queries.‌ ‌ ‌ Frontend‌‌Design‌:‌ ‌ ● Figma‌‌to‌‌design‌‌templates‌‌for‌‌the‌‌application.‌‌It‌‌provides‌‌numerous‌‌designing‌‌tools‌‌that‌‌ can‌‌be‌‌used‌‌to‌‌assist‌‌the‌‌frontend‌‌development‌‌jobs‌‌at‌‌the‌‌same‌‌time.‌ ‌ ● Adobe‌‌Illustrator/XD‌‌to‌‌design‌‌necessary‌‌icons‌‌and‌‌backgrounds‌‌for‌‌the‌‌application.‌ ‌ ● Adobe‌‌Photoshop‌‌to‌‌design‌‌templates‌‌and‌‌convert‌‌them‌‌to‌‌HTML‌‌and‌‌CSS‌‌styling‌‌code.‌‌ ‌ ‌ DevOps‌:‌ ‌ ● Azure‌ ‌that‌ ‌can‌ ‌be‌ ‌paired‌ ‌with‌ ‌GitHub‌ ‌repositories'‌ ‌versions‌ ‌to‌ ‌synchronize‌ ‌the‌‌ repositories’‌‌code‌‌with‌‌the‌‌deployed‌‌hosts.‌ ‌ 5.‌‌Timeline‌ ‌ We‌‌have‌‌developed‌‌a‌‌project‌‌timeline‌‌for‌‌the‌‌rest‌‌of‌‌the‌‌capstone.‌‌This‌‌section‌‌provides‌‌you‌‌of‌‌a‌‌ list‌ ‌of‌ ‌project‌ ‌goals‌ ‌that‌ ‌will‌ ‌be‌ ‌completed‌ ‌by‌ ‌the‌ ‌end‌ ‌of‌ ‌next‌ ‌semester.‌ ‌The‌ ‌dates‌ ‌listed‌ ‌are‌‌ ‌ 111‌ ‌ anticipated‌ ‌starting‌ ‌and‌ ‌ending‌ ‌dates‌ ‌and‌ ‌aren’t‌ ‌hard‌ ‌deadlines‌ ‌meaning‌ ‌they‌ ‌are‌ ‌open‌ ‌to‌ ‌be‌‌ changed‌‌as‌‌needed.‌‌The‌‌table‌‌below‌‌lists‌‌each‌‌of‌‌our‌‌tasks‌‌to‌‌complete,‌‌their‌‌starting‌‌date,‌‌ending‌‌ date,‌ ‌duration,‌ ‌and‌ ‌which‌ ‌team‌ ‌member‌ ‌will‌ ‌be‌ ‌in‌ ‌charge‌ ‌of‌ ‌completing‌ ‌that‌‌task.‌‌In‌‌the‌‌table‌‌ each‌‌Task‌‌is‌‌assigned‌‌a‌‌number‌‌and‌‌this‌‌can‌‌be‌‌used‌‌to‌‌lookup‌‌a‌‌task‌‌shown‌‌on‌‌the‌‌Gnatt‌‌chart‌‌in‌‌ Figure‌‌2‌‌which‌‌gives‌‌a‌‌visual‌‌representation‌‌of‌‌our‌‌project‌‌timeline.‌ ‌ ‌ Task‌‌ #‌ ‌ Task‌‌Name‌‌/‌‌Description‌ ‌ Start‌‌ End‌‌ Duratio‌ Team‌‌ Date‌ ‌ Date‌ ‌ n‌ Member(s)‌ ‌ (Weeks)‌ ‌ Backend‌‌–‌‌RESTful‌‌API‌‌and‌‌Database‌ ‌ 1‌ ‌ Establish‌‌API‌‌endpoints‌‌for‌‌households,‌‌meals,‌‌ grocery‌‌lists,‌‌and‌‌calendars‌ ‌ 5/2‌ ‌ 6/27‌ ‌ 8‌ ‌ Michael‌ ‌ Bridger‌ ‌ 2‌ ‌ Create‌‌a‌‌robust‌‌testing‌‌suite‌‌for‌‌API‌‌endpoints‌‌ with‌‌a‌‌mock‌‌local‌‌database‌ ‌ 5/2‌ ‌ 8/22‌ ‌ 16‌ ‌ Michael‌ ‌ 3‌ ‌ Create‌‌endpoints‌‌to‌‌add‌‌batch‌‌of‌‌items‌‌to‌‌ decrease‌‌total‌‌number‌‌of‌‌API‌‌calls‌ ‌ 6/27‌ ‌ 8/22‌ ‌ 8‌ ‌ Michael‌ ‌ Bridger‌ ‌ 4‌ ‌ Update‌‌database‌‌to‌‌include‌‌holidays‌‌in‌‌ everyone’s‌‌calendar‌ ‌ 8/22‌ ‌ 9/5‌ ‌ 2‌ ‌ Michael‌ ‌ 5‌ ‌ Integrate‌‌Web‌‌API‌‌with‌‌identity‌‌server‌‌to‌‌ check‌‌user‌‌authentication‌ ‌ 8/22‌ ‌ 9/12‌ ‌ 3‌ ‌ Bridger‌ ‌ 6‌ ‌ Make‌‌all‌‌endpoints‌‌occur‌‌within‌‌a‌‌transaction‌‌ to‌‌ensure‌‌data‌‌integrity‌ ‌ 8/29‌ ‌ 9/12‌ ‌ 2‌ ‌ Michael‌ ‌ 7‌ ‌ Integrate‌‌RESTful‌‌API‌‌with‌‌identity‌‌server‌‌to‌‌ allow‌‌admins‌‌to‌‌assign‌‌tasks/events/etc.‌‌to‌‌ other‌‌family‌‌members‌ ‌ 9/5‌ ‌ 9/26‌ ‌ 3‌ ‌ Bridger‌ ‌ 8‌ ‌ Add‌‌in‌‌checks‌‌to‌‌ensure‌‌users‌‌can‌‌only‌‌access,‌‌ 9/12‌ ‌ modify,‌‌and‌‌delete‌‌things‌‌they‌‌should‌‌have‌‌ access‌‌to‌ ‌ 10/3‌ ‌ 3‌ ‌ Michael‌ ‌ Bridger‌ ‌ 9/26‌ ‌ 11/28‌ ‌ 8‌ ‌ Michael‌ ‌ Bridger‌ ‌ Add‌‌in‌‌deletion‌‌checks‌‌which‌‌will‌‌ 11/7‌ ‌ 11/21‌ ‌ automatically‌‌delete‌‌old‌‌data‌‌no‌‌longer‌‌needed‌ ‌ 2‌ ‌ Michael‌ ‌ 2‌ ‌ Michael‌ ‌ Bridger‌ ‌ 9‌ ‌ 10‌ ‌ 11‌ ‌ Set‌‌up‌‌Web‌‌Sockets‌‌to‌‌allow‌‌concurrency‌‌ between‌‌shared‌‌items.‌‌Everyone‌‌will‌‌always‌‌ has‌‌the‌‌most‌‌up‌‌to‌‌date‌‌version‌‌of‌‌things‌ ‌ Add‌‌in‌‌method‌‌to‌‌auto‌‌generate‌‌grocery‌‌list‌‌ based‌‌on‌‌scheduled‌‌Meals‌ ‌ 11/28‌ ‌ 12/12‌ ‌ Identity‌‌Server‌ ‌ ‌ 12‌ ‌ Make‌‌the‌‌registration‌‌UI‌‌prettier;‌‌may‌‌use‌‌a‌‌ modal‌‌instead‌‌of‌‌separate‌‌page‌ ‌ 5/2‌ ‌ 5/23‌ ‌ 3‌ ‌ Pierce‌ ‌ 13‌ ‌ Create‌‌a‌‌“Success”‌‌page‌‌and‌‌set‌‌up‌‌email‌‌ verification‌ ‌ 5/23‌ ‌ 6/20‌ ‌ 4‌ ‌ Pierce‌ ‌ 112‌ ‌ 14‌ ‌ Make‌‌a‌‌page/modal‌‌for‌‌password‌‌reset‌ ‌ 6/20‌ ‌ 7/11‌ ‌ 3‌ ‌ Pierce‌ ‌ 15‌ ‌ Support‌‌third-party‌‌sign-in‌‌with‌‌google‌‌and‌‌ Facebook‌ ‌ 7/11‌ ‌ 8/22‌ ‌ 6‌ ‌ Pierce‌ ‌ 16‌ ‌ Figure‌‌out‌‌family‌‌“roles”:‌‌admin‌‌and‌‌ non-admin‌ ‌ 8/22‌ ‌ 9/19‌ ‌ 4‌ ‌ Pierce‌ ‌ Frontend‌‌–‌‌Web‌‌Application‌ ‌ 17‌ ‌ Implement‌‌the‌‌tasks‌‌section‌ ‌ 5/2‌ ‌ 8/22‌ ‌ 16‌ ‌ Liam‌ ‌ 19‌ ‌ Implement‌‌the‌‌budgeting‌‌section‌ ‌ 8/22‌ ‌ 9/19‌ ‌ 4‌ ‌ Liam‌ ‌ 18‌ ‌ Make‌‌an‌‌Account‌‌Settings‌‌tab:‌‌Allow‌‌users‌‌to‌‌ change‌‌personal‌‌account‌‌info‌‌after‌‌registration‌ ‌ 9/5‌ ‌ 9/19‌ ‌ 2‌ ‌ Pierce‌ ‌ 20‌ ‌ Make‌‌a‌‌user‌‌management‌‌page.‌‌Allow‌‌users‌‌to‌‌ 9/19‌ ‌ search‌‌other‌‌users‌‌and‌‌add‌‌them‌‌to‌‌their‌‌ “family”‌ ‌ 10/3‌ ‌ 2‌ ‌ Pierce‌ ‌ 21‌ ‌ Implement‌‌the‌‌meals‌‌section‌ ‌ 9/19‌ ‌ 10/17‌ ‌ 4‌ ‌ Liam‌ ‌ 22‌ ‌ Set‌‌up‌‌Calendar‌‌event‌‌CRUD‌ ‌ 10/3‌ ‌ 10/24‌ ‌ 3‌ ‌ Pierce‌ ‌ 23‌ ‌ Implement‌‌the‌‌grocery‌‌lists‌‌section‌ ‌ 10/17‌ ‌ 11/7‌ ‌ 3‌ ‌ Liam‌ ‌ 24‌ ‌ Style‌‌calendar‌‌plugin‌‌to‌‌fit‌‌with‌‌site‌‌UI‌ ‌ 10/24‌ ‌ 11/7‌ ‌ 2‌ ‌ Pierce‌ ‌ 25‌ ‌ Polish/finish‌‌remaining‌‌web‌‌application‌‌ features/Add‌‌in‌‌extra‌‌features‌ ‌ 11/7‌ ‌ 12/5‌ ‌ 4‌ ‌ Liam‌ ‌ Pierce‌ ‌ 26‌ ‌ Deploy‌‌final‌‌Hestia‌‌web‌‌application‌ ‌ 12/5‌ ‌ 12/12‌ ‌ 1‌ ‌ Liam‌ ‌ Pierce‌ ‌ Frontend‌‌–‌‌Mobile‌‌Application‌ ‌ ‌ 27‌ ‌ Complete‌‌Calendar‌‌Page‌ ‌ 5/2‌ ‌ 5/30‌ ‌ 4‌ ‌ Thang‌ ‌ 28‌ ‌ Complete‌‌Meals‌‌Page‌ ‌ 5/30‌ ‌ 6/27‌ ‌ 4‌ ‌ Thang‌ ‌ 29‌ ‌ Complete‌‌Grocery‌‌Lists‌‌Page‌ ‌ 6/27‌ ‌ 7/25‌ ‌ 4‌ ‌ Thang‌ ‌ 30‌ ‌ Polish‌‌and‌‌touch‌‌up‌‌page‌‌designs‌‌and‌‌release‌‌ Beta‌‌version‌ ‌ 7/25‌ ‌ 8/22‌ ‌ 4‌ ‌ Thang‌ ‌ 31‌ ‌ Complete‌‌hookups‌‌with‌‌the‌‌backend‌‌API‌‌and‌‌ the‌‌identity‌‌server.‌ ‌ 8/22‌ ‌ 10/10‌ ‌ 7‌ ‌ Thang‌ ‌ 32‌ ‌ Set‌‌up‌‌external‌‌push‌‌notifications‌ ‌ 8/29‌ ‌ 10/31‌ ‌ 9‌ ‌ Thang‌ ‌ 33‌ ‌ Fix‌‌bugs‌‌in‌‌Beta‌‌version‌‌and‌‌release‌‌new‌‌test‌‌ version‌ ‌ 9/14‌ ‌ 10/31‌ ‌ 7‌ ‌ Thang‌ ‌ 34‌ ‌ Fix‌‌bugs‌‌in‌‌the‌‌test‌‌version‌ ‌ 10/31‌ ‌ 12/5‌ ‌ 4‌ ‌ Thang‌ ‌ 35‌ ‌ Release‌‌final‌‌Hestia‌‌app‌ ‌ 12/5‌ ‌ 12/12‌ ‌ 1‌ ‌ Thang‌ ‌ 113‌ ‌ ‌ ‌ Figure‌‌2:‌‌‌Project‌‌Timeline‌‌Gantt‌‌Chart‌ ‌ ‌ 114‌ ‌ 6.‌‌Appendix‌‌A:‌‌UI‌‌Sketches‌ ‌ ‌ Figure‌‌3:‌‌‌Landing‌‌Page‌ ‌ ‌ ‌ Figure‌‌4:‌‌‌Tasks‌‌Page‌ ‌ ‌ 115‌ ‌ ‌ Figure‌‌5:‌‌‌Calendar‌‌Page‌‌Month‌‌View‌ ‌ ‌ ‌ Figure‌‌6:‌‌‌Registration‌ ‌ ‌ ‌ 116‌ ‌ ‌ Figure‌‌7:‌‌‌Login‌ ‌ ‌ ‌ 117‌ ‌ 7.‌‌Appendix‌‌B:‌‌Use‌‌Cases‌ ‌ ‌ Number‌ ‌ Use‌‌Case‌‌1‌ ‌ Title‌ ‌ Registration‌‌and‌‌Login‌ ‌ Short‌‌Description‌ ‌ The‌‌user‌‌can‌‌register‌‌a‌‌new‌‌account‌‌and‌‌login‌‌through‌‌IdentityServer.‌ ‌ List‌‌of‌‌Steps‌ ‌ 1. The‌ ‌user‌ ‌clicks‌ ‌the‌ ‌registration‌ ‌button‌ ‌on‌‌the‌‌home‌‌page‌‌and‌‌fills‌‌out‌‌ the‌‌registration‌‌form‌‌to‌‌create‌‌a‌‌new‌‌account.‌ ‌ 2. The‌ ‌user‌ ‌clicks‌‌the‌‌login‌‌button‌‌on‌‌the‌‌home‌‌page‌‌and‌‌gets‌‌redirected‌‌ to‌‌the‌‌Identity‌‌Server's‌‌login‌‌page.‌ ‌ 3. The‌ ‌user‌ ‌enters‌ ‌the‌ ‌username‌ ‌and‌ ‌password‌ ‌and‌ ‌clicks‌ ‌login.‌ ‌If‌ ‌the‌‌ login‌ ‌information‌ ‌is‌‌correct,‌‌they‌‌get‌‌redirected‌‌back‌‌to‌‌the‌‌dashboard‌‌ page.‌ ‌ Related‌‌UI‌ ‌ Figure‌‌2,‌‌Figure‌‌5,‌‌Figure‌‌6‌ ‌ ‌ ‌ Number‌ ‌ Use‌‌Case‌‌2‌ ‌ Title‌ ‌ View‌‌calendar‌ ‌ Short‌‌Description‌ ‌ The‌‌user‌‌can‌‌interact‌‌with‌‌the‌‌calendar‌‌to‌‌see‌‌the‌‌family's‌‌plans.‌ ‌ List‌‌of‌‌Steps‌ ‌ 1. The‌‌user‌‌can‌‌filter‌‌the‌‌events‌‌based‌‌on‌‌family‌‌members.‌ ‌ 2. The‌‌user‌‌can‌‌filter‌‌the‌‌events‌‌based‌‌on‌‌tags.‌ ‌ 3. The‌‌user‌‌can‌‌create‌‌new‌‌events‌‌and‌‌new‌‌tags.‌ ‌ 4. The‌‌user‌‌can‌‌select‌‌the‌‌day‌‌he/she‌‌wants‌‌to‌‌view‌‌in‌‌the‌‌date‌‌panel.‌ 5. The‌‌user‌‌can‌‌switch‌‌the‌‌calendar‌‌view‌‌between‌‌month,‌‌week‌‌and‌‌day.‌ ‌ Related‌‌UI‌ ‌ ‌ ‌ ‌ Figure‌‌4‌ ‌ 118‌ ‌ Number‌ ‌ Use‌‌Case‌‌3‌ ‌ Title‌ ‌ View‌‌tasks‌ ‌ Short‌‌Description‌ ‌ The‌‌user‌‌can‌‌interact‌‌with‌‌the‌‌tasks‌‌to‌‌see‌‌what‌‌the‌‌family‌‌is‌‌up‌‌to.‌ ‌ List‌‌of‌‌Steps‌ ‌ 1. The‌‌user‌‌can‌‌create‌‌new‌‌tasks‌‌by‌‌typing‌‌in‌‌task‌‌information‌‌in‌‌a‌‌certain‌‌ format.‌‌For‌‌example,‌‌typing‌‌in‌‌"Clean‌‌the‌‌kitchen”‌‌with‌‌the‌‌accomplish‌‌ by‌ ‌date‌ ‌set‌ ‌as‌ ‌tomorrow"‌ ‌would‌ ‌create‌ ‌a‌ ‌new‌ ‌task‌ ‌called‌ ‌"Clean‌ ‌the‌‌ kitchen"‌‌with‌‌tomorrow‌‌as‌‌the‌‌due‌‌date.‌‌Tasks‌‌with‌‌a‌‌due‌‌date‌‌will‌‌be‌‌ added‌‌as‌‌an‌‌all‌‌day‌‌event‌‌in‌‌the‌‌calendar.‌ ‌ 2. The‌‌user‌‌can‌‌mark‌‌tasks‌‌as‌‌completed‌‌or‌‌not‌‌completed.‌ ‌ 3. The‌‌user‌‌can‌‌delete‌‌and‌‌edit‌‌existing‌‌tasks.‌ ‌ Related‌‌UI‌ ‌ Figure‌‌3‌ ‌ ‌ ‌ ‌ 119‌ ‌ ‌‌ ‌‌ ‌‌ ‌‌ ‌‌ ‌ Name‌‌of‌‌Candidate:‌ Shawn‌‌Michael‌‌Linnebach‌‌III‌ Date‌‌of‌‌Submission:‌ December‌‌21,‌‌2021‌ ‌ ‌ ‌ ‌‌ ‌‌ ‌‌ ‌‌ ‌‌ ‌‌ ‌ ‌