DEV Community: Emmanuel Uchenna

10 Key Data Structures We Use Every Day

Emmanuel Uchenna — Mon, 27 May 2024 00:13:55 +0000

Data structures are like the building blocks for organizing information in our daily lives. While they might not be explicitly called out, these structures underlie many of the things we do. Here are 10 key data structures we use every day:

Lists: These are ordered collections of items, like a grocery list, a to-do list, or the songs in your music playlist. You can easily add, remove, or rearrange items on a list.
Arrays: Similar to lists, arrays hold a fixed number of items in a specific order. Imagine the buttons on a calculator or the channels on your TV – you access them by their position in the sequence.
Stacks: These follow a "Last In, First Out" (LIFO) principle. Think of a stack of plates – you can only add or remove plates from the top. This structure is used in things like browser history (you visit the most recently accessed page first) or when undoing actions on a computer program.
Queues: Unlike stacks, queues operate on a "First In, First Out" (FIFO) basis. Imagine a line at a coffee shop – the person who has been waiting the longest gets served first. Queues are used in waiting lists, task scheduling, and even traffic flow management (vehicles that enter the queue first exit first).
Trees: Hierarchical structures that mimic real-world trees. Imagine a family tree or an organizational chart. They represent relationships between items, with a root element at the top and branches (sub-elements) connecting to it.
Graphs: These represent connections between objects. Think of a social media network where users are connected to their friends, or a map where cities are connected by roads. Graphs help us visualize and analyze relationships between different entities.
Hashes: Used for fast retrieval of information. Imagine a phonebook – you look up a name (key) to find the corresponding phone number (value). Hash tables store data with unique keys for efficient access.
Sets: Collections of unique items, like the unique words in a document or the different types of fruits in a fruit basket. Sets ensure no duplicates exist within the collection.
Associative Arrays (Dictionaries): Similar to hash tables, these store key-value pairs but allow for more complex data types as values. Imagine a recipe book where the recipe name (key) is associated with a list of ingredients and instructions (value).
Linked Lists: These are linear data structures where elements (nodes) are not stored contiguously in memory. Each node holds data and a reference (link) to the next node in the sequence. They are useful for dynamic data (frequently changing size) like managing musical playlists or social media feeds.

Understanding these underlying data structures allows us to better appreciate the organization that underpins seemingly simple aspects of our daily lives.

Which data structure do you find most surprising in everyday use? Why? or Have you encountered any data structures in your hobbies or work that aren't on this list? Share your experiences!

Spring Bean Scopes

Emmanuel Uchenna — Sun, 26 May 2024 23:38:38 +0000

Bean scope in Spring Framework refers to the lifecycle of a Spring bean and its visibility in the context of the application.
When you create a bean definition, you create a recipe for creating actual instances of the class defined by that bean definition. The idea that a bean definition is a recipe is important, because it means that, as with a class, you can create many object instances from a single recipe.

Spring provides multiple scope to register and configure beans and scoping has an impact on a state management of the component.
Singleton is the default scope of a bean, which means one instance per application context.

Bean Scopes provided by Spring:

Singleton Only one instance of a bean is created and all request of that bean will receive the same instance. This is useful for beans that do not hold state or where the same state is to be shared by all users or threads. For example, a database connection pool

@Configuration
public class DataSourceConfig {

    @Bean
    public DataSource dataSource() {
        HikariConfig config = new HikariConfig();
        config.setDriverClassName("org.postgresql.Driver");
        config.setJdbcUrl("jdbc:postgresql://localhost:5432/yourdatabase");
        config.setUsername("yourusername");
        config.setPassword("yourpassword");
        config.setMaximumPoolSize(10);
        config.setMinimumIdle(2);
        config.setPoolName("HikariCP");

        return new HikariDataSource(config);
    }
}

Prototype A new instance is being created each time a bean is requested from the container. Useful for stateful beans or beans that are not thread-safe, such as a bean that maintains user-specific data during an operation.

@Component
@Scope("prototype")
public class UserData {

    private String username;
    private String operation;

    // Getters and setters
    public String getUsername() {
        return username;
    }

    public void setUsername(String username) {
        this.username = username;
    }

    public String getOperation() {
        return operation;
    }

    public void setOperation(String operation) {
        this.operation = operation;
    }
}

Request This scope is Only valid in the context of a web-aware Spring ApplicationContext for a single http request. A new bean is created for each http request. For example, a bean that tracks the progress of a user's request or data specific to that request, such as user credentials or input parameters.

@Component
@RequestScope
public class RequestData {

    private String userId;
    private String requestStatus;

    // Getters and setters
    public String getUserId() {
        return userId;
    }

    public void setUserId(String userId) {
        this.userId = userId;
    }

    public String getRequestStatus() {
        return requestStatus;
    }

    public void setRequestStatus(String requestStatus) {
        this.requestStatus = requestStatus;
    }
}

