DEV Community: Sabbir Siddiqui

Which for-loop is the fastest in JavaScript?

Sabbir Siddiqui — Sun, 25 Dec 2022 09:35:46 +0000

I was curious to see how fast loops perform in JS after seeing a similar post for C#, so I wrote a quick script to check.

For this test, I tried four different for-loop syntaxes, where each loop was simply incrementing a counter variable 10^8 times, and each loop ran five times to get an average time. Here are the results:

for-of: 1616.2 milliseconds
forEach: 1488.6 milliseconds
for loop (with index): 282.4 milliseconds
for loop (with cached array length): 278.8 milliseconds

Interestingly, for very small arrays (< 10^3 elements) it does not really make a difference. However, for 10^3 to 10^6 size, the result is a bit surprising.

Results for 1000 iterations:



{
  "forOf": 0.2,
  "forLoop": 0,
  "forEach": 0,
  "forLoopCached": 0
}

Results for 100,000 iterations:



{
  "forOf": 5.4,
  "forLoop": 2,
  "forEach": 0.4,
  "forLoopCached": 0.6
}

So when it comes to <10^6 arrays, the classic forEach seems to be just fine.

I personally used to use the for-of (slowest) syntax because it seemed like the easiest one, well now we know which one I'm going to start using!

Here is the script: https://github.com/siddiqus/useful-scripts/blob/master/for-loop-benchmark.js

P.S. Happy Holidays everyone!

20 Common NodeJS tools / packages for your backend production app

Sabbir Siddiqui — Thu, 08 Dec 2022 11:23:28 +0000

Let's cut to the chase, if you're planning on building a production level backend NodeJS application, chances are you'll need all or most of these packages:

Express or NestJS for backend API framework
Node-convict and dotenv for configuration management
Joi for API request validations or data validations
Sequelize ORM for MySQL/Postgres databases, or Mongoose for MongoDb
RabbitMQ for publishing/subscribing to message queues, or Kafka for streams and message brokers
Ioredis / node-redis for caching with Redis
Axios for handling third party API integrations. Need a good command of json API calls and response handling
Bull queue or Faktory for delayed/background jobs
Socket.io for real time peer to peer connections
Jest/Supertest for unit testing or integration testing and coverage reports
Winston / Morgan for logging (use morgan-body if you want to log request / response, useful for debugging in staging and dev environments)
Passport.js for authentication, or any custom authentication service using cookie-parser, jsonwebtoken or oath
Node-cron for cron jobs
Multer for handling file uploads
Swagger for OpenAPI documentation (swagger-ui-express or @nest/swagger)
Lodash for utilities
Luxon for date time manipulation, especially when dealing with timezones
ESLint + TSLint + Prettier for static code analysis and formatting
Husky for Git hooks
Docker for containerisation (Not NodeJS specific, but it helps)

Feel free to comment anything that you also work with on a daily basis!

softwareengineering #nodejs #typescript #javascript #softwaredevelopment #bestpractices #npm #npmtools #nodetools

Sequelite - a lean TypeScript ORM for NodeJS

Sabbir Siddiqui — Thu, 08 Dec 2022 11:20:10 +0000

I have worked with NodeJS + Sequelize for more than 6 years now, and I can conclude two things:

Sequelize is awesome!
Model abstraction in a complex system has diminishing returns

The more complex our systems got, the more we tended to go towards a convention of

> Basic CRUD with ORM Models, complex stuff with raw queries

So, with that convention and my cumulative experience, I released yet another ORM for NodeJS - Sequelite

Yes, the name is a little on the nose.

Just released v1.0.0 of my own #opensource ORM in NodeJS! Link is in the comments.

Sequelite is a lightweight ORM built on top of Sequelize with proper Typescript support, no annotations, no heavy model classes, and easy setup.

The main motivations behind creating this package were having

An easy setup
Full type support for CRUD operations based on a declared TS interface
Common raw queries wrapped around Sequelize and exposing them as generic functions, e.g. bulkUpdate, etc.
Flexible configuration and DB connection through Sequelize
Out of the box support for MySQL and Postgres, but segregated by separate base models considering their query differences

Working with Sequelize in the last few years on several projects, I found the model definitions and setup boilerplate to be a bit clunky, although that is the price to pay for an otherwise awesome ORM.

This project will give you the ability to do basic CRUD queries with full type support, which is convenient. However, in more complex systems and queries, I found raw queries are superior to any ORM wrapper interface since it gives you full control of what you are actually querying, so the client also exposes interfaces for raw select queries.

Already thinking of some improvements, like

declaring an identity column (or columns) within a model class, so internally it will know which ID to use for upsert, or for index related queries.
strengthening the where clause interface

