EPIC: Clarifying Goals/Roadmap for Image Uploads Project

Apologies for not making this clear earlier. I _thought_ it [was](https://github.com/dwyl/technology-stack/issues/67#issuecomment-437145610). But on reflection it _really_ wasn't. 🤦‍♂️
So I'm going to try and clarify. 🤞

We need a _standalone_ image uploading App because images are used in _many_ situations:

A. **_General_ Communication**: we send many images (e.g: via Signal) each day;
images often communicate an idea _considerably_ faster than text.
B. **Business**: accounting, banking, insurance, design, law, architecture, engineering, construction, etc. all employ image uploading, sharing, review & approval. If we have good image uploading and OCR we can build great business tools.
C. **Social**: there’s a _reason_ the most valuable valuable social networks ([Instagram](https://github.com/dwyl/home/issues/29), Snapchat, TikTok, etc.) are based on images (and now video). It comes back to the communication speed; our eyes can process an image very fast and thousands of words can be conveyed in a single image.

We can build _many_ different kinds of Apps if we get image uploading “right”.

# The Goals of the Image Uploads (`imgup`) Project are:

1. A **_fully_ functional image uploader** that works on **_any_ device** (Mobile, Desktop & API)
with an intuitive/familiar interface
that a **_completely_ non-technical `person`** can use to **_easily_ upload** a **image/photo**. 📸
There should be no "landing page" or button/link to click to upload; zero friction.

2. A **_robust_ `REST API`** with **_excellent_ error handling + messages**
that we can use from any other platform e.g. our **`Flutter`** [App](https://github.com/dwyl/app). 📱

3. **Comprehensive documentation + instructions** for recreating the upload code, interface and `REST API` that _anyone_ can follow (yes, including [`ClosedAI`](https://news.ycombinator.com/item?id=35163587)... 🤖🙄). The better our docs the more people will consider contributing improvements. 🤞 The better the docs on a "showcase" project the _much_ easier it is for you to get your next "job" or recruit people to your Startup. 💭

5. **_Real_ Tests that _fail_** when **something goes wrong**. **_Not_ Mocks** that **_always_ pass** and give **_`false`_ positives/negatives**. We have built projects that upload to `AWS S3` in the past and written _real_ tests. e.g: https://github.com/dwyl/aws-lambda-deploy/blob/master/test/05_upload.test.js If we cannot figure out how to create **_real_ tests** (AKA "end to end tests") for our project(s) then we have _failed_. Yes, I _know_ that this is ironic considering we have the [`aws-sdk-mock`](https://github.com/dwyl/aws-sdk-mock) project, but that is for calling specific AWS methods in a complex `JS` project where people don't _want_ end-to-end tests. 👩‍🔬

6. **Logging which device** made the upload so that we have some metrics: 📈

7. **`Auth`** to restrict who can upload files beyond a certain size e.g: allow anonymous uploads up to `1mb` to _test_ the demo App and then if `people` authenticate allow uploading up to `10mb` and for paying customers e.g. Wedding Photographers taking `43 megapixel raw photos` allow uploads of unlimited size. Spin up a dedicated Fly.io instance to avoid crashing on `100mb+` files.

8. **Re-size** and optimise (compress) large images to save bandwidth on mobile devices. 📱
We already have a good proof-of-concept for this thanks to @LuchoTurtle 🎉
But it currently only creates [`200px`](https://github.com/dwyl/imgup/blob/0366a9184f404115fb3c18c17cd90eebc04aaafa/an_aws_sam_imgup-compressor/src/index.js#L21) thumbnails that are _tiny_ on any screen.
e.g: https://s3.eu-west-3.amazonaws.com/imgup-original/zb2rhe5aFXPKonoWchLRYo9yJDqWyUdUeTQ6MQQJsTWnzzNum.jpg
Becomes: https://s3.eu-west-3.amazonaws.com/imgup-compressed/zb2rhe5aFXPKonoWchLRYo9yJDqWyUdUeTQ6MQQJsTWnzzNum.jpg
We need to make resizing dynamic (dependent on the screen size of the device)
***or*** pick a frequently used screen size like `iPhone` and `iPad` and render for that.
See: https://github.com/dwyl/imgup/issues/99

9. **Use URL shortening** & redirection (proxy) to serve images with **shorter URLs** e.g:
Instead of requesting the image directly from `S3`:
https://s3.eu-west-3.amazonaws.com/imgup-compressed/zb2rhe5aFXPKonoWchLRYo9yJDqWyUdUeTQ6MQQJsTWnzzNum.jpg
The `imgup` app acts as a `proxy` and the URL can be _much_ shorter:
https://dwy.is/zb2rh uses the _minimum_ number of characters from the `CID` so the `URL` is as short as possible.
Request latency should be minimised to

Related Side Quest: https://github.com/dwyl/linky/issues/13 🔗

9. Allow requesting _several_ sizes of compressed images via URL params without changing the filename e.g:

10. _Eventually_ migrate off `AWS S3` to something `else` to not waste cash... 💸
e.g: BackBlaze https://github.com/dwyl/technology-stack/issues/63 -> https://github.com/dwyl/imgup/issues/98
***or*** investigate [**`IPFS`**](https://github.com/dwyl/learn-ipfs) But we need to run tests on request/response times (latency), durability and figure out how to do the resizing/compression. 💭

As you can tell from this list, we have already shipped a couple of the features.
But there's still quite a lot left.
I will work on splitting it all out into sub-issues/tasks. 🧑‍💻 ⏳