DEV Community: irshad sheikh

Accessing Child Component Refs in React-A Step-by-Step Guide using forwardRef

irshad sheikh — Sat, 27 Jan 2024 00:00:00 +0000

As a developer, you’ve likely encountered situations where you need to access the reference of a child component. Managing component references is a crucial aspect of building robust and efficient React applications. Let’s explore how to access child component refs using the forwardRef feature in React. This step-by-step tutorial aims to provide clarity and beginner-friendliness while addressing common challenges faced by developers.

Understanding the Basics of Refs in React

Refs in React allow us to access and interact with the DOM directly. They are particularly useful when you need to grab a reference to a React component and perform imperative actions. While using refs is straightforward, accessing refs of child components can be a bit tricky.

Challenges Faced in Accessing Child Component Refs

When dealing with child components, the typical approach of using this.refs or React.createRef() might fall short. Enter forwardRef, a feature introduced in React to pass refs down to child components.

Getting Started with forwardRef

Step 1: Importing React and forwardRef

Let’s start by importing the necessary modules:

import React, { forwardRef } from 'react';

Step 2: Creating a Child Component with forwardRef

Define your child component using forwardRef:

const ChildComponent = forwardRef((props, ref) => {
  // Your component logic here

  return <div ref={ref}>Child Component Content</div>;
});

Note the (props, ref) parameters in the function. This is where the ref will be passed to the child component.

Step 3: Using the Child Component in a Parent Component

Now, in your parent component, use the ChildComponent:

import React, { useRef, useEffect } from 'react';

const ParentComponent = () => {
  const childRef = useRef();

  useEffect(() => {
    console.log(childRef.current);
  }, []);

  return (
    <div>
      <ChildComponent ref={childRef} />
      {/* Additional parent component content */}
    </div>
  );
};

Step 4: Accessing the Child Component Ref

With this setup, you can now access the child component’s ref in the parent component:

import React, { useRef, useEffect } from 'react';

const ParentComponent = () => {
  const childRef = useRef();

  useEffect(() => {
    console.log(childRef.current);
  }, []);

  return (
    <div>
      <ChildComponent ref={childRef} />
      {/* Additional parent component content */}
    </div>
  );
};

Practical Examples and Best Practices

Example 1: Modifying Child Component Styles

import React, { useRef, useEffect } from 'react';

const ParentComponent = () => {
  const childRef = useRef();

  useEffect(() => {
    const childElement = childRef.current;
    childElement.style.color = 'red';
  }, []);

  return (
    <div>
      <ChildComponent ref={childRef} />
    </div>
  );
};

Example 2: Triggering Child Component Methods

import React, { useRef, useEffect } from 'react';

const ParentComponent = () => {
  const childRef = useRef();

  useEffect(() => {
    const childElement = childRef.current;
    childElement.someMethod();
  }, []);

  return (
    <div>
      <ChildComponent ref={childRef} />
    </div>
  );
};

Conclusion

By using forwardRef with functional components, you can seamlessly access and manipulate the refs of child components in React.

Different Ways to Implement Thread-Safe Singleton Pattern in Java

irshad sheikh — Sat, 26 Aug 2023 15:00:00 +0000

The Singleton design pattern is a well-known creational pattern that ensures a class has only one instance while providing a global point of access to that instance. However, ensuring thread safety in a Singleton is crucial, especially in multi-threaded environments. In this blog post, we will explore various techniques to implement a thread-safe Singleton pattern in Java, and we’ll discuss the pros and cons of each approach.

Understanding the Singleton Pattern

Before diving into different ways of achieving thread-safe Singletons, let’s recap the basics of the Singleton pattern:

The Singleton pattern is designed to guarantee a single instance of a class, and it typically involves three key components:

Private Constructor : To prevent external instantiation of the class.
Private Static Instance : To hold the single instance of the class.
Public Static Method : To provide global access to the instance.

Different Ways to Implement Thread-Safe Singleton Patterns

1. Eager Initialization

In the eager initialization approach, the Singleton instance is created at the time of class loading. This ensures thread safety but may not be memory-efficient if the Singleton is not used immediately.

public class EagerInitializedSingleton {
    private static final EagerInitializedSingleton instance = new EagerInitializedSingleton();

    private EagerInitializedSingleton() { }

    public static EagerInitializedSingleton getInstance() {
        return instance;
    }
}

While this approach is Simple and thread-safe but it may create the instance even if it’s not needed.

2. Lazy Initialization (Synchronized Method)

In this approach, the Singleton instance is created only when it’s requested for the first time. It uses a synchronized method to ensure thread safety.

public class LazyInitializedSingleton {
    private static LazyInitializedSingleton instance;

    private LazyInitializedSingleton() { }

    public static synchronized LazyInitializedSingleton getInstance() {
        if (instance == null) {
            instance = new LazyInitializedSingleton();
        }
        return instance;
    }
}

This approach uses Lazy initialization, and is thread-safe but the synchronization can introduce performance overhead.

3. Double-Checked Locking

This technique combines lazy initialization and double-checked locking to improve performance by avoiding synchronization once the instance is created.

public class DoubleCheckedLockingSingleton {
    private static volatile DoubleCheckedLockingSingleton instance;

    private DoubleCheckedLockingSingleton() { }

    public static DoubleCheckedLockingSingleton getInstance() {
        if (instance == null) {
            synchronized (DoubleCheckedLockingSingleton.class) {
                if (instance == null) {
                    instance = new DoubleCheckedLockingSingleton();
                }
            }
        }
        return instance;
    }
}

This technique uses Lazy initialization and provides improved performance but it requires careful implementation to avoid subtle issues.

4. Bill Pugh Singleton

The Bill Pugh Singleton, also known as the Initialization-on-demand holder idiom, is a clever way to ensure thread safety in a Singleton without requiring explicit synchronization. It leverages the fact that static nested classes are not loaded until they are referenced, ensuring safe lazy initialization. Here’s how it works:

Inner Static Class : In the Bill Pugh Singleton pattern, the Singleton instance is nested within a private static inner class. This inner class is not loaded until it is referenced.
Lazy Initialization : The Singleton instance is created when the inner class is first referenced. This ensures that the instance is only created when it is needed, which is a form of lazy initialization.
Static Final Instance : The Singleton instance is declared as a static final variable in the inner class. This guarantees that it is initialized only once, and subsequent access to it returns the same instance.

Here’s a simplified example of the Bill Pugh Singleton pattern:

public class BillPughSingleton {
    // Private constructor to prevent external instantiation
    private BillPughSingleton() {
        // Initialization code here
    }

    // Inner static class responsible for lazy initialization
    private static class SingletonHelper {
        // Static final instance of the Singleton
        private static final BillPughSingleton INSTANCE = new BillPughSingleton();
    }

    // Public method to access the Singleton instance
    public static BillPughSingleton getInstance() {
        return SingletonHelper.INSTANCE;
    }
}

Thread safety is guaranteed in this pattern because:

The Singleton instance is only created when the getInstance method is called, ensuring lazy initialization.
Static initialization guarantees that the instance is created only once, even in a multi-threaded environment.
There is no need for explicit synchronization since the JVM handles the class loading and instance creation in a thread-safe manner.

The Bill Pugh Singleton pattern is a recommended way to create thread-safe singletons in Java, and it avoids synchronization overhead until the Singleton instance is actually needed.

5. Singleton Using Enum

Enums in Java are more than constants because they can encapsulate behavior, making them versatile.

The Java enum type itself provides inherent thread-safety, as enum values are effectively singletons by design. They are initialized once, when the enum class is loaded, and they cannot be instantiated again.

Using an enum for Singleton patterns is not only concise but also more resistant to several Singleton-related issues, such as reflection-based attacks and serialization problems, which other Singleton implementations may require additional effort to address.

import java.security.SecureRandom;

public enum OtpService {
    INSTANCE;

    // Inner OTPService class
    private static class OTPService {
        private final SecureRandom random = new SecureRandom();
        private final int otpLength = 6;

        public String generateOtp() {
            StringBuilder otp = new StringBuilder();
            for (int i = 0; i < otpLength; i++) {
                otp.append(random.nextInt(10)); // Generates a random digit (0-9)
            }
            return otp.toString();
        }

        public boolean verifyOtp(String providedOtp, String expectedOtp) {
            return providedOtp.equals(expectedOtp);
        }
    }

    private final OTPService otpService = new OTPService();

    // Delegate methods to the inner OTPService
    public String generateOtp() {
        return otpService.generateOtp();
    }

    public boolean verifyOtp(String providedOtp, String expectedOtp) {
        return otpService.verifyOtp(providedOtp, expectedOtp);
    }
}

