In this blog post I would like to put a spotlight on most important changes we have recently
made in Bootzooka.
The live demo is available at bootzooka.softwaremill.com.
The project is available in our GitHub repository under Apache 2.0 License
which means you can freely use any part of it.
Bootzooka has been actively developed all the time, but in the last few weeks we introduced changes that have
noticeable impact on the whole project. Let's take a look on it:
Flattened project structure
The number of SBT sub-projects was decreased by pulling backend-related modules into a common project called bootzooka-backend.
This way we achieved clearer separation between server- and client-side components.
We dropped MongoDB
While MongoDB is a really great document store, it has a limited scope of application kinds, which may be problematic when
you're developing the scaffold.
With such project you cannot predict where it will be used and have absolutely no guarantee that NoSQL will fit
particular project's needs.
Thus we decided to replace it with a traditional SQL database which has a wider scope of application, thereby making
Bootzooka more universal.
We chose H2 SQL database because it's lightweight and doesn't require any
3rd party software to be running (e.g.
This simplifies both development on a local machine and a Continuous Integration (CI) process.
Since we're in the SQL's eco-system, you're able to replace H2 with any other 'production' RDBMS (e.g. MySQL, PostgreSQL or Oracle)
without any pain.
Painless database schema evolution
Explicit schema comes with the need of applying DDL scripts whenever it evolves.
Often such scripts are applied manually during deployment, which makes the whole process more complex (you have to check
which scripts are already applied at the particular environment and which one you have to apply next)
and error-prone (e.g. you may forget to apply one of the scripts or apply them in wrong order).
Bootzooka has been integrated with Flyway - a tool that can automatically apply appropriate
DDL & DML scripts.
You only need to put your scripts under
db/migration/ directory (which must be present in the classpath) and obey the
Flyway's naming convention.
Bootzooka stores its schema evolution SQLs under
Migration will be performed automatically on an application start.
Also, by extending
FlatSpecWithSql you can bring Flyway to your integration tests and catch any problem with scripts
during regular CI (which usually is done right after problematic change was pushed to the repository).
Interactive REST API documentation
The interactive API docs are available at
The raw JSON produced by Swagger lives at
Don't hesitate yourself to play with our demo instance's interactive API browser, available at
That's all about interesting changes in the backend. Let's check what has changed at the client-side!
New views' routing
We decided to replace plain old uri-oriented Angular's ng-router with modern, states-oriented
The new mechanism is more flexible and supports parallel & nested views, which makes master-detail
views development a piece of cake :)
Brand new user notification service and directive
The old notification mechanism had a big disadvantage - it could display only one message of particular type
(error or info) at the same time.
It has been replaced with dedicated
NotificationsService (available in
that aggregates notifications and
<bs-notifications /> directive which dynamically creates
pop-ups for each notification incoming from the given source.
Michał Ostruszka came out with a brilliant idea of
decoupling directive from messages provider.
Such separation allows us to include many notification directives displaying different kind of content on the
same page. Reusability has been increased :)
That's all of noticeable changes. We also updated Scala, Scalatra, AngularJS
and other dependencies to the most recent stable versions, to keep Bootzooka up to date.
Any kind of suggestions, ideas and pull requests are welcomed!