Session A new bean is created for each http session by the container. Also applicable in web-aware Spring ApplicationContext. Useful for user sessions in a web application, like storing a user's authenticated session or a shopping cart in an e-commerce site.

@Component
@Scope(value = "session", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class UserSession {
    private String username; // You can add more session-related data here

    public String getUsername() {
        return username;
    }

    public void setUsername(String username) {
        this.username = username;
    }
}

Application Scopes a single bean definition to the lifecycle of a ServletContext. Only valid in the context of a web-aware Spring ApplicationContext. For example, application-wide configuration that is web-context aware, like a cache that is shared across sessions but not across different applications.
WebSocket Scopes a single bean definition to the lifecycle of a WebSocket. Only valid in the context of a web-aware Spring ApplicationContext.

The scope of a bean affects its injection into another bean in terms of lifecycle management and statefulness:

Singleton beans injected into other beans will have their state shared across the entire application, making them suitable for shared configurations or stateless services.

Prototype-scoped beans ensure that a new instance is provided each time a bean is injected, suitable for stateful beans or beans that are not thread-safe.

Request, Session, Application, and Websocket scopes allow beans to be tied to the lifecycle of web components, making them ideal for managing user sessions, application context, and real-time communication channels respectively.

Singleton Beans with Prototype-bean Dependencies
When you use singleton-scoped beans with dependencies on prototype beans, be aware that dependencies are resolved at instantiation time. Thus, if you dependency-inject a prototype-scoped bean into a singleton-scoped bean, a new prototype bean is instantiated and then dependency-injected into the singleton bean. The prototype instance is the sole instance that is ever supplied to the singleton-scoped bean.

Custom Scopes
The bean scoping mechanism is extensible. You can define your own scopes or even redefine existing scopes, although the latter is considered bad practice and you cannot override the built-in singleton and prototype scopes.

Mastering REST API Best Practices: A Developer's Guide

Emmanuel Uchenna — Fri, 17 May 2024 18:48:44 +0000

Introduction

In the realm of web development, REST APIs (Representational State Transfer Application Programming Interfaces) have become the backbone of modern applications. They provide a standardized way for different systems to communicate over HTTP, enabling seamless integration between various components. However, not all APIs are created equal. To ensure efficiency, scalability, and maintainability, it's essential to follow best practices when designing and implementing REST APIs. In this article, we'll explore some key principles and guidelines to help you craft robust and developer-friendly APIs.

1. Designing RESTful Endpoints:

Use nouns instead of verbs in endpoint URLs to represent resources.

POST /createUser (incorrect)
POST /users (correct)

Follow a hierarchical structure for resource representation.

GET /users/{userId}/posts
GET /users/{userId}/posts/{postId}

Utilize HTTP methods (GET, POST, PUT, DELETE) appropriately for CRUD operations.

GET /users - Retrieves a list of users
POST /users - Creates a new user
GET /users/{userId} - Retrieves details of a specific user
PUT /users/{userId} - Updates details of a specific user
DELETE /users/{userId} - Deletes a specific user

Version your APIs to maintain backward compatibility.

2. Response Formats and Status Codes:

Return responses in JSON format for easy consumption by clients.
Use appropriate HTTP status codes to indicate the outcome of the request (e.g., 200 for success, 404 for not found, 400 for bad request).
Provide meaningful error messages and adhere to standard error formats like RFC 7807 (Problem Details for HTTP APIs).

3. Authentication and Authorization:

Implement secure authentication mechanisms such as OAuth 2.0 or JWT (JSON Web Tokens).
Use HTTPS to encrypt data transmission and prevent eavesdropping.
Enforce proper authorization checks to restrict access to resources based on user roles and permissions.

4. Request and Response Payloads:

Keep request payloads concise by only including necessary data.
Use query parameters for filtering, sorting, and pagination to optimize performance.
Include relevant hypermedia links in responses to facilitate navigation within the API.

5. Error Handling and Logging:

Handle errors effortlessly and provide informative error messages to assist developers with troubleshooting.
Log API interactions, including requests, responses, and errors, for debugging and auditing purposes.
Monitor API performance metrics such as response time, throughput, and error rates to identify and address bottlenecks.

6. Testing and Documentation:

Write comprehensive unit tests to validate the functionality of individual API endpoints.
Conduct integration tests to ensure seamless interaction between different components.
Document your API thoroughly, including endpoint descriptions, request/response formats, authentication methods, and usage examples, using tools like Swagger or OpenAPI Specification.

Conclusion:
By adhering to these REST API best practices, developers can create robust, efficient, and developer-friendly APIs that enable seamless integration between diverse systems. Remember, the goal is not just to build an API but to empower developers to leverage it effectively. Embrace these principles, iterate based on feedback, and strive for continuous improvement to deliver exceptional API experiences.