These materials explore Resonate’s technology architecture, particularly the transition from our current Wordpress setup to an independent, integrated setup.
Some details may be out-of-date; see the notes under each resource.
[coming soon]
Inaccuracies? I think its more a question of ‘what has changed’ since
…e.g. small example changing out Twirp framework in favour of GRPC-Gateway and intention to use that across our other GO API’s
These docs were intended to provide a single source of truth on what was being built, by whom, by when and for how much (and where the funds were to be coming from). It’s a model, so that it can be easily discussed and changed at a coarse level so that we could select and shape our near term epics and sprints and get them properly funded and done without constant interruption / changing of direction.
The ‘why’ part of the doc set was intended to explain the rationale for past technical decisions and choices on direction (the ‘to-be’ part of the architecture)… based on the ‘principles’.
It’s OK to create simplified summaries of the architecture / plan for different stakeholder audiences… for example fundraisers need to have a target and a rough idea about the projects and their purpose. Tech volunteers need to know what skills will be needed and when. It’s important that we are consistent and honest overall about what can be done, not tell different stories all over the community forum in different documents. What we do has been discussed in so many different places over the past 2 years (Rocketchat, Trello, Basecamp, Discourse and so on).
These docs are far from perfect and were never intended to be presented as a polished communication tool. They were offered as a scratchpad model to help folks keep the story straight and consistent overall. Ideally we would update them as we get down into design detail and improve our coarse estimating. They can also help us remember ‘why we did things that way’ - sometimes it’s easy to forget parts of the picture if they are not written down - but that does not mean we should not challenge or change things!
Would “Exploring Resonate’s technology architecture” be more accurate as a title? As you say, these are research and planning tools, not communication materials per se. Regardless, they have incredibly good diagrams and explanations of how things work or could work at Resonate. I think your work here is very valuable.
My hope here is that this guide will eventually be a one-stop-shop for those who want to dive deep into learning about our architecture.
Nooo… they are painfully rough and unfriendly and are only a start… this stuff is normally done TOGETHER around a drawing board… needs discussing and explaining. IMHO best done freehand sketches with lots of coffee. Useless if it’s not shared.
Need diagrams…
Lists / catalogs (of the things on the diagrams) … linked to the plan
Some matrices / links between the things
Agree it in principle then put some pretty TLDR comms essentials out for wider consumption…
