We were inspired to incorporate Twilio SMS messaging API and the Wunderground API to built a simple JS webapp where people can register their phone number and a list of cities that they would like to receive urgent or emergency weather alerts about via text.

How it Works: The app is a built with Javascript, Angular, NodeJS, and Firebase. We store our city lists(by zip code) and our phone numbers in Firebase. Each is saved by a dynamically timestamped automatically generated ID on behalf of firebase. This ID represents the User. When a user signs in to the home page, they are added to our firebase database if they are not already in it. They can then add more than one zip code of cities as input on the next page of the site.

Obstacles we encountered: We spent a lot of time on authorization, supporting multiple users, and how to structure our database(by phone number, by email and password, by dynamically generated ids?) We found that email and password is simply overkill for this type of service but login would be appropriate so city lists can only be updated by that authorized user. We also struggled to focus on the simple minimum viable product even though we had really trimmed down our ambitions!

Additionally, we had two api struggles: We had hoped that the API we were using to check for emergencies was just one endpoint that would return a object with a list of places or emergencies(called "alerts" by Wunderground). This way, we would be able to scrub that against our users' array of zip codes. Hence, a match is found, then that objects respective phone is messaged with our Twilio api.

What we learned: Instead, this endpoint (the Wunderground alerts API) could only be queried with a particular zip or city name in tow(included with request), so we had to iterate through our list and query, then look for a match and invoke the sendMessage function. This opened a new can of worms: How often would this process need to happen to ensure our users are getting frequent data? Would the same person be getting constant messages if they were a match? We needed to decide on a time interval and protect the user from being spammed. Also, luckily, Wunderground helped us unlimit our API calls so we could test to our delight!

Our successes: We worked really well together, focusing on our strengths and helping each other along. We didn't have any problems agreeing on anything except where to sit. We each learned a lot. Although, it doesn't work as well as we'd planned as we put all the pieces together, each piece worked on its own. It was a truly educational and fun process, and a glimpse of real world use cases-- something that we have not yet experienced as we are new to programming.

We learned a LOT about modularization, controllers, services, organization of files and concerns. This is a new concept for us students, (we are in week 4 of a bootcamp). After spending only about a day or two learning each Firebase and Angular, we were able to get a lot done. We also learned how to pack third party dependencies with our webpack even though they weren't necessarily webpack-loaders.

What's next for pocketWatch: We each want to put this in our portfolio so it is not done. Samantha wants to implement MMS and other endpoints that return satellite data. Darien wants to test this with different structured firebase approaches. We plan to incorporate multiple users with multiple phone numbers, ease of login, and geo-location so your current location is always suggested as a city in your accounts city list. We also can't wait to implement more Twilio APIs that enable inbound messaging so people don't even have to log in or go online!

Share this project:
×

Updates