TrueCar values transparency and strives to give back to the developer community at large. Given this generosity of spirit, we thought the world would like to see what our awesome dev teams are up to. We are releasing a new tool, but doing so a little early (rough edges and all) so people can see our process. We’re still tinkering, so we consider this a pre-beta release.

After months of work, problems and problem solving, we’re excited to give you GlueStick, a command line interface that lets users rapidly develop universal web applications. (Feel free to open issues or submit pull requests on GitHub.)

GlueStick allows users to quickly create new applications with its bootstrap generator, along with generators for components, containers, and reducers. In addition, GlueStick contains a fully functional test environment, server-side rendering, and an asset bundler. However, GlueStick sidesteps the hassle of any configuration files.

Keep reading to find out why and how we built GlueStick, and why it’s so exciting for us!

Our Best Tools Yet… Are Not Good Enough

Recently, lots of innovations have been released that make building web applications better than ever before. React, for instance, has completely changed the way front-end applications are made. Rendering the same components client-side and server-side is now relatively easy. It’s amazing what developers can make when they combine libraries like React, React-Router, and Redux with tools like Babel, webpack and Node.js. Yup. Server-side rendering of front-end applications has arrived! (Okay–it might have actually arrived a while ago, but with these tools, the entire process has become enjoyable.) Still, that is a LOT of components.

Breaking It Down

Learning how to hook up webpack, Babel, Node.js, and Redux for a universal application requires a lot of boilerplate code. This is a barrier for people new to these tools, and a pain for even for experienced people who are starting a new project. None of these items is particularly complex or time consuming on its own, but when combined together, the process can be cumbersome and annoying.

There are boilerplate projects developers can fork for their own projects, but doing it in such a piecemeal fashion falls short of what we expect in modern programming workflows. As Rails developers, we just want to type something like `rails new project_name` and be done with it.

Enter Yeoman. Yeoman seemed like the perfect solution to the problem. Developers can take a boilerplate project and create a generator that they and others could use to go from 0 to web app in seconds. It is very simple to create a Yeoman generator, thanks to the Yeoman generator for generating generators.

I ran with this for a while, and thought it was the solution to our problems and this jumble of tools. However, a nasty XSS vulnerability was uncovered in the way we were connecting our front-end application with the server-side rendering. Fixing it was relatively simple, but it got me thinking that a generator might not be enough. If there were several applications that were generated from our generator, which was luckily still private, there would have been applications floating around with this XSS vulnerability. Resorting to manual updates for these types of things was not an acceptable solution. It wouldn’t be as simple as replacing the trouble files in each application because the developers may have updated those trouble files already. We needed a dead simple way to see which apps that used our generator needed to be updated, and an equally simple way to update them.

Security updates weren’t our only concern; we wanted the flexibility to make updates that would optimize our server-side rendering, improve our testing stack and logging, and allow for a whole bunch of other cool stuff.  There may have been a way to get Yeoman to work for this, but it was starting to look like less of a perfect solution and more like only a piece of the puzzle. We needed something that would also allow us to maintain and innovate on the shared parts of our applications. Cloning boilerplate projects and Yeoman generators were not going to solve the entire problem we wanted to solve.

So What Did We Do?

The decision to ditch our Yeoman generator and write a command line interface (CLI) from scratch was not one we took lightly. I didn’t invest a lot of time in our Yeoman generator since its simplicity decreased my emotional attachment to it. A new project generator was only part of what we needed. We no longer wanted just a generator; we wanted something that would allow the developer to see and think beyond the glue that held the browser and server-side rendering together. We needed a solution that let developers get straight to the application code without mucking around with config files to get a testing environment set up. At the same time, this magical solution needed to be extremely simple in order to ensure that developers had updated access to it quickly and easily. We needed a way to tie it all together.

We needed something to hold it all together…a gluestick.

As we continued exploring the idea of writing our own CLI, we realized that we could also sweep all of the testing, webpack and Babel configuration files behind this CLI if we did it right. Not only that, we could use this glorious CLI and sweep the server-side rendering behind it as well.

Yes, moving these things out of the developers’ hands would come at a cost. For instance, if they want finer-grained control over their stack, like the ability to add new webpack loaders, and Redux middleware on an app by app basis, they wouldn’t have access to those files. Obviously, since our whole impetus is to improve productivity, the last thing we want is to hold developers back. However, just because the bulk of these configuration files live in the CLI and not inside the application code doesn’t mean we can’t provide hooks to the parts that developers will care about. We have plans to add these hooks in the near future.

The Road Ahead

Although it’s early, we are very serious about this tool and we fully plan to continue iterating on it. Some improvements in our very near-term road map include deployment tools. We use Docker here at TrueCar and hope to make it extremely simple to create Docker images for GlueStick apps as simple as `gluestick dockerize`. A CLI from scratch is not an easy thing to develop or integrate, but we are continually forging ahead here at TrueCar—designing for the future, not just for current schemes.

Please visit the project on GitHub for more information on how to get started.  We have also included a guide to getting started here on our blog.