DEV Community: Vishesh

Spring AOP and Kotlin coroutines - What is wrong with Kotlin + SpringBoot

Vishesh — Fri, 19 Sep 2025 04:52:32 +0000

Are you using Springboot and Kotlin? Have you heard about spring AOP? If not then some of spring annotations like @HandlerInterceptor, @Retryable may not work as you except.

What?

AOP Proxies and Suspending Functions:

Spring AOP primarily relies on creating proxies around your beans. When you apply an aspect to a method, Spring creates a proxy that intercepts calls to that method and applies the advice (e.g., @Around, @Before, @After). This mechanism generally works for suspending functions as well. But when using AOP based annotations. We must exercise caution and test them.

Why Spring creates proxies?

Proxies are for cross-cutting concerns:

Web Request Handling - HTTP request/response processing, validating request, serialising and deserialising request and response, processing headers, so on ...
Transaction Management - Begin/commit/rollback
Security - Authorization checks
Caching - Store/retrieve cached results
Retry Logic - Retry failed operations
Logging/Monitoring - Method entry/exit tracking

Example of commonly used proxy enabled Spring components:
@RestController // Creates proxy for web-related concerns
@Transactional // Database transaction management
@Cacheable // Caching
@async // Asynchronous execution
@Secured // Security
@PreAuthorize // Security authorization
@Retryable // Retry logic

Reason why AOP does not work well with co routines is: Fundamental Architecture Mismatch: AOP proxies operate at method call level, coroutines operate at language/compiler level

Below are commonly used annotations and how to properly use them in kotlin.

@Transactional

This is supported as per recent update. Maybe your LLM like chatgpt and others maynot have the latest context. So do not believe it, here is the closed github issue https://github.com/spring-projects/spring-framework/issues/24226

@Retryable

The spring's interceptor AOP will be unable to process the suspended function and catch its exceptions to retry. Best way is to add a custom retry mechanism. Below is sample of what works. this is testable and no need to mock during tests as well.
Note: But do not create a custom spring annotation again here as it will again lead to using spring AOPs and the logic wont work.

/**
 * Utility class for retry operations with configurable backoff strategy.
 */
public class Retry {
    /**
     * Executes a block of code with retry logic and configurable backoff.
     *
     * @param <T>            The return type of the block.
     * @param maxAttempts    Maximum number of retry attempts.
     * @param initialDelayMs Initial delay in milliseconds.
     * @param maxDelayMs     Maximum delay cap in milliseconds.
     * @param backoffFactor  Multiplier for exponential backoff (default is 1.0 - no backoff).
     * @param retryOn        List of exception types that should trigger retry.
     * @param block          The block to execute with retry logic.
     * @return The result of the block if successful.
     * @throws Exception If all retries fail or a non-retryable exception is thrown.
     */
    public static <T> T withRetry(
            int maxAttempts,
            long initialDelayMs,
            long maxDelayMs,
            double backoffFactor,
            List<Class<? extends Throwable>> retryOn,
            Callable<T> block
    ) throws Exception {
        int attempts = 0;
        Throwable lastException = null;
        long currentDelay = initialDelayMs;

        while (attempts < maxAttempts) {
            try {
                return block.call();
            } catch (Throwable e) {
                boolean shouldRetry = false;
                for (Class<? extends Throwable> retryClass : retryOn) {
                    if (retryClass.isInstance(e)) {
                        shouldRetry = true;
                        break;
                    }
                }
                if (shouldRetry) {
                    lastException = e;
                    attempts++;
                    if (attempts >= maxAttempts) {
                        break;
                    }
                    // Calculate exponential backoff
                    if (attempts > 1 && backoffFactor > 1) {
                        currentDelay = calculateBackoffDelay(
                                initialDelayMs,
                                maxDelayMs,
                                backoffFactor,
                                attempts
                        );
                    }
                    try {
                        Thread.sleep(currentDelay);
                    } catch (InterruptedException ie) {
                        Thread.currentThread().interrupt();
                        throw ie;
                    }
                } else {
                    // For exceptions we throw immediately, no retry
                    throw e;
                }
            }
        }
        if (lastException instanceof Exception) {
            throw (Exception) lastException;
        } else if (lastException != null) {
            throw new RuntimeException(lastException);
        } else {
            throw new IllegalStateException("Retry failed for unknown reason");
        }
    }

