- Q1) Why re-write the exisiting angular app?
- Q2) What benefits are being architected in this rewrite of the old app?
- Q3) Why was vue chosen over angular latest version?
- Q4) Why was expressJS chosen over laravel?
- Q5) Should each component be in its own repo?
- Q6) Should a table library be used or developed internally?
- Q7) Why use an auto doc generator?
# Q1) Why re-write the exisiting angular app?
The current angular app was developed to discover the psychiatrists needs. The system could not have been pre-architected to deliver the discovered features.
The current angular app is in 1.x and LTS ends in July 2021. Also good libraries are not being developed on Angular 1.x
# Q2) What benefits are being architected in this rewrite of the old app?
# A. User experience benefits
# A1. Local storage
Reload: When page is reloaded and there is no/slow connection to DB server the page will load from localstorage immediately.
Recall: When a component is already on the doctor browser and the doctor gives the command "rec" then the recommendations show immediately from localcache and api is fired in the back. If the api returns new data the view is updated. (lazy-read)
Write: When doctor adds a rec, the view gets updated. If server update fails then the view is reverted. (lazy-write)
Offline: When doctor is offline and open a patient file they see the page. #not-working
# A2. Responsive
Number: In each table column has priorities. So when less space is available low priority columns get hidden https://phppot.com/css/automatic-column-hiding-using-css-in-responsive-table
Width: When there is more space available the data columns instead of breaking the paragraph into 2 lines use 1 line.
Choice: User chooses which columns to display in browser. This setting is saved in localstorage. Each component has default selection and user can easily revert back to that.
# B. Tech Benefits from eco-system
Temporal DB: No need to maintain created and discontinued related fields. Each table 8 fields are replaced with 3 fields.
ORM:
Server side interaction with DB is through ORM sequelize.
1A. So standard queries are already written. 1B. [DB versioning and migrations can happen.](https://github.com/savantcare/patientfile/blob/master/node-server/models/recommendation.model.js)
Client side vuex-orm
elelemt.io Pre made components
Jest
Application folder framework Industry standard best practives. Decided to use nuxt. This has built in integration with element.io and vuex-orm
GraphQL: So only the required fields are fetched. vuex-orm-graphql
# C. Tech Benefits from improved development practice
Maintain state on the client. When recommendation card state changes the rec panel changes its view automatically. In the current angular app the recommendation panel was listening on socket and then receiving HTML to update its view.
No HTML is generated on server. All view is inside the .vue component. This view works on json returned by the server api. This allows different UIs to be written.
Slim DB: Remove fields not needed and make component DB's consistent and clean.
Review: Code review before making it to master branch
Open source: Better code quality by developing it in open and make it open source from start.
Documentation: using vuepress and vue-stylegudist
# D. Other fields to explore:
- Graphql
- Form management
- Any other nodejs library
# Q3) Why was vue chosen over angular latest version?
Simpler to understand
Useful libraries
Above advantages validated by, more github stars compared to angular or react. Stars are like voting from worldwide developers.
# Q4) Why was expressJS chosen over laravel?
Laravel: Used by 660 and Stars 59K
express nodejs: used by 6.6M and Stars 49K
Sequlize nodejs: Used by 190K and Stars 22K
# Q5) Should each component be in its own repo?
Current choice: Mono-repo https://en.wikipedia.org/wiki/Monorepo
Positives of mono-repo:
- easier to refactor
- new dev can get started without dependency hell.
- No need to cooridate what version of node-server repo works with the current version of vue-client
Negatives of mono repo:
When recommendation a new version is released Sanjay wants to do git pull only for recommendation repo on the prod server. Counterpoint:
But the recommendation repo may depend on a specific version of the service side recommendation repo.
Service side rec repo may depend on a specific version of sequlize.
The dependency graph between rec UI repo and all the other repos is hard to maintain.
Convention over configuration: The multi repo design takes a lot of configuration. Without configuration, During work I need to update docs, node-server and vue-client all at once. When I do a git commit I want tests to get fired and run. When multiple repo the edits take more time. The test running becomes more complicated.
Hence branching is a better idea.
# Q5.1) Why not try branching concept?
Sometimes we need to invite external developers to work on a component and we do not want to give them access to the git repo containing other components. Counter point -> Protecting source code is not the first priority.
# Q5.2) Why is each component not a seperate npm package?
The goal is for recommendation-panel and recommendation-card to have the same vuex store. So when the state changes in recommendation-panel the view of recommendation-card is automatically updated.
The code till 4th May implemented recommendation-panel and recommendation-card as two different npm packages. Different npm packages cannot share the same vuex store.
Hence recommendation-panel and recommendation-card cannot be two seperate npm packages they have to be components of the same vue app.
# Future research
How to keep these files in a seperate repo. How to run them independently. Possible solution: https://github.com/teambit/bit
# Q6) Should a table library be used or developed internally?
Features needed:
- KB to go up and down the data rows
- Multi select using only KB or mouse.
- Actions for each data row invoked using keyboard single key.
- When multiple rows are selected then invoke "Multi select actions"
- Tabbed tables -> First tab shows table 1 and 2nd tab shows table 2. Used at "Your recommendations" "Others recommendations"
For the tabs each tab can be a table component. And the tabs are displayed using Vue’s component element with the is special attribute: https://vuejs.org/v2/guide/components.html#Dynamic-Components
- Drag to reorder rows
# Q7) Why use an auto doc generator?
Decided not to use storybook since want something where the code is auto parsed.
So for vue client side code decided to use vue-styleguidist Ref: https://www.youtube.com/watch?v=ryyAiUYvfY8
Click here for steps to run the doc generator