Feedback is welcome!

Checkout the github source here - https://github.com/siddiqus/sequelite

npm - https://www.npmjs.com/package/@siddiqus/sequelite

What sets candidates apart?

Sabbir Siddiqui — Sun, 03 Jul 2022 18:32:41 +0000

"What sets a candidate apart?" - this is a question I often get from junior engineers who are going through interviews and recruiting process.

Is it Leetcode solving? StackOverflow points or GitHub stars? Those may be some kind of indicator, but beyond the technologies, here are my other key criteria when comes to assessing a candidate

👉 problem solving thought process - I don't mean solving Leetcode problems, I mean how the candidate approaches practical ones related to a product or existing system

👉 humility vs arrogance - how they react to negative feedback or criticism, and how they portray their own knowledge and experience

👉 big picture thinking - do they think of edge cases, external impact, do they ask meaningful follow up questions

👉 curiosity vs apathy - do they try to understand the reasons behind why they do the things they do, or why certain practices or patterns are in place, or do they just go through the motions without asking questions

👉 improvement mindset - whether they think about how to better themselves, their code, and their knowledge

👉 clarity of communication - how clearly they can explain concepts, how well they can explain their own thought process

👉 collaborative nature - when I give problems I try to phrase it as something we are trying to solve together, not me against them. how they generally react to those situations, and handle back and forth's.

These can be a huge boost for the candidate's profile and can complement their tech skills, or even overcome shortcomings thereof.

How to deal with Technical Debt

Sabbir Siddiqui — Sat, 02 Jul 2022 17:36:04 +0000

As per Wikipedia,

In software development, technical debt (also known as design debt[1] or code debt) is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

As per my opinion and / or experience, there are two kinds of technical debt - intentional and unintentional ones.

The unintentional ones stem from technical decisions that may not take the big picture in mind, where the engineer is unaware of the debt they are creating for the future. These can happen due to lack of context, lack of experience, or lack of proper impact analysis, or you know just plain human error (we are all human). Processes like pair programming, diligent PR reviews, or allocating more time on task design may be a way to mitigate these kind of issues.

The intentional ones are from deliberate engineering decisions. A team or someone decided to implement something they knew they would need to fix or refactor in the future, but decided to go ahead with it anyway due to time / deadline / business constraints. Meaning, if there is a debt, it's there for a reason, and has been put on the back-burner along with the others.

No system is perfect, and in any growing product / software, especially startups, the latter tends to happen for shorter time-to-market. "For now we will do X to solve the problem, but in the future we should do it Y to make it more generic and scalable".

Now, how to manage this debt? Like any other debt, tech debt can and should be paid in instalments. It's important for tech leads and engineering managers to be aware of tech debt, have a prioritized backlog of the same, and try to incrementally get rid of the debt over time by introducing reworks / refactors / implementations within the Sprint or regular development process as a part of normal tasks. The prioritization would happen based on a combination of business need vs which is more likely to degrade system health in the near future.

It is also the responsibility of technical leadership to collaborate with and persuade product managers / business teams on considering the additional time towards tech debt before delivering a requested feature.

For example, let's say there are some new requirements regarding SMS notifications, and the current notification system needs an overhaul. A plea to product managers would be "I know we are trying to achieve ABC with this feature to facilitate growth, however we need some time to refactor our notification system. This will allow us to implement any new notification requirements easily, plus make the notification system more scalable. If we don't do this now, with the growing number of notifications, it will degrade our performance by X hence affecting growth."

At the end of the day, both tech and business parties should work together, and be aware of the importance of technical debt, how it can affect the current system, and hence the current business. The idea is we are all working together towards a common goal.

Git Rebase got you conflicted? Here's what you can do.

Sabbir Siddiqui — Tue, 28 Jun 2022 18:49:52 +0000

Let's say you're working with feature branches. I know Trunk based development is the way to go, but hear me out. If your team is using git flow, this will help you get out of a sticky situation.

If two people are collaborating on the same feature branch, and one person rebases the branch with main/master and pushes to origin, then the other person will face a load of conflicts when pulling the branch from origin (because of the new rebased commits). Here's how you can refresh your local branch completely:

𝐠𝐢𝐭 𝐟𝐞𝐭𝐜𝐡 𝐨𝐫𝐢𝐠𝐢𝐧 𝐭𝐡𝐞-𝐛𝐫𝐚𝐧𝐜𝐡 (fetch branch from origin)
𝐠𝐢𝐭 𝐫𝐞𝐬𝐞𝐭 --𝐡𝐚𝐫𝐝 𝐨𝐫𝐢𝐠𝐢𝐧/𝐭𝐡𝐞-𝐛𝐫𝐚𝐧𝐜𝐡 (reset local branch and point to origin)