    /**
     * Calculate delay with exponential backoff.
     * Example:
     * With maxAttempts = 3, initialDelayMs = 100ms and backoffFactor = 2.0:
     * Retry Attempt 1: 100ms (initial delay)
     * Retry Attempt 2: 100 * (2^1) = 200ms
     * Retry Attempt 3: No delay as max attempt reached
     */
    private static long calculateBackoffDelay(
            long initialDelayMs,
            long maxDelayMs,
            double backoffFactor,
            int attempt
    ) {
        long exponentialDelay = (long) (initialDelayMs * Math.pow(backoffFactor, attempt - 1));
        // Cap at maximum delay
        return Math.min(exponentialDelay, maxDelayMs);
    }
}

@HandlerInterceptor

The spring's interceptor AOP will be unable to process the suspended controller function. This will make the controller return coroutine object as response but meanwhile the actual controller logic will be running on the background. Hence, the client will receive empty or wrong response.

To circumvent above issue. The best way is to use CoWebFilter. This filter is applied same as handler. It can handle request and response. Below is a sample implementation.

@Component
class HeaderInterceptor : CoWebFilter() {

  // Filter runs BEFORE any controller is involved
  public override suspend fun filter(
    exchange: ServerWebExchange,
    chain: CoWebFilterChain
  ) {
        // Verify requests details

        // Decorate the response to capture it for any processing
        val decoratedExchange = decorateExchange(exchange, idempotencyKey)

        // proceed to the controller        
        chain.filter(decoratedExchange)
    }

private fun decorateExchange(
    exchange: ServerWebExchange,
    idempotencyKey: String
  ): ServerWebExchange {
    val decoratedResponse =
      object : ServerHttpResponseDecorator(exchange.response) {
        override fun writeWith(body: Publisher<out DataBuffer>): Mono<Void> {
          // Read the body and cache it
          return DataBufferUtils.join(body)
            .flatMap { dataBuffer ->
              val bytes = ByteArray(dataBuffer.readableByteCount())
              dataBuffer.read(bytes)
              DataBufferUtils.release(dataBuffer)

              mono {
                // Add your own logic to save or modify the response body and status code
                // response data is available as `bytes`. you can convert to String or DTO
              }.subscribe()

              // Write the original response body
              super.writeWith(
                Mono.just(
                  exchange.response.bufferFactory().wrap(bytes)
                )
              )
            }
        }
      }

    // Return a new exchange with the decorated response
    return exchange.mutate().response(decoratedResponse).build()
  }
}

API Idempotency: Why Your System Needs It?

Vishesh — Fri, 19 Sep 2025 03:52:45 +0000

API Idempotency: Why Your System Needs It?

In any system, there are processes that cannot be duplicated and the system must be resilient to duplicate requests. It's better to prevent issues rather than correct them later down the line.

Clients retry failed requests. Your system processes them multiple times. Data gets corrupted.

Example:

Client: "Add 100 units to inventory"
Server: Adds it
Client: Network fails, hence retries
Server: Adds 100 units... twice
Result: 200 units instead of 100 ❌

Solution: Idempotency header

Client responsibilities:

Create unique idempotency key for each request
Re-use same idempotency key for any retry attempts

Server responsibilities:

If idempotency key is given, save the successful responses. Only success 2XX responses because they are the only ones that update the main DB data. Other 4XX, 5XX do not change the DB.
If idempotency key is not given*,* process as usual as it's the client*'s* responsibility to add idempotency for critical operations
Do not save idempotency data for GET HTTP APIs as they only retrieve data and do not update any data.
Based on the need*,* add a scheduled job to remove the idempotency data. E.g.: Delete records older than 7 days

Sample DB (Postgres) design to store the response:

Column	Type	Nullable	Default
id	int8 (Primary Key)	False	Auto Increment
idempotency_key	VARCHAR(50)	False	NA
http_status_code	VARCHAR(50)	True	NA
http_response	TEXT	True	NA
created_at	TIMESTAMP	False	CURRENT_TIMESTAMP

Sample implementation (API):

Interceptor

@Component
class SimpleIdempotencyInterceptor implements HandlerInterceptor {

    @Autowired
    private final IdempotencyDataRepositoryImpl idempotencyRepository;

