CommuniMap

Inspiration

Building solutions for communities is hard. One of the most important steps of the engineering design process, gathering requirements, is increased greatly in difficulty for groups that are geographically and demographically diverse, as the sweet spot for a successful project is tightened by varying needs and wants. This poses a problem for a project which I have 24 hours to complete, so I decided for a different approach. Rather than "who I want to help", the question because "what are things that everyone needs?"

I ran through a few ideas for that, but what really stuck in my mind was information. We live in the data age, and having the ability to leverage that to support friends, family, neighbors, and more is something that I'd be interesting in working to provide. Of course, there's no shortage of traditional messaging platforms, mailers, bulletins, and other forms of communication, so I had to figure out a solution that would be reasonably novel.

Enter CommuniMap!

What it does

Two things: CommuniMap allows you to create a map, which establishes a public geographic map, and contribute, which places a feature with some extra information on a given map. These contributions are updated in near-real-time (more on this in a second), giving users a view of the shape and activity of their community at a glance, at any time.

I've also had some alternative use cases suggested that the application supports with this model, including:

• mapping the locations of all the cool mushrooms on a college campus
• birdspotting records
• finding spots that need manual labor, ex. snow shoveling

How we built it

CommuniMap is hosted entirely on AWS and has a serverless architecture to keep costs low at low traffic. To spare you a verbal explanation of something resembling a plate of spaghetti, here's a nicely organized diagram:

The bulk of CM is an HTTP API through AWS API Gateway that proxies requests to one of a number of Lambda functions. This is an approach I've used before, and I appreciate it as an intuitive way to integrate idiomatic HTTP handling from any language into a cloud infrastructure. Map definitions (geographic areas) and panels (the bit that lets you contribute) are stored in S3, and contributions are stored in DynamoDB in a table indexed by the ID of the map you're contributing to.

I don't want to make this too verbose, so I'll put a shameless plug in for my blog post where I discuss undertaking a similar project. If you want to read more about my decision-making process around these services, that's the best place to go.

Challenges we ran into

My plan going in was a little bit too ambitious, as is any good hackathon plan. The biggest difference between my thoughts going in and the product coming out is that I wanted to use websockets rather than polling to manage live updates. Essentially, the user would connect to a websocket, triggering a backfill message to send them all of the old contributions. Further contributions would be posted individually. It turns out that websockets are funky, especially when it comes to serverless architecture, so at some point I cut my losses and went with a polling approach. This may create some pricing problems down the line, but by then I will have also had more than 24h to solve them.

A few other features that I was really pushing for, such as private or domain-limited maps, more customized contribution panels, or a page of public maps, didn't end up in the final cut for the hackathon as a result of time and energy constraints.

Accomplishments that we're proud of

I'm a cloud developer in practice, but building a full application alone, start to finish, in 24 hours, was an intimidating undertaking. There were several points in the hackathon that I didn't expect to finish much of anything. I consider coming out of this with something presentable, functional, and fairly aligned with my original vision to be a triumph in its own right. I'm just really happy to watch the points appear on this map as I wait for presentation time--it's visual evidence that I've made something that's reached across the nation in some small way.

What we learned

• It can be a big help to a project to drop features you don't have time to properly implement
• Sometimes cutting out code can be as effective a solution as adding it
• Consistency in architecture is a factor in how achievable a solution is given constraints

What's next for CommuniMap

A break!

I'd like to come back to this project after a good long rest, with a few things in mind:

1. Code quality: I wrote this code very fast and it's not my best work. It could use a once/twice/thrice over.
2. Replace old libraries: One specific tool I use for the API-serverless-proxy-thing setup was recently archived due to lack of support, and given time to learn a new tool I think it'd be greatly beneficial to use it.
3. Fill out existing features: I think the map creation page in particular could use some extra love from its current state; there's technically support for much more customization, but I'm not the strongest web developer and couldn't get it working under the deadline in a more robust state
4. More stuff!!!

Attributions

All code in CommuniMap is original to the project and done in the 24h time frame. Some of the tools used are external; below is a list of attributions.

• I used my personal website as a base for formatting the CommuniMap website (think navbar, margins), though it got changed a good bit by the time I was finished with it
• I used orb (Copyright (c) 2017 Paul Mach) (link to manage any GeoJSON data on the backend.
• I used react-map-gl and Mapbox to display map data.

Built With

• amazon-web-services
• go
• mapbox
• next