From 7fa925fdae9ed35640039f49771abf5e94869e8f Mon Sep 17 00:00:00 2001 From: Petr Stefan Date: Tue, 10 Jan 2017 10:41:47 +0100 Subject: [PATCH] More pictures! --- Rewritten-docs.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/Rewritten-docs.md b/Rewritten-docs.md index ee74a1c..7218d81 100644 --- a/Rewritten-docs.md +++ b/Rewritten-docs.md @@ -812,6 +812,16 @@ server side based on the inputs from the user. This decoupling gives us the ability to create multiple client side tools which may address different needs of the users. +One possible configuration of ReCodEx system is ilustrated on following picture, +where thete is one shared backend with three workers and two separate instances +of whole frontend. This configuration may be suitable for MFF UK -- basic +programming course and KSP competition. But maybe even sharing web API and +fileserver with only custom instances of client (web app or own implementation) +is more likely to be used. Note, that connections between components are not +fully accurate. + +![Overall architecture](https://github.com/ReCodEx/wiki/blob/master/images/Overall_Architecture.png) + The frontend developed as part of this project is a web application created with the needs of the Faculty of Mathematics and Physics of the Charles university in Prague in mind. The users are the students and their teachers, groups correspond @@ -913,6 +923,12 @@ and testing, and it is understood by programmers so it should be easy for a new developer with some experience in client-side applications to get to know with the ReCodEx API and develop a client application. +To sum up, chosen ways of communication inside the ReCodEx system are captured +in the following image. Red connections are through ZeroMQ sockets, blue are +through WebSockets and green are through HTTP(S). + +![Communication schema](https://github.com/ReCodEx/wiki/raw/master/images/Backend_Connections.png) + ### Broker The broker is responsible for keeping track of available workers and