DEV Community: Deepak Chaudhary

Exploring Spring Native

Deepak Chaudhary — Mon, 29 Mar 2021 01:04:24 +0000

Demo Application to explore Spring Native.

Sample application to explore Spring Native Capabilities. Abbreviated version of something like bitly. Not for production use, yet! All persistence to in-memory H2 db. So, the application does bit more than Hello World type stuff, Source Code at!

Features / Spring Modules included

Spring Boot 2.4.x.
Spring Data JPA [Starter].
Spring Security [Starter] with JWT.
Spring Cloud Function [Starter].
Spring Boot Actuator.
Tomcat with SSL.
Exposing only REST endpoints.

Summary 03/25

Quick Start:

Get prebuilt native package from repo - note, the image is native to machine that built it - so it might not run on yours - see package details.

# requires graalvm locally installed.
$ ./com.dccorp.urlshortner.urlshortnerapplication

Or execute following to pull docker image:

# docker on local.
$ docker run -p 8080:8080 docker.pkg.github.com/chaudharydeepak/urlshortner/urlshortner:0.1

Detailed Instructions:

# checkout source code to local.

# native image plugin - ref pom.xml line 22-49, line 209-210
# requires GraalVM locally installed.
$ mvn -Pnative-image package
# execute generated native image
$ ./com.dccorp.urlshortner.urlshortnerapplication

# using buildpacks - ref pom.xml line 193-212
# requires docker local installation.
$ mvn spring-boot:build-image
# execute docker image 
$ docker run -p 8080:8080 urlshortner:0.0.1-SNAPSHOT

# after application starts [built either with buildpacks or native image plugin]
# register a new user
curl -k --location --request POST 'https://localhost:8080/signup' --header 'Content-Type: application/json' --data-raw '{
    "firstName":"FName",
    "lastName":"LName",
    "userName":"userName",
    "password":"userPassword"
}'

# execute login endpoint to get JWT
curl -i -k --location --request POST 'https://localhost:8080/login' --header 'Content-Type: application/json' --data-raw '{
    "userName":"userName",
    "password":"userPassword"
}' | grep Auth
# will print Auhtorization Header
Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.e.......

