Irwan Hendra's Random Codes Blog

 Spring Boot 2: Using Spring WebFlux & Tomcat for Reactive APIs Spring WebFlux is a somewhat new (since 2019) library from Spring Boot 2 that provides massive improvement in performance compared to the traditional synchronous calls. To quote the Spring documentation itself: Why was Spring WebFlux created? Part of the answer is the need for a non-blocking web stack to handle concurrency with a small number of threads and scale with fewer hardware resources. Servlet 3.1 did provide an API for non-blocking I/O. However, using it leads away from the rest of the Servlet API, where contracts are synchronous ( Filter ,  Servlet ) or blocking ( getParameter ,  getPart ). This was the motivation for a new common API to serve as a foundation across any non-blocking runtime. That is important because of servers (such as Netty) that are well-established in the async, non-blocking space. Further reading:  https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html In s

Optus Breach and Medibank Breach: A Breach Made in Hell  Problem: In the past few weeks there have been a whirlwind of data breach news from  Optus and then  Medibank . Anyone in Australia knows that these are two gigantic service providers in the country serving a huge portion of the population. Therefore the data stolen are horrendously massive, and when combined, extremely deadly. Let's have a look at Optus vs Medibank data stolen according to news:  As we can see, either data from Optus breach or Medibank breach alone provides ONE PRIMARY ID which is sufficient for a hacker to: Register a new phone number Open Buy Now Pay Later account Open crypto account in Centralized Exchange etc (not going to list all of them for security reason) To make things even worse, if someone got their hands on both of them and join them together: Basically they will produce a complete identity of a person with TWO PRIMARY ID  documents. With those documents, a hacker can: Access the victim bank ac

Transactional Outbox Pattern, Why? (part 1) Background In microservice and event driven architecture, transactional outbox pattern is crucial to maintain the state of data (or "aggregate" as per Domain Driven Design) in two or more persistent storages, especially when 2 Phase Commit is not available nor desired. You can read an excellent explanation of the pattern here . This article will be divided into two parts, part 1 will discuss why we need it, part 2 will discuss how we can implement it. In my experience designing solutions with transaction outbox pattern, I have come across multiple similar questions challenging why do we have to do it in such a complex way, and why can't we just reverse the order, use try catch clause, database transaction, etc. Based on those frequent conversations, here is my attempt to explain why we can't solve the problem with ordering, try catch clause or transactions. Suppose we have a system where we create a person record, which will

PostgreSql takes on no-sql approach as hybrid using JSONB data type is quite impressive, it provides the versatility of RDBMS and nosql. I will not discuss further on it, for more information you can read at: https://www.postgresql.org/docs/9.5/functions-json.html. This page focus on one difficulty that developer often encounter: now that I have a complex json inside the jsonb column, how do we index it? and how do we index the sub-object inside json array ?  Suppose we have Postgres table name sample with: CREATE TABLE IF NOT EXISTS public.sample ( id integer NOT NULL DEFAULT nextval('sample_id_seq'::regclass), name character varying(100) COLLATE pg_catalog."default" NOT NULL, more_info jsonb, CONSTRAINT sample_pkey PRIMARY KEY (id) ) And the following is the structure of json data inside the more_info column: '{ "info":{ "address":[ { "addressType":"PPOR

Implementing gRPC Using Spring Boot and Gradle Background GRPC (gRPC) is a RPC framework pioneered by google later on made public and open source. GRPC has not been officially supported by Spring Framework, so far there are few community libraries that can work seamlessly with Spring Boot. In this article, I will use the lognet's grpc-spring-boot-starter. Project Structure Ideally, the proto files for gRPC is located in another directory, which will then be accessed by the gradle plugin to auto generate the required files.   Gradle Script The heart of gRPC enablement lies on the grpc boot starter, which includes few other tasks outlined as below. https://github.com/overtakerx/grpcbootdemo/blob/main/build.gradle Few important note: first you have to run gradlew compileJava for the auto generation to generate the files from the proto file, then you will need to rebuild the project for Intellij to recognise the auto-generated files. Full demo: https://github.com/overtakerx/grpcbootdem

As the title mentioned, this post is about creating a Gradle Spring Boot project that can deploy to both Azure Functions and AWS Lambda. SpringBootConfiguration Before we get into the multicloud project, a bit exploration on the Spring Boot and Spring Cloud Function. Spring Cloud Function provides a faster way to load the Spring Boot application thereby reducing the notorious cold start time experienced in AWS Lam With Spring Boot @SpringBootApplication and @Bean @SpringBootApplication public class MulticloudApplication { @Bean public Function<String , String> uppercase () { return value -> value.toUpperCase() ; } public static void main (String[] args) { SpringApplication. run (MulticloudApplication. class, args) ; } } AWS Lambda Java Cold Start Duration: 4814.89 ms With Spring Boot @SpringBootConfiguration and Java Function<> @SpringBootConfiguration public class MulticloudApplication implements Function<String , String> { public static voi