DEV Community: Shrey Dabhi

Rappel: An idea & repo management tool [DO Hackathon Submission]

Shrey Dabhi — Sun, 10 Jan 2021 19:31:04 +0000

What I built

Rappel - An idea management tool which is inspired from kanban boards and integrated with GitHub

Category Submission: Built for Business

App Link

The app (frontend): https://rappel.tech
API documentation (backend): https://api.rappel.tech/api/schema/redoc/

Screenshots

Description

An idea management tool, inspired from kanban boards and integrated with GitHub. It has the following features:

Automatically sync your GitHub repos
Sort the repos into 5 categories:
1. Backlog
2. Active
3. Work In Progress
4. Done
5. Archive
Add working notes for the repos directly inside their cards

Link to Source Code

Frontend: https://github.com/sdabhi23/rappel-ui

Rappel

An idea management tool, inspired from kanban boards and integrated with GitHub

This repo only contains the frontend for the app. Please check sdabhi23/rappel

Features

Automatically sync your GitHub repos
Sort the repos into 5 categories
1. Backlog
2. Active
3. Work In Progress
4. Done
5. Archive
Add working notes for the repos directly inside their cards

Roadmap

Add notes for new ideas
Filter repos
Search repos
Hide stale repos into a separate tab
Automatically delete repos when they are deleted from GitHub
Integration with PyPI and NPM
Integration with GitLab

Run locally

Install dependencies
```
➜ npm install
```
Run the app locally
```
➜ npm start
```

The api docs should be available at http://localhost:8000/api/schema/redoc/

Screenshots

Homepage
Authorize GitHub
GitHub Callback
Dashboard

License

Copyright 2021 Shrey Dabhi
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the

…

View on GitHub

Backend: https://github.com/sdabhi23/rappel

Rappel

An idea management tool, inspired from kanban boards and integrated with GitHub

This repo only contains the backend for the app. Please check sdabhi23/rappel-ui

Features

Automatically sync your GitHub repos
Sort the repos into 5 categories
1. Backlog
2. Active
3. Work In Progress
4. Done
5. Archive
Add working notes for the repos directly inside their cards

Roadmap

Add notes for new ideas
Filter repos
Search repos
Hide stale repos into a separate tab
Automatically delete repos when they are deleted from GitHub
Integration with PyPI and NPM
Integration with GitLab

Run locally using Docker

Generate dependency lists from Pipfile.lock using jq tool

➜ jq -r '.default | to_entries[] | .key + .value.version' Pipfile.lock > requirements.txt
➜ jq -r '.develop | to_entries[] | .key + .value.version' Pipfile.lock > requirements-dev.txt

Run the app

➜ docker build -t rappel-tst .
➜ docker-compose up -d
➜ docker run -d --name rappel -p

…

View on GitHub

Permissive License

Frontend: Apache License 2.0
Backend: Apache License 2.0

Background

I completed my bachelor's degree in mid-2020. I always made it a point to put whatever meaningful projects I built on GitHub. That combined with forks of some projects and a few more projects that I actively managed left me with more than 50 repos.

I was already looking for some tool which can provide me an overview of all my repos and categorize and manage them in a better way, but couldn't find anything which exactly fit the bill. So I decided to build it on my own.

How I built it

I had to make choices about tech stacks and though I wanted to explore new horizons I decided to go with the tools and technologies I am most comfortable with in-order to build a solid stable application.

I have deployed Flask apps earlier, but this is the first time I deployed a Django application. The DNS management service provided by DigitalOcean is great.

Additional Resources/Info

Libraries / frameworks used:
- Semantic-UI React for styling
- React-Trello for boards
- React-Quill for rich-text editor
- Django and Django Rest Framework for api
- Django Rest Knox for better token management
- Daphne for deployment
- drf-spectacular for API docs
DigitalOcean’s App Platform is pretty good but the Docker builds take longer than expected and monorepo support can be improved.

Minimum viable product

Shrey Dabhi — Sun, 10 Jan 2021 17:32:47 +0000

In the last post I discussed about technology choices for Rappel. In this post I would like to discuss which features I prioritized for the first version and how.

