Version 2 already? Isn’t it too soon? Long story short, we had to take a different business approach, or in another word, pivot. We also ended up rewriting some stuff, not to mention redesigning the whole UI/UX. Basically, not much has changed, and yet so much has changed, enough for a major version bump.
Getdebug was initially built as a B2B bug management platform for corporations. Well, now in version 2, we’re more focused on building a collaborative bug management platform that can be used by anyone or team, so long as they have something they need to track its bugs in.
Let’s Talk Tech
Now finally, on to the tech behind getdebug.
Disclaimer: I probably wouldn’t be able to disclose everything in detail (obviously because of IP), but I’ll try to cover as much as I could.
Getdebug is built in multi-tier architecture layers. It is essentially a web app, and much like any modern web application that isn’t monolithic, our bug management platform has two main parts – the backend, and the frontend.
The backend runs on NodeJS and served with express. The decision at the time on why we chose this stack was mainly because the people working on this, have worked with this stack and we feel confident to use this. Also when speaking of NodeJS, it’s almost de facto that the go-to framework is express. Besides, we want something that is really lightweight, so flexible, and could be ready if we were to take a direction we hadn’t even thought about. And so far, it delivers.
On the database-management side, we’re using a relational one (that much I can disclose). It just felt so right and robust at the time we started it. We may have encountered some speed bump when we pivot, and we may have thought about migrating to a non-relational one, but it’s been resolved and we’re still using it. We still have plans to add (not move to) a nosql as a secondary dbms once we hit a certain point, so it’s not entirely out of the table.
The frontend is built with NuxtJS. It’s a framework based on VueJS. Again, the reason we chose this at the time was because this is what we were most familiar with. Also, having to work with other libraries/framework, I find working with VueJS environment really boosts developers’ productivity and especially with Nuxt, it has the best developer experience (DX), and with Vue’s awesome documentation, we can practically build anything without banging our heads against the wall.
On the UI part, we didn’t really have a dedicated UI/UX team at the time, so when we started working on this, we just use Bootstrap as it just works and can just bootstrap our app (get it?). Now though, despite we’re still using that, you probably won’t notice that it’s actually still using bootstrap as we’ve customized the hell out of it. Also, we now have a UI/UX team, so at least the direction is clear for how the user interface will take form.
How do we ship getdebug with those two separate parts, and how do they communicate with each other? In a production environment, we ship each of them in a container, and deploy them in a server. And for security reasons, obviously we close the access for the backend container, and let only the client (frontend) container to communicate with it through an API.
This is probably also too obvious but each codebase is also stored in a git repository and connected to a CI/CD pipeline that allows us to deploy everything automatically for any changes/releases.
Now, what you read here is just a frontline app. Getdebug as its core, will be much more complex than this.
In the third part (if I ever find the time, I hope), we’ll talk about getdebug’s future. Hopefully we can talk about the tech behind the very core of getdebug itself, the automation engine, or even the collaboration mechanism.
And not to forget to mention, bug management platform: getdebug version 2 is currently in Beta so, go ahead and give it a try.