public class Main {
    public static void main(String[] args) {
        // Get an instance of the OTP service
        OtpService otpService = OtpService.INSTANCE;

        // Generate an OTP
        String otp = otpService.generateOtp();
        System.out.println("Generated OTP: " + otp);

        // Simulate OTP verification
        String userEnteredOtp = "123456"; // Replace with user input
        boolean isOtpValid = otpService.verifyOtp(userEnteredOtp, otp);

        if (isOtpValid) {
            System.out.println("OTP is valid.");
        } else {
            System.out.println("OTP is invalid.");
        }
    }
}

We create an inner class called OTPService within the OtpService enum. This inner class encapsulates the OTP generation and verification logic.
The otpService field within the enum is an instance of OTPService , and it is used to delegate OTP-related operations to the inner class.
The generateOtp and verifyOtp methods within the enum delegate their operations to the corresponding methods in the OTPService inner class.

Conclusion

Each of the methods discussed has its own merits and use cases. The choice of which approach to use depends on your specific requirements and the trade-offs you are willing to make between eager or lazy initialization, synchronization overhead, and code complexity.

write join queries using jpa criteria queries

irshad sheikh — Sun, 13 Aug 2023 00:00:00 +0000

In this blog post, we’ll explore how to effectively use JPA’s criteria API to combine information from different database tables, enhancing your ability to retrieve and work with interconnected data.

The Essence of Joins

At its core, a join merges rows from two or more tables based on a related column between them. This operation provides a link between data that would otherwise exist in isolated silos. By seamlessly integrating information from different tables, joins facilitate comprehensive data analysis and enhance the granularity of queries.

Left Joins: Bridging the Data Divide

Scenario: Customer-Order Association

Consider a situation where you’re managing a database of customers and their corresponding orders. In some instances, customers may not have placed any orders yet. To retrieve a list of all customers and their orders, regardless of whether orders exist, a left join comes to the rescue.

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<Customer> query = cb.createQuery(Customer.class);
Root<Customer> customerRoot = query.from(Customer.class);
Join<Customer, Order> orderJoin = customerRoot.join("orders", JoinType.LEFT);
query.select(customerRoot).distinct(true);

In this code snippet:

orderJoin: Join<Customer, Order> establishes a left join between the Customer and Order entities, ensuring customers are fetched alongside their orders.
The argument 'orders' passed to join() identifies the property on the Customer entity representing the relationship with the Order entity.
JoinType.LEFT specifies a left join operation.
query.select(customerRoot).distinct(true) signifies the selection of Customer entities and the utilization of the distinct modifier to eliminate duplicate customers from the result set.

The generated SQL query resembles this:

SELECT DISTINCT c.*
FROM customer c
LEFT JOIN order o ON c.id = o.customer_id;

Right Joins: Shifting the Focus

Scenario: Product-Order Association

Imagine a scenario where you’re interested in determining products that have yet to receive any orders. This situation calls for a right join, focusing on data from the associated table to lead the way.

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<Product> query = cb.createQuery(Product.class);
Root<Product> productRoot = query.from(Product.class);
Join<Product, Order> orderJoin = productRoot.join("orders", JoinType.RIGHT);
query.select(productRoot).distinct(true);

Here, the spotlight shifts to products, and the right join captures products that are yet to find placement within an order. The corresponding SQL query takes form:

SELECT DISTINCT p.*
FROM product p
RIGHT JOIN order o ON p.id = o.product_id;

Full Joins: Embracing Data Wholeness

Scenario: Author-Book Relationship

Imagine a situation where you’re examining the relationship between authors and their published books. A full join brings together the benefits of left and right joins, combining information from both tables to provide a comprehensive overview.

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<Author> query = cb.createQuery(Author.class);
Root<Author> authorRoot = query.from(Author.class);
Join<Author, Book> bookJoin = authorRoot.join("books", JoinType.FULL);
query.select(authorRoot).distinct(true);

With a full join, the endeavor of gathering insights about authors and their books encompasses both published and unpublished works. The SQL counterpart takes shape:

SELECT DISTINCT a.*
FROM author a
FULL JOIN book b ON a.id = b.author_id;

Write programmatic criteria queries. It explains the JPA Criteria Api.
how to select values in criteria Queries. This post explains various methods provided in Criteria API to select single or multiple values. It also explains tuple criteria queries.

Spring Security Oauth2- JWT Authentication in a resource server

irshad sheikh — Wed, 29 Sep 2021 00:00:00 +0000

Oauth2 is an industry-standard protocol for authorization.

As per Oauth2 specification(RFC-6749) —

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

The following diagram illustrates the working of an Oauth2 authentication request with an Authorization Code Grant flow.

There are four parties involved —

Client is a third party Application that wants access to the protected resource from a resource server.
Authentication Server is the server which helps to authenticate a Resource Owner.
Resource Owner is the user that owns the protected resource.
Resource Server is the server which serves the protected resources owned by Resource Owner.

First of all, the client sends an authorization request to Resource Owner so that on behalf of the Resource Owner, it can access the protected resource(s).
If the Authorization-code-grant is used, the Authorization code is returned to the client. It means the Resource owner has given access to the client for protected resources.
The client sends this Authorization code to the Authentication Server, which in return provides an Authentication token — typically a JWT token.
Once the client has the authentication token, It use it to access the protected resources from a resource server. The token expires after a set timeout.

In this post, we will focus on the 4th step i.e. How a Resource Server validates a JWT token provided by any third party client.

First let us understand, what is JWT and what API’s are provided by spring security to implement Jwt Authentication.

What is JWT?

👉🏼 Checkout the complete introduction at jwt.io 😜

Spring Security API for JWT Authentication

The below diagram provides a thorough overview of Spring security API Specs for JWT Authentication.

When a client submits a request along with bearer token. It is passed through the security filter chain. The BearerTokenAuthenticationFilter creates a BearerTokenAuthenticationToken of the type Authentication.
Next, The AuthenticationManagerResolver resolves the AuthenticationManager which in turn selects the specific AuthenticationProvider.
The BearerTokenAuthenticationToken is passed to AuthenticationProvider by ProviderManager( the default Implementation of AuthenticationManager)
For JWT authentication, JwtAuthenticationProvider is selected. It decodes, verifies and validates the Jwt using JwtDecoder.
If the authentication succeeds, the Authentication is set on the SecurityContextHolder.
If the Authentication fails, SecurityContextHolder is cleared.

Finally, Let move ahead with implementing the JWT Authentication.

JWT Authentication in Spring Security

In order to implement it, we would require the following components —

Authentication server - we will use Keycloak. It supports Oauth2.0.
Resource Server - We will create one using a spring-boot application.
Client - We can use Postman API client as the client.
User - we will setup one user in Keycloak server.

Authentication server via Keycloak

Follow this link to quickly setup a Keycloak server via Docker.
Follow this tutorial to setup Keycloak Authorization code grant.

While you are at it, here are few things, you would require once the Keycloak server is setup.

issuer uri — http://authserver.com/auth/realms/{realm}
jwks-uri — http://authserver.com/auth/realms/{realm}/protocol/openid-connect/certs
Metadata endpoint —To use the issuer-uri property, the Authorization server should support either one of the below URLs as the metadata endpoint :

Make sure to replace authserver.com with valid domain. Also make sure to provide the value value for realm

Once you have the Keycloak server ready — Let’s go ahead and create a resource server.

Resource Server

The resource server will be the simplest one and will contain only one secure rest API.

Dependencies:

spring-security-oauth2-resource-server **— Most of the resource server support is collected here.
spring-security-oauth2-jose — provides support for decoding and verifying JWT.

<dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-oauth2-resource-server</artifactId>
</dependency>
<dependency>
        <groupId>org.springframework.security</groupId>
        <artifactId>spring-security-oauth2-jose</artifactId>
</dependency>

API Endpoint

GET /api/v1/users

@RestController
@RequestMapping("/api/v1")
public class UserController {

    @GetMapping("/users")
    public List<User> getUsers(){
        return Arrays.asList(
                new User("john doe", 100),
                new User("jane doe",300)
        );
    }
}

Since we have Spring security in the class path, every route will be private.

Setup JWT issuer URL

This is minimal setup required to implement the JWT authentication. The issuer-url provided is used by Resource Server to discover public keys of authorization server and validate the token. It is also the same URL present in iss claim.

Spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-url: http://localhost:8080/auth/realms/{realm}

When the Resource server is starts up , it will automatically configure itself to validate JWT encoded Bearer Token. It achieves this querying the Authorization Server metadata endpoint for jwks_url property. This provides access to supported algorithm and its valid public keys.

