Starter webapp using Spring Boot on the backend and Angular 2 on the frontend, with Maven and Angular CLI as build tools and with hot reloading on both sides.
Run the app:
git clone https://github.com/dlizarra/spring-angular2-cli-starter.git
cd spring-angular2-cli-starter
mvn spring-boot:run
The app will be available at http://localhost:8080.
There's also a sample REST endpoint at /users, the H2 console at /h2-console and all the endpoints exposed by Spring Boot Actuator (/health, /beans, etc.)
The Java code is available at src/main/java as usual, and the frontend source files are in
src/main/frontend.
Run StarterMain class from your IDE.
Go to src/main/frontend and run ng serve.
Now we should work with http://localhost:4200 since this is where the Livereload server will serve the content. All the requests will be proxied to the Spring Boot backend at http://localhost:8080.
We can change the proxy url in the .ember-cli file.
There are only configuration files involved:
- package.json where we have a "build" script that runs
ng build. - pom.xml in which we configure the frontend-maven-plugin to run this "build" script during the
generate-sourcesphase. - The .ember-cli file where we specify the output directory for the compiled frontend files, which is
src/main/resources/static.
When we run mvn spring-boot:run the frontend source files will be compiled and left at src/main/resources/static which is one of the default locations that Spring Boot specifies for static content (the others are /META-INF/resources, /resources and /public), so it will take those files and move them to target/classes/static.
In the backend we make use of Spring DevTools to enable hot reloading, so every time we make a change in our files an application restart will be triggered automatically.
Keep in mind that Spring DevTools automatic restart only works if we run the
application by running the main method in our app, and not if for example we run
the app with maven with mvn spring-boot:run.
In the frontend when we run ng serve Angular CLI starts an Ember Livereload server that will watch for any change in our frontend files.
The project comes prepared for being used in three different environments plus another one for testing. We use Spring Profiles in combination with Boot feature for loading properties files by naming convention (application-<profile name>.properties).
You can find the profile constants in
StarterProfiles
and the properties files in src/main/resources.
The database connections are configured in DatabaseConfig where we can find a working H2 embedded database connection for the default profile, and the staging and production configurations examples for working with an external database.
Instead of the default JDBC Tomcat connection pool we added a faster Hikari CP one.
The project includes three base data repositories:
- ReadOnlyRepository: We can use this base repository when we want to make sure the application doesn't insert or update that type of entity, as it just exposes a set of methods to read entities.
- CustomCrudRepository: It's the same as the
CrudRepositorythat Spring Data provides, but thefindOnemethod in the custom version returns a Java 8Optional<T>object instead of<T>. It's just a small difference but it avoids having to override thefindOnemethod in every repository to make it return anOptionalobject. This repository is intended to be used when we don't need paging or sorting capabilities for that entity. - CustomJpaRepository: Again, it's there to provide the same funcionality as the Spring
JpaRepositorybut returningOptional<T>. We can extend this base repository if we want CRUD operations plus paging and sorting capabilities.
All the boilerplate for the initial Spring Security configuration is already created. These are they key classes:
- User, Role and RoleName which are populated by data.sql file for the default profile only.
- CustomUserDetails
- CustomUserDetailsService
- SecurityConfig with just very basic security rules.
The project includes Orika and it already has a class, OrikaBeanMapper, ready to be injected anywhere and be used to do any mapping. It will also scan the project on startup searching for custom mappers and components.
You can see how to use it in UserServiceImpl or in this sample project.
This, along with Lombok annotations for auto-generating getters, setters, toString methods and such, allows us to have much cleaner Entities and DTOs classes.
For unit testing we included Spring Test, JUnit, Mockito and AssertJ as well as an AbstractUnitTest class that we can extend to include the boilerplate annotations and configuration for every test. UserServiceTest can serve as an example.
To create integration tests we can extend AbstractIntegrationTest and make use of Spring @sql annotation to run a databse script before every test, just like it's done in UserRepositoryTest.
The project is also ready to use Cobertura as a code coverage utility and Coveralls to show a nice graphical representation of the results, get a badge with the results, etc.
The only thing you need to do is to create an account in Coveralls.io and add your repo token key here in the pom.xml.
And if you want to use different tools you just need to remove the plugins from the pom.
A travis.yml file is included with a minimal configuration just to use jdk 8, trigger the code analysis tool and deploy the app to Heroku using the api_key in the file.
We also included a Heroku Procfile which declares the web process type and the java command to run our app and specifies which Spring Profile we want to use.
- Spring Boot
- Spring MVC
- Spring Data
- Spring Security
- Spring Test
- JUnit
- Mockito
- AssertJ
- Lombok
- Orika
- Maven