    // Before sending request to the controller we can check the headers here
    @Override
    public boolean preHandle(
        HttpServletRequest request,
        HttpServletResponse response,
        Object handler
    ) throws Exception {
        // Skip GET requests and non-configured paths
        if (request.getMethod().equals(HttpMethod.GET.name()) || !isPathEnabled(request)) {
            return true;
        }

        String idempotencyKey = request.getHeader("myapp-idempotency-key");
        if (idempotencyKey != null) {
            return handleIdempotency(idempotencyKey, response);
        }

        return true;
    }

    // Save the response after receiving form the controller
    @Override
    public void afterCompletion(
        HttpServletRequest request,
        HttpServletResponse response,
        Object handler,
        Exception ex
    ) throws Exception {
        String idempotencyKey = request.getHeader("myapp-idempotency-key");
        if (idempotencyKey != null && response.getStatus() >= 200 && response.getStatus() <= 299) {
            // Cache successful response
            cacheResponse(idempotencyKey, response);
        }
    }

    private boolean handleIdempotency(String idempotencyKey, HttpServletResponse response) {
        IdempotencyDataEntity existing = idempotencyRepository.findByIdempotencyKey(idempotencyKey);

        switch (existing == null ? "null" : "exists") {
            case "null":
                // First time - create placeholder record
                idempotencyRepository.save(
                    new IdempotencyDataEntity(
                        idempotencyKey,
                        0,
                        ""
                    )
                );
                return true;
            default:
                // Return cached response
                sendCachedResponse(response, existing);
                return false;
        }
    }

    private void cacheResponse(String idempotencyKey, HttpServletResponse response) {
        try {
            IdempotencyDataEntity existing = idempotencyRepository.findByIdempotencyKey(idempotencyKey);
            if (existing != null) {
                // ... response body reading logic would go here ...
                String responseBody = "/* extracted response body */";

                idempotencyRepository.save(
                    new IdempotencyDataEntity(
                        idempotencyKey,
                        response.getStatus(),
                        responseBody
                    )
                );
            }
        } catch (Exception e) {
            log.warn("Failed to cache idempotency response for key: " + idempotencyKey, e);
        }
    }
}

Scheduler for cleaning up old Idempotency data

/**
     * Cleanup idempotency records older than 7 days
     * Runs daily at 2 AM
     */
    @Scheduled(cron = "0 0 2 * * *")
    public void cleanupOldIdempotencyRecords() {
        try {
            LocalDateTime cutoffDate = LocalDateTime.now().minusDays(7);
            int deletedCount = idempotencyRepository.deleteByCreatedDateBefore(cutoffDate);
            logger.info("Cleaned up {} old idempotency records (older than {})", deletedCount, cutoffDate);
        } catch (Exception e) {
            logger.error("Failed to cleanup old idempotency records", e);
        }
    }

Import data(CSV) (Google Cloud Import API)

Vishesh — Mon, 20 Jan 2025 06:33:50 +0000

Recently in my SpringBoot application I was working on importing data from multiple CSV files into my GCS(Google Cloud) Postgress DB.

Problem statement

The import operation will be triggered by a REST endpoint in SpringBoot.
All the CSV files will be available in the GCS bucket.
A CSV file can contain 1 to 10 million records.
We will have to all the CSV files before proceeding to next task.
The import operation status should be recorded.

Below are the solutions I explored,

Method 1: COPY Command - Perform PostgreSQL Import CSV Job using the COPY Command. We will have to download the file to the machine and then run the below query in the application.

COPY employees(emp_id,first_name,last_name,dob,city)
FROM ‘C:newdbemployees.csv’
DELIMITER ‘,’
CSV HEADER;

Method 2: Postgres CLI COPY command - Use Postgres CLI COPY command. We will have to download the file to the machine and then run the below CLI query in the application

/* Login */
psql postgres://postgres:postgres@localhost:5432/postgres
/* Copy */
\COPY employee_table FROM 'employees.csv' WITH CSV HEADER;

Method 3: Use GCP import API - This might be little slow as import API is synchronous and only allows importing one file at a time.Only suitable if the import is straightforward and has no follow up operations on the imported data.
Method 4: Stream file and save in DB - This is the fastest. We can read the file as a stream and save each CSV line that we read in the database. We can leverage database batching to save multiple lines (ex: 1000) at a time. If we stream the file we need not download the full file locally. We can also stream the file asynchronously thus improving speed.

Solution