This will update your local branch with the one in the remote. However, if you already made some changes in your own local branch and the other teammate has rebased it, here's what you can do

Scenario A -> If you already committed the changes, in that case you can just do this:

𝐠𝐢𝐭 𝐟𝐞𝐭𝐜𝐡 𝐨𝐫𝐢𝐠𝐢𝐧 𝐭𝐡𝐞-𝐛𝐫𝐚𝐧𝐜𝐡 (fetch remote branch)
𝐠𝐢𝐭 𝐫𝐞𝐛𝐚𝐬𝐞 𝐨𝐫𝐢𝐠𝐢𝐧/𝐭𝐡𝐞-𝐛𝐫𝐚𝐧𝐜𝐡 (rebase your local with the remote)

Scenario B -> If you were just working on some changes but you did not commit them yet, you can simply

𝐠𝐢𝐭 𝐬𝐭𝐚𝐬𝐡 (To stash your local changes)
follow the initial 2 steps to refresh the local branch
𝐠𝐢𝐭 𝐬𝐭𝐚𝐬𝐡 𝐩𝐨𝐩 (to get your local changes back)
continue your work!

gitflow #trunkbaseddevelopment #softwareengineering #softwaredevelopment #git #github #versioncontrol

How to better estimate your tasks

Sabbir Siddiqui — Fri, 17 Jun 2022 18:14:18 +0000

First of all, an estimate is just that - an estimate. Most of the time engineers struggle with estimation because of maybe some unforeseen side effects, or because of underestimating the task itself, or a plethora of other reasons.

Secondly, as an engineer you have to keep in mind that your primary goal is not to estimate the task itself, but to get a clear idea of what you will be implementing. The more details you know about what you are going to implement, the better an idea you will have about how much time it might take. Here are some steps that will help you achieve that:

Ensure a central list of requirements, e.g. acceptance criteria is in place. if you can identify any edge cases within the requirements immediately, add them to the list. Solid requirements will help you build a solid feature. It is also up to the engineer to analyse the requirements and add to them, because the product manager might not come up with all the various cases that need to be handled. This will also help QA and engineers devise the test cases for unit tests, manual tests and integration testing.
Once you have all your requirements in one place, start thinking about the data flow. What is the trigger point? What is the initial source of data? What kind of data will you need to store, and where (in db or cache)? How will the client eventually get access to this data? What kind of processing do you want to do to this data so that it meets the given requirements? Thinking about the data flow from start to finish, and writing down the steps will help you arrive at the overall design.
Schema changes - now that you know what the data flow will be, you can use that to write down the schema level changes e.g DDL statements, any new or alter table commands, adding indexes, partitions, etc.
API Design - from the data flow, and schema, you will get to know what APIs need to be implemented or updated. Think step by step what APIs you need to achieve your requirements. Are you creating new resources? updating existing ones? or fetching the new data to show somewhere?
Integration points - think about where will this new feature be integrated, whether your APIs will be consumed within the same module, or by another backend, or by a frontend UI. Think about the challenges the integrations might face, for example how will authentication/authorization work, does it need pagination, does your module need to be idempotent, what will happen if any external system makes concurrent requests with the same data, etc.
Impact analysis - how will your change impact the rest of the system? Chances are you are changing an existing system (or extending it). What will be the side effects? Do you need to emit any events to let other modules know what you are doing? Will your changes break any other module flows? Here analysing the existing system is important to understand how your changes will fit in, and how you can ensure continuity to the existing flows.
Task breakdown - Finally, now you should have a complete idea of what to do in order to implement this feature. If you did step 2 right, then this should be easier now. Using all of the analysis from above, start listing your todos / subtasks one by one in order in terms of what is needed to be done.
Finally cross check your todos/subtasks to make sure all the acceptance criteria are being met. If you find any further edge cases like "x flow should not break", or "y system should be notified", add those to your acceptance criteria. By the end of this exercise, you will have a well-documented process for how to implement the feature.

Now that you will have a good idea about what needs to be done, and will have a granular level breakdown of the tasks/subtasks, you can ballpark each subtask (should each be within 1-4 hours), then add up the hours to get a final estimate. Don't forget to account some time for writing unit tests / integration tests, and then also some buffer for some unforeseen circumstances (it happens). By now you will have a more reasonable estimate of how long the whole thing should take.

Key words are "more reasonable". However, a fair warning - you still might not be able to complete the task in the time you thought. It happens to everyone, welcome to software development :)

Git commands I find very useful and why

