“Do you think you can make a map that people can pushpin places they think we should visit?”

“Do you think you can make a map that people can pushpin places they think we should visit?” — The wife.

“Sure thing.”

I have a tendency to promise the world after working in a sales-based career for many years. I’ve found it easier, for me at least, to always assume I can make a client’s request happen, whatever it may be. The wishy-washy, “Let me see, I’m not sure…” reply just screams fear of commitment, or worse, a lack of putting forth effort. I rather reply, “Yep, I can do that” even if I have to correct myself later with “I tried and I could not actually do that.”

Luckily, this challenge didn’t seem too difficult. My initial first thoughts:

Map => D3.js

Database => Postgresql

Backend => Rails

Server => Heroku

I knew how to utilize three of the four already so I began reading about D3.js. The framework seemed very powerful. After a few hours I came to realize if I feel like I’m going to use only ten percent of a framework, I should probably at least consider another option. The ‘pushpin’ part of my wife’s request made me think about Google Maps markers. I took a look at the Maps API.

The more I read, the more I saw how perfect of a fit Maps API would be. I built the initial map call, which draws to a HTML div:

Other than hunting down a good centered lat and long for the United States, this code is pretty much identical to the API’s examples . I played around with the marker and info windows a bit and then shelved the project for a few days.

I was browsing Hacker News a few days back and found a job posting for Firebase.com. They asked for something clever the applicant had made with Firebase. I had no idea what Firebase was at the time so I opened up a new tab. Funny, that little marketing trick worked. Firebase is an API-driven database. Hmm…I didn’t really grasp the functionality. After reading the docs for a bit, I closed out the tab and forgot about it.

A few days later, I integrate Google Places API to trigger an autocomplete on the location section. This allows me to accurately capture the lat and long coords of specific locations via the API. I start thinking about integrating it into a Rails backend. It’d be so simple if this otherwise static site didn’t need a database. Ah-ha! If I use Firebase to handle the DB I could avoid any need for Rails. I check Firebase. There is a very decent free development tier. Nice! I follow the tutorial alongside my own app and come up with the following:

On submitting the form, jQuery.val() captures the values in the input fields (Comments, Submitter) and autocomplete provides its currently selected place (autocomplete.getPlace). PlaceRef is my Firebase DB object. PlaceRef.push() sends a JSON object to the DB and Firebase takes it from there. Next, I build a constructor function to create the markers:

Kind of a lot going on here but the gist is I pass the setMarker() constructor a location’s lat, long, name, comment, and submitter. The comment and submitter arguments get stuffed into an html-lined string. Lat and Long are used to create a new google.maps.LatLng object which gets passed into the google.maps.Marker constructor. The infoWindow is built using the contentString variable and a click listener is added to open the info window when the marker is clicked. Finally, the marker is ‘set’ on the map.

Wow. At this point, I can’t believe it is all working just as I wanted. I haven’t really worked with JS much before so seeing this come together was blowing my mind. Maybe JS isn’t so bad after all…Last step, I need to iterate through all existing DB entries and make markers for them at load. Here it is:

You’ll notice these two are very similar. Both methods call the marker constructor with data from the Firebase DB. The first one iterates through all database keys to populate the map with markers at start. The .once() method on the Firebase object calls for a snapshot of the DB only once, preventing the markers from being re-rendered after a new entry is made. The second method uses .on() to set up a listener for any new additions into the database. On an entry addition to the DB, the marker constructor is called. As an added bonus, the listener will also see any new entries in the database and render the new markers for them in real-time on the page.

So what does this all mean? Well, this little applet can be hosted with zero back-end a little HTML/CSS, and less than 100 lines of JS. More importantly, my wife was blown away with how well it functioned. And best of all, if I can keep clients as impressed with my work as my wife was with this little widget I can continue using my ‘sure thing’ attitude towards any requests.