Create systems diagrams of the 2015 MozFest app

mmmavis commented 8 years ago

Part 1: system diagram of the existing 2015 MozFest app

Part 2: from @xmatthewx

[...] you can focus on the current app architecture and how we might evolve it with the current feature set for our next few events.

mmmavis commented 8 years ago

System diagram of the 2015 MozFest App can be found here: https://docs.google.com/presentation/d/13zNzQLXFZzpkQaDz2Sgvr60dZUkEJLYrMZOjVmg0FZQ/edit#slide=id.g1284108e96_4_37

system diagram of mofo convening app 1

let me know if this makes sense / need edits :grin:

/cc @xmatthewx @vazquez @simonwex @ryanpitts

xmatthewx commented 8 years ago

Thanks @mmmavis. Looks good. I just took a peek at your suggestion for revised architecture in the doc. Also looks good and seems reasonable.

I wonder if there's alternate approach we should consider alongside your outline. Each event could have their own repo for data, configs, styles, assets and load the core app as a dependency. That would allow other organizations to build their own event wrapper leveraging the core.

mmmavis commented 8 years ago

hey @xmatthewx

I actually like your idea better! I'll create a 3rd diagram based on your suggestion. Maybe the core app will have default styles, assets, etc and can be overwritten by custom configs.

mmmavis commented 8 years ago

Had a chat with @ScottDowne earlier and we thought having configs live with the core app would be a good starting point. Once that's working, we will re-evaluate and decide whether or not we should separate config from the core app (e.g., to have MozFest config live on its own separate repo etc)

We are thinking about turning the currently jQuery-built Schedule app into a React app, using Pomax's React Example App as the base. Basically the app will have a server but with client side routing as well. We can also eliminate the templating library that the current app uses by utilizing React components.

(I'm seeing the revised Schedule app as a tiny site that consumes and displays session related data)

system diagram of mofo schedule app

Any thoughts? @simonwex @ScottDowne @xmatthewx :grin:

xmatthewx commented 8 years ago

We discussed this earlier today on our stand. We'd like to minimize the amount of engineering required to clean this up for the next event. A full refactor should wait until we have new features that require it. For now, they won't change.

mmmavis commented 8 years ago

system diagram of mofo schedule app 1

I updated the diagram again!

The index.html of the current app includes templates and hardcoded timeslots(so that the script can fill sessions data into the corresponding templates and predefined div blocks). This means every single time when a change to timeslot is made in the Google Spreadsheet it will require us to update this index.html manually.

I decided to pull index.html out from the core app and make it a schedule app builder script instead. The index.html each app has will probably only contain <head> and js dependencies (e.g., jQuery, schedule-builder.js etc). To build the app I'm thinking we can just initiate a Scheduler instance with custom config. And the script will build each view based on the data it receives. So as long as the data is well-formatted I think we should be good with this approach.

I think the challenges might be on the data processor piece (blue block at lower left in the diagram). Since Google Spreadsheet doesn't have much built-in validation, we need to think about ways to constrain the data entered in the Spreadsheet so that the data processor won't run into problems when it tries to parse the information.

Thoughts? @xmatthewx @simonwex

If this plan sounds good I can start filing issues for the next heartbeat. :grin:

ScottDowne commented 8 years ago

I think we should find small chunks from Mavis' plan that we can do now, that ultimately help that end goal, without being a complete rewrite, and without waiting for new features. It means when we're ready to add new features, it'll be much much easier, instead of trying to do it all at once. Thoughts?

xmatthewx commented 8 years ago

This is great. Good separation of concerns. The index shift makes sense. Agreed @ScottDowne – there's no need to wait for new features or do a complete rewrite. Just set the stage to make things easier to use and test new ideas when they're ready.

This looks ready for issues. It might be good to start with a meta planning ticket to set priority or order. But, only if that sounds useful to you.

After, let's set up a milestone and try to identify a heartbeat worth of work that brings the app to next plateau. What's most critical? What's most risky?

mmmavis commented 7 years ago

I have to close this thread since it no longer applies to what we do in this repo (Hive Chicago Buzz schedule).

mozilla / hive-chicago-buzz

Create systems diagrams of the 2015 MozFest app #37