Authors: Sylver-John Imhoff, Mathieu Morainville
Pulsar is a small team of web developers whose goal is to deliver new quality projects regularly. In this article we will give you our vision of a good way to build a side project from scratch, with simplicity and rapidity in mind. So let’s talk about Freatle, our last side project.
Every project we start is born on a Google Doc shared to each Pulsar’s member where we can discuss about the features, the stack, the architecture and so on. Once this step is done we clean the document up and put it on a Trello board. This way, we don’t develop useless features and we avoid switching from X langage to Y because our choices were wrong. Now you may think:
Come on, no one start by coding from scratch and only then think about it.
But if you think about the students who just finished their studies or the developer who has only worked with a CMS, you understand that not everyone starts by this step.
For Freatle we went from a Google Doc:
To a Trello board:
The Trello board of Freatle
We build side projects for two main reasons: fun & learning. So we choose the languages that we love. For Freatle we picked:
How to create a new event on Freatle
And… That’s all!
Really? Which language do you use for your backend?
Here comes my favorite part: we don’t have a backend.
What?
Remember, we want to build a side project with simplicity and rapidity in mind, so why should we build a backend, host a server, buy a domain name? This cost a lot a time and a lot of money (and earning money should never be the first goal of your side project).
But, how do you store your data? How do you host your frontend application?
There are many online solutions to solve this problem: Firebase, mLab, Graphcool, etc.
These applications provide you everything you need: hosting, business logic programming, storage, etc. So basically, you don’t need a backend. If you only have to store and manage some data, create a Firebase project and access it through your Firebase’s API.
Because we wanted to learn something new, we choose Graphcool to use GraphQL and because we didn’t want to reinvent the wheel, we used Apollo to build our GraphQL request.
To sum up we have:
Ok I get it, you don’t have to host your own backend. But what about your frontend ?
Again, there are a lot of online solutions to host your frontend application for free, GitHub, Surge, Now, etc. This way we don’t have to buy a server and a domain name. We chose Surge for Freatle because we had already work with GitHub Pages and wanted to explore a new option.
To sum up:
We are almost done…
Do you work with several developers? Do you want them to work quickly and efficiently? There is only one choice: Git. Use Git. Work with Git. Eat Git.
You have the choice: you can host a private repository for free on Bitbucket, host your own server with GitLab, use a public repository for free on GitHub, etc. We wanted to keep our code private for free so we chose Bitbucket.
With Git we use the pull request workflow: we have different branch to work on, keep master clean, use pull requests to merge the code, review the code of each pull request, etc. It helps us to implement continuous integration to keep our project clean and stable. And to keep our change log clean, we use the Git Commit Guidelines that Google uses for AngularJS.
We don’t want to manually deploy our application after each release. We have to automate the task, just as we automatically run tests for each pull request. Since this is a side project you may not want to lose your time writing tests but if you want to be proud of your project in front of a recruiter, you should. For Bitbucket we use CircleCI (it’s free and otherwise you have Travis for GitHub). This is an online service which will connect to your repository and automatically run the tasks defined in a configuration file.
For example:
# Javascript Node CircleCI 2.0 configuration file## Check https://circleci.com/docs/2.0/language-javascript/ for more details#version: 2jobs:build:docker:# specify the version you desire here- image: circleci/node:7.10
_\# Specify service dependencies here if necessary_
_\# CircleCI maintains a library of pre-built images_
_\# documented at_ [_https://circleci.com/docs/2.0/circleci-images/_](https://circleci.com/docs/2.0/circleci-images/)
_\# - image: circleci/mongo:3.4.4_
working\_directory: ~/freatle
branches:
only:
- master
steps:
- checkout
_\# Download and cache dependencies_
- restore\_cache:
keys:
- v1-dependencies-{{ checksum "package.json" }}
_\# fallback to using the latest cache if no exact match is found_
- v1-dependencies-
- run: sudo npm install -g surge
- run: npm install
- save\_cache:
paths:
- node\_modules
key: v1-dependencies-{{ checksum "package.json" }}
- run: npm run build
- run: surge ./dist --domain [https://freatle.surge.sh](https://freatle.surge.sh)
_\# run tests!_
- run: npm test
Thanks to this file, every time we make a pull-request on master, CircleCI run the tests and when a pull-request is merged, it deploys our application to Surge.
If you want to make a side-project quickly and efficiently, follow this steps:
If you follow these points, you will have a stable, scalable front-end application, built for free and with a really quick setup time (nowadays we can create an application from scratch in one day). If you follow this, you will be proud to have a project cleaner than most of the companies you would apply to.
We repeat, this is our personal opinion, you may think this is stupid to waste time on setting up CircleCI and write tests for a side project, you may think that implementing continuous integration is not useful if you work alone, but we don’t think so. We think that a side project should be built as you would build a perfect application to run a startup and even if no one will see your code today, even if no one use your application today, you don’t know how it will be tomorrow.