# 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