MyPortfolio
NB : This document will always be a work in progress as we are using an agile methodology.
The main purpose for the re-design of MyPortfolio (Portfolio.Next()) is to increase user engagement,
capture useful and relevant user analytics and allow for usage on all modern devices (web application,
mobile/tablets for both android and ios).
It's aim is to allow for easy interaction with the front end using graphs and relevant data for tracking
the affiliates publications and stock recommendations from guru's for eventual trading.
Other benefits of the re-design is that we have already obtained some useful data resulting from a "design sprint"
regarding user experience and user interface with a design prototype, this feedback provides a good level of assurance
before moving forward with the actual implementation.
The system will be built around simple microservices and a pluggable stock data feed.
All affiliates and their subscribers are the targeted user's for the new MyPortfolio.
Context/Overview Diagram
Use Case
The main features of the MyPortfolio design :-
- To empower subscribers viewing their portfolio by providing them with a portfolio app that shows the performance of
both recommended stocks and their own stocks that so it drives user engagement.
- Professional user design and best practices
- Allow for quick feature development
- Admin interface for affiliates to update data, news feeds, other timely information
- Enhance page load times
- Scalable (thousands of concurrent users)
- Robust (High availability)
- Cloud enabled
User Stories
As a user/subscriber I want a list of stocks to add to Portfolio so that I can track their performance
Acceptance Criteria
- Table with list of stocks
- Stocks are listed per affiliate/publication
- Meets the design spec (Shane)
- Fast load time and performance
Tasks
- BE - MS to build the stock list (affiliate/publication)
- BE - MS to get the list of stocks for subscriber per affiliate/publication
- FE - View list of stocks as per design
- FE - Track stocks from list
As a user/subscriber I want a graph to easily view the aggregated values and aggregated history of the stocks
in Portfolio so that I can track their performance
Acceptance Criteria
- View aggregated with list of stocks in a line graph
- Stocks are from the list of selected/tracked stocks
- Meets the design spec (Shane)
- Fast load time and performance
Tasks
- BE - MS to store the tracked stocks per user
- BE - MS to view graph per listed stocks with history week/month
- FE - Graph view with history selector of tracked stocks
- FE - Remove/Add stocks to graph
As a user/subscriber I want load the MyPortfolio application from the existing wp application so that I can view
it without the need to login again
Acceptance Criteria
- Open the Portfolio Tracker in a new window
- If logged in proceed without the need to login
- If not logged in show the login screen to proceed with Portfolio Tracker
- Meets the design spec (Shane)
- Fast load time and performance
Tasks
- BE - MS to handle login via wp with JWT
- FE - Handle login screen if not logged in
As a user/subscriber I want a mobile version of the MyPortfolio so that I can access all the features on the go at any time
Acceptance Criteria
- Some affiliates don't have a mobile version of their site. This will allow a user to have PT on a mobile device
- PWA for Android and IOS as well as Desktop (browser agnostic)
- Meets the design spec (Shane)
- Fast load time and performance
Tasks
- FE - Build PWA for Android and IOS devices
The software architecture overview will best be described in the following diagram
Architecture Overview Diagram
Overview Description
The software architecture is broken up into several layers. The front end will host the actual portfolio tracker application,
view and add stcoks to a watchlist, and view te graphs (6 months data)
The backend is broken up into 2 microservices. The first microservice does all the db initialization and
data migration into the document store in the form of affiliates with a one to many relationship with publications
which in turn has a one to many relationship with stocks
The second microservice is a data translator for the "Rates Engine" lookup, this allows for a pluggable rates engine
that can be integrated into the existing architecture without having to change any data schemas, front end and other microservices.
Architecture Deploy Detail Diagram
Microservices
Each microservice will be embedded into a linux container (preferably using centos7 base images).
The microservice will do one thing and do it well. All microservices will adhere as far as possible to the 12 factor app principals.
API-Gateway
The api gateway actually consists of the api-gateway and a centralized proxy-pass server.
This enables us to make use of a route mesh pattern. The api-gateway can be configured to handle complex mapping
allowing for a single call (i.e for mobile devices) that will aggregate all necessary calls into one json payload.
The proxy-pass can also be configured to allow for easy addition/removal of a microservice.
The api-gateway and centralized proxy-pass server will also be embedded into a linux container (rhel based ubi images).
REST API Endpoints
OpenAPI (3.0) will be used to document all REST API endpoints. The yaml/json api definition file will be stored in the microservice repo
Wordpress Plugins
The wordpress plugins will consume the api endpoints for the relevant microservices
Databases and Caching
All databases (except for the mirrored SQLServer and Data Lake) will be a replicated document store in HA clustered configuration.
Caching does not need to be clustered (HA)
The Data Lake (Hadoop etc) will expose a REST API endpoint and the relevant Json payload will be posted into the agreed schema for MI use
Front End Application
The front end application (Vue.js) is a PWA (progress web app). It is deployed on the Firebase host via the automated
deployment (continuous) tool. The Firebase host then pushes copies of the application to its edge servers in each region.
Analytics Data Event Push
The front end application will push data (in the form of a Json payload) to the data push microservice.
This service acts as an interface to allow for pluggable backend systems to push to. For the MVP the service will
push directly to Lytics but will have the initial capabilities to push to other systems also.
This will allow us then to keep a standard interface for the front end while allowing us then to add "Trackmate" and other systems
API Contract
Please refer to the API documentation that can be accessed directly from each microservice
Entity Diagram
The data diagram is really self explanatory. Bascially each affiliate has many publication which inturn have many stocks.
This means we have 4 collection, affiliate,publications,stocks and watichlist all with the same DB. We use a simple redis cache
for all graph data, this will reduce the traffic to make expensive graph data api calls.
db.createUser({ "user" : "pt", "pwd": "pt", "roles" : [{"role" : "readWrite", "db" : "myportfolio"}]});
curl --location --request GET 'https://servicegateway.agora-inc.com/middleware/data/username/{email}/password/{1234}/' --header 'token: '
curl -k -d '[{"id": "SBR-01", "name":"Test","token": ""},{"id": "BH-02","name":"Banyan Hill","token":""}]' https://nginx-service-portfoliotracker.e4ff.pro-eu-west-1.openshiftapps.com/dbservice/api/v1/setup
curl -k -X '{"affiliate":"Banyan"}' https://nginx-service-portfoliotracker.e4ff.pro-eu-west-1.openshiftapps.com/dbservice/api/v1/migratespecific
curl -k -X POST https://nginx-service-portfoliotracker.e4ff.pro-eu-west-1.openshiftapps.com/dbservice/api/v1/index
curl -k -d '{"stocks": "GOOGL"}' https://nginx-service-myportfolio.apps.aws2-dev.ocp.14west.io/graphservice/api/v1/graphs