Method 4 (Stream file and save in DB) if you have to upload multiple files parallelly
Method 3 (GCS import API) if you are have lesser files and uploading one by one synchronously is not a concern

Disadvantages

Method 1 & Method 2:

We must do lot of heavy lifting and handle many error cases.

The files are present in the GCS bucket. Hence, to pass it to the command, I will have to download it first and keep it in the system memory. Which is not ideal.
After importing is done, I must delete the file form the server. If any error occurs here then the system memory will increase.
During the import operation my system memory and CPU usage will spike. Especially when the CSV files have millions of records.
Accessing production psql is generally not recommended and has security concerns. It would lead to easier SQL query injection, etc...

Method 3

The main problem with GCS import API is that its synchronous. We can only run one import operation at one time per DB instance. This is because postgres itself under hood only allows one COPY process to run at a given time. It is a necessary condition to avoid data inconsistency.

If one table is being updated by 2 different files then the order of data cannot be preserved.
Also, it will be added overhead to rollback incase of failure when 2 or more files are being imported

Hence we have to ensure to wait for one file import to complete and then trigger another file.

Method 4

High CPU utilisation. Processing parallelly may need higher configuration of the system
High database utilisation. Since we are saving line by line. When saving large files. Huge number of queries run. Hence we will need higher configuration of database
Better error handling. Asynchronous processes are often difficult to handle, we need to plan for errors at multiple stages. Like Connecting to DB, thread locking, query fails, etc...

API logs - Best practices

Vishesh — Mon, 13 Feb 2023 04:16:53 +0000

How to log information in APIs?

Logging the right information will save you hours of debugging and improve code flow visibility.

Do not console.log or println etc... Because,
- These logs are directly added to the terminal where the server runs.
- This is difficult to read and record.
Use a library or create a separate service for logging. Better to save them in a separate file at a secure location if not using any existing libraries.
Avoid logging sensitive data. Like,
- usernames
- tokens
- password
- Database config data
Avoid logging each stage of the API like, starting, started, processing, done. Instead add details like,
- Non-sensitive but critical input data that determine the API flow. Ex: flags or reference ids.
- Log any third party integrated APIs. Ex: "Firebase Authentication response: 200 success", but do not log the actual response.
Make it as meaningful as possible with limited data.
Add a header for easy filtering. Ex: "Login API: ...." or "Get user details: ...
Add enough facts or information for debugging the issue. Not just plain sentences like as it will be easy to cross refer and confirm the understanding. Ex:
- Avoid: "Received response from firebase"
- Better: "User authenticated by firebase: " or "Firebase authentication failed: "
Add only suspicious or areas where logs could help. Ex: Third party integration - It will help decide if our code went wrong or third party API returned wrong.
- Avoid adding in simple get APIs. Where there is no much data processing, only data retrieving. So, no need of detailed logging here.
Do not forget to remove when not necessary. It will save a log of time when viewing and filtering the logs.
Do not add logs in core areas like (index.js, routes, middlewares, etc…)

Log types

Error: This is used when you need to log any error like DB connection failed or uncaught error thrown.
Debug: This is debugging logs. This is used to log any information that can will used for better understanding of the API flow. Ex: "Third party auth succeed".
Warn: This is used when logging issues that may or suspected to cause issues. Like malformed data from any third party or any API header missing.
Log: This is a general log type.

Software releases

Vishesh — Thu, 02 Feb 2023 10:17:30 +0000

Intro

It depends .... 😜

This is the common term in software industry. And for the most part its true. Unless you know about the goals of the software you cannot determine a release process. Generally there is a standard framework(that I observed working in 10+ projects):

Note: the software here means both frontend and backend

Split the software into small deliverable modules. Ex: to build a motor cycle start by building a skateboard, then a cycle then a motor cycle. This way you can use and test each module.
Build minimum 3 environments where the software can be deployed. ITs more like having same software running in 3 different servers and 3 domains
- dev.mysoftware.com - Development environment
- stage.mysoftware.com - Staging / beta environment
- mysoftware.com - Production / main environment
- test.mysoftware.com - Temporary testing environment

Each environment will have it's own code running in backend and frontend servers. Each environment code will be different and will be a different branch in the GitHub repository.

Development environment

This is where developers can deploy all latest working code and release to testing.

Staging environment

This is essentially a well tested copy of software with new features or modules waiting to be tested and approved by the stakeholders(Who own the software).

