How to build a good side project

Pulsar
HackerNoon.com
6 min readSep 26, 2017

--

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.

Thinking before writing

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:

The Google Doc for Freatle

To a Trello board:

The Trello board of Freatle

Choosing the stack

We build side projects for two main reasons: fun & learning. So we choose the languages that we love. For Freatle we picked:

  • Vue.js as the JavaScript framework. If you don’t know Vue.js, stop reading this now and go read an article about this marvelous framework!
  • Bulma as the CSS framework. It is really easy to use (from our personal opinion, easier than Bootstrap) and it doesn’t include any JavaScript so it’s framework agnostic. It allows to quickly create a good-looking design (see below).
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?

Choosing the architecture

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:

  • a frontend application in Vue.js using GraphQL with Apollo
  • a backend application running with Graphcool, for free and it can be easily scalable

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:

  • our frontend is hosted with Surge for free
  • our backend is hosted with Graphcool for free

We are almost done…

Last step: a good workflow

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:

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.

Conclusion

If you want to make a side-project quickly and efficiently, follow this steps:

  1. Think about the whole project on a Google Doc and Trello
  2. Use Git and the pull request workflow
  3. Automate your deployment and tests with CircleCI or Travis
  4. Pick your favorite frontend technology
  5. Don’t waste your time building a backend if you don’t need it, use a BaaS (Backend as a Service)
  6. Host your frontend application on a free online solution like Surge or Now

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.

--

--