The Only drawback to this setup is that it would fail if the Authentication server is not already up. To void startup failure, we would need to add the jwk-set-uri

Spring:
    security:
        oauth2:
            resourceserver:
                jwt:
                    issuer-url: http://localhost:8080/auth/realms/dev
                    jwk-set-uri: http://localhost:8080/auth/realms/{realm}/protocol/openid-connect/certs

Now, the Resource Server will not ping the authorization server at startup. However, issuer-uri is still kept to validate the JWT iss claim on incoming token.

Spring Security provides extension points to override or customize the default behavior of the implementation. We will look into customizing some of the default features.

…But before that, Let’s test the default implementation.

Time to Test the Implementation 💎

If you recall, the resource server contains one endpoint with path /api/v1/users. If we call it without providing an authentication token, it will return 401 - Unauthorized status. That is due absence of authorization token.

Let’s see how we can can use authorization code grant to fetch a token from the Keycloak server and use it to access the API provided by the resource server.

Step - 1: Request OAuth Authorization Code

At this point, we would need a client to request the Authorization code. However to make it easier to test, we can run the following URL in the browser. It should redirect you to the login page and you will have to provide the credentials of the user.

http://authserver.com/auth/realms/{realm}/protocol/openid-connect/auth
?client_id=your-client-id&response_type=code&state=app-state

After the successful completion, it will redirect you to the redirect-url with the values similar to below.

http://{redirect-url}/?state=appstate
&session_state=d7c5d4de-c883-494a-a2a2-e5108062830c
&code=f5935f66-88e0-4085-80aa-000b2a6b2b51.d7c5d4de-c883-494a-a2a2-e5108062830c.bf89a5ff-5703-42d6-9534-ca59f667f81f

We would require code to fetch the actual token.

Step - 2: Fetch the Authentication Token

curl -L -X POST "http://localhost:8080/auth/realms/dev/protocol/openid-connect/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-H "Cookie: JSESSIONID=E8D36F0DBCBF7E33130B9125F8795CAC.9b51ecd0cc5c; JSESSIONID=8E34666DECDB395B1754FD08C5B385F2" \
--data-urlencode "client_id=client-id-value" \
--data-urlencode "client_secret=client-secret-uuid" \
--data-urlencode "grant_type=authorization_code" \
--data-urlencode "code=92236b97-c48f-4827-ae80-80a46e39a0f2.d7c5d4de-c883-494a-a2a2-e5108062830c.bf89a5ff-5703-42d6-9534-ca59f667f81f" \
--data-urlencode "redirect-uri=http://localhost:8085"

client-id, client-secret can be fetched from the client credentials in Keycloak server.
grant_type = authorization_code describes the grant type used.
code fetched in the Step-1.
redirect-url should be same as configured for client in Keycloak server.

The response returned would look similar to the below example:

{
    "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICI0S1ZQNGVhRVdjdno4ZjRndXlPd05XTE9GWFEzYWo0b1I0eWx0dkFSZldFIn0.eyJleHAiOjE2MzI5MzMzOTksImlhdCI6MTYzMjkzMzA5OSwiYXV0aF90aW1lIjoxNjMyOTMzMDgyLCJqdGkiOiIzZTk1NGRkMi0zMjhhLTQ3NzItYWQ2NS0xOWQ3NGM2MGZjZGEiLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZGV2IiwiYXVkIjoiYWNjb3VudCIsInN1YiI6ImMzNjFkMGVjLWM1MWItNGRmNy05MTA1LTVhOWUyZGViMmRjOCIsInR5cCI6IkJlYXJlciIsImF6cCI6InJlc291cmNlc2VydmVyIiwic2Vzc2lvbl9zdGF0ZSI6ImMyYWRiODIyLWQwY2ItNDY3MC1iYmNjLWU3NWJlOTkyYzg5OSIsImFjciI6IjEiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsiZGVmYXVsdC1yb2xlcy1kZXYiLCJvZmZsaW5lX2FjY2VzcyIsInVtYV9hdXRob3JpemF0aW9uIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsicmVzb3VyY2VzZXJ2ZXIiOnsicm9sZXMiOlsiVVNFUiJdfSwiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJlbWFpbCBwcm9maWxlIiwic2lkIjoiYzJhZGI4MjItZDBjYi00NjcwLWJiY2MtZTc1YmU5OTJjODk5IiwiZW1haWxfdmVyaWZpZWQiOmZhbHNlLCJ1c2VyX25hbWUiOiJ1c2VyIiwicHJlZmVycmVkX3VzZXJuYW1lIjoidXNlciJ9.A66uqbRwsUL36GSGozZ7FC3x-M4SCYYLaABMdps-XneseP1saIjsTbHO2QrYq2HbD9jl6nKTYxJHjMdbsRJyY3VtM2mf1D8W24-u8y8qmGf1YNbtFfSTZyrUmwiACEv17onAT8wKgR0C4sdbVFETpRY12f2qQb0mM4ZkT9QQ5DYPBu6dnwyBVXLYJzn8kfmp7JB0OR6LsBTTtyh03t_xiRwb1nSALbUmwq7iUk9lTFEUuUZ182p05q3TKxy9b_kxrCh91EYoYWUdBEhRM4yHjrvN99T-MFpRVaCadyn2YibFbCeZHpsqUmgi-ghR3I70U70HGsL22FEAE4N9X5y_pg",
    "expires_in": 300,
    "refresh_expires_in": 1800,
    "refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICIzZGU1NjBjZi1kMDZlLTRiZmItODY2Yi1mNzJhYjk0YjA0NGMifQ.eyJleHAiOjE2MzI5MzQ4OTksImlhdCI6MTYzMjkzMzA5OSwianRpIjoiODQ5OWNmY2QtZjY1Yy00YzdhLThhNDctMzdhNjg4ZGZjMjU0IiwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo4MDgwL2F1dGgvcmVhbG1zL2RldiIsImF1ZCI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC9hdXRoL3JlYWxtcy9kZXYiLCJzdWIiOiJjMzYxZDBlYy1jNTFiLTRkZjctOTEwNS01YTllMmRlYjJkYzgiLCJ0eXAiOiJSZWZyZXNoIiwiYXpwIjoicmVzb3VyY2VzZXJ2ZXIiLCJzZXNzaW9uX3N0YXRlIjoiYzJhZGI4MjItZDBjYi00NjcwLWJiY2MtZTc1YmU5OTJjODk5Iiwic2NvcGUiOiJlbWFpbCBwcm9maWxlIiwic2lkIjoiYzJhZGI4MjItZDBjYi00NjcwLWJiY2MtZTc1YmU5OTJjODk5In0.747XKhyNqZCDEzSfLV4K96sgAW0daN1C1ROUr5L_s_E",
    "token_type": "Bearer",
    "not-before-policy": 0,
    "session_state": "c2adb822-d0cb-4670-bbcc-e75be992c899",
    "scope": "email profile"
}

Step - 3: Run the API with

We will use the access_token value from previous response as the bearer token to run the private API — (api/v1/users) provided by resource server.

curl -L -X GET "http://localhost:8090/api/v1/users" \
-H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICI0S1ZQNGVhRVdjdno4ZjRndXlPd05XTE9GWFEzYWo0b1I0eWx0dkFSZldFIn0.eyJleHAiOjE2MzI5MzMzOTksImlhdCI6MTYzMjkzMzA5OSwiYXV0aF90aW1lIjoxNjMyOTMzMDgyLCJqdGkiOiIzZTk1NGRkMi0zMjhhLTQ3NzItYWQ2NS0xOWQ3NGM2MGZjZGEiLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZGV2IiwiYXVkIjoiYWNjb3VudCIsInN1YiI6ImMzNjFkMGVjLWM1MWItNGRmNy05MTA1LTVhOWUyZGViMmRjOCIsInR5cCI6IkJlYXJlciIsImF6cCI6InJlc291cmNlc2VydmVyIiwic2Vzc2lvbl9zdGF0ZSI6ImMyYWRiODIyLWQwY2ItNDY3MC1iYmNjLWU3NWJlOTkyYzg5OSIsImFjciI6IjEiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsiZGVmYXVsdC1yb2xlcy1kZXYiLCJvZmZsaW5lX2FjY2VzcyIsInVtYV9hdXRob3JpemF0aW9uIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsicmVzb3VyY2VzZXJ2ZXIiOnsicm9sZXMiOlsiVVNFUiJdfSwiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJlbWFpbCBwcm9maWxlIiwic2lkIjoiYzJhZGI4MjItZDBjYi00NjcwLWJiY2MtZTc1YmU5OTJjODk5IiwiZW1haWxfdmVyaWZpZWQiOmZhbHNlLCJ1c2VyX25hbWUiOiJ1c2VyIiwicHJlZmVycmVkX3VzZXJuYW1lIjoidXNlciJ9.A66uqbRwsUL36GSGozZ7FC3x-M4SCYYLaABMdps-XneseP1saIjsTbHO2QrYq2HbD9jl6nKTYxJHjMdbsRJyY3VtM2mf1D8W24-u8y8qmGf1YNbtFfSTZyrUmwiACEv17onAT8wKgR0C4sdbVFETpRY12f2qQb0mM4ZkT9QQ5DYPBu6dnwyBVXLYJzn8kfmp7JB0OR6LsBTTtyh03t_xiRwb1nSALbUmwq7iUk9lTFEUuUZ182p05q3TKxy9b_kxrCh91EYoYWUdBEhRM4yHjrvN99T-MFpRVaCadyn2YibFbCeZHpsqUmgi-ghR3I70U70HGsL22FEAE4N9X5y_pg" \
-H "Cookie: JSESSIONID=8E34666DECDB395B1754FD08C5B385F2"