Sabbir Siddiqui — Sat, 28 Aug 2021 04:51:11 +0000

git checkout [some-branch] -- [some/file/path.ts]
This will check out (and stage) that specific file from that specific branch into your local branch. This is great for working in teams where changes are being made in the same codebase in parallel. Suppose in another branch your teammate wrote a util that you can also use, or if you yourself want to get the latest version of a file to remove avoid unnecessary merge conflicts. An alternative to these scenarios is:
git cherry-pick [commit-hash]
Get code from a specific commit into your own branch. You can use the --no-commit flag to stage the changes before committing them to your branch (in which case the history/hash will be changed). Useful if you want to copy over an exact commit from another branch to your own. Again, useful working in teams. Also useful if you yourself committed changes to the wrong branch, and you want to bring those changes over to the proper branch. After which you want to do:
git reset [--hard] HEAD~[n]
Let's say you committed directly in master branch because you forgot to checkout of your own branch. Or you pulled into a local branch that was rebased in remote and now your history is all messed up. Lots of different scenarios, one easy fix. The --hard reset will get rid of all changes permanently, so use this with extreme caution. Not using the --hard option will just remove the commit. For merge commits n=1 will work, but once the commits pile on it might get more difficult to use. Nevertheless, very useful.
git commit --amend
For when you want to make a small change to your previous commit but don't want to create a new commit. If you haven't pushed the branch then it works fine, if already pushed then you'll need to --force it, since you're effectively rewriting history :)

NodeJS + ESLint + Prettier - Simplest setup ever

Sabbir Siddiqui — Mon, 23 Aug 2021 20:01:43 +0000

Don't expect any fancy images in this post, let's get down to business. I'm just gonna hope you're using yarn because you should be.

yarn add eslint --dev (from here)
yarn run eslint --init (also from above link)
Follow whatever options your heart desires in the eslint setup prompts.
Get rid of the package-lock.json cause likely the eslint cli used npm to install something. tsk. Remove that file, and just run yarn to make things right again.
yarn add prettier eslint-config-prettier eslint-plugin-prettier @typescript-eslint/parser -D (from here)
Your repo should have an .eslintrc.js file by now that looks like this:

module.exports = {
  env: {
    browser: true,
    es2021: true,
    'jest/globals': true,
    node: true,
  },
  extends: ['airbnb-base', 'eslint:recommended', 'prettier'],
  parser: '@typescript-eslint/parser',
  parserOptions: {
    ecmaVersion: 12,
    sourceType: 'module',
  },
  plugins: ['@typescript-eslint', 'jest', 'prettier'],
  rules: {
    semi: ['error', 'always'],
    quotes: ['error', 'single'],
    'import/extensions': [
      'error',
      'ignorePackages',
      {
        js: 'never',
        jsx: 'never',
        ts: 'never',
        tsx: 'never',
      },
    ],
    'import/no-dynamic-require': 0,
    'global-require': 0,
    'import/prefer-default-export': 0,
    'no-underscore-dangle': 0,
    'no-await-in-loop': 0,
    'no-restricted-syntax': 0,
    'no-return-await': 0,
    'no-console': 0,
    'prettier/prettier': [
      'error',
      {
        trailingComma: 'es5',
        singleQuote: true,
        printWidth: 80,
        tabWidth: 2,
        endOfLine: 'lf',
        arrowParens: 'always',
      },
    ],
  },
};

And an .eslintignore that looks like this: (if not create one)

/node_modules
/reports

Add a command in your package.json to run lint fixes

{
...
  "scripts": {
    ...
    "lintfix": "eslint src --fix --cache",
    ...
  },
}

If you want to use husky for pre-commit hooks, be my guest. You can check the site for instructions but here they are anyway: a. yarn add husky --save-dev b. npx husky install c. npx husky add .husky/pre-commit "yarn eslint && git add -A" d. git add -A e. git commit -m "finally configured eslint and prettier and husky without any 🐄 💩

Writing fully testable React components using the 'Helper Pattern'

Sabbir Siddiqui — Sat, 14 Dec 2019 06:34:40 +0000

I am still learning about React Hooks and Redux (I know, I need to catch up quick), and I know writing basic React classes is pretty much dated at this point, but I wanted to share a little tidbit that I found to be useful over the years.

The problem

Consider a CRUD application for products, where a user can view a list of products (paginated), and create, modify, or delete a product. The component class would look something like this

class ProductsPage extends React.Component {
    constructor(props) {
        super(props);
        this.state = {}; // state may include product list, product form variables, loadingStatus, etc.
        this.productService = new ProductService(); // some product service to manage products

        this.onAddButtonClicked = this.onAddButtonClicked.bind(this);
        this.onDeleteButtonClicked = this.onDeleteButtonClicked.bind(this);
        this.onUpdateButtonClicked = this.onUpdateButtonClicked.bind(this);
    }

