librematch:design:architecture:start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
librematch:design:architecture:start [2022-10-27 20:45] – simonsanlibrematch:design:architecture:start [2022-10-28 01:27] (current) – [LibreMatch] nimda
Line 1: Line 1:
-====== Architecture ======+====== Architecture (Overview) ======
  
 ===== Example (Bright Sky) ===== ===== Example (Bright Sky) =====
Line 10: Line 10:
 This is taken from the [[ https://github.com/jdemaeyer/brightsky/#architecture | Official repository ]]: This is taken from the [[ https://github.com/jdemaeyer/brightsky/#architecture | Official repository ]]:
   * The brightsky worker, which leverages the logic contained in the brightsky Python package to retrieve weather records from the DWD server, parse them, and store them in a database. It will periodically poll the DWD servers for new data.   * The brightsky worker, which leverages the logic contained in the brightsky Python package to retrieve weather records from the DWD server, parse them, and store them in a database. It will periodically poll the DWD servers for new data.
-  * The brightsky webserver (API), which serves as gate to our database and processes all queries for weather records coming from the outside world.+  * The brightsky web server (API), which serves as gate to our database and processes all queries for weather records coming from the outside world.
   * A PostgreSQL database consisting of two relevant tables:   * A PostgreSQL database consisting of two relevant tables:
     *  sources contains information on the locations for which we hold weather records, and     *  sources contains information on the locations for which we hold weather records, and
Line 22: Line 22:
 {{ ::librematch-arch-draft.png?400|}} {{ ::librematch-arch-draft.png?400|}}
  
-Basically we should poll the Relic Link API endpoints for all data every so many seconds (this time is our minimum latency for our whole system).+Basically, we should poll the Relic Link API endpoints for all data every so many seconds (this time is our minimum latency for our whole system).
 So the time frame in which we see certain information (Match infos, wins of games) and could deliver information to our API. So the time frame in which we see certain information (Match infos, wins of games) and could deliver information to our API.
  
-Then we parse the results into a data structure of ourselves to make error handling easier and also deal with types of data and not handle everything as a huge JSON-Array that is being exposed by the Relic Link API. This data we send to the database which is our persistence layer. From our persistence layer we are able to request data for our endpoints that we expose to the users.+Then we parse the results into a data structure of ourselves to make error handling easier and also deal with types of data and not handle everything as a huge JSON-Array that is being exposed by the Relic Link API. This data we send to the database, which is our persistence layer. From our persistence layer, we are able to request data for our endpoints that we expose to the users.
 Some endpoints may require a Pub/Sub API (e.g. live updates for match information), some are fine with the usual REST-API approach. Some endpoints may require a Pub/Sub API (e.g. live updates for match information), some are fine with the usual REST-API approach.
  
 {{:librematch:librematch_2022-10-09_3_.jpg?600|}} {{:librematch:librematch_2022-10-09_3_.jpg?600|}}
  • librematch/design/architecture/start.1666896339.txt.gz
  • Last modified: 4 years ago
  • by simonsan