Production environment

This is where fully approved software is deployed and used by the end users.

Testing environment

If only obsoletely necessary, we can have this environment to test any new things we try. Like DevOps terraform or AWS etc.. integrations.

Release cycles

General code release process

When working on a module / feature create a feature branch from development branch and work in it.
After completing feature development. Update the feature branch code in development branch. Normally we use PR (Pull requests).
Deploy to development environment.
Initiate testing.
Do bug fixes if there are any. Here as well create a bug fix branch and move the code to development using PRs.
Post testing passed, move development code to staging branch.
Deploy in staging environment.
Perform a sanity to ensure all changes are working fine.
If there are any bugs identified in sanity then fix them by creating a new hotfix branch from staging. Make sure to move these hotfix changes to development branch as well.
Post completing sanity, move all changes in staging to production branch.
Deploy production branch. [Do not do testing in production]

Release with feature flags

Post releasing a feature or change to production. Suppose, this new feature needs to be rolled back or put on hold because of any issue, for example server / website performance is slow. Then our only way is:

Create a hotfix in staging to remove this feature
Test this change
Do a bug fix if this change causes any issues
Re-test if any bug fixes
Move code to production.
Repeat the same, from step 1 to enable this feature later on.

This is very expensive and includes multiple developing and testing cycles. Can we avoid it? Oh yes, feature flags. They are similar to environment variables. Each environment will have different values but the name will remain the same.

The concept is to develop features with feature flag conditions in place, in such a way that,

If the flag value is true then feature should be enabled or shown in the software.
If the flag value is false then feature should be disabled or should not be shown in the software.

Hence, here if we need to rollback / switch off a feature, its very simple. We just need to set this flag as false and re-deploy or use a cloud third party like LaunchDarkly and change the value to false.

Once a feature is in production and working fine. We must remove this feature flag conditions form code.

Release with scientific experiment

This is special case for microservices covered in this article How to test new microservice APIs - (Monolith to Microservice)

Few additional tips:

Think ahead of time and maintain a sheet with release check lists. It will help in future.
Make sure that infra setup is working fine before deploying.
Double check with environment variables.

Communication within microservices

Vishesh — Thu, 02 Feb 2023 06:19:15 +0000

Intro

Every microservice has its own bounded context and will not have data is not within it's domain. Lets assume, we have a ecommerce system with below microservices:

User microservice - Includes APIs to login, log out and user profile
Product microservice - Include APIs to list, add, edit or delete products
Billing microservice - Include APIs to generate bill and initiate delivery.

Why we need to communicate?

If we observe closely, for billing microservice, to generate a bill it will need product price and details. Hence the billing microservice will need to communicate with product microservice and get the full product details.

How to communicate?

Simple, call the list API in product microservice from billing microservice. Yes, this should be fine and we are not violating the bounded context by accessing product details directly from DB.

But ...

But we have to authenticate right? Generally frontend will use the user login token to authenticate. But how can a microservice get this token? It will not have the user login details. Moreover, this is user token and is meant to be used for APIs that a end user can access. So, its not a good practice to use this token to communicate between microservices.

Solution

Hence we will need a specific token to authenticate communication between microservices. Token can be anything:

JWT token
Firebase token
Custom token generation logic

We must ensure to follow below process to ensure the communication is secure,

Solution 1

In the authentication mechanism for all APIs introduce a new API header like "X-MS-TOKEN". When ever this is passed decrypt and verify this token.
In the billing microservice when calling product microservice for details. Encrypt and attach the token in the "X_MS_TOKEN" API header This is a very simple way. But this has a security concern that if this token is leaked then anyone can easily access the API. We are not refreshing this token at all. This could be a concern when dealing with APIs that involve billing. Anyone could easily generate multiple bills.

For more security

Use a third part service like firebase or create your own token generation service and fetch a token every time you call API to get details from other microservice. This way the token remain fresh each time and even if its leaked it not relevant for single use.

How to test new microservice APIs - (Monolith to Microservice)

Vishesh — Thu, 02 Feb 2023 05:11:55 +0000

This article will cover on a interesting approach to test newly build microservice APIs. Assuming that we are building a new microservice breaking an old monolith application that is already in production and used by end users.

Debrief

We had a very large monolith and had to break them into multiple microservices. This was easy due to the TDD practice. The problem was on deciding the release process. How will you release the microservice APIs without affecting the end users and also test then thoroughly.

