Closed ECHibiki closed 1 year ago
More reading
on design patterns
password hashing(rate limitting on bcrypt)
db.Exec inputs
Deep read on Gin
Testing variables should be in a single file and reused
Turn some of these files into an extended Gin library for future projects
Read on Golang time library
More thoughts on DB construction in the future
Read on Golang/Gin's file handling
os.mkdir... how to see if it's a permission or file exists error
"File is an interface to access the file part of a multipart message. Its contents may be either stored in memory or on disk. If stored on disk, the File's underlying concrete type will be an *os.File. " How to select store on file or memory?
The decision of using methods or functions
Expand the degree of user input validation
DB character limit errors expressed to the user
Password auth methods
Tools.go removal of functions into former subpackages and etc.
fuzzing
Gin tests https://gin-gonic.com/docs/testing/ shows how to do unit tests with Gin
Notable is "net/http/httptest"
Converting Twig to an alternative https://medium.com/@kataras/whats-the-fastest-template-engine-in-go-fdf0cb95899b
Use an alternative to the standard regex engine https://nightfall.ai/best-go-regex-library
Using structs for some initializers... Further condense files( runGin args for example ) into structs
Int64 into more generic appropriate types
Pass configs and etc. by reference into function
Fully remove panics
FailureObject should be a map with the FailPosition as a key
Responder's response deletes should go into destroyer. Might be other cases like this
Storage of versions
Status code chekc
Rollback inputs on fail
The above should be converted into a new issue list when the time is right\
[x] Rebuild the mod UI to use dynamic dropdowns
[x] Allow mods to navigate back to home from Create, Edit and Form-List