Creating a customer-facing app for the first time was a bit different for a team that was traditionally focused on doing back-end work. In a talk from PAYMENTSfn 2019, Jared Knipp gives us an inside look at how the customer experience team at Spreedly was formed, how they selected their JavaScript framework, and how the Spreedly Dashboard came about.
Check out Jared's talk above, and follow along with the transcript below.
Transcript of "A Backend Engineer's Vue of Front-End Development"
Jared Knipp: Hi, I'm Jared Knipp. I'm a staff software engineer and technical lead here at Spreedly. I recently had the opportunity to lead development on the customer experience team building customer facing applications, but I've primarily been a back end engineer throughout my career, so it was a big change for me to shift to more of a front end development focus.
Jared Knipp: A quick background of the customer experience team ... There we go. Okay. The team was originally formed to focus on customer facing applications, where Spreedly has traditionally been a back end focused engineering group. One of customer experience's core objectives was to consolidate multiple existing applications into a single tool that we called Dashboard, which we hope one day will be our primary customer facing application.
Jared Knipp: Dashboard started off as a standard Elixir in Phoenix server-side MVC app with a small bit of jQuery and JavaScript for displaying our insights graphs. As we started to think about the future and our longterm user experience, we began thinking more about our front end tooling needs and defining what we wanted our user experience to be for our customers. We wanted to expand beyond the simple static pagers and start introducing more interactivity into our application. We also wanted to display data without doing a full page refresh. We wanted to do some research and plan for future growth. We didn't have a need for a single page application at the time, but we might in the future.
Jared Knipp: We were starting from scratch in picking front end tooling, and we needed to pick a JavaScript framework, a build tool, and a unit testing framework. I set off to explore the world of modern JavaScript, and I was immediately overwhelmed with all the options that were available. It just seemed like there was a new framework, a build tool JavaScript version every month or every week. I just didn't really know where to start. There's just so many options available.
Jared Knipp: I took a step back and started developing a set of criteria to help drive our decision making process for choosing front end tools. What I was really searching for were front end tools with the following characteristics. I wanted whatever we chose to have excellent documentation, also wanted whatever we chose to have great community support, to make sure whatever we chose would be around for longer than a week, hopefully with lots of GitHub stars. I wanted it to be easy to get started in, but powerful enough that we could add advanced functionality later on. I also wanted the ability to bring in components of piecemeal without introducing wholesale change to the application. Perhaps the main consideration was that the team was composed of engineers with varying levels of experience. We had very little front end development expertise. The experience that we did have was using jQuery and it was outdated. We didn't want to get overwhelmed by learning all the things in the JavaScript universe so that it would impede progress of the team.
Jared Knipp: Armed with my new set of criteria, I went back and started evaluating a limited set of options. I started looking at frameworks. We already had some experience with jQuery. We started asking the question, did we really even need a fancy front end framework for our need, or could we leverage what we already had? The answer quickly became like, no, we couldn't use jQuery. It was just too small for our future needs, and the way that DOM manipulation is done, it just felt like there had to be a better way with modern JavaScript frameworks.
Jared Knipp: Next we looked at Angular. Angular just seemed too big and too complicated and we didn't need all the features it provided up front and we weren't doing a single page application yet. That left us with two solid contenders, React and Vue.js. Both had great documentation, vibrant communities and the ability to pull in components of piecemeal, but it just felt harder to get started in React, so in the end we decided to choose Vue.js. Vue lets you write code using single file components, which allow you to write template logic, JavaScript and styling all in one file. They also have the concept of template directives. Vue just felt like a natural fit for us.
Jared Knipp: Next we looked at build tools. Our Phoenix application was originally built using Brunch, but we also considered using Gulp and Grunt, but the Phoenix and Rails communities were moving to Webpack as their default, so we made the decision to use Webpack as well.
Jared Knipp: Then we looked at unit testing frameworks. The goal here was simplicity and ease of getting started. First we looked at Mocha and Karma, and these required additional dependencies and configuration. They were harder to get started in and we didn't need the flexibility that they provided. Then we looked at Jasmine, which was definitely a good option, but in the end, because Jest is based on Jasmine, we decided to use Jest instead. Jest is described by their website as delightful JavaScript testing, and yes, it was. It was easy to use and worked out of the box with zero configuration. It has great documentation. It's developed by Facebook, so it has good community support, and it played well with Vue.js.
Jared Knipp: To recap our dashboard tool set, we chose Vue.js as our JavaScript framework, Webpack as our build tool, and Jest for unit tests. We also ESLint for linting and style enforcement, which really helped improve our JavaScript capabilities as a team. At our specific dashboard implementation, we introduced a Vue into existing Elixir templates a page at a time with supporting back end APIs. We started off with Vue's single file components and built in state management, but we could switch to Vuex in the future if we needed to. We also opted to use Phoenix's server-side routing, but we could move to Vue Router if we moved to a single page application model in the future. This worked really well for us while allowing for future growth and expansion.
Jared Knipp: My big takeaway is that front end development doesn't have to be mysterious and scary. Define your tooling needs ahead of time and be intentional in picking the right tool for the right job. If you'd like to talk more about our front end tooling decisions, our challenges in dashboard or payments in general, please come find me. Thank you.
Download the Payments Orchestration eBook Below
.png)
.svg){kind=icon}
.svg)
.png)
.png)
