diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000000000..cc05638e6
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,3 @@
+# node mudules
+node_modules
+.env
\ No newline at end of file
diff --git a/app.js b/app.js
new file mode 100644
index 000000000..f069ff849
--- /dev/null
+++ b/app.js
@@ -0,0 +1,30 @@
+import express from 'express';
+import httpModule from 'http';
+import { Server } from 'socket.io';
+import path from 'path';
+
+import handleConnection from './events/connection.js';
+import handleDisconnect from './events/disconnect.js';
+import handleMessage from './events/message.js';
+
+const app = express();
+const http = httpModule.createServer(app);
+const io = new Server(http);
+const port = process.env.PORT || 3000;
+
+app.use(express.static(path.resolve('public')));
+app.set('view engine', 'ejs');
+
+app.get('/', (request, response) => {
+ response.render('index');
+});
+
+io.on('connection', (socket) => {
+ handleConnection(socket);
+ handleDisconnect(socket);
+ handleMessage(socket, io);
+});
+
+http.listen(port, () => {
+ console.log(`listening on localhost:${port}`);
+});
diff --git a/course/college 1 - live code voorbeeld.md b/course/college 1 - live code voorbeeld.md
deleted file mode 100644
index 24b3bfb0b..000000000
--- a/course/college 1 - live code voorbeeld.md
+++ /dev/null
@@ -1,109 +0,0 @@
-# Live code college 1
-Gevoed door [https://socket.io/get-started/chat](https://socket.io/get-started/chat) en uitgewerkt in [https://github.com/ju5tu5/barebonechat](https://github.com/ju5tu5/barebonechat).
-
-## Stap 1 - Basic Node + Express (AKA Project Tech)
-Minimale express app, het enige dat nodig is is een `npm init` en `npm install express`. Daarmee heb je vanuit node.js de mogelijkheid te luisteren naar een poortnummer en daar een response op te geven. In dit geval een heel simpele response na een call op `/`, de root van een website.
-
-```
-const express = require('express')
-const app = express()
-const http = require('http').createServer(app)
-
-app.get('/', (request, response) => {
- response.send('
Hallo wereld!
')
-})
-
-http.listen(4242, () => {
- console.log('listening on 4242')
-})
-```
-
-## Stap 2 - Serving HTML
-Het zou naar zijn om alle HTML te *embedden* in javascript. Vroeger in PHP was dit de normale manier van werken maar wij vinden scheiden van inhoud/ vormgeving/ functionaliteit belangrijk. Dus.. we stoppen wat HTML en CSS in een bestand en serveren dat.
-
-```
-const path = require('path')
-
-app.use(express.static(path.resolve('public')))
-```
-
-## Stap 3 - Socket.io
-We runnen het commando `npm install socket.io` om dit pakketje binnen te trekken. Het wordt daarmee automagisch als dependency opgenomen in package.json (nice!).
-
-Is iedereen bekend met de event loop in (node).js? Het is wel een ingewikkeld ding maar ik probeer die heel gesimplificeerd uit te leggen zodat je een idee hebt. Voor de nerds kunnen we daar later dieper op in gaan.. animo? (zie sheet!)
-
-`Socket.io` propageert zelf events, daar kunnen we dus een event listener aan koppelen en iets doen. We passen het server script aan om een console bericht te loggen zodra er een gebruiker verbinding maakt met via socket.io, dat zie je aan het `connection` event.
-
-```
-const io = require('socket.io')(http)
-const port = process.env.PORT || 4242
-
-io.on('connection', (socket) => {
- console.log('a user connected');
-});
-```
-
-Om de boel werken te krijgen moet er wel een gebruiker connecten. Daarom passen we de static file `/public/index.html` aan. `Socket.io` zorgt zelf voor de afhandeling van alle aanvragen op `http://example.com/socket.io/`, daar hoeven we dus verder niets voor te doen (w00t!).
-
-```
-
-
-```
-
-Als een gebruiker connectie maakt zie je de log message die we ingesteld hebben, misschien willen we ook zien wanneer een gebruiker disconnect.
-
-```
-...
- socket.on('disconnect', () => {
- console.log('user disconnected')
- })
-...
-```
-
-Uitproberen in de console met `nodemon start`, nodemon is heel handig tijdens developen want die update de draaiende code zodra er in de source iets veranderd.
-
-## Stap 4 - event propagation
-Het grote idee achter socket.io is het afvuren en versturen (engels propagation) van events. Laten we *client-side* een event op de socket plaatsen als de gebruiker via het formulier een event verstuurt.
-
-```
-...
-var messages = document.querySelector('section ul')
-var input = document.querySelector('input')
-
-document.querySelector('form').addEventListener('submit', (event) => {
- event.preventDefault()
- if (input.value) {
- socket.emit('message', input.value)
- input.value = ''
- }
-})
-
-```
-
-In het kort i) luisteren (!) we naar het ‘submit’ event van het formulier, ii) stoppen de standaardactie (versturen en verversen van de huidige pagina), iii) checken of er inderdaad iets in het invoerveld staat, iv) versturen datgene in het invoerveld dmv. `emit` (uitzenden/uitstoten) en v) maken het invoerveld leeg. Nb alléén de server ontvangt dit event.
-
-Natuurlijk moet er ook op de server *geluisterd* worden naar dit type event op de socket. We voegen de volgende afhandeling toe:
-
-```
-socket.on('message', (message) => {
- console.log('message: ' + message)
-})
-```
-
-Check het resultaat in de console! Okee we zijn nu op de server, elke client die connect kan berichten sturen die `console.log`ed worden. Nu moeten alle clients nog weten dat er ook berichten zijn. We sturen opnieuw via `emit` een event op de socket, nu vanaf de kant van de server. Nb. álle clients krijgen dit event.
-
-We breiden het script op de client uit om iets met dit event te doen, dat doen we door het toevoegen van een.. je raad het al.. event-listener. Voeg de volgende code toe.
-
-```
-...
-socket.on('message', function(message) {
- var element = document.createElement('li')
- element.textContent = message
- messages.appendChild(element)
- messages.scrollTop = messages.scrollHeight
-})
-```
-
-En klaar is onze barebone chat app.. chat mee op [https://barebonechat.herokuapp.com/](https://barebonechat.herokuapp.com/)
\ No newline at end of file
diff --git a/course/peer-review.md b/course/peer-review.md
deleted file mode 100644
index e48005d17..000000000
--- a/course/peer-review.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Peer review
-
-## Goals
-- Get feedback on your work
-- Check if your documentation is understandable
-- Find out where you stand in relation to learning goals for this course
-
-## Preparation (please do this before attending)
-- Push the latest changes to your readme, code, and/or wiki
-- Make sure you’ve read and understand [the rubric](https://github.com/cmda-minor-web/real-time-web-2021#grading) for this course
-- Read up on [how issues fit into the Github workflow](https://guides.github.com/features/issues/) and make sure you know how to [write useful issues](https://upthemes.com/blog/2014/02/writing-useful-github-issues/)
-- Start a call with your sub-team (eg. Squid B.1 or R2D2 C.2) in MS Teams
-
-## Peer Review
-Write feedback in issues on the repository of your peers, Use a separate issue for each point you’re making. Remember, positive feedback is also welcome and can be put into an issue! Follow the steps below for each of your sub-team members.
-
-### Steps
-- Scan your buddy's repository
- + Does the repo have an apt description?
- + Is there a link to the live demo at the top?
- + Are any files in the repo that shouldn't be there like an .env file or node_modules?
- + Is there a section about the concept, install notes, data life cycle, external API, and real-time events?
-- Try to understand the concept
- + Read about the concept in the readme, do you understand what the app does?
- + Open up the live link (if it's already alive) and play around with the app
- + Review the app's functions in an issue, feel free to add cool new ideas in an issue
- + Test the app in multiple tabs, does multi-user functionality work as expected?
-- Understand the data life cycle
- + Are all the app's components present in a visual diagram?
- + Is it clear what data is stored for each component?
- + Is it clear how components communicate with each other? (socket, polling, OAuth)
- + Can you follow where real-time data is created?
-- Check the real-time events
- + Are all custom events described?
- + Can you imagine how the client-server communication works now that you know which events are used?
-- Review the API info
- + Is it clear what data the external API offers?
- + Are instructions present on how to get a key from the API and how to connect to it?
-### Switch!
-Follow the steps again for each of your sub-team members, add issues for feedback not already mentioned, add your own insights to issues created by other sub-team members.
-
-## Wrapping up
-- Review the issues that were created for your own repo. Ask your reviewers about them if you don't understand.
-- Respond to the issues with a message describing which action you take. For instance: valid point, will fix. Or: I won't fix this because of ...
-- Close issues when they are solved.
\ No newline at end of file
diff --git a/course/week-1.md b/course/week-1.md
deleted file mode 100644
index eeb9111d2..000000000
--- a/course/week-1.md
+++ /dev/null
@@ -1,102 +0,0 @@
-# Assignments for week 1
-
-## Intention
-After all you learned so far, you now will learn how to build real-time applications, and rule the world!
-
-## Assignments
-1. [Make it so! (team)](#assignment-1-make-it-so)
-2. [Make it so! (individually)](#assignment-2-make-it-so)
-
-## Assignment 1: Make it so!
-This is a team exercise which means you work together on one repository. (Of course you will all fork it if the work is done so you’ve got your own copy in your own portfolio ;)). During this course we will use *readme driven development* (RDD) which is a way of organising your work. Use this - relatively simple - assignment to get a grip on the way you set up a project in this course.
-
-### Readme
-Start out by forking [this repository](https://github.com/cmda-minor-web/real-time-web-2021) to one of your github accounts. Add all your team members as collaborator so you can work together.
-
-Read this [article about RDD](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html) if you haven’t already and look at these [notes about RDD](https://deterministic.space/readme-driven-development.html) and [some of the examples in this gist](https://gist.github.com/stefanbirkner/835b7d0c498b4026f65a). Discuss findings, insights and/or allergies you encounter in with team. As you will be using markdown a lot when writing readme files you might want to freshen your knowledge by scanning [mastering markdown](https://guides.github.com/features/mastering-markdown/).
-
-Write your [README.md](../README.md) and get started on your project. As a team you will discuss details, make sketches, make decisions, divide tasks etc. Write all of this down so everyone has an idea of what to work on.
-
-*Note: keep your documentation up-to-date while working on your project!*
-
-*Note: Keep a teams meeting open in your squad channel while you work so we can find you and invite us into your meeting when you need help.*
-
-### Coding Style
-Maybe you already have a preferred code-style, maybe you want to try something else. Discuss the style you will use during this project and write up a few basic rules in a section in your readme. You can look at some of the style guides below but keep in mind that these are very extensive, for this project (and your own sanity), please keep it simple.
-
-Set up at least an [npm script](https://docs.npmjs.com/cli/run-script). You will probably want some integrations with your editor. Use Nodemon or similar to allow instant reloading while developing.
-
-#### Resources
-*Styleguides:* [w3schools.com .js conventions](https://www.w3schools.com/js/js_conventions.asp), [Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html), [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript)
-*Linters/auto-formatting:* [xo](https://github.com/xojs/xo), [standard](https://github.com/standard/standard), [prettier](https://github.com/prettier/prettier), [eslint](https://github.com/eslint/eslint), [vscode marketplace](https://marketplace.visualstudio.com/search?term=ES)
-
-### Serving static files
-Set-up [Express](https://expressjs.com/en/4x/api.html) for static file serving or templating (optional). Implement your team page so that it will be served through express.
-
-### Implement socket.io
-Set-up [socket.io](https://socket.io/). Create a basic real-time app using sockets. Bare minimum is a successful message from client to server and from server to all connected clients (“round trip”). You can use the [live coded example](https://github.com/ju5tu5/barebonechat) or the [chat demo from socket.io](https://socket.io/get-started/chat/) to get started.
-
-### Deploy on Cyclic.sh
-Get your app running on [Cyclic](https://www.cyclic.sh/)! Add a link to your live demo to your project and a screenshot showing of your team page including the new chat functionality at the top of your readme.
-
-**Note:** Don’t 😱 if this doesn’t work out: there’s plenty time to deploy in week 2 or week 3. But it may be advantageous to deploy now so you can make sure all team members understand how to do this.
-
-### Extra challenges
-Try to add an extra feature from the list below to your basic chat app. Do this one step at a time, each time discussing with your team what feature would be nice and how you would go about implementing it. Ask for help if you need it! **Note**: Update your readme vigourously ;)
-
-- Add support for nicknames.
-- Broadcast a message to connected users when someone connects or disconnects.
-- Don’t send the same message to the user that sent it. Instead, append the message directly as soon as he/she presses enter.
-- Add “{user} is typing” functionality.
-- Show who’s online.
-- Add private messaging.
-
-### Great job! Now wrap it up...
-Review the project as a team, create issues for everything that needs extra attention if you would have more time. Update [README.md](../README.md) to reflect the latest changes, take new screenshots, link to all team members etc. Finally, have all team members fork this repo so you each have a copy in your own Github account - it’s your technical portfolio.
-
-## Assignment 2: Make it so!
-This individual exercise is not alltogether different from [assignment 1](#assignment-1-make-it-so) - the one you did as a team.. remember? It even bears the same name! For assignment 2 (this one) you will collect all of your experience and go full-out on a unique realtime app. Again you will use *readme driven development* (RDD). Use this assignment to start your adventure towards comprehension of the realtime universe.
-
-### Readme
-You have probably forked your team project at the end of last assignment. Create a new branch called ‘team-page’ and switch back to the main branch. By branching out we’ve created a snapshot of this repository at this point, you can always find the code by switching to the ‘team-page’ branch. You will be working on this project by yourself so there is no need to add collaborators to Github.
-
-Think up unique features that will make your chat much more interesting. What is unique? Not unique are storing nicknames, showing who’s online or any of the other feature requests listed at the bottom of the [socket.io tutorial](https://socket.io/get-started/chat/). Unique is using D3 to structure text into SVG art, using words to fight each other in a text based game, additional features you can earn if you stay in chat long enough. It doesn’t even have to be a chat app, just use the socket.io framework.
-
-Think of something that matches your skill level. If you have trouble understanding the basics of socket.io, focus on the basics (and talk to us if you need help).
-
-Write your [README.md](../README.md), use the resources below and *make it so*!
-
-#### Resources
-You’ve probably read all these before in [assignment 1](#assignment-1-make-it-so):
-- [article about RDD](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html)
-- [notes about RDD](https://deterministic.space/readme-driven-development.html)
-- [some RDD examples](https://gist.github.com/stefanbirkner/835b7d0c498b4026f65a)
-- [mastering markdown](https://guides.github.com/features/mastering-markdown/).
-- [npm script](https://docs.npmjs.com/cli/run-script)
-- [w3schools.com .js conventions](https://www.w3schools.com/js/js_conventions.asp)
-- [Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html)
-- [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript)
-- [xo](https://github.com/xojs/xo)
-- [standard](https://github.com/standard/standard)
-- [prettier](https://github.com/prettier/prettier)
-- [eslint](https://github.com/eslint/eslint)
-- [vscode marketplace](https://marketplace.visualstudio.com/search?term=ES)
-- [Express](https://expressjs.com/en/4x/api.html)
-- [Socket.io](https://socket.io/)
-- [Live coded example](https://github.com/ju5tu5/barebonechat)
-- [Chat demo from socket.io](https://socket.io/get-started/chat/)
-- [Cyclic](https://www.cyclic.sh/)
-
-### Extra challenges
-Again, try to add extra features from the list below to your basic chat app. Do this one step at a time. Ask for help if you need it! **Note**:Again, update your readme zealously :P
-
-- Add support for nicknames.
-- Broadcast a message to connected users when someone connects or disconnects.
-- Don’t send the same message to the user that sent it. Instead, append the message directly as soon as he/she presses enter.
-- Add “{user} is typing” functionality.
-- Show who’s online.
-- Add private messaging.
-
-*Extra challenge: Start working on your final app. [Look at the exercises from week 2](./week-2.md), pick an API and think of a strong concept. Start working on that instead of a barebone app*.
-
-*Extra challenge: Instead of socket.io, use the native [server-sent-events](https://www.voorhoede.nl/en/blog/real-time-communication-with-server-sent-events/)! It works very well although sending messages from client to server is trickier.*
\ No newline at end of file
diff --git a/course/week-2.md b/course/week-2.md
deleted file mode 100644
index 7d290711e..000000000
--- a/course/week-2.md
+++ /dev/null
@@ -1,90 +0,0 @@
-# Assignments for week 2
-
-## Intention
-Last week you built a basic socket web app. The purpose was to learn about real-time communication using websockets. This week you’re going to take it to the next level and build a **meaningful** webapp that consumes an external source.
-This week we will focus on client-server communication and data management.
-
-## Assignments
-1. [(Proof of) Concept](#assignment-1-proof-of-concept)
-2. [Proof of Concept](#assignment-2-proof-of-concept)
-
-## Assignment 1: (Proof of) Concept
-Let’s create a concept! Why..? Because we always create a concept.. You can start either by writing the readme for a **meaningful** realtime application and then finding a matching API; or by looking at existing realtime APIs and finding meaningful realtime uses for them. Choose your approach and read the corresponding paragraph below.
-
-### Readme
-We’re practicing RDD remember? Start by creating a vague outline for three concepts in your [README.md](../README.md). Make at least three variations so you can pick the best one later on. Make (pencil/paper) sketches to define basic usage, maybe you want to draw a happy little wireframe to demonstrate what you mean. Snap a photo with your phone and add your sketches to the [README.md](../README.md) file. Share your ideas with your teammates, try to find out which of your ideas has the most potential and choose wisely.
-
-Now.. try and describe your finished realtime app as close as possible without touching any code (we know this is hard but please try). Keep in mind: concepts are NOT final products. They are rough drafts that give an idea of how your **meaningful** realtime app could take shape. Here are some hints:
-- What do you need to write to show how to use this?
-- What features do you need to show so that other people understand what you are aiming for?
-- How do you want your realtime app to be used?
-
-Make some more sketches, add comments, highlight core functionality etc. to make your concept clear as daylight. Again, snap a photo with your phone and add your sketches to the [README.md](../README.md) file.
-
-### Pick an API
-Time to find an API that either carries your concept or that you can build a concept on (@cmd: remember project web last year?!) Here's a [list of some realtime APIs](https://docs.google.com/spreadsheets/d/1YKMTvdWVbzJ-CXDCHBEH2n3KofcQTN7EerTOEXy9MHI/edit?usp=sharing) we’ve collected for you. Let us know if you want to add any and I'll make you a collaborator.
-
-You could, for instance, use an [API that tracks the number of crypto currency transactions globally](https://www.coinapi.io/) and estimate their CO2 impact (per currency or per transaction).
-
-Or, you might use Amsterdam's [real-time open trash API](https://api.data.amsterdam.nl/afval/) to figure out which neighbourhoods produce the most (plastic) trash.
-
-You could even track a trend on twitter to show the status of an important development like the recent [#trashtag event](https://twitter.com/search?q=%23trashtag&src=typd)
-
-**Your external data source should be real-time (like a twitter feed).** If you want to build an app that uses a data source that can't be consumed in real-time (or by polling external data that changes regularly) there is an alternative. Create an app where you use a non real-time external source but where your users can manipulate the data model on your server in real time. Like this [drawing app made by Fenna de Wilde](https://live-draw.herokuapp.com/) or this [game made by Mees Rutten](https://github.com/meesrutten/real-time-web). If you don't use a real-time external data source, please check with a teacher if your concept is sufficient to pass the course.
-
-Pick a data source and define what you want to do. You can use a real-time source you find by yourself (be weary of OAuth, poorly documented, strict rate limiting etc.) or you can pick one from [our list](https://docs.google.com/spreadsheets/d/1YKMTvdWVbzJ-CXDCHBEH2n3KofcQTN7EerTOEXy9MHI/edit?usp=sharing). If you find outdated information in this list, please update it 🙏🏼.
-
-### Data modelling
-Describe the API you intend to use, including it’s properties (rate-limiting, authorization method, API methods, etc.). Use [data modelling techniques](https://www.ibm.com/cloud/learn/data-modeling) to map the data in your API to get a grip on the structure of the data you will use. If you’ve picked a really extensive API you only need to map those parts you will actually use in your **meaningful** realtime app. Please start out by using a pencil and paper to model your data. Begin with a conceptual datamodel, adding more and more detail to move through a logical towards a physical data model. Don’t spend too much time on getting the details on relations... Snap a photo with your phone and add your sketches to the [README.md](../README.md) file.
-
-**Hint:** if you really want to go berserk on the data-model you can use your favourite drawing program or [https://asciiflow.com/](https://asciiflow.com/) if you want to let your inner nerd out (example below).
-
-```
-┌─────────────┐ ┌──────────┐
-│uniqueID:int ├──────────┤thisID:int│
-│whatever:str │ │what:str │
-│data:blob │ └──────────┘
-│resides:str │
-│in_your:date │
-│API:str │
-└─────────────┘
-```
-
-### User testing?!
-Test your concept against team- and/or squad-members. Ask what they think about your concept and if they have any additions of their own that can help you along. Write down everything they say and refine your concept.. Do this at least three times..
-
-## Assignment 2: Proof of Concept
-So you’ve got a concept? And a grip on your API’s data? Nice..! Your next step is testing if you can actually build a reliable frontend based on the chosen API. Start out by building a spike solution testing the core idea. Once you’ve made sure you can do this you get a grip on the data-flow in your **meaningful** realtime app by creating a data lifecycle diagram. Finally you can set out to create a nice, semantic and user friendly representation of the API data in your frontend.
-
-### Build a spike solution
-A [spike solution](http://wiki.c2.com/?SpikeSolution) is a [well documented](http://wiki.c2.com/?SpikeDescribed) way of testing out a core concept in code. It’s usually a throw-out piece of code to make sure the idea you’ve got will work out. Let’s go!
-
-Reflect some of the data from the external API in a frontend view. The first step is to have your server consume data from the external source. Then you'll want to send that data to user. Finally, the frontend should deal with the data and show some HTML content.
-
-#### Resources
-- [npm script](https://docs.npmjs.com/cli/run-script)
-- [Express](https://expressjs.com/en/4x/api.html)
-- [Socket.io](https://socket.io/)
-
-### Data lifecycle diagram
-What data lives in your app universe? What are the entry points of data in your app? Where can the data be manipulated from? If you want to answer these questions, making a data lifecycle diagram can help. Check out [the slides]() if you need a recap and follow the steps described below. Here's an [overview of the symbols](https://www.gliffy.com/blog/how-to-flowchart-basic-symbols-part-1-of-3) you can use and their meaning.
-
-1. Draw each of the major components of your app (usual suspects: client, your server, external resource server)
-2. Write under each component what’s inside its data model
-3. Add lines for different pieces of data shared between components
-4. Add information to your diagram showing the methods for getting and exposing data (e.g. pub-sub, request over socket, OAuth authorization, input validation)
-
-Add the model to your [README.md](../README.md). **We will check this during your assessment!** You may of course replace the sketch with a proper visualisation. What’s that? Of course you can use [https://asciiflow.com/](https://asciiflow.com/) you nerd...
-
-### Building a ‘nice’ frontend
-Now that you have a *spike* that implements the core idea and grip on the *data lifecycle* for your **meaningful** realtime app, you can use everything you have learned in this and other courses to create an accessible, user-friendly, WCAG proof frontend for a realtime API. If you’ve got the frontend set-up, work on a way for your user to change the data on the server using sockets.
-
-### Extra challenges:
-If you're certain you can meet the baseline for this course as per [the rubric](https://github.com/cmda-minor-web/real-time-web-2021#grading), these are good challenges to add:
-
-- Security (validate user requests server side)
-- Mix different communication methods (SSE, XHR/Fetch, Sockets, Long Polling)
-- Offline Support (what happens when the source is unavailable, what happens when the client temporarily loses their connection to your server?)
-- Add publication subscription model too elegantly keep clients up to date
-- Don't use socket.io for client server communication but try the native implementation instead.
-
diff --git a/course/week-3.md b/course/week-3.md
deleted file mode 100644
index f01f0bd81..000000000
--- a/course/week-3.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# Assignments for week 3
-
-## Intention
-Last week you started work on a **meaningful** webapp that consumes an external source. This week you will learn how to store and serve data from an external source to your own clients. We'll also provide extra challenges, it's up to you if you want to add fancy features or make the app more secure. Just be sure to check your features against [the rubric](https://github.com/cmda-minor-web/real-time-web-2021#grading) and to always properly test with multiple users.
-
-## Assignments
-1. [Data management](#assignment-1-data-management)
-2. [User testing](#assignment-2-user-testing)
-3. [(Optional) Not ignoring the UI stack](#optional-assignment-3-not-ignoring-the-ui-stack)
-
-## Assignment 1: Data management
-You probably want to persist data in a database (tunnel event, initial load, etc.) so set up some of way of storing the data. If you want to start out simple, store the data in-memory first (like an array of data items) and move it to a database later.
-
-Describe the chosen database system in your [README.md](../README.md). Make sure you only store the data you **actually need** for your application. This almost always involves cleaning and restructuring the data. For instance, if the external API you chose returns a complex object with confusing property names, use the functional programming trinity: [map](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map), [filter](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/filter) and [reduce](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce) to change the data to your own format.
-
-## Resources
-Databases: [levelup](https://github.com/level/levelup), [mongo](https://www.npmjs.com/package/mongodb), [redis](https://github.com/NodeRedis/node_redis), [postgres](https://github.com/brianc/node-postgres)
-
-Cleaning data: [array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array), [string](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace), [object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object)
-
-## Assignment 2: User testing
-Make sure that by Friday, your app works with at least three people connected (preferably more) at the same time. They will probably need different parts of your database so you will need to set up some server-side functionality that serves a specific part of your database depending on the type or request a clients sends. These types of requests like “getLatestData” or “sendMessage” form the basis of the API of *your* server. think about which methods/ events your server will have/ allow and describe them in your [README.md](../README.md). It’s okay if not all methods work yet but try to plan ahead, after all, we’re practicing RDD right?!
-
-## (Optional) Assignment 3: Not ignoring the UI stack
-You’ve probably heard something about building robust interfaces [without ignoring the UI stack](https://www.scotthurff.com/posts/why-your-user-interface-is-awkward-youre-ignoring-the-ui-stack/). Try to address all states (blank, loading, partial, error, ideal) in your **meaningful** realtime webapp but take them on one state at a time. Use the scenario’s below to test if your app informs and helps the user to stay in control, even if his internet connection fails..
-
-Build adequate user feedback for the following scenario's:
-- The client can't reach the server. What does the user see? Can they still generate content which is served to the server when the connection resumes? Think about the tunnel event and how socket.io handles this out of the box. Should that behaviour change for your app? Think about queueing (real world) messages bot client and server side.
-- The server can't reach the client. Should it do anything with its data model? Should other users be notified?
-- The server can't reach the external source. Can the app still work? What should the end users see?
-
diff --git a/docs/css/generic.css b/docs/css/generic.css
deleted file mode 100644
index 79f01b67f..000000000
--- a/docs/css/generic.css
+++ /dev/null
@@ -1,153 +0,0 @@
-:root {
- --cmd-primary: #fff;
- --cmd-secondary: #000;
- --minor-one: #34a8e0;
- --minor-two: #e9590e;
- --minor-three: #3aaa34;
-
- --dark: #000;
- --course: #01cd85;
- --light: #fff;
-
- --groen: #01cd85;
- --blauw: #01b4eb;
- --geel: #f1e40a;
-}
-
-* {
- box-sizing: border-box;
- scroll-behavior: smooth;
-}
-
-html {
- background-color: var(--groen);
- background: linear-gradient(12deg, var(--groen) 46%, rgba(0, 0, 0, 0) 34%),
- linear-gradient(21deg, var(--geel) 56%, var(--blauw) 46%);
- background-size: cover;
- background-attachment: fixed;
- font-family: 'Open sans', Helvetica, Sans-Serif;
- font-size: 1.3em;
- line-height: 1.5em;
- color: var(--cmd-primary);
- padding: 0;
- margin: 0;
-}
-body {
- overflow-x: hidden;
- padding: 0;
- margin: 0;
- transition: all 0.25s;
-}
-h1,
-h2 {
- font-size: 1.6em;
- position: relative;
-}
-a {
- color: var(--cmd-primary);
-}
-a:hover,
-a:focus,
-summary:hover,
-summary:focus {
- background: var(--cmd-primary);
- color: var(--cmd-secondary);
-}
-pre {
- overflow-x: hidden;
-}
-q {
- display: block;
- margin: 1em 0;
- font-size: 1.1em;
- font-style: italic;
-}
-p {
- hyphens: auto;
- hyphenate-limit-lines: 2;
- -webkit-hyphenate-limit-before: 3;
- -webkit-hyphenate-limit-after: 2;
- hyphenate-limit-chars: 6 3 2;
- hyphenate-limit-zone: 2em;
- hyphenate-limit-last: always;
-}
-abbr {
- hyphens: none;
-}
-i {
- font-style: normal;
-}
-ul {
- list-style: none;
- padding-left: 0;
-}
-
-/*
-Header met het logo en de titel
-*/
-body p {
- max-width: 40em;
-}
-body > header {
- padding: 1rem;
-}
-body > header h1 {
- padding-top: 1rem;
- line-height: 2;
-}
-svg {
- margin-top: 0.5rem;
-}
-/* main */
-main {
- transition: transform 0.25s ease-in;
-}
-main > header {
- max-width: 30em;
-}
-section {
- position: relative;
- padding: 1rem;
- display: flex;
- flex-direction: column;
- align-items: flex-start;
-}
-
-/* footer */
-footer {
- padding: 1em;
- border-radius: 0.2em;
- overflow-x: hidden;
- margin-top: 4em;
- color: var(--cmd-primary);
-}
-footer h2 {
- padding: 0.2em 0.3em;
- background-color: var(--cmd-primary);
- color: #000;
- display: inline-block;
-}
-footer h3 {
- margin-left: 2em;
-}
-footer p {
- max-width: 30em;
-}
-footer a {
- color: var(--cmd-primary);
-}
-footer img {
- background: white;
- padding: 0.6em;
- margin: 0;
-}
-footer img[title='wd'] {
- width: 10.1em;
- filter: brightness(1);
-}
-footer img[title='cmd'] {
- width: 6.19em;
-}
-footer img[title='hva'] {
- width: 12em;
-}
diff --git a/docs/css/styles.css b/docs/css/styles.css
deleted file mode 100644
index e6b5972c2..000000000
--- a/docs/css/styles.css
+++ /dev/null
@@ -1,83 +0,0 @@
-html {
- height: 100%;
- background-color: #ff70c5;
- background: repeating-conic-gradient(
- from 0deg at 50% 120%,
- #ff70c5 0deg 0.4deg,
- #ffffff 0.4deg 4deg
- );
- background-size: cover;
- background-attachment: fixed;
-}
-body {
- color: black;
- font-weight: 400;
-}
-a {
- color: black;
-}
-h1 {
- font-size: 10vw;
- margin: 0;
- margin-top: 60vh;
-}
-h1 em {
- font-size: 2rem;
- display: block;
-}
-h2 {
- font-size: 2em;
- margin-top: 1.5em;
-}
-section > ul {
- display: flex;
- justify-content: space-between;
- list-style-type: none;
- padding: 0;
- margin: 0 -1rem;
-}
-
-section > ul li {
- display: flex;
- flex-direction: column;
- align-items: center;
- margin: 1rem;
-}
-
-ul img {
- border: 2px solid var(--light);
- margin-top: 2em;
- margin-bottom: 2em;
-}
-img {
- max-width: 100%;
-}
-section#lecturers ul {
- /* flex-wrap: wrap; */
-}
-section#lecturers li {
- width: 45%;
- text-align: center;
-}
-
-section#lecturers img {
- border-radius: 100%;
- margin-right: 1em;
- width: 20vw;
-}
-section#lecturers a {
- white-space: nowrap;
-}
-article {
- margin: 2em -2rem;
- background-color: rgba(255, 255, 255, 0.1);
- padding: 2rem;
-}
-
-.examples img {
- max-width: 25vh;
-}
-footer {
- font-style: italic;
- color: #000000;
-}
diff --git a/docs/img/placeholder.png b/docs/img/placeholder.png
deleted file mode 100644
index 41d321d9a..000000000
Binary files a/docs/img/placeholder.png and /dev/null differ
diff --git a/docs/index.html b/docs/index.html
deleted file mode 100644
index a51e955ba..000000000
--- a/docs/index.html
+++ /dev/null
@@ -1,65 +0,0 @@
-
-
-
-
-
-
-
-
-
- Realtime Web - Minor Web Development - CMD Amsterdam
-
-
-
-
-
Realtime Web
-
-
-
-
Description
-
During this course you will learn how to build a real-time application. You will learn techniques to setup an open connection between the client and the server. This will enable you to send data in real-time both ways, at the same time.
This course has a Code of Conduct. Anyone interacting with this repository, organisation, or community is bound by it. Staff and students of the Amsterdam University of Applied Sciences (Hogeschool van Amsterdam) are additionally bound by the Regulation Undesirable Conduct (Regeling Ongewenst Gedrag).
- Shyanta Vleugel ... -
- - Justus Sturkenboom Philosophy/ Computer Science Lecturer at CMD Amsterdam - and Frontend Design & Development. -
-