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:
Test it with:
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".
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.
eHelp stories are in this Trello board.
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 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.