Files
legolog/README.md
Ben 3301e111e2 popouts
Former-commit-id: 9313d7ee4fe7d0b30070ecfc9a90ead5f8294ba3
2022-04-22 15:16:36 +01:00

119 lines
7.3 KiB
Markdown

# LegoLog - A lego catalouge for you
Submitted for the Application Programming coursework of 2021/22
# Installation
Input psql database credentials into the .env file.
For more detailed configuration instructions, see the
[docs/CONFIGURATION.md](CONFIGURATION.md) file.
If npm i fails, and you go down the manual route, make sure you run it
again to fill the database with the data.
```bash
npm run setup
```
The demo MUST be run from localhost NOT 129.0.0.1
# Resources / Notes
### Web design (i hate web design)
- https://www.smashingmagazine.com/2009/06/fixed-vs-fluid-vs-elastic-l
ayout-whats-the-right-one-for-you/
- https://blog.hubspot.com/website/fluid-design
- https://jonsuh.com/hamburgers/
### Usable shop design
- https://www.semrush.com/blog/11-great-examples-ecommerce-navigation-
improve-sales/
### Databases
- https://rebrickable.com/downloads/
- https://www.bricklink.com/catalogDownload.asp?a=a
- https://www.eurobricks.com/forum/index.php?/forums/topic/140643-open-
and-freely-available-data-set-of-all-partspieces/
- https://www.sqlitetutorial.net/sqlite-nodejs/
- https://dbschema.com/features.html
# Documentation & Implementation Rationale
Make sure to see docs/ for more detailed module documentation
IMPORTANT MAKE SURE TO READ CONFIGURATION.md BEFORE RUNNING
## 1.1 Content Delivery and Storage of Thousands of Images
Due to the fact that there is ~85000 images of individual lego bricks
and even more of sets. I have chosen not to store them in a database as
a BLOB or anything else like that as it is inefficient. I am also aware
of the pitfalls of a conventional filesystem for storage of mass data.
The way I have approached a solution for this is in preprocessing, by
hashing the name of the image file (which is also the brick / set in
question), I can then use the filesystem's natural directory cache
speedyness to speed up access times significantly.
Take the file name `2336p68.png`, which is a Lego "Cockpit Space Nose",
after a simple MD5 hash, the result is:
```text
"d2ef319ea58566b55070e06096165cb8"
^^^^
```
Using the first four characters in the hash, we can allocate images
into buckets for storage and quick retreval. This acts very similar
to a hash table implemented in the filesystem.
Also due to the non-ability to use subdomains during this project, all
content served like this will use the API suffix, `cdn/`
**This implementation description does not take into account resource
cacheing.**
## 1.2 Database Storage of the Bricks of a Set
Because I am using a bloody RELATIONAL database, I cannot simply store
all of the pieces in a set, in that set without serialising it. So
that's what I did, sets have a JSON field of IDs and amounts for the
easy retrieval of the pieces used in a lego set, unfortunately this
reduces the easyness of using fancy SQL joins to get the piece from
that.
My other option for this was to have a seperate table which includes
relationships, for example, there could be a set|piece|number column
however, there would be not much room for a primary key in that case,
unless some hashing of sets/pieces went on. We will see how I approach
this.
## 1.3 Database
See docs/DATABASE.md for more technical documentation.
# Troubleshooting
Sometimes with installing you must manually install those plugins that
require `node_gyp` to be installed.
The most common to have issues are,
```bash
npm i pg
npm i jest
npm i sharp
```
# Acknowledgements
Jacek Kopecký for the PortSoc Eslint
(I'm sorry I overwrote your 2 spaces rule, I prefer 4)
The MIT Permissive Software License can be found in LICENSE
Copyright 2021/22 Benjamin Kyd