I also realized that ideas have their own life-cycle and considering them as a subset of repos would be a really bad idea. I wanted to put them in a separate section. So the whole ideas board in the app went on the back-burner.

The priority was to build a system which can help manage a large number of repos on GitHub. I kept working diligently kept working towards that one goal.

It was quite difficult to wrap my head around the way GitHub OAuth apps work. The most complex part was figuring out how to create and use access tokens without hitting the rate limits when multiple users are using the system simultaneously. Turns out that OAuth apps can create a token per user.

I finally built a working prototype on my machine, but with so many repos (57 to be precise in my case), it was not much effective. It still needs an option to hide certain repos from the main board, search repos and filter repos based on various tags.

We had already stepped into 2021 by the time I was able to work out all the kinks in the basic prototype. I still had to check-in the code into Git and deploy it on DigitalOcean. I had to put these things on roadmap instead of feature list and move on to completing all other tasks. You might even notice that all of the posts were written and published in under 24 hours.

I started testing the domain name I had bought and realized that the default DNS management capabilities were not good enough. They did not even support CAA records 🤷🏻‍♂️. Thankfully, if we already own the domain name, DigitalOcean provides DNS management for free. The transfer took more than 24 hours and now any DNS changes propagate very quickly, plus I get a nice shiny interface to manage it, so a win-win!

Reflections

I had a choice: either to create a rock solid base version and defer nice to haves until after the hackathon OR implement all features at a "it just works level" without taking care of edge cases. I went with the former options and am quite happy with it.
DigitalOcean App Platform can have better support for mono-repos. I was not able to deploy from sub-folders. For example, I had my react app stored in a UI subfolder, but as there was a Dockerfile at the root of the repo I was not able to choose any other buildpack. Using multistage builds and storing the output of npm run build in the final stage would be an alternative, but the build time was too high for that.

Cover image: Photo by Alexis Fauvet on Unsplash

Technology choices

Shrey Dabhi — Sun, 10 Jan 2021 16:35:45 +0000

In the previous post, I discussed how I decided what to build. In this post I would like to discuss more about the technology choices.

I heard about the DigitalOcean Hackathon and immediately decided that it would be the perfect motivation and opportunity to complete building the tool. The first choice I faced was to choose the components, some of the options I came up with are:

1. PostgreSQL + Hasura + Frontend (logic stays on frontend)

The schema management would be difficult and would need a separate service to manage users. I would end up with too many moving parts and all the keys and credentials would be exposed in the browser. Not a good choice for multi-user apps

2. Database + Serverless functions + Frontend (logic stays in functions)

This would definitely solve the problem of securing the keys and credentials. The number of functions required for CRUD operations would be just too many.

3. Database + Serverless functions + Hasura + Frontend (logic stays in functions)

Same as #2, but uses Hasura for CRUD. There's a slight chance of exposing user info stored in the same DB via Hasura.

4. A monolithic app which can handle both backend and frontend

This is a very promising option. Just that I didn't know about any good frameworks, so would have to roll my own CSS and the board like structure would be next to impossible to build with vanilla JS.

5. REST API server + SPA for frontend

This option felt like a silver bullet when I set-out to build this tool. I had to choose from ExpressJS, Ruby on Rails and Django for building the API, and Angular and React for building the frontend. I chose Django and React as I am more comfortable with them as compared to the other options.

Initially I was very skeptical about completing this project, but soon I was confident enough that I bought a domain name for it. I named it "Rappel". It is a synonym of Abseiling.

Abseiling, also known as rappelling from French rappeler, 'to recall' or 'to pull through', is a controlled descent off a vertical drop, such as a rock face, using a rope.
Abseiling on Wikipedia

Cover image: Photo by Victoriano Izquierdo on Unsplash

How to manage ideas and repos

Shrey Dabhi — Sun, 10 Jan 2021 16:01:03 +0000

I was already looking for some tool which can provide me an overview of all my repos and categorize and manage them in a better way, but couldn't find anything which exactly fit the bill.

So I decided to build one such tool on my own and started working on the basic concept in November, 2020. It did not look like much work back then.. just dump metadata from GitHub APIs into some DB and add a few additional fields and that's it!

