DEV Community: Ashish Ranjan

Unlocking Success in Problem Solving: Start with the Problem Statement!

Ashish Ranjan — Mon, 11 Sep 2023 16:18:52 +0000

In the world of development, it's easy to dive headfirst into solving issues. However, before we solve any issue, we should identify the Problem statement clearly and accurately. This is often a step when overlooked or done poorly, leads to wasted time and resources.

The problem statement

As a developer, I often see people misinterpret issues as problem statements. This can lead to solutions that are not effective or even counterproductive. We've all been there, facing an issue, and thinking that the problem statement is simply a feature not working correctly. But wait, there's more to it!
The feature not working correctly is not the actual problem statement; it's just the issue that needs fixing. We should collect some basic info like criticality and identify the problem statement to work upon, which can be like we need to hotfix this issue or we need to identify the root cause and fix the issue. The approach to both the problem statements can be very different.

You can try answering these questions to phrase the core problem statement to work on:

What is the issue?
Who is affected by the issue?
What is the importance?
What are the consequences?
What are the desired outcomes?

Why is this important?

The approach to problem-solving can vary dramatically based on the problem statement. Whether it's a POC, planning of architecture, or process design, understanding the problem statement is a game-changer. When you know the problem, you can start thinking about how to solve it. This can help you narrow down the options and choose the best solution for your needs.

It's important to remember that there is no one-size-fits-all solution to every problem. We have countless ways, tools, and frameworks at our disposal to solve problems. However, blindly following what others are doing isn't the best strategy. Instead, align the pros and cons of available options with your specific problem statement. Give weightage to the pointers that fit your problem. The best solution will vary depending on the specific problem statement.

Some additional thoughts on the importance of identifying the problem statement:

It can help you avoid wasting time and resources on solutions not addressing the core problem.
It can help you get buy-in from stakeholders, as they will be more likely to support a solution that they understand and believe is necessary.
It can help you identify the right people to be involved in problem-solving.
It can help you track your progress and measure the success metrics of your solution.

If you're facing a problem, I encourage you to take the time to identify the problem statement first. By taking the time to identify the problem statement, you can increase your chances of solving the problem.

How to access a private S3 bucket via Cloudflare

Ashish Ranjan — Tue, 01 Aug 2023 20:09:39 +0000

In this blog post, we'll explore how to access a private S3 bucket via Cloudflare. Most of the tutorials on the internet suggest that you need to enable static hosting on your S3 bucket and use the same name for your bucket and your domain. For example, if your domain is example.com, your bucket name should be example.com too.

However, this approach has some drawbacks. Amazon S3 website endpoints do not support HTTPS. Using the same name for your bucket and your domain is not always possible or desirable. Bucket names have to be unique across all of AWS, so you might not get the name you want. Also, you might want to map multiple domains to the same bucket, or use an existing bucket with a different domain name.

The solution

In this demo, I will show you how to access a private S3 bucket with a different name than your domain via Cloudflare. Let’s assume that we have a bucket named test-bucket in the eu-central-1 region, and we want to map it to our domain test.ashish.link.

Step 1: Add a CNAME record on Cloudflare

The first step is to add a CNAME record on Cloudflare that points to the S3 endpoint of our bucket. The S3 endpoint has the format <bucket-name>.s3.<region>.amazonaws.com. In our case, it is test-bucket.s3.eu-central-1.amazonaws.com.

Step 2: Add a bucket policy for Cloudflare IPs

The second step is to add a bucket policy on our S3 bucket that allows Cloudflare IPs to access our objects. You can find the list of Cloudflare IPs on their website. The bucket policy should look something like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCloudFlareIP",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": [
                "arn:aws:s3:::test-bucket",
                "arn:aws:s3:::test-bucket/*"
            ],
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": [
                        <list of ips>
                    ]
                }
            }
        }
    ]
}

This policy grants read access to our bucket and its objects only to the requests that come from Cloudflare IPs. You can find the list of cloudflare IPs from here.

