# Is there a block diagram that documents how Discourse works

**URL:** https://meta.discourse.org/t/is-there-a-block-diagram-that-documents-how-discourse-works/56037
**Category:** Development
**Created:** [19 Gennaio 2017, 9:09am UTC](https://meta.discourse.org/t/is-there-a-block-diagram-that-documents-how-discourse-works/56037 "2017-01-19T09:09:53Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![JagWaugh](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jagwaugh/32/69335_2.png) [@JagWaugh](https://meta.discourse.org/u/JagWaugh)
#### Post date: [19 Gennaio 2017, 9:09am UTC](https://meta.discourse.org/t/is-there-a-block-diagram-that-documents-how-discourse-works/56037/1 "2017-01-19T09:09:53Z")

</div>

On a similar note, I haven’t managed to find a block diagram of how the system is put together. A block diagram might help new mods and admins get an overview of how a discourse “appliance” works. It would eliminate some queries of the form:

> [@Installed Discourse. Need help understanding code structure](https://meta.discourse.org/t/installed-discourse-need-help-understanding-code-structure/56011):
>
> Forgive me, if this is a really juvenile question. There are routes defined in both ruby on Rails and ember. How the routing is working? Similarly, The views in Ruby on Rail defines the html code and similarly templates of ember. How is everything interacting? Thanks.sweat_smile

The block diagram wouldn’t have to be too detailed, it could be as simple as, well… some blocks indicating what the block is called (droplet, docker, discourse, ruby, rails) with an indication of how the bits communicate with each other, what they do, and how to access them (ssh, /launcher enter app etc), read their logs, and configure/start/stop/update them, how/where their data and configuration are stored, and how to check the health status of each.

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [19 Gennaio 2017, 3:55pm UTC](https://meta.discourse.org/t/is-there-a-block-diagram-that-documents-how-discourse-works/56037/2 "2017-01-19T15:55:24Z")

</div>

Feel free to create such a diagram if you feel it is necessary.

---

<div class="post-metadata">

### Author: ![JagWaugh](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jagwaugh/32/69335_2.png) [@JagWaugh](https://meta.discourse.org/u/JagWaugh)
#### Post date: [19 Gennaio 2017, 4:09pm UTC](https://meta.discourse.org/t/is-there-a-block-diagram-that-documents-how-discourse-works/56037/3 "2017-01-19T16:09:39Z")

</div>

It will take a while before I understand it well enough to create much more than a box with “technical krimram” in the center, and a border composed of the text “There be dragons” surrounding it, but I’ll try and keep some notes.

One of the problems in creating good technical documentation (not just in IT) is that by the time you’ve sussed it well enough to explain it, you tend to have lost track of how much of an enigma it seemed when you didn’t know much about it.

Which kind of ties in with the idea of complaint driven development. Do you remember the IBM and Dec system documentation sets of the '80s? WALLS of manuals, which were generally all detail, and no overview. When you went to decomission a system there was always a cupboard full of manuals, often still in their plastic shrinkwrap.
