Learning how to show images in UICollectionView: http://www.kaleidosblog.com/uicollectionview-image-gallery-download-and-display-images-inside-the-cell
Creating a node KOA2 placeholder project: https://github.com/echowaves/WiSaw.node
I will be using KOA2, because it's the latest and greatest, it addresses the "callback hell" elegantly with async/await construct and avoids the "generator functions hell" which KOA1 suffers from.
Side Note: if you think you can just download some node.js boiler plate project off the web and use it -- think again. In the past I tried at least a dozen of such projects, none of which really did what I needed. So, I ended up combining various things from various sources into my own boilerplate project which works for me. Will it work for someone else? Most likely -- no. But this is what I will be using for WiSaw to give me some initial jumpstart.
Setting up Postgresql RDS instance. Going with micro type for now, still it's going to cost me $25 per month. Nothing comes free, but, this is a small price to pay to see if your experiment ever succeeds.
Side Note: I recently have learned from someone, that RDS has a limit which is not widely advertised. Once you get into the high enough IO, it will simply stop working and you will not be able to buy your way out of it. The only option you will be left with is to host the DB yourself (you can still do it on AWS EC2 instance). That's a good problem to have, and I will definitely not have to worry about it for a while, so RDS is still a great option in my case.
Even though this project is just an experiment, it's still a good idea to take care of basic common sense security issues upfront. Let's make sure we never check in any passwords or sensitive configuration data into the repo. Let's store this type of config data in the env vars. The sample .env.example file will be checked into the repo so that we do not forget what variable we need to configure the run-time environment.
Let's design the database now. It's going to be super simple. Just 1 table. The table name will be "Photos".
Yes, Postgresql is that great -- it has a data type called "uuid", so we will use that out of the box.
imageData: bytea -- we will store the image right on the table. Technically, it would be more proper to store the image data in s3 bucket. In my case, I feel, it would be easier to store the binary data right in the database. Setting up the s3 bucket, keeping it synchronized with SQL store -- all this would require extra work, and would not serve any benefit. Eventually, it should not be difficult to redesign this part and do it the canonical way. Keeping everything in SQL for now is much simpler. BTW, the table is generated by a migration, which is a feature of sequelize.js npm. After running my migration I encounter something weird -- I have to put the table name as well as columns in quotes, otherwise plsq will not recognize/autocomplete it. Not sure, if this is the sequelize migration issue, or some postgresql config option. If someone knows -- let me know. I'm not spending time on figuring this out and continue moving on.
Next, working on photo taking in iOS. The photo will have to be stored on the device as well as sent over the wire. First, will implement storing the images on the phone. We will implement the API interaction when the API is ready for us to use. Tried half a dozen different online blogs tutorials for simple photo taking, most of them are outdated. The only one which worked for me is: https://makeapppie.com/2016/06/28/how-to-use-uiimagepickercontroller-for-a-camera-and-photo-library-in-swift-3-0/
The image orientation is not handled properly out of the box which is super frustrating -- all these little things add up and take time. Following link to the rescue: https://iosdevcenters.blogspot.com/2017/04/image-orientation-before-upload-on.html
Side Note: It used to be that you'd need to read a book, in order to learn or create something new. Not anymore. Most of info comes from blogs these days and sites like StackOverflow. But even Googling for answers can be challenging. Google has it's own way of guessing what may be relevant for you. Even if some blog was incredibly popular in the past, it will not do any good for you, if the software you are investigating has moved a few versions up. Since I prefer to stay on the bleeding edge, typically, when I'm Googling for tech questions, I first look at the time the article was published. Most of the blog posts older then 2017 usually have no value any more, although they may still come on top based on previous popularity.