# Inspiration

After talking to Richard White from EDR, we decided that using a graph database to search for patterns seemed like a very interesting problem to solve. Though the problem was narrow, we were able to use existing platforms to efficiently solve the problem.

# What It Does

Graph.srch allows the user to specify parts of a mailing address and retrieve all possible matches from the graph database. In addition, the user can search for two different address parts and see the similarities and differences between the datasets returned.

# How We Built It

The frontend is written in React.js and the backend is written in Python with Flask and a Neo4j Bolt driver. The graph database solution we used was Neo4j with its Cypher query language. The Neo4j database is hosted on Google Cloud.

# Difficulties

We initially intended to host the database with Google Cloud Bigtable, but found setting it up to be more complicated than intended. The datasets given had some addresses with no street address which we had to work around since Cypher's MERGE does not do well with null fields. We also struggled with processing and querying as large of a dataset as we were tasked to handle. Our frontend proved difficult to complete and integrate with the backend because of formatting issues and pagination.

# Accomplishments

We accomplished a lot in 36 hours. Most of us worked with technologies we had never encountered, including graph databases We used Python to interact with the database and learned how to use Cypher to query. Our frontend took a lot of collaboration to get running, including CSS help and getting through JavaScript formatting.

# If We Had More Time

We'd like to deploy Graph.srch on Heroku, Netlify, or a similar platform. Other plans include showing a Google Maps view of addresses for user selection and including a visual of the graph data returned. Fuzzy searching with Levenshtein or Lucene search would also be nice to support.
## Inspiration

This week a 16 year old girl went missing outside Oslo, in Norway. Her parents posted about it on Facebook, and it was quickly shared by thousands of people. An immense amount of comments scattered around a large amount of Facebook posts consisted of people trying to help, by offering to hang up posters, aid in the search and similar. A Facebook group was started, and grew to over 15 000 people within a day. The girl was found, and maybe a few of the contributions helped?

This is just one example, and similar events probably play out in a large number of countries and communities around the world. Even though Facebook is a really impressive tool for quickly sharing information like this across a huge network, it falls short on the other end - of letting people contribute to the search. Facebook groups are too linear, and has few tools that aid in making this as streamlined as possible. The idea is to create a platform that covers this.

## What it does

Crowd Search is split into two main parts:

* The first part displays structured information about the case, letting people quickly get a grasp of the situation at hand. It makes good use of rich media and UX design, and presents the data in an understandable way.
* The second part is geared around collaboration between volunteers. It allows the moderators of the missing person search to post information, updates and tasks that people can perform to contribute towards.

## How we built it

Crowd Search makes heavy use of Firebase, and is because of this a completely front-end based application, hosted on Firebase Hosting. The application itself is built using React.

By using Firebase our application syncs updates in realtime, whether it's comments, new posts, or something as a simple as a task list checkbox. Firebase also lets us easily define a series of permission rules, to make sure that only authorized moderators and admins can change existing data and similar. Authentication is done using Facebook, through Firebase's authentication provider.

To make development as smooth as possible we make use of a series of utilities:

* We compile our JavaScript files with Babel, which lets us use new ECMAScript 2016+ features.
* We quality check our source code using ESLint (known as linting)
* We use Webpack to bundle all our JS and Sass files together into one bundle, which can then be deployed to any static file host (we're using Firebase Hosting).

## What's next for Crowd Search

The features presented here function as an MVP to showcase what the platform could be used for. There's a lot of possibilities for extension, with a few examples being:

* Interactive maps
* Situational timelines
* Contact information
## Inspiration

We were inspired by the untapped potential of local businesses and the challenge they face in gaining visibility within crowded marketplaces (especially in major cities). We wanted to create a platform that empowers communities to easily discover and support these hidden gems, while giving businesses the tools to thrive in the smart city ecosystem.

## What it does

Local.ly connects users with local businesses, helping them discover new places and redeem exclusive offers. It provides a seamless platform for businesses to create profiles, promote special deals, and engage directly with their community. Users can browse, find unique businesses, and access deals—all in one place.

## How we built it

We built Local.ly using a combination of frontend and backend technologies. On the frontend, we used React and Tailwind, and for the backend, we used Express.js, Prisma, and PostgresQL. For the backend, we integrated a relational database to more easily manage user and business information, and used the Google OAuth protocol to allow users to sign in with their Google accounts without using a pre-built app that handles the state management of the back and forth between the client, server, and Google.

## Challenges we ran into

One of the biggest challenges we ran into was actually using Prisma with the CRUD operations to our PostgresQL database. We ran into many issues, including some where we faced were circular dependency / infinite recursion and null values from our Prisma query args, which we ended up not being able to fully solve due to a limit of time we had to actually test our solution. For example, we had models Business and Promotion in our schema, where Business has fields locations and promotions, and Promotion has field business, and for some reason the prisma include args would return some data as null, even though we checked the database and the values were actually present.

## Accomplishments that we're proud of

We’re proud of building a platform that empowers local businesses while creating a streamlined experience for users. Successfully overcoming the OAuth challenges and designing a user-friendly interface were also major wins for us. Additionally, our platform highlights businesses in a way that feels both fresh and essential.

## What we learned

Integrating Prisma was more complex than anticipated, especially when managing nested relationships and optimizing queries for performance. We encountered issues with circular dependencies in our data models and had to refactor our schema multiple times to ensure the integrity of our data. This process deepened our understanding of database design and how to efficiently fetch and transform relational data.

## What's next for Local.ly

We plan to expand Local.ly by adding advanced features such as personalized recommendations, real-time business analytics, and integrations with smart city technologies to provide businesses with more insights and users with a tailored experience. We also aim to onboard more local businesses and grow our user base to foster stronger community connections.