    componentDidMount() { } // some code to fetch data for list view

    onAddButtonClicked() { }
    onDeleteButtonClicked() { }
    onUpdateButtonClicked() { }

    _renderPageHeaderWithCreateButton() { }
    _renderProductTable() { }
    _renderProductModal() { }
    _renderLoadingModal() { }
    _renderErrorAlert() { }

    render() {
        return (
            <React.Fragment>
                {this.state.error && this._renderErrorAlert()}
                {this._renderPageHeaderWithCreateButton()}
                {this._renderProductTable()}
                {this._renderProductModal()}
                {this._renderLoadingModal()}
            </React.Fragment>
        )
    }
}

This is usually how I like to organize my React classes. Apart from the usual functions for button clicks, I also like to split my render function into smaller chunks if it starts to get bigger, and then later decide to split this into separate components as needed. A user might see a simple list but there's a lot going on in this component.

After mounting, the class needs to set a 'loading' state, and then fetch data from a server using the 'ProductService', and if the call is successful, set the data to a 'productList' state variable, or otherwise handle errors. Then if a user wants to create or modify a product, you have to manage the state for a modal along with form variables. All in all, we end up with a lot of state variables and button actions to manage.

Apart from splitting this up into smaller components and having to pass down state and actions, could we make this one component less bulky and the state easier to manage? Also think about unit testing. Jest provides the tools to test React components, but do we really need those to test our logic? I tried using the Logic/View pattern before where there would be one React component for the view and one for managing all the logic e.g. 'ProductsPage' and 'ProductsPageView'. That seemed great at first, but the logic was still contained in a React component that didn't necessarily need to be. So I thought about flipping this pattern on it's head. Could I have a view class where I delegate managing all the logic to another class, but one that wasn't a React component? Yes I could!

The solution: The Helper Pattern

The idea was simple - each React component would have a Helper class that would manage all the logic for that component.

class ProductsPage extends React.Component {
    constructor(props) {
        super(props);

        this.helper = new ProductsPageHelper(this); // pay attention
        this.state = {}; // some state vars

        this.onAddButtonClicked = this.onAddButtonClicked.bind(this);
        this.onDeleteButtonClicked = this.onDeleteButtonClicked.bind(this);
        this.onUpdateButtonClicked = this.onUpdateButtonClicked.bind(this);
    }

    async onAddButtonClicked() {
        this.setState({
            loading: true
        });
        const newState = this.helper.addProduct();
        this.setState(newState);
    }

    // ... other stuff
}

If you notice, the helper class is initialized with 'this'. Why would we do this? (pun intended) We would have access to all of the React component's props and state variables and can manage the logic from there. Take a look at the new 'onAddButtonClicked' method, where most of the logic is taken away in the helper. Here is an example of the helper.

class ProductsPageHelper {
    constructor(component) {
        this.component = component; // our React component
        this.productService = new ProductService(); // this is now removed from the React class
    }

    async addProduct() {
        // some logic to add a product using the product service
        // returns new state e.g. new product list or errors
    }

    // ... other functions
}

Okay, great. We have some separation of logic from the React component, and most of the logic is now in a 'helper' class which is a regular Javascript class. Could we do better? The answer is yes! Why manage the state in two different places where you could manage the state in one? Finally after a few more iterations, this is what I came up with.

class ProductsPage extends React.Component {
    constructor(props) {
        super(props);

        this.productsPageHelper = new ProductsPageHelper(this);
        this.state = this.productsPageHelper.getInitialState(); // init state variables

        this.onAddButtonClicked = this.onAddButtonClicked.bind(this);
        this.onDeleteButtonClicked = this.onDeleteButtonClicked.bind(this);
        this.onUpdateButtonClicked = this.onUpdateButtonClicked.bind(this);
    }

    componentDidMount() {
        this.helper.getProducts(); // state fully managed here
    }

    onAddButtonClicked() {
        this.helper.addProduct(); // state fully managed here
    }

    onDeleteButtonClicked(product) {
        this.helper.deleteProduct(product); // state fully managed here
    }

    onUpdateButtonClicked(product) { 
        this.helper.updateProduct(product); // state fully managed here
    }

    // ...render functions
}

Notice:

I initialized the state from the helper method 'getInitialState', so the developer working on the helper class knows what state variables the component has without actually looking at the view component.
All the state is now fully managed from the helper class

You could reduce the React component code even further by getting rid of the event functions and the 'bind' code, by using the arrow function syntax in JSX. For example:

