Download &

Have Fun Now!

wisaw itunes store
wisaw google play store

© echowaves. 

Search
  • Dmitry Amelchenko

Day 2 (Saturday) [KOA2 API implementation]

Updated: Apr 9, 2018

  • Started the day by working on wiring up the KOA2 API. The first method GET /api responds with 200, which is a good sign.


WiSaw on localhost

  • Initially, I thought, I will not write any tests to speed the development up. As soon as I started working on the project, I realized -- the fastest way to know your API method works is by quickly writing a test for it. This is what I will be doing next -- writing a test for submitting a new photo through the API and then implementing the post API method.

  • Spent next 3 hours getting simple API mocha test to work with async/await -- egh. Hopefully going forward will be faster. Still had a lot of fun figuring it out.

  • For the past 3 hours spinning wheels on figuring out how to resize image in memory on the backend. The image is submitted to the server and comes in as a JSON array, so, I do not want to write it to a file as an intermediate step. I'm also trying to avoid any 3rd party binary dependencies like imageMagic -- I simply can not use it due to limitations of ElasticBeanstalk. Tried few interesting NPM's: sharp, jimp, few other smaller ones. Each comes with it's own corks and issues. Some require heavy weight 3rd party dependencies, some fail to install, some simply error out. I can not believe how hard it is sometimes to do what seems to be such a basic thing. Still looking.

  • Ended up using 'sharp' npm as the most stable solution. Finally, the API works, the tests pass.

  • Back on iOS. Let's try to send the image from the phone via this brand new API and see it appear in the database. Now, that we know the API works (according to the mocha testing anyways), it should be piece of cake.

  • But first, let's make sure we can deploy the API we worked on today to AWS Elastic Beanstalk, so that we can connect the iPhone to a real backend. I will also need to configure wisaw.com DNS so that we can connect to it by name. I could technically do it all on local sandbox. Since I'm starting fresh, I will use the prod environment as a sandbox prior to the rollout. Once everything is live in production, only then I will worry about configuring localhost sandbox.

  • Ran into a surprise: the node version supported by the ElasticBeanstalk is 6, while I was doing development on local host on the 8. Using nvm to set my local default version to 6.11.1. As the result, also had to roll back koa-bodyparser 2 major versions back, and one major version for koa-logger. Let's see if everything still works after this. Ideally, since Elastic Beanstalk supports Docker, I would spend time and get the config to the latests and greatest node version. Not now though -- I have to keep moving forward, so, it's OK to be few versions behind, until AWS start supporting the latest and greatest.

  • After the downgrade all tests pass again, and I see new records in the database as the result of running the tests. Am I glad that I spent extra time on providing coverage?

  • Configuring AWS Elastic BeanStalk, DNS (A, C records, redirects), SSL. Super easy with AWS (they even offer free wild card cert generation, which is honored by browsers), but, since I'm defaulting to the smallest possible instance types (micro) due to savings consideration, everything is super sloooooow, and takes very long time when I deploy a new version of my app, or make even a smallest configuration change in Elastic Beanstalk. It does take quite a few iterations to get Elastic Beanstalk configured properly, and every change requires a long wait.

3 views