This app looks up "Mobile Food Facilities" as permitted by the City of San Francisco. The data is provided by a government open data resource known as DataSF. It is a full-stack solution with a React/Redux-based front end and a Node.js server running a RESTful API.
When the user enters a query, an API call is made to the app's API server, which in turn makes a call to Google's geocoding API to translate that natural language query to a set of coordinates. Those coordinates are used to make another query in the DataSF API, which sorts all of the data points by how far they are from the query point. Those points are then displayed on the map and listed on the side.
I am responsible for specifying all of the API endpoints as well as the components and redux state bahaviors. I didn't architect most of this though. That's the nice thing about using a boilerplate. I also am not responsible for almost any of the styling.
With a project like this, oftentimes the specific libraries and techniques you end up using are detemrined by the boilerplate you choose to use. The main concern with this full-stack solution was protecting the security of the API keys. Inherent in any front-end only solution is that you are exposing the keys to the client, such that a potential bad actor could misuse them and cause disruptions in service. Time mainly limits how much you can diverge from what the boilerplate offers.
With more time, I would have incorporated some sort of client-side caching for previous requests, as well as server-side CRON-based caching of the query results. Obviously the styling here is pretty bare-bones, it would have been nice to incorporate more pizzazz and fun loading animations. There also seem to be a lot of problems with the dataset itself, as many items lack location information or don't seem to really have valid addresses. Also the tests in place for this project are mostly demonstrative -- it would be a very good idea to spend more time on those.