Hello, Web Technologies! — Part II

This is a follow-up to my first post about technology choices I made while building out our product. I wanted to pen my thoughts on what worked well and what didn’t go as well as planned and some new friends I discovered along the way.

AngularJS has worked out great so far. As a newbie to frontend development, I appreciated a framework that was prescriptive about how to build a webapp. It is very well documented and there’re a whole host of blogs, articles and forums should you run into any problems. One thing to watch out for is that debugging an AngularJS app can be a little daunting in the beginning because of all the async calls. There’s no real callstack that you can step through as you might in a Java application. AngularJS Batarang is a must-have debugging tool that will simplify your life considerably. I ended up rewriting large portions of the codebase a couple of times when I realized there was a much better way to do things in AngularJS — this is pretty natural when you’re learning a new language or framework. One recommendation I have is to learn about angular directives. I ended up creating a few directives that have helped create re-usable components and minimize code duplication.

Angular-material has been a mixed bag. It comes with a lot of good-looking UI elements out of the box . However, it is notoriously difficult to customize — changing color themes is super complicated to the point of being frustrating. Angular-material generates style tags and inserts them dynamically and you need to know what selectors to change the look for any element. It does comes with flexbox support which made it ridiculously easy to build a responsive webapp. I was able to get the same webapp working pretty well on different screen sizes on iOS Safari and Chrome on both iOS and Android.

Dropwizard has worked out well as a web-service framework to build REST apis. I integrated Guice dependency injection framework to make my life a little easier. I hadn’t thought too much about the choice of ORM layer and ended up going with JDBI which was mentioned in the Dropwizard docs. Now, I have some more perspective in the matter. When you’re building out your product, your DB schema changes quite a bit as new requirements come in. Every new column added meant a bunch of cascading changes in multiple files. This was a time-consuming, tedious process. Even common operations like retrieving an object by its primary key had to be coded up in SQL. Fortunately, I was very comfortable with SQL. If you’re not, you may want to consider Hibernate or some other tool. The advantage of using JDBI is that you know exactly what kind of SQL queries are sent to the backend DB and you can optimize for them by creating the right indexes. You can also create views for common query patterns and materialize them over time. There are also a number of backend-as-a-service players including Kinvey and Parse.com (as I write this, I see that parse.com is shutting down its service). If I had to do this all over again, I would’ve looked at this options more carefully.

Heroku as a platform with PostgreSQL backend has been a fantastic. It basically cost me nothing to have a prototype running for demo purposes. Deploying to Heroku is as simply a git push. There is no lock-in since I’m using OSS frameworks and can simply move to AWS infrastructure, if required. Custom domain mapping was pretty straightforward as was SSL setup — the documentation is pretty comprehensive.

Pretty much every web application needs to be able to send out email (e.g. activation, notifications). In our case, we also needed to be able to process incoming emails. I ended up using Postmark for this purpose . For outgoing emails, I created a few templates based on samples provided. To send an email, it is as simple as sending a POST request to Postmark with an auth key and a JSON doc with a “To” address and Postmark takes care of sending the email. It also tracks email bounces for you. Processing incoming mail was a little bit more work. I was using Google Apps / Gmail for email. I had to create a new user in my org and then create a custom rule to forward mails to this user to a postmark email address. This email is parsed and a POST request is sent to an endpoint of my choice. RequestBin gives you a temporary end point to see what the request looks like. I then hooked that up with an end-point with my Dropwizard service and, voila!, I was processing incoming emails in my webservice. Postmark automatically takes care of retries. The JSON that Postmark sends uses CamelCase convention — just watch out for that. I had to add appropriate annotations to parse them properly using Jackson.

I needed to build a mobile version of the webapp and decided to look into Ionic framework. Basically, what Ionic promises is that you can get an iOS and Android app implemented using HTML/CSS/AngularJS. You can potentially share a large part of your codebase across your webapp, iOS and Android app and not worry about learning multiple languages and frameworks. I’m still pretty new to Ionic, so I’ll write a followup post on whether Ionic lives up to its promises.

Please leave comments if you found any of this useful or have any suggestions or recommendations!