Portugal - Building microservices so we can test the system, document specs and the exchange of messages between them
Scala
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
docs
project
src
.gitignore
.travis.yml
LICENSE.txt
Procfile
README.md
build.sbt
system.properties

README.md

eHelp Build Status Apache 2.0 License

From a domain perspective, the idea is to enable Someone to Flag a Problem Somewhere and Ask for Help.

From a technical point of view, we are building microservices so we can test the whole system, document specs and the exchange of messages between them.

Api specs are available here.

Building the Application

Build it with:

sbt compile

Test it with:

sbt test

Check this out to see more sbt commands.

Running the Application

Run the app without it being packaged using Native packager:

sbt stage
./target/universal/stage/bin/ehelp

Or starts eHelp (with 'prod' profile enabled):

$ heroku local web

Environment Variables & System Properties

  • $PORT is mandatory when running in "prod" profile.
  • -Dprofile defines the targeted environment. It defaults to "dev", but can be set to "prod".

Guidelines

Spec tests

Spec tests (which may include acceptance or smoke tests) should:

  • be written as documentation so developers can consult them to understand the API provided;
  • be automatically published after every successful CI build so a developer can easily consult the specs.

This and this are two examples of spec tests that follow these guidelines.

Stories

eHelp stories are in this Trello board.

About Monorepos

This project was first intended to be managed as a monorepos, that is, it would contain everything from the microservices that composes the stack till the testing tools in a single Git repository.

The idea is quite cool: everything necessary for a project in one place. Everything you need is there, just clone the project and you are in! (Much has been sad about how nice monorepos are, including Facebook and Google use it.)

Unfortunately, we've found difficult (not to say impractical) to embrace monorepos in our current context.

CI build and deploy configuration

We want to build apps so people can use it, which (for us it) means being able to deploy apps in a safe, cheap and easy way. That translates to build and deploy (if the build succeeds) with nothing more than a 'git push to the repository.

We are integrating Git, TravisCI and Heroku to achieve that, and there's where our problems with monorepos begin: it's hard to integrate everything when having a Git project with many apps, and very very hard when these app are developed for different plataforms (e.g. Android, JDK, Erlang OTP).

Here are a few links to articles and texts where people are trying to come across this sort of problems:

Plus, there are well-know conceptual and performance challenges with Monorepos.

So?

So we are backing away from monorepos for now. But we do have interesting questions here, and, maybe, we should come back to monorepos one day.