As some of you may know, we have been working hard on building our own task planning software called Vindigo. While this has been in the works for a while now, we are finally making substantial progress towards a possible alpha release. For this reason we have decided to start releasing frequent progress reports on the current status and plans for Vindigo.
Before we jump into the latest development updates, I'll give a quick rundown of the architecture powering Vindigo, the software we use, and some of the more important decisions we have made.
One of our main goals for Vindigo is to create a clean and maintainable codebase to future proof us in the long run. Since the goals and ambitions of a project change over time, we too have had many situations where substantial parts of the codebase have undergone refactoring.
At the current moment in time, we are extremely satisfied with the software and feel that it is a great fit for the project. Vindigo uses a variety of different libraries, frameworks, and techniques behind the scenes, so here is a quick rundown of our most important setups and decisions behind them.
The Vindigo repository is configured as a monorepo and contains all different packages essential to each Vindigo installation. This includes the Server, the Client, and the CLI, among other packages.
The Vindigo server
In order to manage and sync all actions from each client, the server consists of a node.js process exposing an API for clients to communicate with. After spending weeks performing initial research into the communication options available, we ultimately decided on using GraphQL as our main means of communication. This was mainly due to its built-in support for documentation, low bandwidth requirement, and support for live messaging via subscriptions.
The server is operated from the Vindigo CLI, a separate command line tool used to manage a Vindigo installation. The CLI provides easy means of starting Vindigo, both directly or as background process, performing updates, as well as setting up new Vindigo installations.
The Vindigo client
One of our main focuses on Vindigo was to provide a fast and efficient web experience. Since I have plenty of personal experience with Vue.js, this became the most obvious way to go. While the initial setup of the client was built using a lot of custom Vue.js application boilerplate code, we have since switched to using Nuxt.js to simplify many aspects. While the majority of styling is done manually using Sass (SCSS, to be pricise), we use the awesome and lightweight Wave UI which provides us with many useful components. All these libraries combined equip Vindigo with a strong, efficient, and extensible frontend utilizing the latest web technologies.
In order to update the UI live, we use GraphQL subscriptions to listen to live events. This allows us to efficiently and instantly sync up clients in response to various actions, such as changing the summary of a task, or adding a user to a project. During development we use a fantastic tool named Altair to write and test our client GraphQL queries before integrating them into the codebase.
The design process
Before new pages and components are created, we go through a design process of designing and iterating upon mockups. This allows us to finetune the looks of each page before we start writing any of the code behind it.
Most mockups take at least two or three iterations before we consider them good enough, however sometimes it takes many more attempts before we're satisfied! Besides making sure each page looks good, we believe design consistency is equally as import, hence all font sizes, font weights, and spacing follow consistent values.
While the design process is not performed publicly at the moment, we have made sure to keep all mockups and every iteration of each. We might even reveal some in a future progress report!
The current status of Vindigo
Over the past months developing Vindigo, we already completed many of the tasks we set out to do. While it is still not recommended for production use, as many features are still missing, we have already completed most functionality we intend to include in Alpha, such as authentication, user profiles, global search, and of course the kanban boards.
In the next progress report I will be explaining about our philosophy behind projects and tasks, and how we decided to implement them to make Vindigo as customizable and extensible as possible.
Working towards Alpha
As I said earlier, we’re confident we’re approaching an initial alpha release in the near future. As there are still many more features we would like to implement, I cannot give an exact date just yet.
Especially in the area of tasks we still have a lot of work left to do, including implementing remaining project task views, adding task hierarchy support, and streamlining the workflow. Naturally we will continue to address the latest developments in future progress reports :)