Response:

[
    {
        "name": "John Doe",
        "age": 100
    },
    {
        "name": "Jane Doe",
        "age": 300
    }
]

Next steps in this implementation are to customize the default such as

Added a different timeout value to avoid any issues in distributed systems.
Configure GrantedAuthority mapping
.. and much more.

I have written a comprehensive tutorial about it.
You can check it out here

Spring Bean Scopes and Lookup method injection

irshad sheikh — Wed, 01 Sep 2021 00:00:00 +0000

Spring Bean Scope defines the lifecycle and the visibility of the instances created from the bean definitions.

This article is focused on — how to inject a bean with a shorter-lived scope such as a prototype into another bean with a longer-lived scope such as a singleton. we will briefly discuss relevant bean scopes.

Below are various scopes provided by the Spring framework :

singleton — Only one instance of the bean is created per ApplicationContext. It lives and dies with ApplicationContext — thus, It provides the longest life span. This is the default scope and every Spring-managed bean has it unless another scope is provided.
prototype — New bean instance is created every time a request for the specific bean is made. Thus it has a shorter lifecycle.

The below scopes are relevant only for web-aware Spring ApplicationContext

request — A new instance of the bean is created for every HTTP request from a single bean definition.
session — A new instance of the bean is created for an HTTP session.

Spring also provides globalSession , application and websocket scopes as well.

we can use @Scope annotation to provide the scope to the bean.

@Scope("prototype")
public class Command {
...
}

For XML configuration, we have to add a scope attribute to the bean definition.

<bean id="appCommand" class="com.initgrep.demos.Command" scope="prototype"/>

Now that we have a little background of how Spring Bean Scopes work. Let’s analyze the below code snippets 😎:

@Component
@Scope("singleton") //default
public class CommandProcessor {

    @Autowired
    private Command command;

    public void processCommand() {
        command.run();
    }
}

CommandProcessor.java

@Component
@Scope("prototype")
public class Command {
    public void run(){
        System.out.println("Command Run for hashCode - "+this.hashCode());
    }
}

Command.java

@Component
public class ProcessorApplication{

    @Autowired
    CommandProcessor processor;

    @Override
    public void run() {
        processor.processCommand();
        processor.processCommand();
        processor.processCommand();
        processor.processCommand();

    }

ProcessorApplication.java

let’s see what we have here —

A Singleton Scoped Bean - CommandProcessor and a Prototype Scoped Bean — Command. The CommandProcessor bean also has a dependency on Command Bean and invokes the Command.run() method.

We also have a singleton scoped bean — ProcessorApplication bean which invokes CommandProcessor.process() method.

In terms of the number of instances, two singleton bean instances for CommandProcessor and ProcessorApplication are created .

Since the Command bean has the prototype scope. I am assuming, we should have multiple instances of it.

If you run the above code, the output will be similar to the below. The hash code of the Command bean instance returned is the same for all invocations of the run() method. That means, only one bean instance of Command is created even though it has the prototype scope.

Command Run for hashCode - 1155862258
Command Run for hashCode - 1155862258
Command Run for hashCode - 1155862258
Command Run for hashCode - 1155862258

Wait 🤔— Shouldn’t the prototype scope generate multiple instances since it is being called multiple times? The answer is No.

Despite the fact, the dependency has a Prototype scope, the Singleton bean is created once and all of its dependencies are resolved at that time. Hence, even though Command has a prototype scope, it would still have only one instance of it present in the CommandProcessor bean.

Now the obvious question here is — what if I want to inject a prototype bean in a singleton but still want multiple instances to be created, much like prototypal behavior?

Well, Spring framework provides multiple options to help with that. We will go through each one of them in detail below.

This article was orginally posted @ initgrep.com.
You can check the detailed post here

@Transactional Rollback options in Spring Data

irshad sheikh — Tue, 24 Aug 2021 00:00:00 +0000

Transactions manage the changes that are performed in a system. The main purpose of transactions is to provide ACID characteristics to guarantee data validity.

Spring provides a consistent programming model for transactions. @EnableTransactionManagement is used to enable transaction management for the spring application. Spring boot enables it by default.

@Transactional annotation is used to designate the transaction boundary.

If this annotation is provided on the class then all the methods of the class have transactions enabled.
If no annotation is provided on the class, then the individual methods will require the explicit @Transactional annotation - if required.

@Transactional annotation provides various options to control the behavior of the transaction. We will only focus on two options that help in defining the rollback behavior of the transaction.

The default behavior of the transactions is to rollback for the runtime exceptions and the errors. You wouldn’t need to change the defaults in most of the scenarios. However, there are some cases, where you might care about whether the transaction should rollback or not.

Let’s consider the below example —


class ProductService{

    @Transactional
    public void processProducts(){

            saveAllProducts(...products); // saves the data in the database
            sendNotification();
    }