// for a product list view
{
    this.state.productList.map((product) => {
        return (
            <Row>
                {/* {some code for product row} */}
                <button onClick={() => this.helper.deleteProduct(product)}>
                    Delete
                </button>
            </Row>
        )
    });
}

Here is the helper class now:

class ProductsPageHelper {
    constructor(component) {
        this.component = component; // our React component

        this.productService = new ProductService(); // this is now removed from the React class
    }

    _updateState(state){
        this.component.setState(state);
    }

    getInitialState() {
        return {
            loading: false,
            productList: [],
            error: false,
            errorMessage: "",
            productFormVars: {},
            productModalIsShown: false
        }
    }

    _handleGetProductsSuccess(productList){
        this._updateState({
            loading: false,
            error: false,
            productList
        });
    }

    _handleGetProductsError(error) {
        // some error handling
        this._updateState({
            loading: false,
            error: true,
            errorMessage: "some error message"
        })
    }

    async getProducts() {
        this.component.setState({
            loading: true
        });

        try {
            const productList = await this.productService.getProducts();
            this._handleGetProductsSuccess(productList);
        } catch (error) {
            this._handleGetProductsError(error);
        }
    }

    // ... other functions
}

Woohoo! As you can see, the state can be accessed/managed just by using this.component.state and this.component.setState. Now since the helper is just any other Javascript class, we can easily get full test coverage on this. For example, to test the logic for 'componentDidMount':

describe("ProductsPageHelperTest", () => {
    it("Should get products and set state properly", async () => {
        const mockComponent = {
            setState: jest.fn()
        };

        const helper = new ProductsPageHelper(mockComponent);
        const mockProductList = [1, 2, 3];
        helper.productService = {
            getProducts: jest.fn().mockResolvedValue(mockProductList)
        }

        await helper.getProducts();

        expect(mockComponent.setState).toHaveBeenCalledWith({
            loading: true
        });
        expect(helper.productService.getProducts).toHaveBeenCalled();
        expect(mockComponent.setState).toHaveBeenCalledWith({
            loading: false,
            error: false,
            productList: mockProductList
        });
    });
});

We can just pass a 'mockComponent' object with an initial state and the 'setState' stubbed function to fully test the state change behavior. Testing the React component also became easier since all the logic was driven by the Helper class, you could write tests by stubbing the helper methods and checking to see if those were called when appropriate.

Outcomes

What was the benefit from doing all of this?

Leaner component classes - The previously bulky React classes were now much leaner and easier to go through at a glance.
Code consistency - The pattern helped to make development easier for everyone on the team as all the components' states were managed in the same way, so team members knew what to expect.
Improved productivity and collaboration - You could have multiple team members working in parallel on the same component where one person would work on the view while another person could work on the logic. A backend engineer with some Javascript experience could work on the helper class, as long as the methods / contracts were defined. This made the team more cross functional.
Code coverage - Before using this pattern, team members avoided writing unit tests since using Enzyme was painful when it came to logic contained within the React components. Code coverage went from 30% to over 80% after using the Helper pattern, since now all of the logic could be tested.

Now it's time to leave this behind and move forward into the world of Redux and Hooks! :)

3 things about Infinity in JavaScript you probably already knew, but didn't know why

Sabbir Siddiqui — Mon, 02 Dec 2019 12:50:01 +0000

1. The largest denominator

If you run the standard 1/0 in Javascript, this yields the Infinity type. But what about very small denominators? If you keep making the denominator smaller, the result will obviously keep getting bigger. But when will it reach Infinity?

console.log(1/0);
console.log(1/0.1);
console.log(1/0.000000000000001);
console.log(1/0.0000000000000000000000000000000000000000001);
console.log(1/0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000001);
console.log(1/0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001);
console.log(1/0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001);
console.log(1/0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001);
console.log(1/0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001);
console.log(1/0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001);
console.log(1/0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001);

Output:

Infinity
10
999999999999999.9
9.999999999999999e+42
1e+85
1.0000000000000001e+304
1e+305
1e+306
1.0000000000000001e+307
1e+308
Infinity

So as we reach the 309th decimal place, we get Infinity. This might not be a novel revelation, because as we all may know (actually TIL) that 1.797693134862315E+308 is the limit of a floating point number. This is also a roundabout way of asking When does a number turn into Infinity in Javascript?. As you would expect:

console.log(1e306); // 1e+306
console.log(1e307); // 1e+307
console.log(1e308); // 1e+308
console.log(1e309); // Infinity

2. Parsing Infinity

Sometimes we don't always get what we want when we parse stuff. Infinity at the least is no different. Observe:

