On the Sprintly code side of things, we’ve been working on some larger, foundational changes to the application that will allow us to deliver more resilient code faster. I’m pretty excited about it, and I’d like to share it with you.
You may have noticed that we recently switched from hashbang urls (i.e. #!) to more standard urls with slashes. One of the chief benefits of this was it offered a bit more consistency around navigation events and back buttons around the app. It also offers us a degree of flexibility in possibly breaking out (or adding) functionality to Sprintly that is decoupled from the main application. That is to say, while /product/1/reports/ now lives alongside /product/1/timelines/, this change allows for a future wherein those could live on different servers or run separate code.
In this vein of separating code, we’ve open sourced a JavaScript API client called sprintly-data. It’s a work in progress, but we’re actively investing in it. We’re in the process of porting portions of the app over to use it, and it will get more features as that happens. The first on the list is the Reports view, and the initial performance results have been promising, especially when loading large amounts of items like accepted.
We’re also working on componentizing portions of our application. This will result in a uikit powered by Facebook’s React library. One of the central goals here is that developers (those here at Sprintly and those who use Sprintly) will be able to easily create web applications that look and feel like the Sprintly product.
While the portions of the app we’re refactoring are foundational, this isn’t a ground up rewrite of our app. We’re still actively investing in the health of the code, having closed out 87 bugs fixes just this month.
As you can see, the focus here is around improving the quality of the app on both the short-term and long-term time scales. We’re doing this by breaking out layers of the application to increase maintainability, performance and speed of development. It’s my personal goal that our technically inclined users are able to build their own views into ticket data and have it look just as beautiful as Sprintly does.
As always, we love to hear your feedback. If I can answer any questions around the technical side of sprintly or what it is we’re doing here, please feel free to reach out to me on twitter or email.
Thanks,
Justin Abrahms, Director of Product Engineering
