expand/CCash
1
0
Fork 0
mirror of https://github.com/Expand-sys/CCash synced 2025-12-16 16:12:14 +11:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update implementation.md

Browse source
This commit is contained in:
William Katz 2021-07-15 21:16:10 -07:00 committed by GitHub
parent 5eaf38baab
commit ef69b29761
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
docs/features/implementation.md
View file

@ -24,6 +24,8 @@ base64 decoding is required for Basic Auth so I used this clean and fast solutio
simdjson was the fastest JSON parsing I could find, its used for request parsing.
## [Drogon webframework](https://github.com/an-tao/drogon)
at the time of making this doc Drogon is the 3rd fastest web framework as per [this](https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite) sites metric of measuring web frameworks, it also has multi threading support.
![image](https://user-images.githubusercontent.com/31377881/125890904-36507318-2183-494d-be83-85af8af863c5.png)
## Sparse saving
#### Saving on close
when the program is interupted with CONTROL + C it will save before closing the webserver, **it will not however save during a crash**.
@ -44,4 +46,4 @@ saving is done using FBE, this slightly reduces file size compared to JSON and i
considering phmap and drogon both massively benefit from being multi-threaded it seemed obvious that the entire program should be, this is enabled by default and manually settable at `MULTI_THREADED`. Below are some graphs visualizing the gain of doing so:
<!-- graph -->
## Backwards Compatible API
versioning is implemented by the endpoints path, for example `/v1`. Breaking changes will ideally be sparse and backwards compatability will be maintained, for example ideally API `v3` instance can still run `v1` endpoints.
versioning is implemented by the endpoints path, for example `/v1`. Breaking changes will ideally be sparse and backwards compatability will be maintained, for example ideally API `v3` instance can still run `v1` endpoints.