parseInt(Infinity); // NaN
parseFloat(Infinity); // Infinity

Tada! Okay but the first line can be explained pretty easily. parseInt is expecting a string type parameter, and if the argument cannot be converted into a ninteger, it returns NaN. So this makes sense since Infinity is not within Javascript's integer range.

However, as we've seen in the previous point, Infinity is actually represented by the float type in Javascript. Hence the parseFloat result makes sense!

Also, a bonus:

//
parseInt("Infinity", 10); // -> NaN
// ...
parseInt("Infinity", 18); // -> NaN...
parseInt("Infinity", 19); // -> 18
// ...
parseInt("Infinity", 23); // -> 18...
parseInt("Infinity", 24); // -> 151176378
// ...
parseInt("Infinity", 29); // -> 385849803
parseInt("Infinity", 30); // -> 13693557269
// ...
parseInt("Infinity", 34); // -> 28872273981
parseInt("Infinity", 35); // -> 1201203301724
parseInt("Infinity", 36); // -> 1461559270678...
parseInt("Infinity", 37); // -> NaN

I got that from this fun repo

3. Infinity is not a number, right?

Okay so without getting too much into Number Theory (I'm not even bragging, I have no idea about Number Theory), let's see how Javascript deals with Infinity as a type.

typeof(Infinity) // "number"

Okay, so it's a number. But is it?

1 + 1 // 2
Infinity + Infinity // Infinity
5 - 5 // 0
Infinity - Infinity // NaN

Wait, what? Okay speaking in Javascript terms, when you write Infinity - Infinity, it is evaluated as this:

Infinity + (-Infinity) // NaN

Since Infinity and -Infinity are different 'objects' in Javascript, this would yield a NaN. So wait, it's not a number? or is it? I actually don't know this one.

Thanks for reading!

Quest for a practical NodeJS API Framework

Sabbir Siddiqui — Sun, 24 Nov 2019 09:04:18 +0000

While working on REST APIs with Express JS / Node, I came across some common challenges:

I had to configure Express the same way every time using some common stuff - body parser, cors, validators etc.
It's a free-for-all in terms of how you organize your code when it comes to Express, best practices in terms of coding and code organization had to be implemented manually every time.
There is built in central error handling in Express, but it's not declarative, and you'd want a more elegant solution as well as have more control over errors on specific endpoints.
Documenting APIs seemed like a chore since you needed to setup swagger, and maintain a separate swagger JSON file which is kind of removed from your actual code.

Working with Express for the last 3 years, I started thinking about how to use ES6 classes and OOP to implement REST controllers, about common patterns and ways I can modularize the APIs I develop. Each REST endpoint has a URL, an HTTP method, and a function it carries out. Any REST controller would be for handling requests for a given endpoint e.g. "/products", with different functions for handling the different HTTP methods. So I began my quest, and my first iteration of a would-be framework was to have a BaseController that each REST controller would extend. Here is a snippet of such a REST controller.

Let’s say the ProductController manages actions regarding products of an e-commerce site. A productService is injected through the constructor, and a method is implemented for getting a single product based on its ID.

Pay attention to two parts of the code:

The API validation is done at the beginning of the method, where it returns out of the method if there are errors. This was done using express-validator.
Whatever error is thrown inside the method is caught and sent to the next middleware using the "next" function, to avoid the general "internal server error" response. We will need to remember these two points later in the article.

You may notice that the controller has a property “router”, which is actually an Express router, and the “route_” prefix convention is used to register any endpoint for that router, both of which are implemented code in the BaseController. So now if you wanted to have an API for products, you could do this:

Recently I’ve been working on a project where we have several microservices using Java Spring Boot, and it was interesting to see Spring Boot has a similar convention as I derived here. Not to brag, but I mean it's common sense, right?

Then I thought, what happens if you bring nested APIs into the mix? Let’s say each product has reviews associated with it, and we need a set of endpoints to go with that. How would we organize our code then? We would have a separate controller for reviews with their CRUD functions, but would the URI “/:id/reviews” be repeated for each one? Here’s what I wanted the ReviewController to look like.

This controller allows endpoints to create a review, get all reviews, and get a single review by ID. How would we define the paths for these endpoints? Then came the idea of “subroutes”, where I implemented a mechanism to define nested routes within a controller itself. Just like the “routes_” prefix convention, I added a ‘subroutes’ method in the BaseController which you would extend in your own controller and return an array of controllers to be registered in the Express router internally. Here is an example of how to use the 'subroutes' method.

Let’s say I declare the “/products” path from where my main app is routed like before, and with this particular example what we have done is declare the following APIs:

GET /products
POST /products/:id/review
GET /products/:id/review
GET /products/:id/review

Okay great, now there was a way to do nested APIs, and we could keep declaring controllers for root level routes or subroutes for nested paths, and the framework handled registering the paths. However, this became kind of a mess, or so I figured after taking a step back. Here is all that was wrong with the ‘framework’ so far (as far as I know):

The code was very verbose
Different controller classes would be tied to each other
You would have to pass around services to controllers that had no business with them specifically
Remember how I mentioned the API validation and error handling? As I wrote out a few more APIs, I realized I would have to repeat those two lines in every single controller method. No can do.

This was a mess. It broke the Single Responsibility Principle, and probably a few others that don't want to think about anymore. It’s not the controller’s job to register other controllers is it? Is it the controller’s job to register any endpoints at all? Why should I write the same lines of code to validate APIs and catch errors every single time? I created a monster! Surely this could be done better, where some things are done centrally, and maybe we could just define the controllers and externally handle the routing somehow?

I showed one of my colleagues what I had so far, and discussed ways to take out the subroutes feature and make that mechanism independent of any controller. That seemed doable, so then I ended up with independent controllers that can be configured into any route or subroute. “At this rate, you’ll be left with a single JSON file for defining this whole damn API” - my colleague joked.

It was funny, but as I laughed I immediately thought, why not? If controllers are made up of independent endpoints, and subroutes are just a collection of those endpoints, could we rearrange the code to make all of this fully modular? Since the ‘subroutes’ is just an array of objects, and the individual HTTP routes can also be defined using objects (path, HTTP method, controller, etc.), aren’t we just looking at a big object that has a bunch of objects inside it, that kind of look like the big object itself?

My quest took a recursive turn to a recursive turn to a recursive turn to a…okay you get the point. I figured let’s just have a recursive object to define the routes and their functions. And henceforth, a few weeks of coding later, Expressive was born!

Expressive is meant to be flexible but opinionated, because sometimes it's good to have opinions about best practices. It's still Express JS under the covers, with the middleware flexibility, and now I had a modular way of defining every endpoint. This is what I ended up with:

I made an 'ExpressApp' class that takes the router and recursively registers the express endpoints with it's respective routes and functions. You will also notice that each endpoint has a 'validator' with it, and now since each 'controller' is it's own endpoint, the validation code is refactored into a single line internally to avoid repetition.

That's all in one file, but you can see how you could put the "rootRouter" object in one file, the "productsRouter" in another file, and the "reviewRouter" in another, and define endpoints in a very declarative way. This way you could define your root level entities in your APIs in one router file, and the rest would follow. The code was still verbose, so a little refactoring and I came up with this:

There, that's much better! I introduced two new exports - 'Route' and 'subroute' for their respective definitions. Since I was just using objects with the same properties, I thought why not encapsulate them and make things easier to implement and more readable.

Last but not least, API documentation was a concern. Now I figured since each endpoint itself is an independent object, and Swagger definitions are the same thing, why not add a 'doc' property where I can just put a Swagger JSON object? The next steps were naturally to integrate Swagger and Swagger UI (in development mode, but also configurable), where by default it would create the basic Swagger templates for each endpoint that you declare in your router endpoints using the path and method, and you could declare the full API documentation using the 'doc' property, like so:

If you run the app, the docs are available on the "/docs" route by default.

Great success! Now we have an API framework with built in documentation! And you can see which routes are present right away, even if the docs aren't specifically declared!

The ExpressApp class also takes a second object parameter for defining middleware and other options. For example:

You can generally configure your whole API with this class. I was happy with the framework so far because it solved my aforementioned problems. It had built-in middleware like body-parser, cors, express-validator, etc. that's common for every REST API I want to build. I could specifically define a centralized error handling middleware function. I could define API endpoints in a declarative way that makes sense, while having a maintainable code structure. And I could document my code with ease.

I recently came across this article that compares various NodeJS Rest API frameworks, and it was amusing to see the evolution of the frameworks from Express, and how it seems my own framework's endpoint declaration is similar to LoopBack's. We have been able to use my own framework at my current place of work in a few different projects and since it's built on top of Express which we had already done, integrating it with CI/CD was no challenge. I was happy to see my coworkers had fun while using the framework, and that I wasn't the only one that found the features useful. The journey has been fun and fulfilling, and I know I can use the Expressive framework for building REST APIs pretty confidently, but as usual I'm always learning new things, and trying to find ways to make this framework better. And so, my quest continues!

Links:

Github: https://github.com/siddiqus/expressive
NPM: https://www.npmjs.com/package/@siddiqus/expressive
Inspiration article: https://strongloop.com/strongblog/compare-express-restify-hapi-loopback/