    /*
    * sendNotification throws an exception
    */
    private void sendNotification() throws NotificationException{
        //sending the notification
    }

}

processProducts() method supports the transaction.
saveAllProducts() saves the product data in the database.
sendNotification() sends the notification through some external system. It throws NotificationException for any failure.

This code will work just fine. The products will be saved and after that, the notifications will be sent.

However, if the external system is down and we are unable to send the notifications, NotificationException will happen and the transaction will rollback all the changes. This means, due to the notification failure, we are unable to save the products in the database.

Now, if we want to save the data irrespective of the notification operation success or failure. We would need to modify the default transaction rollback behavior.

@Transactional annotation provides two options dontRollbackOn and rollbackOn for the same.

You can check the complete post at here

Spring Security Architecture fundamentals

irshad sheikh — Tue, 17 Aug 2021 00:00:00 +0000

Authentication and authorization are fundamental to the security of a web applications. While authentication determines if the user can be identified by the system, Authorization determines if the user has the access to the specific resource.

Authentication as well as authorization design paradigm is continuously evolving. The main reason behind it is the continuous evolution in different methods of exploits used against the applications.

Spring security tries to solve this problem by packaging all the possible solutions together.

The purpose of this article is to provide a high level understanding of spring security architecture for Servlet applications. It may not help you to immediately implement spring security in your application but it would definitely help you in the subsequent steps when you dive deeper.

Filter pattern in spring security

Spring security for the web applications use the filter pattern to implement different type of security solution. At the very core of it are Servlet filters. Spring framework provides DelegatingFilterProxy filter and Spring security adds FilterChainProxy filter on top of it. Both these filters are pivotal in Spring security.

Spring Security Filter architecture

DelegatingFilterProxy Filter

Similar to the Servlet filters, the Spring security filters are implementFilter interface but they are also Spring beans which means they are managed by Spring ApplicationContext.

Since these filters are not registered via Servlet container standards(configured in web.xml), the servlet Container is not aware of them.

Spring provides DelegatingFilterProxy filter which sits in the filter chain. It bridges the Servlet containers lifecycle and Spring ApplicationContext.

When a request is delegated to DelegatingFilterProxy. It looks up bean filters from the application context and then invokes the relevant bean filter. DelegatingFilterProxy filter also allows for delayed bean Filter lookup.

FilterChainProxy Filter

Spring security provides a special bean filter named as FilterChainProxy. This filter is a single entry point which enables spring security for a web application.

It allows delegating request through a set of filters bundled as SecurityFilterChain. In order to determine which Spring Security Filter’s should be invoked, FilterChainProxy uses SecurityFilterChain. There could be multiple SecurityFilterChains present.

FilterChainProxy is also used to perform some security specific task such as clearing SecurityContext. FilterChainProxy is more flexible than traditional Servlet Filters. It can determine which securityFilterchain to invoke by leveraging the RequestMatcher interface.

SecurityFilterChain

It is a list of security filters which are also Spring managed beans. These are registered with FilterChainProxy. The advantage of being registered with SecurityFilterChain are following:

FilterChainProxy leverages RequestMatcher interface to determine invocation based upon anything in ServletRequest including the URL. Incase of multiple SecurityFilterChains, FilterChainProxy can determine which SecurityFilterChain should be used. It also clears SecurityContext to avoid any memory leaks.

Customizing the default SecurityFilterChain

Spring security creates an instance of WebSecurity via WebSecurityConfiguration. WebSecurity is responsible for creating an instance of FilterChainProxy filter.

We can create customizations to the built-in functionality by —

Either extending WebSecurityConfigurerAdapter and exposing it as a Configuration
Or implementing WebSecurityConfigurer and exposing it as a Configuration.

This configuration is imported when using @EnableWebSecurity annotation.

AuthenticationEntryPoint

When a client sends a request without authentication credentials, an implementation of AuthenticationEntryPoint will be used to send the response to the client to ask for credentials.

The AuthenticationEntryPoint implementation might perform a redirect to a log in page , respond with an WWW-Authenticat e header, etc.

AbstractAuthenticationProcessingFilter

This is the base filter used for authenticating the requests. When the user request comes in

If it has credentials pre-populated, the implementation of AbstractAuthenticationProcessingFilter is directly called.
If the credentials are not populated, the implementation of AuthenticationEntryPoint is called first to request credentials from the client
- After that AbstractAuthenticationProcessingFilter is directly called.

Authentication Architecture API

AuthenticationManager

This is a strategy interface which provides the API to perform authentication. It is invoked by spring security filters. The authentication object that is returned is set on SecurityContextHolder.

It basically checks the authentication and decides

If the principle is valid
If the principle is invalid
If the authentication is null

Incase, Security Filters are not used such as when using user-defined filters, Authentication can be set on SecurityContextHolder manually.

ProviderManager

It is common implementation of AuthenticationManager. It delegates to a list of AuthenticationProviders. Each AuthenticationProvider has the opportunity to authenticate as well as to show that it can not.

It also allows an optional parent AuthenticationManager. If no AuthenticationProvider are provided, the parent AuthenticationManager is consulted for authentication.

If no authenticationProviders can authenticate, authentication fails.

AuthenticationProvider

Its implementations performs a specific type of authentication. For example, DaoAuthenticationProvider supports username/password based authentication while JwtAuthenticationProvider supports authenticating a JWT token.

SecurityContextHolder

This object contains the authentication information about a request.

It contains SecurityContext which by default is a threadLocal object. thus every request thread has its own SecurityContext object.

SecurityContextHolder API Diagram

Security Context

The securityContext object contains Authentication Object. The Authentication object serves two main purposes within Spring Security —

It acts as an input to AuthenticationManager to provide the credentials a user has provided to authenticate.

  AuthenticationManager.authenticate(Authentication authentication)

It also represents the currently authenticated user. The current Authentication can be obtained from the SecurityContext.

  SecurityContextHolder.getContext().getAuthentication()

Authentication provides the below details regarding an authenticated user:

Principal — which identifies the user. When authenticating with a username/password this is often an instance of UserDetails interface.
Credentials — is basically the password
GrandtedAuthorities — provide the authorization scope for the principal. It is fine grained scope for authorization. GrantedAuthorities can be obtained from the Authentication.getAuthorities() method.

if you have reached this far and want to explore more on spring security. Here are a few posts to get you going.

Reactive State management in the angular - NgRx Store, actions, selectors

irshad sheikh — Tue, 15 Sep 2020 00:00:00 +0000

NgRx framework helps to build reactive angular applications.

Basic Concepts

NgRx store provides reactive state management for the angular application. NgRx store is the redux implementation developed specifically for angular applications and provides RxJS observable API.

state is an immutable data structure that is a single source of truth for the whole application.

NgRx Actions represent the unique events in the application which may be used to perform state transition or trigger side-effects.

NgRx Reducersare pure functions that react to Actionsto perform state transitions.

NgRx Selectorsare pure functions that select, derive, or compose a slice of the state.

NgRx Effects allow the isolation of side-effects.

Prerequisites -

you have a fair understanding of the angular framework.
You have a basic understanding of redux architecture.
you have a fair knowledge of RxJs Observable API and various operators.

Installation
State
- Design the State
- Initialize the State
NgRx Actions
NgRx Reducer
- createReducer function
- Create ActionReducerMap
- Register the State
NgRx selectors
- Selectors
- createSelector function
- String selectors.

Installation

If you already have an angular app, you can directly go to step - 4

# 1) install angular cli
npm install -g @angular/cli

# 2) create a demo app
ng new ngrx-angular-demo

# 3) navigate to demo app
cd ngrx-angular-demo

# 4) install ngrx store
ng add @ngrx/store@latest

# 5) run angular in dev mode
ng serve

To begin with , let us have a look at an example file structure. A structure like this would be helpful to split up each feature of NgRxstate management in your app. I usually replicate the same structure in each feature module.


    ──store
        |_ app.actions.ts
        |_ app.effects.ts
        |_ app.reducer.ts
        |_ app.selectors.ts

app.actions.ts file will contain the NgRX actions
app.effects.tsfile will contain the NgRx effects.
app.reducer.ts file will contain the State design and its initialization. it will also contain a reducer function.
app.selectors.ts will contain the NgRx selectors.

Here is the complete project setup.

State

The state represents an immutable object that contains the state of an application. It is read-only, so every state transition will return a new state rather than modifying the existing state. As the application grows, each feature should contain a separate state which are part of the global app state. As such, the application state contains one or more feature states.

The state is similar to Javascript objects. It contains the feature states as the key-value pairs _where the key represents a feature state and the value is the feature state object.

The state related to a feature module is referred to as feature state.

interface State{
    feature_1: FeatureOneState,
    feature_2: FeatureTwoState,
    feature_3: FeatureThreeState
}

Design the State

Let’s assume, our angular application has many feature modules. One of the feature modules is responsible for user’s profile. The profilemodule is responsible for rendering the list of usersand the related posts.

To design the state, we can assume that the state required for the profile module should contain List of users and List of posts.

Let’s call the profile state as ProfileFeatureState.

/** User modal */
export interface User {

