Inspiration
One of the biggest issues with current social medias is that it features groups, to represent a group of people in real life. While this feature is very useful, it falls short as unlike groups or organizations on these platforms, real life groups of people has multiple layers of sub-groups under one giant group. We decided that we needed a flexible platform that allows people to create layers and groups and sub-groups.
We also believe that the software industry was shipping a lot of bloat with their software. For example, Electron is a great framework built for cross platform development with web technologies. While this saves a lot of time for the developer, it also causes a lot of bloat as Electron packages a Chromium browser alongside the actual app. For these reasons we have decided to create a command line client for our platform.
What it does
The primary features of this social media was the ability to have multiple layers of groups and the officially supported command line client. Thus what type of content the platform hosts was mostly irrelevant. We decided to go with a very simple type of a community: an online forum.
How we built it
Our approach to making the API server was simple. We were able to find a bunch of good libraries for developing a GraphQL endpoint, so we could leverage Django's state-of-the-art ORM. We kept adding more models and the queries and the mutations on our GraphQL endpoint until basic CRUD functionality was up and running (although we don't plan on supporting the delete operation for now).
For the front-end CLI application, we decided to use Rust as it is known for being safe and flexible while still maintaining the same speed as languages like C++. Since we were using a GraphQL API as opposed to a REST API, we used the graphql-client crate which is officially endorsed. We also used the tui-rs crate with a crossterm backend (in order to maintain compatibility) to create the actual user interface.
Challenges we ran into
One challenge we ran into was that we didn't have enough time to implement everything that we wanted in our application. This is for a variety of reasons, including needing to sleep and some miscommunication between our group members. However, we think that the final product turned out rather well for something made in 36 hours, and we can definitely improve upon it in the future.
Accomplishments that we're proud of
For us, the biggest accomplishment was definitely actually finishing the project. On the second day, we worked almost the entire day but didn't get as far as we wanted in terms of features. When it came time to sleep, we knew that if we did we wouldn't be able to finish the project. So, some of our group members decided to stay awake for almost the entire night doing the project. Although this is unhealthy and we don't recommend it, we feel that it was the biggest reason why we finished the project by the deadline.
What we learned
We had to think on our feet often when working on the project. Many libraries (especially for the front-end) that we used were discovered on the spot and we had to learn how to use them quickly.
Another major thing that we learned was using a GraphQL API instead of REST. Previously, we had been more comfortable using a REST API because of its simplicitly. However, we've come to learn that in some cases, GraphQL can be advantageous because it has only a single endpoint and queries can be freely defined by the user.
What's next for Borz
We plan to maintain and update Borz after the Hackathon is over. There are still a bunch of features that haven't been implemented yet, or have been scrapped because of the time constraint. Some of these features include user-hosted instances and a diverse user profile.
Log in or sign up for Devpost to join the conversation.