Step 3: Set a Host header override on Cloudflare

The final step is to set a Host header override on Cloudflare that tells S3 which bucket we want to access. By default, S3 uses the Host header of the request to determine the bucket name. For example, if we request example.com/image.jpg, S3 will look for a bucket named example.com. However, since our bucket has a different name, we need to override this behavior and tell S3 to use test-bucket.s3.eu-central-1.amazonaws.comas the Host header instead.
To do this, we need to create a Origin rule on Cloudflare that sets the Host header override as follows:
This origin rule tells Cloudflare to forward all requests for test.ashish.link/* to our S3 endpoint with the correct Host header.

Conclusion:

By following these steps, you can successfully access a private S3 bucket via Cloudflare, regardless of whether your bucket name matches your domain name or not. This setup allows you to securely and efficiently serve your assets while maximizing control over access.

I hope you found this post helpful. If you have any questions or feedback, please leave a comment below.

Modular Ducks - A design pattern for scalable redux architecture

Ashish Ranjan — Mon, 10 May 2021 17:30:29 +0000

The Redux library is highly unopinionated. It lets us decide everything from store set-up and its contents to reducers. This is good because it gives us the flexibility to set it up as per the project requirements, but this flexibility is not always needed. We have to figure out the architecture ourselves, which is not an easy task.

I have worked with many different redux patterns and architectures, and I have found that none of the redux patterns are perfectly ideal. The ducks-pattern is prone to a circular dependency. The traditional folder-based approach requires you to separate actions, reducers, selectors, etc into multiple files that become cumbersome while developing and refactoring.

Redux toolkit provides an opinionated wrapper around redux and lets us do more with less code. But, the issue with the Redux toolkit is that the project structure becomes similar to ducks and is prone to a circular dependency. Redux toolkit has already warned us of this issue here.

In this article, I am sharing my approach for the architecture with Redux toolkit, which is circular dependency safe, and also handles refactoring with ease.

Project Structure

Let's start with the important redux components in the architecture.

Slices

Break your redux store based on the features of the app. With the Redux toolkit, we can use the createSlice API to create actions and reducers for an individual slice.
One thing to keep in mind is no two slices should import from one another. There can be a case when we might have to trigger reducers in two slices for one action. In that case, instead of importing action from one slice to another, create a common action in a separate file using createAction and register this in both the slices with extraReducers.
Export a constant key from the slice file to be used in the combineReducers to combine the reducers. Keeping the constant key in a slice file makes the store structure more predictable.
Keep selectors for all the keys of a slice file in the same slice file. You can also create separate selector files, but keeping them in the slice file makes refactoring a little easier. You can also use createGlobalStateSelector an ultra-light npm library to generate global state selectors from the local slice selectors. This approach reduces the refactoring efforts by quite a lot.

Common Actions

Based on the project structure we can have multiple common action files which will use createAction to export actions that can be used in multiple slices.
Common action files should not import from any other file (with redux components) in the project directory.
Common actions can be used inside slices, thunks, or our components.

Common Selectors

Just like common actions, we might need selectors from different slices to combine them into one selector (e.g. using createSelector to create a selector based on multiple selectors in different slices).
Keeping combined selectors of two different slices outside the slice file in a different selector file avoids the circular dependency issue.
Common selectors file will import selectors from the slices file and will export combined selectors to be used inside thunks or components.

Thunks

Thunk actions (or any redux middleware functions) should not be kept in the slice file. Thunks have access to the global state (with getState) and it might have to dispatch actions to multiple slices.
You can create multiple files for thunk actions (it is always better to have multiple files than having one giant file). This can also be divided based on the features.
Thunk action files can import from slice files (actions and selectors), common action files, and common selector files.

Import diagram

Sample Code

// personalDetailsSlice.js

import { createSlice } from '@reduxjs/toolkit';
import createGlobalStateSelector from 'create-global-state-selector';
import { clearData } from './commonActions';

export const sliceKey = 'personalDetails';
const initialState = {
  name: 'Ashish',
  age: '26',
  isEligibleToDrink: false
};

const { actions, reducer } = createSlice({
  name: sliceKey,
  initialState,
  reducers: {
    setName(state, { payload }) {
      state.name = payload;
    },
    setAge(state, { payload }) {
      state.age = payload;
    },
    setDrinkingEligibilityBasedOnAge(state) {
      state.isEligibleToDrink = selectLocalAge(state) >= 18;
    }
  },
  extraReducers: {
    [clearData]: (state) => {
      state.isEligibleToDrink = null;
      state.age = null;
      state.name = null;
    }
  }
});

function selectLocalName(state) {
  return state.name;
}
function selectLocalAge(state) {
  return state.age;
}
function selectLocalIsEligibleToDrink(state) {
  return state.isEligibleToDrink;
}

export default reducer;
export const { setName, setAge, setDrinkingEligibilityBasedOnAge } = actions;

export const { selectName, selectAge, selectIsEligibleToDrink } = createGlobalStateSelector(
  {
    selectName: selectLocalName,
    selectAge: selectLocalAge,
    selectIsEligibleToDrink: selectLocalIsEligibleToDrink
  },
  sliceKey
);

// educationalDetailsSlice.js

import { createSlice } from '@reduxjs/toolkit';
import createGlobalStateSelector from 'create-global-state-selector';
import { clearData } from './commonActions';

export const sliceKey = 'educationalDetails';
const initialState = {
  qualification: 'engineering'
};

const { actions, reducer } = createSlice({
  name: sliceKey,
  initialState,
  reducers: {
    setQualification(state, { payload }) {
      state.qualification = payload;
    }
  },
  extraReducers: {
    [clearData]: (state) => {
      state.qualification = null;
    }
  }
});

function selectLocalQualification(state) {
  return state.qualification;
}

export default reducer;
export const { setQualification } = actions;

export const { selectQualification } = createGlobalStateSelector(
  { selectQualification: selectLocalQualification },
  sliceKey
);

// commonActions.js

import { createAction } from '@reduxjs/toolkit';

export const clearData = createAction('detail/clear');

// commonSelectors.js

import { createSelector } from '@reduxjs/toolkit';
import { selectAge } from './personalDetailsSlice';
import { selectQualification } from './educationalDetailsSlice';

export const selectIsEligibleToWork = createSelector(
  selectAge,
  selectQualification,
  (age, qualification) => age >= 18 && qualification === 'engineering'
);

// thunks.js

import { fetchQualification } from './api';
import { selectName } from './personalDetailsSlice';
import { setQualification } from './educationalDetailsSlice';
import { clearData } from './commonActions';

export const getQualification = () => (dispatch, getState) => {
  const state = getState();
  const name = selectName(state);
  fetchQualification(name)
    .then(({ qualification }) => dispatch(setQualification(qualification)))
    .catch(() => dispatch(clearData()));
};

// store.js

import { createStore, combineReducers } from 'redux';
import personalDetailsReducer, { sliceKey as personalDetailsSliceKey } from './personalDetailsSlice';
import educationalDetailsReducer, { sliceKey as educationalDetailsSliceKey } from './educationalDetailsSlice';

const reducer = combineReducers({
  [personalDetailsSliceKey]: personalDetailsReducer, // 'personalDetails'
  [educationalDetailsSliceKey]: educationalDetailsReducer // 'educationalDetails'
});
const store = createStore(reducer);
export default store;

The above example can scale well for large-scale projects. Pro-tip: Never import store directly anywhere except the root component file which passes store data to its child components with Provider. Use redux middlewares (like redux-thunk) when you need to access store data outside your component.

If you are worried about implementing the import rules in a large size project, check out the Dependency cruiser library.

Do share with us your way of creating a modular and scalable redux structure in the comments section.

If you're confused about anything related to this topic or have any questions, you can comment below or reach out to me on Twitter @code_ashish. 🙂