Release and test gradually and not at once
Need a way to test the new microservice APIs before releasing
Foresee any issues early before actual release

Proposed solution

Below is the list of steps how the experiment should work:

Frontend calls the new monolith API.
In backend, the API middleware is triggered. The middle ware will as usual send pass the request to the controller.
The controller performs the operations and returns the response to the middleware.
The middleware here will return the response to frontend. Thus causing no delays to the frontend.
In background the middle ware will do the following.
- A random percentage is calculated. Ex: 3
- This random percentage is compared with the release percentage set either as an environment variable or any flags like LaunchDarkly. Hence if release percentage is set to 5 then there only 5% of chance that the process continues.
- If the above condition matches, then call the microservice API.
- Compare and log the API processing time and response.

We can gradually increase the release percentage whenever there are no issues with monolith and microservice API responses. Ex: start with 5 then increase to 25, then to 50, then to 75 and finally to 100.

Using this setup without even affecting existing monolith API you can test the new microservice API. This will be most effective on APIs that are very sensitive, like billing or most used, like getting main job list.

Conclusion

Once the test succeeds and at 100% you are not receiving any issues. Then you can disable this experiment & monolith APIs and directly enable the microservice APIs.

Code review checklist

Vishesh — Wed, 01 Feb 2023 05:20:24 +0000

Code style

Code duplication
Naming of methods
Naming of variables
Use of Constants for unmodified variables
Developer checklist
Scope and size of the PR (Can it be split?)
Is it tackling too many features/bugs at once?
Commit messages: conventional commits
No commented code checked in
Async/Awaits handled correctly
Any video or screenshot to support the bug fix or feature?

Documentation

API documentation for new/updated endpoints
PR description
Ticket reverence (Ex: Jira ticket)
Updated README.md
Typos/Grammar

Tests

Positive cases
Negative cases
Error/Exception handling
Tests naming
Unit tests
Service tests if necessary
Mocking/stubbing
Increase coverage

Common

Logical implementation
Is the code release complaint (Feature flags or environment variables are up to date?)
No hardcoded values (Date or time)
Time complexity
Timezone aware
Error handling
Null references
Default values
Single responsibility (SOLID principles)
Open for extension/Closed for modification
Interface segregation
Dependency injection (Avoid circular / unused dependencies)
Dependencies
Updated package.json => updated lock files (yarn or npm)
Verify any newly added packages (Is it up to date and licensed)

Bugfixes

Is the bug fixed in all impacted modules?
Does it require to communicate to customers?
Does it impact other teams? Do we need to inform them?
How well is the bug documented

Security

Secrets should be in configuration and values should never be in the code.
No self-made encryption
No client-side encryption
SQL Injection
Authentication
Authorization
Sensitive data in response payloads

Ops

Logging where needed, with appropriate levels
Environment variables added across all environments
New packages should not fail the build

Database

Normalization
Indexes for queries
Indexes for new fields
N+1 queries
Backward compatibility
Migration
Rollback strategy (if needed)
Data types
Cascade deletes

API

RESTful endpoints routes
HTTP semantics in response codes
Uniform response format in the service
Is backward compatibility managed?

Frontend

Is the output screenshot or video available to verify the changes
Code / Design should work across all supported devices (Mobile, tablets, etc..)
APIs should follow the API documentation
DRY. Is the same code duplicated more than twice?
Are functions/classes/components reasonably small (not too big)?
Code has no any linter errors or warnings
No console.logs

Additional resources:

The Code Review Pyramid - https://www.morling.dev/blog/the-code-review-pyramid/

My experience as a professional Developer

Vishesh — Sat, 10 Dec 2022 13:07:44 +0000

I am also learning !! This is just a note from my observations. Excited to hear form you... do comment.

The meaning around being an efficient developer or analyst or any other entry or median level tech role always changes based on the organisation / team you work in. But based on working with local and offshore teams for last 5yrs. I understood few basic expectations that teams have when you want to work with them.

General:

