You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: frontend/docs/ARCHITECTURE.md
+11-10Lines changed: 11 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,15 +6,21 @@ SvelteKit has a lot of features and it is time well-spend to read about them.
6
6
7
7
Mainly we use SvelteKit for the following reasons:
8
8
9
-
* Well-maintained framework that is lightweight and does lead to very fast light-weight frontend code.
10
-
* Rich ecosystem of third party components
11
-
* Open Source
12
-
* Other frameworks, such as React, require you to choose among many different third party components that are not always compatible or different React developers are used to different third party components
9
+
- Well-maintained framework that is lightweight and does lead to very fast light-weight frontend code.
10
+
- Rich ecosystem of third party components
11
+
- Open Source
12
+
- Other frameworks, such as React, require you to choose among many different third party components that are not always compatible or different React developers are used to different third party components
13
13
14
14
# Static assets
15
-
All static assets to be included in the frontend can be found in [../static/](../static/). We have mainly a local copy of the Material icons used in the application. This is also recommended by [Google](https://developers.google.com/fonts/docs/material_icons#setup_method_2_self_hosting). This is faster and more secure than directly fetching them every time when the application us opened by th user from a Google server.
15
+
16
+
All static assets to be included in the frontend can be found in [../static/](../static/) (except fonts/icons).
17
+
18
+
Fonts are NPM packages from [Fontsource](https://fontsource.org/). This means they are included in the web app instead of fetching them during runtime from an external source. You need to install the fonts as devDependency, include them in [../src/routes/+layout.svelte](../src/routes/+layout.svelte) and update the scss file [../src/app.scss](../src/app.scss) with the class used for the fonts.
19
+
20
+
We have mainly a local copy of the Material icons used in the application. This is also recommended by [Google](https://developers.google.com/fonts/docs/material_icons#setup_method_2_self_hosting). This is faster and more secure than directly fetching them every time when the application us opened by th user from a Google server.
16
21
17
22
# SvelteKit
23
+
18
24
We use here [SvelteKit](https://svelte.dev/docs/kit/introduction) to make developing with Svelte simpler and it includes a lot of best practices.
19
25
20
26
# Logger
@@ -29,14 +35,12 @@ We provide a global HTTP Client (see [../src/lib/httpclient/](../src/lib/httpcli
29
35
30
36
By using the HTTP Client you do not need to implement the same error handling functionality in each component that does HTTP requests.
31
37
32
-
33
38
# Accessibility
34
39
35
40
You should take care to implement [accessibility](https://svelte.dev/docs/kit/accessibility) in your application - this makes the application more usable for everyone.
36
41
37
42
Note: We had to deactivate (see [../svelte.config.js](../svelte.config.js) to activate it) one accessibility component: The route announcer. The reason was that it [clashes with Content-Security Policies](https://github.com/sveltejs/kit/issues/11993).
38
43
39
-
40
44
# Security
41
45
42
46
## Content-Security-Policy
@@ -45,17 +49,14 @@ The backend emits content security policy HTTP headers. They are very strict and
45
49
46
50
The application supports strict content-security-policies **_WITHOUT_** unsafe-\*. We do so by letting the backend insert every request to the frontend a random nonce (see [backend documentation](../../backend/docs/CONFIGURE.md)) into the scripts
47
51
48
-
49
52
Note: When running the frontend without the backend then no content security policies are applied. It is thus highly recommended to test all UI functionality with the backend.
50
53
51
54
## Input/Output Sanitzation
52
55
53
-
54
56
As a web frontend it is crucial that you do proper input/output sanitization in frontend AND backend. For the frontend the following mechanisms are relevant:
55
57
56
58
- By default Svelte does not render any HTML/Scripts inserted as variables or by the user: https://svelte.dev/tutorial/svelte/html-tags
57
59
58
60
You should not render HTML/Scripts in variables or by the user, because this allows simple [Cross-Site Scripting attacks](https://en.wikipedia.org/wiki/Cross-site_scripting).
59
61
60
-
61
62
Note: You always need to ADDITIONALLY do sanitization in the backend (see [documentation](../../backend/docs/ARCHITECTURE.md)).
0 commit comments