C9 · Week 10: All at once
The final project goes real-time, and your pod uses it together.
make your final project real-time, then decide how it behaves when several people use it at once — and write down why
The final project has to be real-time: a change one person makes reaches everyone else within about a second, without a reload. This week it has to be. At the crit your pod opens the app on their own devices at the same time, and what one of them does should show up for the others.
How the change travels (WebSockets, server-sent events, fast polling) is mostly settled by your stack. The decision this crit asks for is one level up, about how the app behaves with several people in it. For example:
- what reaches other people live, and what waits until they reload
- whether people can see who else is here, and how
- what happens when two people change the same thing at once
- what someone sees when they reconnect, or come back the next day
Pick one that matters for your app, decide it by what your README.md says good
means, and write it down in the repo with the options you considered and what
your choice costs. An
architecture decision record
is a good form. Your pod will argue for the option you didn’t pick.
The spec
The brief on this page poses the problem and leaves room for your response. The spec is the fixed contract: what your tutor considers when judging whether that response meets the requirements. Some lines can be checked mechanically; the rest call for human judgement.
- your final project is real-time by the brief's definition, deployed by the cutoff: a change one person makes appears in every other open session within about a second, with no reload
- one decision about how the app behaves when several people use it at once is made and written down in the repo, and you can say why
- the repo shows the process — commits that grew with the work, a process overview in PROCESS.md, and the week's reflection in reflections/crit-9.md
- you can account for how you directed, grounded and corrected the work