Have an open mind. Do not be judgemental. This will help you to think in all angles.
Do not multi-task. It will never end good.
Learn to say no humbly. Else no one will know your limits, even you. Can end up taking more work or responsibility than you can handle.
Share learnings and short comings as much as possible. Both organisation wise and team wise. This will promote team culture.
Ownership - you must be able to understand how your code / solution works. The full flow from program / server start to end.
Ability to learn - There is nothing wrong in not knowing anything, after all Software field is widening in all verticals every day. Difficult to always stay on top. But should be eager to know and learn about it.
Communication - Ability to communicate the solution to all levels of the organisation (Team, Leads, Managers and Management).

Coding:

Follow and enforce the latest standards in code.
Follow up and stay in sync with the latest changes and upgrades in the programming language you are working.
Always analyse the impacts before coding. Understand the whole picture both feature wise and code wise.
- Can create sequence diagrams.
- Note down knowns and unknowns in an excel and explore.
Always add test cases and mockups. Cannot stress enough about this. Because by adding just unit test's you can easily notice the gaps and come up with some innovative ideas to improve existing code.
Always watch out for more improvements and have a plan to tackle them.
Prioritise - Split the work efficiently and reorganise based on priority.
Ask for help or co-work as much as possible (Don't hesitate)
Every piece of code you write should be production ready.

Apart from this if you are senior. Then there is added expectations like below,

Team culture - Share all discussion with the team. Be transparent as much as possible.
Involve the whole team in any decision making. It will increase the team morale.
Delegate work - Plan and share work as much as possible with team. Try to ensure everyone in the team get to work in all parts of the program as much as possible so it's both exciting and relaxing for all.
Be available to all in the team. It will help others in the team to move without waiting.
Consistently review work and give feedback actively.
Receive feedbacks regularly and adapt accordingly.
High level thinking - Having an eye on next upcoming work and organising them appropriately. So the team can take it up without any major hiccups.
Actively participate in product level discussions and mention improvements or concerns.
Ability to quickly switch from high level work like building CI/CD, new microservice architectures, etc to coding a feature and raising PRs.
Need to learn high level tech concepts and strategies. Actively suggest the same with the team and stakeholders. Ex: Using deployment automation using terraform and Github workflows.
Actively collaborate with other seniors or teams in the organisation. Everyone can share and learn.

Phew !! 😰 It might me overwhelming at first but biggest learning for me was to keep clam and enjoy the process. No need to rush. Everyone have their own unique way to handing things.

Technical Design Document - Microservice

Vishesh — Sat, 24 Sep 2022 11:02:28 +0000

A Technical Design Document (TDD) is written by the development team and describes the minute detail of the entire design of the system that the team is going to build. It's is a design blueprint for an application or feature.

It should include both functional and technical design. The functional design specifies how a program will behave to outside agents and the technical design describes how that functionality is to be implemented in code.

The primary function of a TDD is to,

🗣️ Communicate the technical details of the work to be done to members of the team and clients.
💡 Gain clear understanding of the system to built. Which will help in planing the development.

The process of writing the TDD forces to organize thoughts and consider every aspect of the design, ensuring that we haven’t left anything out.

How do i know? 📜

I recently got hands on a monolithic system where the stakeholders gave us a problem that there is too much dependency. They had almost 5-6 team working on a single code base and it was almost impossible for the teams to sync with a single release cycle. Hence too much of unfinished code started moving to production, causing many issues.

Thus we were tasked to create a microservice for one of the module. Luckily, thanks to by team lead, I got the opportunity to do the work. Hence I got to create a TDD. Got involved in many discussions and refined the TDD. It was an eye opener, despite having some experience previously in similar work.

Writing a TDD 📖

Writing TDD is exciting because its about building a new system / feature. But TDD is not something that can be written overnight. It is a long progress often with many review cycles. It must go through BA (Business Analyst), project lead, project manager and stakeholders. Hence should be written clear and crisp. It must be well detailed explaining the following:

Product requirements - Here the feature overview and justification is written. This section must answer two important questions. What is the problem identified? and what are the goals?
Technical requirements - The product requirements are translated into technical requirements — what the system needs to accomplish? More like goals.
Technical design - This contains a technical design of the solution to the requirements outlined in the previous steps. This should explain what will be the system architecture? What will be the system inputs? and what should be the expected outputs? Lot of flow diagrams will help to understand the design quicker.
Implementation - This explains how we are planing to execute the design. Generally split into phases, where each phase delivers executable and working part of the output. Final phase will deliver the complete product.
Testing - This should explain how testing is planned. Manual or automation? Should we include load testing? Why so?
Release process - This should outline the plan with respect to releases. At which dates each phase and the final product will be available to the customers.

Bounded context - Bounded Context is a central pattern in Domain-Driven Design. The general rule is that a service should do "one thing". For example, if we set sales as the boundary context then this service must only be responsible for sales data and features. Other features like support should not be accessed directly or updated in this service. However, only when absolutely necessary, sales service can communicate with support service for any data exchange. More about bounded context here (https://www.martinfowler.com/bliki/BoundedContext.html)[https://www.martinfowler.com/bliki/BoundedContext.html]

TDD Template

First page

Name TDD
Status: Draft / In Progress / In Review / Approved

Overview

Problem Identified

Describe about the problem in detail. Explain the impacts and issues that the problem is causing.

Goals identified

List the goals to achieve for solving the problem. Describe about each goal in short sentences.

Supporting documents

List of supporting documents that can be additional reading.

Technical overview

Existing system architecture

Describe about existing system architecture. This could include an architecture diagram and description.

Execution plan

Describe about proposed system architecture. This could include an architecture diagram and description.

Data Model

Describe how the data is stored. This could include a description of the database schema.

Interface/API Definitions

Describe how the various components talk to each other. For example, if there are REST endpoints, describe the endpoint URL and the format of the data and parameters used.

CI/CD

Describe on how to automate continuous code integration and continuous deployment. Explain the strategy and tools to be used.

Fault tolerence

Describe the fault tolerance strategy. How will the system react to various known / unknown issues.

Open Questions and Assumptions

Add any unanswered questions or assumptions here.

Abandoned Ideas

Describe any ideas that were discussed but not considered for the design or solution.

Additional observations / Tips 💁‍♂️

Draw as much as you can. 1 picture can explain 1000 words. No matter how hard you try, it's difficult to explain to multiple readers. Sometimes if it's too long, it can get frustrating to read. Hence create flow diagrams, architecture diagrams, bullet points, etc... You can use draw.io or Whimsical
60% of TDD I built was of diagrams. This actually helped in understanding. One of the reviewers actually confirmed that there were lesser doubts especially because of the diagrams. It helped in understanding the design.
Often we can easily explain things in single line just like in emails. But that never works out in TDD because the readers here are both experienced engineers and also business stakeholders. We will receive many questions. Thus we need to be clear on every claim or fact that we add in the document. For example, if we are to say that the API performance will improve. Though it might be obvious, we are supposed to tell how? and by how much it improves? Perhaps even do a POC to get the metrics. But we must have the metrics else it's hard to prove the statements.
Some popular questions - Why? Why should we do this? Why exactly like this? Why not use different method?
Always remember to check for the best possible ways. If there are multiple ways, do mention them and also confirm which to pick.
Always plan in incremental release model. (i.e) Create the product in small working parts. Hence every part is testable and can be released to production in quick time.

Finally

Hope it was helpful. Let me know your experience of building exciting systems in the comments !! Have a good day !!

JavaScript responsive snake game

Vishesh — Sun, 25 Jul 2021 05:47:56 +0000

My first JS game - https://lnkd.in/gDG9Vhc

I have always been grinding to do the best side project.Most usefull one for interviews as well. But it takes toll after sometime. Hence, i worked and created something simple and fun.

This is a snake game. I tried to make it as much fun as possible. Please play and let me know. Some of its highlights are,

Its completely responsive. Work in mobile and web.
For mobile mode. i have developed a joystick which can be used for snake navigation. Its custom built and not copied or referenced from anywhere.
It has sound effect. Just for fun.
Its has humorous descriptions and funny messages.

Challenges

Responsive design - It was very challenging. I had to adjust canvas based on the size. On top of that i had to adjust the snake size as well. This completely alters calculations.
Joystick - Tried various other ways but joystick was difficult to design as it had to work in all mobile devices.
Random food - Generating a random number between the canvas sizes was also a challenge. But was not very difficult.

Has anyone checked how C pointers work when it is compiled(Emscripten) to WASM file in WebAssembly ?

Vishesh — Mon, 09 Nov 2020 11:19:00 +0000

I know this is more of a question. But there is no much discussion or clarity on this. OR atleast i was unable to find. I have a question for the same in stackoverflow with absolutely no answers or even comments https://stackoverflow.com/questions/64447082/how-to-use-c-compiled-wasm-functions-in-js-pointer-logic-do-not-work-as-expect