  id: number;
  email: string;
  first_name: string;
  last_name: string;
  avatar: string;
}

/ **post modal** /
export interface Post {
  id: number;
  userId: number;
  title: string;
  body: string;
}

/ **the modals should ideally be in their own ts file** /

export interface ProfileFeatureState {
  users: User[];
  posts: Post[];
}

We defined the type for Userand Post and also created an interface for ProfileFeatureState.

Finally, we would add ProfileFeatureState to the applications root state -AppState. The profile key represents the profileFeatureState.

interface AppState{    
    profile: UserFeatureState,    
//..other features here
}

Initialize the State

Initially, the state of the application is nullsince there would be no data. As such, both the users array and posts array would be initialized to null.

export const initialProfileFeatureState: ProfileFeatureState = {
  users: null,
  addresses: null
};

At this point, the app.reducer.ts file should look like -

/*app.reducer.ts*/

/** User modal */
export interface User {
  id: number;
  email: string;
  first_name: string;
  last_name: string;
  avatar: string;
}

/** Post Modal */

export interface Post {
  id: number;
  userId: number;
  title: string;
  body: string;
}

export interface ProfileFeatureState {
  users: User[];
  addresses: Address[];
}

export const initialProfileFeatureState: ProfileFeatureState = {
  users: null,
  addresses: null
};

export interface AppState {
  profile: ProfileFeatureState;
}

Actions:

NgRx Actions represent events in the application. They may trigger a state transition or trigger a side-effect in the NgRx Effect services.

interface Action{
    type:string
    //optional metadata properties
}

The Actioninterface contains a property called Type. The Typeproperty identifies the action. Actions can also contain optional metadata.

createActionfunction is used to create the actions and it returns an ActionCreator function. ActionCreator function when called returns an action of type TypedAction. Optionally, we can also supply additional metadata using props function.

Let’s go ahead and create an action to add users to ProfileFeatureState.

export const addUsers = createAction(
 '[profile] add users',
 props<{ users: User[] }>()
);

Notice the type of addUsers action as [profile] add users. The [profile] represents the source of action. Also, the props contain the array of users as the metadata.

Similarly, we can create an action for adding posts to the feature state.

//file: app.actions.ts

export const addPosts = createAction(
  '[profile] add posts',
  props<{ posts: Post[] }>()
);

addUsers action is dispatched to indicate that the users should be added to the state. It will also contain user[] as metadata.

Similarly the Actions related to posts are dispatched

Actions represent the events and not the commands or operations. A single command or operation may generate many types of Actions. For example, An operation that creates a new user would at least generate Actions for success and failure such as [profile] user created or [profile] user creation failed.

NgRx Reducer -

Reducers are pure functions which perform transitions from one state to another state based on the latest action dispatched. The reducer functions do not modify the existing state, rather it returns a new state for every state transition. Hence all the reducer functions perform immutable operations.

CreateReducer

NgRx provides a createReducer function to create reducers. It takes initialState as the first param and any number of on functions. The on function provide association between actions and the state changes.

When an action is dispatched, all the reducers receive the action. The on function mapping determines whether the reducer should handle the action.

createReducer function returns an ActionReducer function . ActionReducer function takes an Action and a State as input, and returns a new computed State.

Let’s go ahead a create reducer that handles transitions for ProfileFeatureState.

import * as AppActions from './app.actions';

const theProfFeatureReducer = createReducer(
  initialProfileFeatureState,
  on(AppActions.addUsers, (state, { users }) => ({
    ...state,
    users: [...users]
  })),
  on(AppActions.addPosts, (state, { posts }) => ({
    ...state,
    posts: [...posts]
  })),

);

createReducer function maps many actions and returns an ActionReducer function.

addUsers action is mapped to a function that creates a new User array and returns a newly computed state. Similarly the addPosts action is mapped.

The […] spread operator copies the properties of the object and returns a new object. It only performs the shallow copying and does not copy the nested structures. You should always consider a better alternative if you are dealing with a state that contains nested data structures. Libraries like lodash provide methods to clone nested structures.

Create ActionReducerMap

ActionReducerMap provides the mapping as key-value pairs where the key represents the feature name as a string and the value is the ActionReducer function returned by createReducer function.

In our case, the ActionReducerMap will contain profile as a key and value as theProfFeatureReducer.

/**The profileFeatureReducer function is necessary as function calls are not supported in the View Engine AOT compiler. It is no longer required if you use the default Ivy AOT compiler (or JIT)**/

function profileFeatureReducer
(state: ProfileFeatureState = initialState, action: Action) {
  return theProfFeatureReducer(state, action);
}

/ **AppActionReducer Map** /
export const AppActionReducerMap: ActionReducerMap<AppState> = {
  profile: profileFeatureReducer
  // ... other feature go here

};

It is not necessary to create an ActionReducerMap. You can directly provide the mapping in StoreModule.forRoot({key: ActionReducer})while registering the reducer in app.module.ts. You can also separately register the feature state in the feature module. I prefer creating the ActionReducerMapseparately as it provides a better type checking in Typescript.

At this point, our app.reducer.ts file should look like :

/ **app.reducer.ts** /
export interface ProfileFeatureState {
  users: User[];
  posts: Post[];
}

export const initialProfileFeatureState: ProfileFeatureState = {
  users: null,
  posts: null
};

export interface AppState {
  profile: ProfileFeatureState;
}

const theProfFeatureReducer = createReducer(
  initialProfileFeatureState,
  on(AppActions.addUsers, (state, { users }) => ({
    ...state,
    users: [...users]
  })),
  on(AppActions.addPosts, (state, { posts }) => ({
    ...state,
    posts: [...posts]
  }))
);

function profileFeatureReducer(state: ProfileFeatureState = initialProfileFeatureState, action: Action) {
  return theProfFeatureReducer(state, action);
}

export const AppActionReducerMap: ActionReducerMap<AppState> = {
  profile: profileFeatureReducer
};

Register the State

Once the reducer is created, It should be registered in the Module . The state can be registered using one of the two options:

Register Root state

To register the global store in the application

StoreModule.forRoot({ AppActionReducerMap })

StoreModule.forRoot() takes ActionReducerMap as an argument. The map contains key and ActionReducer Object returned by createReducer function.

Register each feature state separately -

Feature states are similar to root states but they represent the state of specific features of an application. Typically, each feature should be registed in its own module.

StoreModule.forFeature({ profile: profileFeatureReducer })

If you have come this far. You might also want to read about NgRx Selectors.

How to create NgRx Selectors
How to use createSelector function to compose selectors with - single or multiple slices of state
How to use a projector function to return only a part within the slice of state.

NgRx selectors are used to select a slice of state. I have a detailed post about it here

Ngrx Effects - Isolate side-effects in angular applications

irshad sheikh — Tue, 15 Sep 2020 00:00:00 +0000

what is a Side-effect?

A side effect refers simply to the modification of some kind of state - for instance:

Changing the value of a variable;
Writing some data to disk;
Enabling or disabling a button in the User Interface.

…source

Why NgRx Effects?
- Service based design vs NgRx Effects based design
NgRx Effects
- Installation
- Implementation
- Register NgRx Effects in module

Why NgRx Effects?

A pure component has an immutable input and produces the events as output. These components are essentially dumb and most of the computations are done outside of it. A pure component has a single responsibility similar to pure functions.

Now, If the components are not doing any computations, most of the computations and side-effects would be moved inside the services. That is the first-hand use of angular services. It is easy to inject them into components and perform various computations.

Now here are a few things you should consider -

First of all, if your application is growing fast and you are storing/managing state inside your components or services, you should consider a state management solution.
The services are an ideal choice but you have to manually take care of storing the state, making sure the state remains immutable, consistent, and available for all the dependent components as well as services.
Let’s assume, you have a service taking care of communicating via APIs to some remote server. You inject the service in a component and call the method of the service inside the component.
…and if you have another service, which performs some computation which is supposed to be run when the user interacts with UI such as a click of a button. Again, you would inject the service in component, and on click of the button, a method of the service is called.

It works great… But if you notice, the component is tighly coupled with the service and it knows about what operations to perform when a user clicks a button or when an API should be called.

The very first disadvantage of this pattern you would come across is components are hard to test since they are dependent on many services. You would also notice that It is almost impossible to reuse the components.

So what is the alternative approach? …

The alternative approach is to let components be pure and not responsible for managing the state . Instead make them reactive so that when an input data is available, it renders it to UI and when there are UI interactions, it generates the relevant Events.

That is it…

The component does not have to know, how the Input data is made available or how the events are handled.

The services are nevertheless an important part of the application. They would still contain all the methods to do various computations or communicate via APIs. But now they are no longer being injected inside the component.

I have already written a post about reactive state management using NgRx store, actions, and selectors. You can go through it to have an understanding of NgRx state management.

Let’s see a comparison between the service-based design and NgRx effects.

You might notice fewer elements in play during service-based design but don’t let it fool you. It is better to have more elements in application than to have a lousy app.

Service based design

Suppose, our AppComponentrequires a list of users.

We have a service AppRemoteService and it contains users$ observable which can be subscribed to get a list of users.

users$ = this.httpClient.get<User[]>(URL).pipe(take(1));

We have injected the AppRemoteService in side the AppComponent and we would subscribe to AppRemoteService.users$ observable .

@Component({
    template: `
    <div class="user-container" 
      *ngIf="localUsers">
     <app-user *ngfor="let user of localUsers" 
                [inputUser]="user">
  </div>
    `
})
export class AppComponent{
//state inside component
localUsers: User[];

constructor(private remoteService: RemoteService){}

  ngOnInit(){
      //handle the subscription here
  this.remoteService.users$.subscrible(
      users => this.localUsers = users;
      );
  }
  }

NgRx Effects based design

Here is how NgRx effects will change it -

The AppComponent would only require NgRx Store to select the state or dispatch actions.

export class AppComponent implements OnInit {
 constructor(private store: Store<fromApp.AppState>) { }
 }

As soon as the component requires the list of users, it would dispatch an action loadUsers when the component is initialized.

export class AppComponent implements OnInit {
 constructor(private store: Store<fromApp.AppState>) { }

 ngOnInit(): void {
     //action dispatched
    this.store.dispatch(fromActions.loadUsers());
 }

}

The Component will use NgRx selector selectUsers and subscribe to its observable.


@Component({
 template: `
     <div class="user-container" 
         *ngIf="localUsers$ | async as users">
         <app-user *ngfor="let user of users" 
                    [inputUser]="user">
     </div>
 `
})
export class AppComponent implements OnInit {
  localusers$ = this.store.select(fromSelectors.selectUsers);