# use authorization header to access secured endpoint.
# basically we are creating a short url for a given url.
curl -k --location --request POST 'https://localhost:8080/create' \
--header 'Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJjaGF1ZGhhcnlkZWVwYWswOEBnbWFpbC5jb20iLCJleHAiOjE2MTc2NDQzNzl9.eSfylYVUIgnOFbUULXG9yjUJuApPvgSKJCti_Jdv-XK-umVPPv7eYRgSm62K60vY89Sp_nRIWx6UOjEuNe5v6Q' \
--header 'Content-Type: application/json' \
--data-raw '{
    "requestURL":"https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/",
    "requestedShortCode":"nativedocs"
}'
#should see response like
{"statusCodeValue":201,"statusCode":"CREATED","body":{"shortURL":"stack",......

# try to see if short url works
$ curl -k -i https://localhost:8080/go/nativedocs
HTTP/1.1 302 
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Location: https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: SAMEORIGIN
Content-Length: 0
Date: Sat, 27 Mar 2021 05:54:59 GMT

# to allow chrome access localhost self-signed certificate
# chrome://flags/#allow-insecure-localhost

Key Learnings

Native image startup time is ~0.55s vs ~4.5s [executable jar] subjective to machine, which is pretty cool.
The Generated native image is around ~182M [using buildpacks] vs ~148M [native image plugin] vs ~40M [jar - of-course since JVM is provided outside of the jar on running machine].
Startup time is almost instantaneous - but build time is significantly higher - which possibly will improve over time as the project matures.
Not all Spring modules /projects are supported yet - for ex. developer tools / AOP support missing [03/25] - things in motion already.
Need significant RAM on the machine to play with Native support in the first place.
No Out-of-the-box native image generation for pre-existing Spring Boot application - tweeks / testing will be required - though in long run that is the goal.
Size of native image could be further reduced by using tools like upx.

  $ ls -lh | grep url
  -rwxr-xr-x   1 deepak.chaudhary  staff   148M Mar 27 00:00 com.dccorp.urlshortner.urlshortnerapplication
  -rw-r--r--   1 deepak.chaudhary  staff    38M Mar 26 23:47 urlshortner-0.0.1-SNAPSHOT-exec.jar
  -rw-r--r--   1 deepak.chaudhary  staff    76K Mar 26 23:47 urlshortner-0.0.1-SNAPSHOT.jar

  $ upx -7 -k com.dccorp.urlshortner.urlshortnerapplication

  $ ls -lh | grep url # size reduced to 43M from 148M which is amazing.
  -rwxr-xr-x   1 deepak.chaudhary  staff    43M Mar 27 00:00 com.dccorp.urlshortner.urlshortnerapplication
  -rwxr-xr-x   1 deepak.chaudhary  staff   148M Mar 27 00:00 com.dccorp.urlshortner.urlshortnerapplicatio~
  -rw-r--r--   1 deepak.chaudhary  staff    38M Mar 26 23:47 urlshortner-0.0.1-SNAPSHOT-exec.jar
  -rw-r--r--   1 deepak.chaudhary  staff    76K Mar 26 23:47 urlshortner-0.0.1-SNAPSHOT.jar

Further image size could be reduced by using trimmed down tomcat [experimental] - ref pom.xml line 118.
Oracle provides GraalVM Dashboard online tool to peek inside native image.

  -H:DashboardDump=dumpfileoversizedbuildArgs
  -H:+DashboardAll

Only available when using native image plugin and not buildpacks to generate native image.
GraalVM Dashboard

You can use dive tool to inspect generated docker image:
Need to watchful around anything that's reflection. AOT[Ahead-Of-Time] compilation is actually analyzing the entire application during build time[hence increased build time] - so it might miss some classes whose instantiation is decided at actual runtime instead[lazy], though there is hint support available to take care of these situations.
Very good support from Community / good documentation Spring Native and GraalVM.
Follow open issue with possible Development Process #651.

Feel free to share / leave your thoughts!

Primer on Automated Testing With Karate DSL

Deepak Chaudhary — Wed, 16 Dec 2020 02:45:06 +0000

Motivation

With Microservices architecture, comes along a plethora of challenges that need to be dealt with - and most of these challenges can be resolved with well established patterns & implementations - for ex Spring Cloud provides concrete implementations along the lines of api gateway, service discoveries , distributed tracings, externalized and centralized configuration server and the list goes on. Having said that, one of the bigger challenges I experienced is testing a distributed system[ not simply testing an individual service] as a whole. This system has many moving parts to it - there are distributed dependent services / UI's / network latencies / data inconsistencies etc.

Now, with 'shift left' being the norm - the idea is to provide faster feedbacks -> which results in faster resolutions -> which leads to better system, way earlier in development process [ vs Traditional Software Developments ].

The goal of this blog is to present Karate DSL as a possible solution for testing such a system. Overall, Karate has much much more to offer and I will encourage you to explore more.

Enter Karate DSL

In my past life I was yearning for an all encompassing automated testing framework that is:

extension-able i.e. allow to do more with what is abstracted.
pluggable / modular i.e. add / remove functionalities as needed.
programming language agnostic [ as much as possible ] for wider reach among different stakeholders.
highly observable with reporting and logging capabilities.
ease of testing API's and UI all at the sametime. - I want to call an API to get auth token and use that token to invoke other services or UI or a combination of both.
should be simple to learn and intuitive to use.

Behold, came the Octoberfest 2020 and I stumbled upon an amazing framework called Karate DSL. I was able to contribute, as well learn more about this awesome tool at the same time.

What is Karate DSL

Peter Thomas is the lead developer, as well main maintainer for this tool.

Karate is the only open-source tool to combine API test-automation, mocks, performance-testing and even UI automation into a single, unified framework. The BDD syntax popularized by Cucumber is language-neutral, and easy for even non-programmers. Powerful JSON & XML assertions are built-in, and you can run tests in parallel for speed.

Hands-On

Lets say, you have an API that allows to do CRUD operations on Posts. Now, look at this feature file - isn't it very intuitive as to what is going on in here? -

With this you have a simple test suite with different scenarios, and you are validating different operations on a API - all written in Gherkin Syntax. And there is nothing else to write or code - except including Karate libs.

Writing this test suite requires a very basic knowledge and anyone in your team - a developer, a tester, a BA, product owner etc. can write these and be glued with the expected behavior of the system. Include this in build pipeline or run on a schedule to measure the performance of the system - as you wish.

Now, let us look at the test report:

This is a very detailed and thorough report - you can see the timestamps and individual step logs:

You can seamlessly invoke rest apis and web UI calls in your test suite and exchange headers and cookies among those calls:

source

You can even perform accessibility testing simply as following -

and your output report looks like this:

There are many more goodies provided by this framework - docker testing support / performance testing / UI testing / test report creations etc just to name a few.

The framework has observed some amazing attraction in recent times [ see github stars ], has amazing community support via slack / stackoverflow / github and is something that should be seriously considered by architects / developers / QA alike. Cheers!

Feel free to leave any feedback.