paint-brush
This is how I chose the stack for GitShowcaseby@pedsmoreira
546 reads
546 reads

This is how I chose the stack for GitShowcase

by Pedro Silva MoreiraFebruary 16th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

<span>C</span>hoosing the technologies for your new project is something hard! There are tons of frameworks out there to choose from. You may also need things like tools for Continuous Integration (testing, code quality), sending email campaigns, repository management (GitHub), and servers.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - This is how I chose the stack for GitShowcase
Pedro Silva Moreira HackerNoon profile picture

Choosing the technology stack while looking for the business. Keep calm and enjoy the ride!

Courtesy of Jake Ingle — Unsplash

Choosing the technologies for your new project is something hard! There are tons of frameworks out there to choose from. You may also need things like tools for Continuous Integration (testing, code quality), sending email campaigns, repository management (GitHub), and servers.

As it is a side project, I had a lot of freedom with GitShowcase to choose what technologies to use. On this post I'm going through my process for choosing each part of the stack.


GitShowcase_Developer, feature your best projects in a plug and play portfolio. The best part, for free._www.gitshowcase.com

Making Choices

The Framework

Over the years I have worked in many projects with very different frameworks. That said, Ruby on Rails has the best developer experience in my humble opinion. It's a breeze to use rails g scaffold and rails new creates a well rounded project.

Because Rails uses Ruby, it provides a lot of flexibility and development friendliness. It may not be the best choice in performance matters (compared to Go, Elixir or Scala), but I highly recommend you to take a look at it before you start your next project.

Laravel (PHP) was also highly considered for this projects, but Rails won the fight because of it's awesome scaffolding tool and Ruby being a lot less verbose than PHP.

The Ruby/Rails community is amazing and there are tons of awesome gems that speed up development process. Once the Rails project was setup I was able to plug and play gems for important parts of my app, like authentication, GitHub API and web inspection.

The Front-end

I consider this the trickiest part. With the recent progress with node.js and huuuge amounts of frameworks, bundlers and languages being created everyday (Typescript, Dart, ES6, Elm, ReactJS, AngularJS…), this is one of the hardest choices.

I decided to choose the good old jQuery with Coffescript, as it's sintax has some similarities with Ruby.

[Voice in the background] - jQuery? Really? It's old!

[Me] - Old?? jQuery Rocks!

jQuery is very easy to use and interacts well with backend generated pages. For performance improvements, TurboLinks does the trick of not reloading the page, so the app looks like a SPA (Single Page App) without the downside of building two entirely separate applications. (PS. it already comes configured for you :O)

I do appreciate the power of frameworks like ReactJS and VueJS, they make building Single Page Apps much easier, stable and robust, but they also drastically increase the complexity of the project.

Choosing the Server

The goal was to code and ship a product.

Choosing Heroku was a no brainer. I do not like to spend time configuring a custom server for a side project that doesn't exist and therefore still has no users. I prefer to ship and then, if it goes well and I start to notice bottlenecks, I can worry about tuning the server then.

I've deployed both front and back end projects on Heroku before and the cost benefit is great. You can get your app up and running in a couple minutes. As your app grows, you can add plugins and upgrade your plan to get better performance. The costs can grow pretty quickly and you may think about migrating to a 5$ instance on Digital Ocean, but don't forget to consider the time you'll if you had to configure everything manually on your own server :) (time is money).

Choosing the Database

If you're familiar with Rails and Heroku, I know you're screaming POSTGRESSSSS!!!

You're right! I chose Postgres. Not only for the easy integration with Heroku and Rails, but also because of the JSON field type that allowed me to create the users's skill list as a hash.

The skill list consists of[{name: mastery}] and doesn't have foreign keys, so it fits perfectly on a JSON field. Doing this allowed me to improve performance, save a lot of database lines (Postgres costs on Heroku are measured by database lines) and reduce the complexity to handle skills.

Choosing the CI tools

I chose to enable automatic deploy on Heroku (from GitHub repo), TravisCI for running the tests and CodeClimate for code quality. TravisCI and CodeClimate are free for OpenSource projects :)

There are other tools like Codeship and CircleCI. I just prefer to work with TravisCI and CodeClimate because I feel comfortable with them, and besides having integration between themselves for easier CodeCoverage, they are easy to use.

Choosing GitHub

Another no brainer. GitHub is the place for Open Source projects. Plus, the project is based on signing in and fetching projects from GitHub!

Before I decided to Open Source the project, I considered BitBucket, as it has a free tier for private projects. In the end Victor (the other Co-Founder) and I decided that sharing the code base would be a great way to share with the community. I will explore this topic more deeply in another post.

Choosing MailChimp

MailChimp has the whole package. It's not the cheapest, but it's certainly great to work with and does not demand lots of development resources. They have a nice campaign builder and an easy to use API for both working with lists and sending transactional emails through Mandrill.

Detaching email marketing from development can help a lot, as it gives freedom to whom is taking care of marketing and relieves the developer of a lot of work. In the early stages, when the developer needs to implement lots of features, this can be very decisive!

Final Thoughts

The stack I described definitely has a lot of bias due to my experience. My recommendation is that you keep your eyes open for new opportunities and technologies, but choose what you're comfortable with.

There will always be some shining new framework, and you don't have to always use the latest one :P

Help spread the word.

You can help GitShowcase be heard by more developers. gitshowcase.com

GitShowcase on ProductHunt

If you’re still here, I know you liked this post. You’re very welcome to share the love and click on the heart :)

If you like this, remember to share the love and recommend it ❤