|
|
@ -846,16 +846,6 @@ 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
|
|
|
|
ability to create multiple client side tools which may address different needs
|
|
|
|
of the users.
|
|
|
|
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 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
|
|
|
|
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
|
|
|
|
Prague in mind. The users are the students and their teachers, groups correspond
|
|
|
@ -866,6 +856,16 @@ also possible to develop their own frontend with their own user management
|
|
|
|
system for their specific needs and use the possibilities of the backend without
|
|
|
|
system for their specific needs and use the possibilities of the backend without
|
|
|
|
any changes, as was mentioned in the previous paragraphs.
|
|
|
|
any changes, as was mentioned in the previous paragraphs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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)
|
|
|
|
|
|
|
|
|
|
|
|
In the latter parts of the documentation, both of the backend and frontend parts
|
|
|
|
In the latter parts of the documentation, both of the backend and frontend parts
|
|
|
|
will be introduced separately and covered in more detail. The communication
|
|
|
|
will be introduced separately and covered in more detail. The communication
|
|
|
|
protocol between these two logical parts will be described as well.
|
|
|
|
protocol between these two logical parts will be described as well.
|
|
|
|