B.A.S.S - Boot Angular Secure Starter

As this is a post related to a project "starter", I decided this time to rather have most of the details in the README.md on github rather than here on my blog.

To skip my ramblings: https://github.com/bdupreez/bass

I have recently done a couple little side projects and proof of concepts, all in Angular 2 (or 4 or whatever someone calls it), all using Spring Boot, all requiring some sort of authentication.

With both Spring and Angular teams iterating and releasing so quickly I found that by the time I got to a new POC I often had to do a number of updates and some of the projects brought in their own unnecessary complications, so it would take longer than I like to get started with the new POC, and therefore I decided it get back to a barebones implementation.

Hopefully it proves helpful to someone that requires an quickstart full stack Angular / Spring application.

It can extended and deployed as required.

One choice I would like to mention as it might not be to everyone's taste is the idea of having the Angular application as a Spring boot application rather than just deploying the static content to Nginx or Apache, and if you're looking to deploy this in a high volume production environment, you'd probably want to relook at that.
The reason I did this was just as convenience for myself. I liked having the whole app deployed as 3 self contained jars and drive both backend and ui configuration from one spring profile environment variable. Of course as this already does contain some of the Spring cloud dependancies, it would be simple enough to include Service discovery with Eureka and a Config Server, but for quickstarter... running 5 or 6 boot applications for a simple web ui might be overkill :)

More details on Github Project README.md

Consumer Driven Testing with Pact & Spring Boot

Recently a colleague of mine stumbled across Pact.io,  Our current application had grown to over 50 services and we we're starting to have some integration test failures and a brittle dev / acceptance test environment. So we decided to have a look at ways to try help with this.

I started out by reading:
https://docs.pact.io/faq/convinceme.html

Then watching:

https://www.youtube.com/watch?v=-6x6XBDf9sQ&feature=youtu.be

Those 2 resources convinced me to give it a shot.

So I set out and created a quick set of Spring boot apps, the GitHub repo here, to test out the concepts and get everything working.

To highlight some important bits from the demo.

Consumer:
As Pact is a consumer driven test framework. This is where you define a unit test, that test mocks the http server response and you assert against that.
Once the test is successful it creates a pact json file in the /pacts directory.

So after the "mock" test is run and the pact file has been created. You need to include a maven plugin ...pact... that is then used to publish the content of the pacts/ folder to the pact broker... which is defined in the pom as below.

Producer:

This uses the JUnit integration from Pact.io to download the pacts from the broker and then run against an running service.

Since this already uses a @RunWith annotation, I could not use the spring boot runner. So to get around that as a before class step, I start the Spring boot application, the pacts then gets run against that running instance... and the boot application gets stopped again after the tests. Depending on your use case I guess it would also be an option to do this with @Before so you get a new service instance started before each pack, but that would slow down the execution tremendously.

The @State annotation, allows for clients to define a specific state, which the producer can the use to setup additional data / conditions required for the test to run.

Once the pacts have executed against the service there are reports generated in the target folder.




Setting up the Pact Broker

1. Grab the public images from Docker Hub.

docker pull dius/pact_broker
docker pull postgres

2. Then setup the Postgres DB

docker run --name pactbroker-db -e POSTGRES_PASSWORD=ThePostgresPassword -e POSTGRES_USER=admin -d postgres
docker run -it --link pactbroker-db:postgres --rm postgres psql -h postgres -U admin
CREATE USER pactbrokeruser WITH PASSWORD 'TheUserPassword';
CREATE DATABASE pactbroker WITH OWNER pactbrokeruser;
GRANT ALL PRIVILEGES ON DATABASE pactbroker TO pactbrokeruser;

3. Once the DB is up, run the actual Broker:

docker run --name pactbroker --link pactbroker-db:postgres -e PACT_BROKER_DATABASE_USERNAME=pactbrokeruser -e PACT_BROKER_DATABASE_PASSWORD=TheUserPassword -e PACT_BROKER_DATABASE_HOST=postgres -e PACT_BROKER_DATABASE_NAME=pactbroker -d -p 80:80 dius/pact_broker

Extra References:

https://docs.pact.io/documentation/
https://docs.pact.io/documentation/sharings_pacts.html
https://github.com/DiUS/pact-jvm
https://github.com/DiUS/pact-jvm/tree/master/pact-jvm-consumer-junit

Get the example project
https://github.com/bdupreez/pactdemo

Oracle Workspace Manager - Basic POC with Spring Boot and Flyleaf

Working with a process to update configuration and master data within an enterprise is always a challenging task. While investigating possible solutions on how to have someone change data via a UI, then have those changes tested, signed off and approved before taking it to production. I stumbled on to Oracle Workspace Manager.
According to their developer docs, it seemed fit this use case exactly:

Manage a collection of updates and insertions as a unit before incorporating them into production data
Workspace Manager lets you review changes and roll back undesirable ones before making the changes public. Until you make the changes public, they are invisible to other users of the database, who will access only the regular production data. You can organize the changes in a simple set of workspaces or in a complex workspace hierarchy. A typical example might be a life sciences application in which Workspace Manager supports the discovery and quality assurance (QA) processes by managing a collection of updates before they are merged with the production data.


You could think of Oracle Workspace Manager as light "git"-like db versioning. 
Simply put:

1. You create a workspace (branch)... 
2. You make your changes there.. other people can connect to your workspace .. also make changes... or alternatively create their own branch from yours.
3. You can refresh (fetch / merge) your workspace and resolve any conflicts that arise.
4. Once everything is sorted and all is well with your changes you merge it back into the "LIVE" (origin: develop / master) workspace.

I used an existing Docker image of a oracle standard edition version. Oracle Workspace manager is not available on XE unfortunately. This is a rather large image, and it does take a couple minutes to initialise. The image is available on here on Docker Hub.

Connect database with following setting:

hostname: localhost

port: 1521

sid: xe

service name: xe.oracle.docker

username: system

password: oracle

To connect using sqlplus:

sqlplus system/oracle@//localhost:1521/xe.oracle.docker

To connect on mac os - install instantclient and run from there:

./instantclient_12_1/sqlplus system/oracle@local

To setup the initial DB I tried out Flyway. All quite simple and easy to implement. 
Under resources/db/migration there are a number of sql files that do the initial database setup.

1. create the tables: CODE and CODE_TYPE, 
2. insert initial data 
3. enable versioning on those tables.

When you enable versioning the following happens, the table is renamed and a view is created allowing the "recording" of changes that occur.

Reference: (oracle presentation available here)



So after the initial setup you will seen a number of tables and views:



To try this out...

1. Get the Oracle Docker image
2. Once the DB is started... run the boot DataApplication.
3. Use Postman on the REST resources below

To check the current workspace:
GET: http://localhost:9119/poc/workspace
To select all the information from the code table for the current workspace:
GET: http://localhost:9119/poc/workspace/data/code
Create code in the current workspace:
POST: http://localhost:9119/poc/workspace/data/code
BODY: 
{
"id":2,
"descr": "some code",
"type": 1
}
To change workspace (LIVE is default and available):
PUT: http://localhost:9119/poc/workspace/{workspaceName}
To create a workspace:
POST: http://localhost:9119/poc/workspace/{workspaceName}
To remove a workspace:
DELETE: http://localhost:9119/poc/workspace/{workspaceName}

To merge a workspace:
PUT: http://localhost:9119/poc/workspace/merge/{workspaceName}

These REST resources just wrap some of the functions from the DBMS_WM Package. 
This is maybe just the tip of a iceberg, as there is a ton of functionality available from this package.

All the code is available here.