IdeaDog Back-end Overview
First off I would like to thank Brennan as this was both his idea and let me be part it as the back-end engineer for his project. If by any change you more interested in the Front-end aspect of the project at the bottom of this article is a link to his post on building an app in React and Typescript.
It’s been a long time since I have written one of these but recently completed my final project, and found this an opportune moment to share what I learned. Little back story, so going through this project, I choose to partner up with one other individual as aforementioned “Brennan D Baraban”. The reason being I wanted to focus on the back-end, and he wanted to do something involving the fronted, this, however, create some new challenge which I’ll get into later. Regardless to say this was a fun and education project and still is a work in progress but overall, I’m was happy with what we achieved within such a short period.
So what is IdeaDog?
To get the full breakdown I would suggest reading this article.
In short, IdeaDog is a social web application for sharing ideas. In essence, Ideadog is like a minimalist fusion of Reddit and Twitter — at its current release — and a showcase of what we have learned while attending Holberton School.
Under the Hood.
TLDR, There 3 pieces to the back-end, one of them being a framework so could be argued that there only 2. That said I’ve listed them below.
- Rust, coding language.
- Actix, web framework used to build the API server in Rust.
- ArangoDB, Database used to house the data.
While I learned a lot at Holberton, like building a Clone of Airbnb in python via flask, due to my proclivities, namely my desired to use Rust. I was using what I learned at a conceptual level and was applying it to another language/framework.
So Rust was the primary language, Rust was chosen because it’s a strongly typed language and compiled. On top of that, there is passive memory management without the use of a garbage collector(GC) meaning that both memory leaks are near impossible and memory usage kept at a minimum. To sum up, this offered latent resilience and fast applications.
From the Rust book:
Rust’s memory safety guarantees make it difficult, but not impossible, to accidentally create memory that is never cleaned up (known as a memory leak). Preventing memory leaks entirely is not one of Rust’s guarantees in the same way that disallowing data races at compile time is, meaning memory leaks are memory safe in Rust
Would suggest reading the chapter on the ownership for Rust which relates to its memory management.
As for the web framework, I chose to use Actix (v0.7) because reinventing the wheel wasn’t necessary or realistic in 2 weeks. There were several other web frameworks to choose, such as Rocket, but Actix was selected because of its speed. Also, my familiarity with the code base was another factor among many others.
Last main component for this project is the Database, If you are familiar with Rust + Web, then you likely heard of Diesel the ORM, this, not the route we went. Instead, we chose to use NoSQL over SQL database, so an ORM wasn’t necessary on top of that rather than using the defacto — MongoDB — we opted to try a lesser-known called “ArangoDB”.
ArangoDB is a native multi-model, open-source database with flexible data models for documents, graphs, and key-values. Build with a convenient SQL-like query language. Ultimately ArangoDB was used because we want to create documents with complex relationships via graphs, which would otherwise enlarge documents with extra data.
Challenges
IdeaDog was different from the get-go, what I’ve experienced up till most for projects were often two or more individuals working on the same code base. However, since Brennan’s was on front-end and I the back-end neither of us touched the others code, mainly because there wasn’t time for the other to learn Rust+Actix or React+Typescript. This project, in a way was to help us solidify our knowledge while also providing us with more responsibility towards the product.
Arguably the biggest challenge was that we were building an application where the two developers were entirely disjointed from the other half. Thus communication and productive meeting were more critical the previous projects. Throughout this project, this would be constant.
To keep each other in the loop use the usual way such as frequent meeting as school or always on Slack. As an additive way to try to bridge the gap between the front and back end, I used Postman a lot to test but also create a public REST API doc for front-end to reference. Other than that that we didn’t set up any time-sheets or task it seam for us playing it by ear work the best for the short time we had.
Honestly, though my partner and I both agree that this was relatively workflow for us and yes there is room from improvement such as a task board.
This article is getting a bit long, and after writing it, I’m thinking of saving the heavy Tech side of it for another article; however, if you are interested in the front-end of the project my partner, Brennan has completed on the front-end.