Ben Balter, a product manager at GitHub, once said that open source isn't a fad, or a bunch of hippies out in California passing around tie-dyed laptops like they would illicit substances. Open source is how modern organizations build software. We couldn't agree more with that and that's why we are opening the code of one of our core services.
The Syncano Platform
Syncano automates large chunks of the process of building an app (web, mobile, IoT, you name it). It enables developers to launch their applications faster with fewer resources. They can get their minimum viable product into the market quicker and get ahead of the competition by focusing on improvements and growth.
Running the backend on our platform means you don’t have to worry about scaling problems when your app hits the big time. We run on top of the industry-leading cloud infrastructure and offer a straightforward pay-as-you-go pricing.
- remove lengthy, complex and painful development processes
- take the burden of security, scaling of servers and operation of technology platforms off the developers’ shoulders
Our more than 40k users -- including startups, independent developers, software houses and enterprises -- have put their trust in us because they know that Syncano is all about ease & speed!
Why are you open sourcing your Dashboard?
Why we decided to open source? Because we believe in transparency and are always searching for new ways to give back to the community:
- We write technical posts about the technologies that we use on a daily basis. You can find them on our blog
- All of our libraries are open source
- Our commercial website is also open source. We are using (the great) Gatsby as a static site generator. See our GitHub page for more projects.
- Also, check out the repositories in the Syncano Community GitHub, where we keep tutorials and small example applications.
- We actively support the hacklag.org foundation, which aims to connect developers, designers, entrepreneurs and new technologies enthusiasts.
- We also want to hear out and collaborate closer with our clients. We want to fix issues and get valuable feedback faster.
And since we believe in transparency, it wouldn’t be fair to not mention the PR benefits. We’ve built a great product over the last couple of years and we want you to know about it, and hopefully use Syncano in your upcoming projects.
The Syncano Dashboard is released under the über liberal MIT license. Copy, modify, merge, show it to your grandma, publish, sell, profit. Seriously, have fun!
What is it made of?
We’ve chosen to use React as the main library for building the user interface. Here are the main reasons underlying this decision:
- Components - composable pieces of code are one of the core concepts of React. You can combine and reuse them in various contexts within your project. The use of Components rapidly speeds up the development process. Thanks to this feature of React, we were able to complete the first version of our Dashboard in a couple of months.
- Great performance - React.js creates its own virtual DOM, calculates what changes need to be made in the real DOM, and then updates it accordingly. This way, React.js avoids costly DOM operations.
- It comes with great developer tools - The React.js chrome extension being one of them. It gives you a direct look into the virtual DOM just as if you were browsing a regular DOM tree in the elements panel.
These are just a few from an ocean of reasons why we decided to go with React. To learn a bit more, you can always check out this post: “Why React? 6 Reasons We Love It”.
The official Facebook proposition for managing the application state and data flow is Flux. Here’s Facebook's diagram that should explain it:
Confused? So were we, and that’s why we decided to go with something a bit more compelling at the time - Reflux. The idea behind it is to “introduce a more functional programming style architecture by eschewing MVC-like patterns and adopting a single data flow pattern.” In practice, it means that the above diagram, representing a data flow in your app, turns into this one:
Components listen to Stores and call Actions on change events. Stores listen to Actions and inform the Components that it’s time to re-render. Plain and simple! That’s why we chose Reflux. (Currently, there are more and more options for managing the data flow within React apps: Redux, Relay and MobX to name few of them. We are considering abandoning Reflux and using a different technology. More on that below in the “Future” section).
We chose the Google Material Design as our design principle. We liked it for its minimalistic approach and clean visual language. Also, the philosophy behind the material design and its components is a perfect match with React’s components. You can clearly see that in Material UI - the React implementation of Google Material Design that we use extensively in our Dashboard. Although now we are making steps towards defining our own design and are steering off from the Material Design components, we’d like to give a big shout-out to the awesome guys at Call-Em-All and all the contributors who made the Material UI happen.
We use webpack as a module bundler and a development server. Since we are writing in ES6, we needed a bundler and Webpack is a bit more suitable for bigger projects than Browserify. Plus, it comes with a hot reloader that propagates changes to React components on the fly, which is very handy during the development.
Currently, the two major competing Node.js build and task automation tools are Grunt and Gulp. When we chose Gulp in 2015, it was less popular than Grunt. The “code over configuration” philosophy behind Gulp seems to have taken the hearts of frontend devs, because now it has more contributors, downloads and GitHub stars than Grunt does. In the Syncano Dashboard, we use Gulp for automating the processes of copying files, starting the dev server, build, and deployment.
Update: Since the article was first published, we've switched to using Webpack 2 instead of Webpack + Gulp. You can see the current configuration here.
Since I have a testing background, I have to mention the testing tools. We are using Nightwatch.js as an end-to-end test framework. It’s a Node.js tool that uses Selenium Webdriver API to interact with the UI elements. There are several reasons behind this choice. Nightwatch:
- Has built-in support for Page Object Pattern methodology
- Is written in Node.js so it nicely integrates with the frontend stack
- Has a built-in test runner. You can run your tests in parallel, sequentially, with different environments, etc.
- Is easy to integrate with CircleCI, which we currently use as our continuous integration tool
- It handles taking screenshots on errors and failures
If you’d like to know how to setup Nightwatch in your project from the ground up, you can check out this post.
Of course, the list of software we use doesn’t end with the ones listed above. Here are several others that also require a mention:
- ESLint is our linting tool. We use airbnb config and extend it with a couple of our own rules. You can have a look at our ESLint config here.
- Lodash, with its utility functions, helps us with working on arrays, objects, and strings.
See the package.json file for a detailed list of modules we use in the Syncano Dashboard.
Over the last year, we’ve worked really hard to deliver the most value to our users and we are planning to keep doing so. We want to make this project better and better, and we are fully aware that there’s a long road ahead. The main challenges that we’ll be facing are:
- Refactoring the code to use a different state management library. When we started the project, Reflux looked like a decent choice. With the emergence of Redux, MobX, Relay and couple of other libraries, it looks like there are better alternatives. The issue with Reflux is that it didn’t scale well with our architecture. Our app has dozens of stores and it’s just getting more and more complicated to manage the state. That’s why we are currently looking closely into MobX and thinking about refactoring the Dashboard to use it as our state management approach.
- We’d also like to implement a mobile version of the Syncano Dashboard so that users are able to work with Syncano from any device.
- We want to add unit and integration tests. Although the Dashboard has pretty good coverage in end-to-end tests, there’s a lot of room for improvements. We are looking into Enzyme, testing utilities for React created by the Airbnb team, and Jest with its snapshot feature.
As you can see there’s a ton of work ahead. Come back once in a while and see how this project evolves.
We’ll be updating this post with more details about the project. Here are some direct links that you might also find useful:
- The Syncano Dashboard GitHub repository: https://github.com/Syncano/syncano-dashboard
- Readme.md file that contains instructions on setting up and running the project
- Maybe a bit off-topic, but we also have a post on how to Build a Pokémon Radar App in React with Syncano
- Last, but not least, we have a series of posts on testing React applications
If you’d like to contribute or simply learn more about the project you can:
- Read the contributing guidelines in the project's readme file
- Join the Syncano Community #dashboard Slack channel. We’ll try to answer any Dashboard related questions there
- Alternatively, you can submit a question on stackoverflow with the tag syncano-dashboard
You can also always send us a message at firstname.lastname@example.org and our twitter handle is @Syncano.
The Syncano team: Patryk Kopyciński (Frontend Team Lead), Hubert Wesołowski, Marcin Godlewski, Wojciech Pasiński, Daniel Siwek, Piotr Owerczuk, Tomasz Ciecierski, Maciej Kucharz (Head of Engineering) and me.
Former contributors: Daniel Kopka (currently Sauce Labs).