  constructor(private store: Store<fromApp.AppState>) { }

  ngOnInit(): void {
    this.store.dispatch(fromActions.loadUsers());
  }
}

NgRx Effects will be listening to the stream of actions dispatched since the latest state change. loadUsers$ effect is interested in loadUsers action dispatched by AppComponent. As such, when the component is initialized, the loadUsers action is dispatched. The effect reacts to it and subscribes remoteservice.users$ .
Once the data is fetched, the loadUsers$ effect will dispatch addUsers action with associated metadata - users. The respective reducer function will transition the state. The latest state will contain recently feteched users.

//app.effects.ts
 loadUsers$ = createEffect(
    () => this.action$.pipe(
        ofType(AppActions.loadUsers),
        mergeMap(() => this.remoteService.users$
        .pipe(
            map(users => AppActions.addUsers({ users })),
            catchError(error => {
            return of(error);
            })
        )),
 ));



//app.reducer.ts
//addUsers action mapping 

const theReducer = createReducer(
  initialState,
  on(AppActions.addUsers, (state, { users }) => ({
    ...state,
    users: [...users]
  }))

);

As soon as the data is available, the localusers$ observable subscription will have users list ready for the component to render.

In contrast with the service-based approach isolating the side-effects using NgRx Effects, the component is not concerned about how the data is loaded. Besides allowing a component to be pure, It also makes testing components easier and increases the chances of reusability.

If you have come this far, you might also want to know how to install and implement the NgRx Effects in an angular application. I have written a detailed post. Click here to check it out.

Create Microsoft Office Addin using Angular CLI

irshad sheikh — Tue, 18 Jun 2019 17:07:29 +0000

If you are reading this tutorial, you are probably one of the developers out there trying to figure out how to create a Microsoft office add-in using Angular CLI.

Microsoft provides the complete process for creating add-ins using angular through a yeoman generator for VS Code editor. This method works fine but it uses the manual webpack config with angular. I also faced issues such as:

not able to use template-url in angular components
no support for CSS files for each angular components

The goal of this tutorial is to demonstrate a way of creating a project structure using angular@8.0.0 CLI, configure it and make it ready for developing office add-ins.

Please note, It still does not support the office-addin-debugger plugin provided by Microsoft. I have added it as an npm dev-dependency here and I am still trying to figure how to make it work. But you can always debug the add-in on the web app such as outlook web.

I assume you have node and npm already installed

Let us begin –

Generate Office add-in angular app using yeoman generator

Office official docs have provided detailed steps. I will only provide concise steps.

Run the following command in the command line. It will install the office Yeoman generator.

npm install -g yo generator-office

Generate the office adding angular project structure using the below command.

yo office --skip-install

The above command will provide interactive input. Choose the below options

   Choose a project type: (Use arrow keys) 
   // choose (2) Office Add-in Task Pane project using Angular framework

   Choose a script type: (Use arrow keys)
   // choose (1) Typescript

   What do you want to name your add-in? (My Office Add-in) 
   //Give any name you want. for this tutorial, I would keep demo-addin

   Which Office client application would you like to support? 
   //choose (3) Outlook

Notice --skip-install argument. Well, We don’t want npm to install all the dependencies here. We would only need manfiest.xml file and some of the Microsoft office dependencies from package.json.

Our outlook addin project structure is done using yeomen generator. Below is the structure of the generated project.

.
    ├── assets
    │   ├── icon-16.png
    │   ├── icon-32.png
    │   ├── icon-80.png
    │   └── logo-filled.png
    ├── CONTRIBUTING.md
    ├── LICENSE
    ├── manifest.xml
    ├── package.json
    ├── package-lock.json
    ├── README.md
    ├── src
    │   ├── commands
    │   └── taskpane
    ├── tsconfig.json
    └── webpack.config.js

Creating an angular application using Angular CLI

Install the Angular CLI

npm install -g @angular/cli

Generate an angular app

ng new demo-angular-addin

Run ng serve to make sure the app is working

The structure of our angular app would look like below:

.
      ├── angular.json
      ├── e2e
      ├── node_modules
      ├── package.json
      ├── package-lock.json
      ├── README.md
      ├── src
      ├── tsconfig.json
      └── tslint.json

Copy the addin manifest to the angular application

Copy the manifest.xml from demo-addin which we generated using yeomen generator and paste it in the root folder of the angular app.

Change the angular application default port number

Notice that the manifest.xml has all the mappings for port 3000 such as localhost:3000. Also, the angular application default port is 4200. We either have to change the port in manifest or change angular server port. Either way, it should work.

Let us change the default port(4200) of the angular app to 3000. Open angular.json file and look for server key and changed the default port. Below is an example.

"serve": {
     "builder": "@angular-devkit/build-angular:dev-server",
     "options": {
         "browserTarget": "demo-angular-addin:build",
         "port": 3000
    },
    "configurations": {
                "production": {
        "browserTarget": "demo-angular-addin:build:production",
        "port": 3000
                }
    }
   },

Run ng-serve to validate the port.

Copy the default icons from generated office addin to angular app

The default icons provided are configured in addin manifest. These icons will be shown when the add-in is loaded.

If both the projects are in the same folder, use the below command or do it manually.

cp -r demo-addin/assets/* demo-angular-addin/src/assets/

Update the manifest mapping – replace with index.html page

In the manifest.xml, for each occurrence of taskpane.url or any other locations where the URL resembles like https://localhost:3000/taskpane.html, update taskpane.html to index.html. You can also remove the taskpane.html and only keep host: port (localhost:3000) only.

Configure SSL for the angular application

It is mandatory for Microsoft Office add-ins to be served over https connection. We need to generate an SSL certificate and key and configure our angular application to serve over https.

Go to this tutorial titled Running Angular CLI over HTTPS with a Trusted Certificate. It has all the steps to configure SSL in an angular application.

If you still face any issues, try to install the certificate by choosing local machine. and use the SSL options directly in the terminal.

ng serve --ssl true --ssl-cert "ssl/server.crt" --ssl-key "ssl/server.key"

You can also configure the same command in package.json inside scripts – such as :

"start-ssl" : "ng serve --ssl true --ssl-cert \"ssl/server.crt\" --ssl-key \"ssl/server.key\""

Change the Typescript compiler target type to es5 instead of es2015

While I was testing the Outlook addin for the desktop app, it did not load angular components. However, It was working fine in the outlook web app. I initially posted a stackOverFlow question. After thorough debugging, I was able to figure out that Outlook desktop app does not support es2015 yet.

Let’s update tsconfig.app.json and add the new target under compilerOptions.

"target": "es5"

Add the missing dependencies and dev-dependencies using npm

npm dependencies

npm install --save @microsoft/office-js @microsoft/office-js-helpers@^1.0.1 office-ui-fabric-js@^1.3.0

I have added office-js also as an npm dependency. However, office js is not a valid es6 module and it can not be used as such. We still need to load it using script tags from CDN. We will get to it later in the tutorial. You can also keep track of this issue here. If it is updated as an es6 module in the future, you can directly use it by importing in components rather loading it from CDN.

npm devdependencies

npm install --save-dev @types/office-js@^1.0.1 @types/office-runtime@^1.0.7 office-addin-debugging@^2.1.13 office-addin-dev-certs@^1.0.1 office-toolbox@^0.1.1

Add the missing types

During compilation, Typescript compiler is going to complain about missing types. Since we will be using Microsoft Office APIs during development, we will need to add office-js to types.

Update the tsconfig.app.json and add office-js under the types array.

"types": [
      "office-js"
   ]

Copy the script from taskpane.html to index.html

As mentioned earlier, Office-js has to be added from CDN. Along with it, if you intend to use office fabric-ui for developing the addin user interface, include the fabric libraries from CDN.

<!-- Office JavaScript API -->
   <script type="text/javascript" src="https://appsforoffice.microsoft.com/lib/1.1/hosted/office.js"></script>

   <!-- For more information on Office UI Fabric, visit https://developer.microsoft.com/fabric. -->
   <link rel="stylesheet" href="https://static2.sharepointonline.com/files/fabric/office-ui-fabric-js/1.4.0/css/fabric.min.css" />
   <link rel="stylesheet" href="https://static2.sharepointonline.com/files/fabric/office-ui-fabric-js/1.4.0/css/fabric.components.min.css" />

   <script src="https://static2.sharepointonline.com/files/fabric/office-ui-fabric-js/1.4.0/js/fabric.min.js"></script>

Bootstrap the angular application inside the `Office.initialize` function.

Office.initialize makes sure the addin is loaded after the Office application has completely loaded.

let’s update the main.ts file by wrapping the bootstrap code inside the initialize function.

Office.initialize = reason =>{
       platformBrowserDynamic().bootstrapModule(AppModule)
                 .catch(err => console.error(err));
   };

The only thing left now is to side-load our Microsoft Outlook addin. You can find it in official documentation here.

--
Originally published at https://www.initgrep.com on June 16, 2019.

Programmatic Criteria Queries using JPA Criteria API

irshad sheikh — Mon, 11 Feb 2019 00:00:00 +0000

Java Persistence API (JPA) provides the specification of managing data, such as accessing and persisting data, between Java Objects and the databases.

There are obviously many ways in JPA that could be used to interact with a database such as JPQL(Java Persistence Query Language), Criteria API, and Entity specific methods such as persist, merge, remove, flush, etc.

I initially found Criteria API quite intimidating. To be frank, I had to invest quite some time to figure it out. It eventually turned out to be quite a fluent API. I thought why not just write about the experiences. So here it is, “Creating Programmatic Criteria Queries using JPA Criteria API”.

Criteria Queries are type-safe and portable. They are written using Java programming language APIs. They use the abstract schema of the persistent entities to find, modify, and delete persistent entities by invoking JPA Entity Operations.

We will be using the following domain model for building the criteria queries in this tutorial.

UML diagram describing the Object Relationship Mapping

We have three Objects( ref. to diagram above ) Student , Course and Passport. Each of the Objects has a relationship with each other:

Student has a One-To-One relationship with Passport. It means that Each Student can only have one Passport and vice versa.
Student has a One-To-Many relationship with Address which means that a student can have one or more addresses and an address is always assigned to one student.
Student has a Many-To-Many relationship with Course which means that Each Student can enroll in many courses and one course can have many students enrolled.

We will begin with a simple Criteria Query and slowly try to build upon it.

public Long getStudentsCount() {

        / **CriteriaBuilder instance** / 
        CriteriaBuilder builder = entityManager.getCriteriaBuilder();

        / **create a criteriaQuery Object** /
        CriteriaQuery<Long> studentQuery = builder.createQuery(Long.class);

        / **create a Root Object -> references to the queried entity** /
        Root<Student> studentRoot = studentQuery.from(Student.class);

        / **Path Object to refer the attribute name of entity** /
        / **we are not using it for now** /
        Path<Object> namePath = studentRoot.get("name");

        / **Aggregate Expression for count operation** /
        Expression<Long> countExpression = builder.count(studentRoot);

        / **** /
        studentQuery.select(countExpression);

        /** instance of Typed Query */
        TypedQuery<Long> typedStudentQuery = 
                            entityManager.createQuery(studentQuery);