I already had a basic structure in my mind by the 2nd week of December. In my initial designs the app looked like a single Kanban board (you can also call it a Trello board). Each lane would signify a stage in the lifecycle of the idea:

Idea
Active (initial POC completed)
WIP (more detailing is being done)
Active (is being actively monitored for issues and features)
Archive (project has gone stale)

The cards in Idea lane here might or might not have a GitHub repo. All the cards in all other lanes would have been populated using GitHub repos of the logged in user.

I had originally planned to deploy it on Heroku, as the Postgres db with 10k row limit that comes with the free tier would be more than sufficient for my needs. It was at this stage that I came across the post Announcing the DigitalOcean App Platform Hackathon on DEV!

Cover image: Photo by Pankaj Patel on Unsplash

My first experience as a speaker

Shrey Dabhi — Sun, 08 Nov 2020 10:53:37 +0000

This is a story about how I got my first shot at public speaking/teaching. I was in 5th semester back then, the college has just reopened and the clubs were gearing up to attract the new students to join as members. I had just spent majority of my 4th semester trying to learn this awesome language called Python, the Flask framework to be more precise. I had created a few projects, which I thought were unimpressive, but my seniors who ran a student’s chapter of a club called Computer Society of India found them pretty interesting!

They wanted me to start a lecture series about python. Naturally I was a bit nervous and initially declined the offer, but they insisted and somehow I made up my mind to do it. To be really honest it felt like a very bad idea to me at that time, but now when I look back I realize that that one decision changed a lot of things for me.

The preparations were in full swing. We had created a Google form for registrations. We went from class to class to publicize this event. We used social media as well for publicity. We received about 80 to 90 registrations, and hence we booked an auditorium with a capacity of about 60 people, because that’s the general ratio, and I was quite prepared for that amount of audience.

It was a hands on session, so I sent an email with a few instructions. I had a couple of flash drives loaded with the required software. I had decided against using a PPT and decided to code then and there along with the participants.

Then came the D day! The stage was set, and I was prepared. I was running late but we had a few volunteers handling the crowd. As soon as I reached the auditorium one of the volunteers told me that around 70 people have already arrived and more students are coming. I was shocked a bit, but still I went in, tested the projector and sound systems and went to the canteen to grab a quick byte.

By the time I came back everyone had arrived. As soon as I stepped into the auditorium I was completely overwhelmed. People had turned up in large numbers. There was a scarcity of chairs. Some students were even perched on the ledges, all with their laptops ready and eagerly waiting for me to begin.

I was utterly speechless. I never anticipated such a huge crowd. With sweaty palms and shaky legs I began my 2 hour long tirade on what Python is and how to approach it as a beginner.

I then went on to conduct 4 more sessions on topics ranging from advanced features of Python to the Flask framework to web scraping using Python. We held a HackerRank contest as well as a session on developing command line apps.

Some glimpses from the first session of LearnPy

The lecture series ran from July, 2018 to October, 2018.

In hindsight this experience gave me a lot of confidence in communicating my thoughts and ideas. I learned how to gauge the level of interest of the audience from their body language, which is something very valuable during face-to-face team meetings. I also became more receptive to constructive criticism and started looking at my ideas and solutions from multiple perspectives!

Cover Image: Photo by Teemu Paananen on Unsplash

DEV Community: Shrey Dabhi

Rappel: An idea & repo management tool [DO Hackathon Submission]

What I built

Category Submission: Built for Business

App Link

Screenshots

Description

Link to Source Code

sdabhi23 / rappel-ui

An idea management tool, inspired from kanban boards and integrated with GitHub

Rappel

Features

Roadmap

Run locally

Screenshots

License

sdabhi23 / rappel

An idea management tool, inspired from kanban boards and integrated with GitHub

Rappel

Features

Roadmap

Run locally using Docker

Permissive License

Background

How I built it

Additional Resources/Info

Minimum viable product

Reflections

Technology choices

1. PostgreSQL + Hasura + Frontend (logic stays on frontend)

2. Database + Serverless functions + Frontend (logic stays in functions)

3. Database + Serverless functions + Hasura + Frontend (logic stays in functions)

4. A monolithic app which can handle both backend and frontend

5. REST API server + SPA for frontend

How to manage ideas and repos

My first experience as a speaker