It’s not easy to create something out of nothing. There were a lot of decisions we had to make before starting to code our first product at The Coral Project.
Whatever we build, there are some key principles we have to stick to:
• It has to be easy to deploy.
We’re building for a broad range of publishers, some big with their own development teams, some small without any developers on staff.
• It has to be flexible with the fewest possible updates, restarts, and pokes.
Each publisher will have their own instance of our products, so we can’t guarantee that any updates will be installed. Finding ways to update functionality without touching the server is at the forefront of our minds.
• It has to be accessible to the open source community.
In a future post, we’ll talk more about the opportunities and challenges that come with this. Let’s just say that everything we do, we do it for you.
• It is language agnostic (as much as possible, anyway.)
This means that each piece we build can be written in the most appropriate language. This also opens the door for more people with a variety of skill sets to contribute.
• It has to be appropriate for mobile, and future proofed (as much as possible.)
This is initially a two-year project. We hope that what we make will be useful far beyond that. Do you know how people will interact with technology then? Neither do we so we’re not going to lock ourselves in.
For deployment, we chose Docker, which should make what we make easy to run and means that we don’t have to worry about different machines and environments. We encourage others to wrap our software in their deployment tools of choice, or build it from source and launch it themselves. To each their own.
For the first product, we’re using Go, React with Flux (redux), and Python.
Going with Go
We’re using Go for the majority of our server side needs. It has an enthusiastic and growing community. The robustness of its type system and other guarantees will mean that we can avoid run-time errors, and it has a very mature group of libraries that we can use in our basic components. It’s easy to deploy – it compiles to a single file; it’s very efficient, so can be run on less powerful hardware, and it’s very fast. On top of all that, it has the support of Google, where it was first constructed. All the members of our team are pretty new to Go, and so far are really enjoying programming in it.
React with Flux on the front end
There is a lot going on these days with front end frameworks. We want to take advantage of recent advances in front end application design while maintaining good browser compatibility and simple tooling for development. We also wanted to choose a language with a strong community, and one that we think will grow in popularity over the coming years.
We spent a lot of time looking at Backbone, Angular, React and Ember. Anyone of these frameworks would do a fine job in creating strong software. However, working with a DOM is our least favorite part of front end dev, and React’s Virtual DOM completely abstracts away without having to worry about the complexities of the DOM. This has enabled a lot of very attractive features:
- The diff-based rendering only updates things that have changed, making it fast and eliminating UI headaches such as losing content of input boxes and rapid changes in page length that mess with the scrolling
- Since the view layer is completely modeled, we can target native iOS, Android, OSX and Windows apps from a single code base
- The ability to fully render the initial DOM state on the server allows us to deliver that crucial first view without needing to download and execute all of the JavaScript (node handles this natively, node handles this natively and go-duktape provides all the bindings needed to run JavaScript in our Go programs.)
- Component based architecture is a very elegant approach to packaging templates and logic, creating a very modular and extensible application.
To compliment React, we are using the Redux flavor of Flux to standardize and simplify the application architecture. Flux reduces the universe of callbacks, promises and other async flows into a single action loop. This is a breath of fresh air for anyone who has tried to pick up a significant application and figure out exactly what is going on. In addition, the replayability of action sequences opens up new frontiers of debugging and application analysis. As our products grow in number and complexity, we hope these principles will help us maintain sanity as well as make it easy for others to contribute.
As for Python… as we build our products, pieces of them will be in a couple of different languages. For our first product, we’re doing the data science piece in Python, because of the maturity of the libraries and the fact that most data scientists already use it.
As we move forward, we’ll go through a cycle with each of the different technologies, seeing how users and others respond to them. If it seems like the right decision, we’re open to switching to something else.
These are just some of our initial thought processes and choices while building at The Coral Project.
When you approach a significant green-field project, how do you make those first few crucial decisions? Tweet at us and let us know.
Click here to discuss this piece within The Coral Project Community.