Advertisement
Guest User

Untitled

a guest
Oct 1st, 2016
104
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.86 KB | None | 0 0
  1. # Design Document
  2.  
  3. ## Environment
  4.  
  5. ### VMs
  6.  
  7. - Main CMS portal
  8. - Public Facing portal
  9. - Admin portal (behind VPN)
  10. - Main API
  11. - DB (MySQL vs Postgres)
  12. - Data
  13. - Dev Portal
  14.  
  15. ### Django
  16.  
  17. - Settings
  18. - Session store in memcache
  19. - Folder Structure:
  20. ```
  21. + project_name
  22. + docker
  23. - Dockerfile
  24. - docker-compose.yml
  25. + conf
  26. + keys
  27. - dummy.crt
  28. - dummy.key
  29. + server
  30. - nginx.conf
  31. - uwsgi.ini
  32. - project_name.service
  33. - error.html
  34. - project_name.env
  35. + bin
  36. - admin_script.sh
  37. + portal
  38. + apps
  39. + django_app
  40. + libs
  41. + custom_library
  42. + utils
  43. + custom_util
  44. + static
  45. + templates
  46. + settings
  47. - common_settings.py
  48. - local_settings.py
  49. - elasticsearch_settings.py
  50. - celery_settings.py
  51. - .gitignore
  52. - README.py
  53. - requirements.txt
  54. - manage.py
  55. ```
  56.  
  57. ### Celery
  58.  
  59. - Rabbit AMQP
  60. - Flower
  61.  
  62. ### Django-Channels
  63.  
  64. - Redis
  65. - Use for Webhooks callbacks
  66. - Use for Websockets
  67.  
  68. ### ElasticSearch
  69.  
  70. - Analyzers
  71. - Data Structure
  72.  
  73. ## Permissions
  74.  
  75. - Different types of users
  76. - Are we gonna have different access levels for the API?
  77. - Portal permissions vs Agave permissions.
  78.  
  79. ## Notifications
  80.  
  81. - Single application to handle notifications.
  82. - Handle any kind of notification. e.g. Agave notifications or notifications sent to users.
  83. - Rely on Django-Channels to process external notifications.
  84. - Should act only as a service layer and then hand out the processing to
  85. different apps, libs, utils, etc...
  86. - Front-end and back-end should work similarly. As in just acting as a service layer.
  87.  
  88. ## Overall Structure
  89.  
  90. - Framework agnostic library
  91. - Converts agavepy into a friendly object oriented library (agavepy_dsl)
  92. - Gives plenty of room for extensibility.
  93. - Django-app
  94. - Views and models necessary to work with django
  95. - Extensibility is paramount.
  96. - Front-end
  97. - Services that know how to talk to its corresponding api.
  98. - Directives to show corresponding data.
  99. - Providers to be able to customize look and feel.
  100.  
  101. ## Testing
  102.  
  103. - Backend tests (without calling any external service)
  104. - Front end tests (without calling any backend service)
  105. - Functionality tests (backend and frontend without calling any external service)
  106. - Integration tests (careful with this ones)
  107.  
  108. ## Logging
  109.  
  110. - A logging format should be defined.
  111. - When running localhost should log to a local logfile.
  112.  
  113. ## Development workflow
  114.  
  115. - Each module should be developed following the **Overall Structure** points.
  116. - Each structure point should be develope with its corresponding test suite.
  117. - Logging features for each structure point should be evaluated before marked as finished.
  118. - Documentation should for each structure point should be revise before marked as finished.
  119. - Corresponding Splunk reports might be created before marked as finished.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement