-
Notifications
You must be signed in to change notification settings - Fork 0
/
tasks.txt
105 lines (57 loc) · 5.27 KB
/
tasks.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
The idea of this project is to build a single web page app where users can download my notes (txt files)
toward my self-tought journey on web developement.
Tasks:
1. Create a script that allows us to interact with the server OS file system. (done)
2. Create the general flow that will allows our MVC app to render the txt files. (done)
3. Create contollers that will allow the user to download the notes (on a button click for exemple). (done)
4. Create an admin route (secret route), where I can upload txt files to the server OS file system. (done)
5. Create an implementation that will allow the admin to delete file. (done)
6. Create a search engine with a full text search implementation using redis (caching principle). (redis-om is not well established yet)
7. Create a stripe.js implementation that will allow generous users to send me some credit. (do this after launch)
UPDATE: (17th May 2023)
- Replace the middleware that adds the file name to res.locals with a session based storage, to gain performance & also make sure that
the session changes only after some age.
- Make this application work with github gists instead of text files.
To do so, I want to have both systems in the same api.
/legacy for text files
/new for github gists
So for all the present controllers, I need to map them to /legacy routes
Then I need to create new controllers to follow the new gists modal. ( or tweak the existing ones )
The idea is to request a list of my personal github gits, & then when a user goes to view them, we just embbed the
corresponding gist to the page.
to embbed a gist you need to add a script tag like this :
<script src="https://gist.github.com/MassiGy/df85af742b60b1f115b08b64fc35e61c.js"></script>
The above script can be also constructed by querying the github api, and then adding .js extension to the html_url.
github gists api: https://api.github.com/users/MassiGy/gists | replace MassiGy by your username.
html_url: https://gist.github.com/MassiGy/df85af742b60b1f115b08b64fc35e61c
UPDATE (19th May 2023)
Since the last time, I was using sessions for data persistency. The data contained in the session is not user related, it is
just data about the available ressource on the server & the available gists on github.
I made the session using a cookie named "webappcontent" that only has an 1 hour max age. This means that every cookie
will be expired in an hour of time, this helps me to not overload my file system api or the github api.
This was a very big imporvement since the last time, where we were making requests to the file system on every req/res cycle.
Although the system is better, it has a drawback. The issue is about the session store, I was not able to use the file store as always
since it did break my static file rendering (I guess it is a problem due to express static middlewares or the package in itself - @npm/file-session-store);
The update of this time will solve this issue by migrating from session based data persistence to jwt based data persistence. This solves
the store issue since they will be on the client browser. Also the jwt will be just for the web app content data as well. So overall the fact that the user might get hijacked won't do any harm (non-confidential data).
UPDATE (19th May 2023)
Since the last time, I tried to implement the json web token strategy but I had some issues:
- I did not have a client side script that catches the token and put it on localStorage, also I did not have the
script that adds it to the authorization req header every time the client sends a request.
- I tried to store the token as a cookie since the browser adds them to the req object automatically, but the token
due to its format takes too much byte size. (cookies limit are around 4k, and the token exceeded that with my usage )
So I ended up with two solutions,
- Implement a session store that uses some kind of a database on the server side (back to the session strategy).
- find a new way to format my data so as the byte size is smaller and actually send multiple cookies. ( we can have up to 20 cookies per site)
Since the first one increases server cost, I went with the second one.
I've reformated my data, and sent three cookies rather then 1. My byte size per cookie went from 4k+ to 600bytes for now.
I have 18 gists on github, and so 600 / 18 ~ 33bytes, which means that every gits costs 33bytes on my cookie size.
Basic math tells me that I can do up to 4000 / 33 ~ 114 gists before the system breaks.
Also this is actually accurate since github uses 32byte-wide ids. ( +1 byte for our the margin)
So I have around 2 years of gist writing before this system breaks XD
Another solution is to implement the session store, but it takes either a cloud solution like mongoAtlas, or a server side
hosted solution like memcache/redis. The problem with the server side is that it is rather expensive at long term.
The problem with the cloud solution is that every time the user sends a request I need to fire up a request to that service too.
At that case why not just fire up a request to github ? ( is github more likely to go down time then mongo ?)
Also, not mentioning the fact that every request to mongoAtlas slows the response time ( I have a free tier on mongo :/ ).
A potential solution for the up coming break is to use more cookies again XD