        / **return the result** /
        Long count = typedStudentQuery.getSingleResult();

        return count;
    }

The above code example retrieves the total count of students present in the database.

Criteria queries are an Object graph where each part of the graph represents an atomic part of the query. The various steps in building the object graph roughly translate to the following steps.

A CriteriaBuilder interface contains all the required methods to build Criteria Queries, Expressions, Ordering, and Predicates.
CriteriaQuery interface defines functionality required to build a top-level query. The type specified for criteria query i.e criteriaQuery<Class<T> resultClass> would be the type of the result returned. If no type is provided, the type of result would be Object. Criteria Query contains the methods that specify the item(s) to be returned in the query result, restrict the result based on certain conditions, group results, specify an order for the result, and much more.
Root interface represents the root entities involved in the query. There could be multiple roots defined in the Criteria Query.
Path interface represents the path to the attribute in the root entity. Path interface also extends to the Expression Interface which contains methods that return Predicates.
builder.count() is an aggregate method. It returns an expression that would be used for Selection of the result. When aggregate methods are used as arguments in the select method, the type of the query should match the return type of aggregate method.
A TypedQuery instance is required to run the CriteriaQuery.

The final output of the above example is below :)

select
        count(student0_.id) as col_0_0_ 
    from
        student student0_

It seems quite the over work–doesn’t it. The output of so many lines of code is just a plain old SELECT query. But the Criteria API was created to serve a different purpose i.e programmable Query API. It helps to build queries dynamically. You could write just one program to build queries for all objects in your application or build queries depending upon your business logic.

Let’s say, we want to get the count of either Students, Courses or any other entities present in our application. We could either write different queries for each of them or we could only use Criteria API.

public <T> Long getCountOfEntity(Class<T> claz) {

        CriteriaBuilder builder = em.getCriteriaBuilder();
        CriteriaQuery<Long> studentQuery = builder.createQuery(Long.class);
        Root<T> root = studentQuery.from(claz);
        Expression<Long> countExpression = builder.count(root);
        studentQuery.select(countExpression);
        TypedQuery<Long> typedStudentQuery = em.createQuery(studentQuery);

        return typedStudentQuery.getSingleResult();
    }

I have only updated the previous example to allow the generic parameter which specifies the Class of the Entity. The rest of the Code stays the same. You can learn more about Java Generics here.

Let’s look at the above example in detail.

Criteria Query

CriteriaQuery<T> createQuery(Class<T> resultClass);

CreateQuery method takes the Class name of the result type as an argument.

If the result is returned as a data-set related to the entity e.g all the students or one of the students. The parameter should be Student.class.

builder.createQuery(Student.class);

If the query returns any other result irrespective of which entity it works on, It should have a parameter of the returned type. As we saw above, when the count was returned, the parameter type was Long.class

builder.createQuery(Long.class);

Root

Root<T> root = studentQuery.from(Student.Class)

The Root refers to the entity on which the query would be run such as Student.class in the above example.

Select

studentQuery.select(countExpression);

The select method specifies the result to be returned by the Query. If all the attributes of an entity are supposed to be returned instead of just returning the count, we could pass the root entity as the parameter such as below.

studentQuery.select(studentRoot);

If you have come this far, you might also want to read about various methods, Criteria API provides to implement criteria join, Fetch Join, Aggregate functions, and subqueries. I have posted a detailed post about it. Click here to check it out.

DEV Community: irshad sheikh

Accessing Child Component Refs in React-A Step-by-Step Guide using forwardRef

Understanding the Basics of Refs in React

Challenges Faced in Accessing Child Component Refs

Getting Started with forwardRef

Step 1: Importing React and forwardRef

Step 2: Creating a Child Component with forwardRef

Step 3: Using the Child Component in a Parent Component

Step 4: Accessing the Child Component Ref

Practical Examples and Best Practices

Example 1: Modifying Child Component Styles

Example 2: Triggering Child Component Methods

Conclusion

Different Ways to Implement Thread-Safe Singleton Pattern in Java

Understanding the Singleton Pattern

Different Ways to Implement Thread-Safe Singleton Patterns

1. Eager Initialization

2. Lazy Initialization (Synchronized Method)

3. Double-Checked Locking

4. Bill Pugh Singleton

5. Singleton Using Enum

Conclusion

write join queries using jpa criteria queries

The Essence of Joins

Left Joins: Bridging the Data Divide

Right Joins: Shifting the Focus

Full Joins: Embracing Data Wholeness

Spring Security Oauth2- JWT Authentication in a resource server

What is JWT?

Spring Security API for JWT Authentication

JWT Authentication in Spring Security

Authentication server via Keycloak

Resource Server

Dependencies:

API Endpoint

Setup JWT issuer URL

Time to Test the Implementation 💎

Step - 1: Request OAuth Authorization Code

Step - 2: Fetch the Authentication Token

Step - 3: Run the API with

Spring Bean Scopes and Lookup method injection

@Transactional Rollback options in Spring Data

Spring Security Architecture fundamentals

Filter pattern in spring security

DelegatingFilterProxy Filter

FilterChainProxy Filter

SecurityFilterChain

Customizing the default SecurityFilterChain

AuthenticationEntryPoint

AbstractAuthenticationProcessingFilter

Authentication Architecture API

AuthenticationManager

ProviderManager

AuthenticationProvider

SecurityContextHolder

Security Context

Reactive State management in the angular - NgRx Store, actions, selectors

Basic Concepts

Prerequisites -

Table of contents

Installation

State

Design the State

Initialize the State

Actions:

NgRx Reducer -

CreateReducer

Create ActionReducerMap

Register the State

Ngrx Effects - Isolate side-effects in angular applications

what is a Side-effect?

Table of contents

Why NgRx Effects?

Service based design

NgRx Effects based design

Create Microsoft Office Addin using Angular CLI

Generate Office add-in angular app using yeoman generator

Creating an angular application using Angular CLI

Copy the addin manifest to the angular application

Change the angular application default port number

Bootstrap the angular application inside the `Office.initialize` function.