Forem: Aniket

Structuring our Node.JS application

Aniket — Mon, 01 Jan 2024 08:42:53 +0000

In this segment we will be discussing how node applications can be structured using clean architecture principles, with the help of a Todo application (github repo link).

To make it easier let’s walk through every single layer from the module of the application to acknowledge the core concepts.

We will be using MongoDB, Node, TypeScript, express and inversify to create the application.

What is Inversify?

With the help of inversify you can automate your dependancy injection, instead of every time passing dependancy manually you can create a container and with the help of TS decorators you can easily pass dependancy into your objects, here is example of passing dependancy with and without inversify

with inversify 👇

interface ITodoService {...}  

@injectable()  
class TodoService implements ITodoService {  
  @inject(Types.Todo\_REPOSITORY)  
  private todoRepository: ITodoRepository;  
  ...  
}  

interface ITodoRepository {...}  
@injectable()  
class TodoRepository implements ITodoRepository {  
  @inject(Types.ToDo\_TABLE)  
  private todoTable: TodoAppDataSource<ITodoModel\>;  
  ...  
}  


export interface ITodoController {...}  

@injectable()  
class TodoController implements ITodoController {  
  @inject(Types.Todo\_SERVICE)  
  private todoService: ITodoService;  
  ...  
}  

// using todo controller  
const todoController = dIContainer.get<ITodoController\>(Types.Todo\_CONTROLLER);

without inversify 👇

interface ITodoService {...}  

class TodoService implements ITodoService {  
  constructor(private todoRepository: ITodoRepository) {...}  
  ...  
}  

interface ITodoRepository {...}  

class TodoRepository implements ITodoRepository {  
  constructor(private todoTable: TodoAppDataSource<ITodoModel>) {...}  
  ...  
}  

export interface ITodoController {...}  

class TodoController implements ITodoController {  
  constructor(private todoService: ITodoService) {...}  
  ...  
}  

// using todo controller  
const todoController = new TodoController(new TodoService(new TodoRepository()))

So you can see from both the example how inversify makes our life easy without inversify every time you want to create instance of TodoController you have to manually pass other 2 dependancies which can be a tedious task as your application grows larger, so it is better to use inversify or some other DI automation tool.

Application layers

Diagram representing our app structure

Sample file structure

Our application is divided into 5 layers, here is the detailed explanation of each layer.

Layer 1 (Routes)

Routes is the inner most layer because it is very rare that you will change any route name so it will be the core of application.

export default function TodoRoutes() {  
  const router = express.Router();  
  const todoController = dIContainer.get<ITodoController>(  
    Types.Todo\_CONTROLLER  
  );  

  router  
    .route("/")  
    .post(todoController.createNewTodo)  
    .get(todoController.getAllTodo)  
    .patch(todoController.updateTodo)  
    .delete(todoController.deleteTodo);  

  return router;  
}

Here if you see the only responsibility of this layer is to register routes and redirect incoming request to its respective controller.

Layer 2 (Controller)

Controller is responsible for

Handling incoming request.
Validating request body.
Sending response to client.

In Below example you see our TodoController is dependant on our TodoService and it implements ITodoService interface so that means all classes that implements ITodoService interface is eligible to be injected in TodoController and this can be used for swapping business logic, it just have to implement ITodoService interface and thats it our TodoController doesn’t needs to know anything about TodoService it will simply adapt with the type of object passed in it.

@injectable()
export class TodoController implements ITodoController {  
@inject(Types.Todo_SERVICE)  

private todoService: ITodoService;  

public createNewTodo = async (req: AuthenticatedRequest, res: Response) => {...};



public getAllTodo = async (  
    req: AuthenticatedRequest,  
    res: Response  
): Promise<Response\> => {...};  
public updateTodo = async (req: AuthenticatedRequest, res: Response) => {...};  
  public deleteTodo = async (req: AuthenticatedRequest, res: Response) => {...};
}

Layer 3 (Service)

Service is our 3rd layer which is responsible of handling our business logic, it is dependant on TodoRepository and any class which satisfy the interface ITodoRepository can be injected in TodoService.

Layer 4 (Repository)

At number 4 we have repository which is responsible of any kind of outer world connection whether it calling any external service API or talking to database all such things are handled in this layer.

@injectable()  
class TodoRepository implements ITodoRepository {  
  @inject(Types.ToDo\_TABLE)  
  private todoTable: TodoAppDataSource<ITodoModel\>;  

  private getParameterObj = (  
    content: string,  
    userId: string  
  ): Omit<ITodoModel, "\_id"\> => ({  
    ...  
  });  

  createNewEntry = async (  
    content: string,  
    userId: string  
  ): Promise<ITodoModel\> => { ... };  

  getAllUserTodo = async (userId: string) => { ... };  

  deleteTodo = async (  
    userId: string,   
    todoId: string  
  ): Promise<ITodoModel\> =>{ ... };  

  updateTodoDetails = async (  
    userId: string,  
    todoId: string,  
    todoDetails: Partial<ITodoModel\>  
  ): Promise<ITodoModel\> => { ... };  
}

As you can see from the above code example our todoTable is injected TodoRepository similarly any class satisfying this TodoAppDataSource can be in injected into TodoRepository

Layer 5 (Database)

At number 5 we have kept our data layer, it encapsulates all our DB queries and expose it with the single interface, there is one base class for each type of DB, refer example shown below for mongoDB and postgresql.

Common interface

export interface TodoAppDataSource<T\> {  
  create(data: T): Promise<T\>;  
  findOne(filter: Partial<T\>, project?: Projection): Promise<T\>;  
  findMany(filter: Partial<T\>, project?: Projection): Promise<T\[\]>;  
  findOneAndUpdate(filter: Partial<T\>, updates: Partial<T\>): Promise<T\>;  
}

MongoDB base class

export class MongoDataSource<T> implements TodoAppDataSource<T> {  
  private table: mongoose.Model<T>;  
  constructor(tableName: DB\_TABLES) {  
    this.table = ALL\_TABLES\[tableName\] as mongoose.Model<T>;  
  }  

  public async findOne<T>(  
    selectQuery: Partial<T>,  
    project: Projection = {}  
  ): Promise<T> {  
    return this.table.findOne(selectQuery as FilterQuery<T>, project);  
  }  

  public async create<T>(data: T): Promise<T> {  
    const newRecord = new this.table(data);  
   return newRecord.save() as Promise<T>;  
  }  

  public async findOneAndUpdate<T>(  
    selectQuery: Partial<T>,  
    updates: Partial<T>  
  ): Promise<T> {  
    return this.table.findOneAndUpdate(selectQuery as FilterQuery<T>, updates, {  
      new: true,  
    });  
  }  

  public findMany = async (  
    filter: Partial<T>,  
    project?: Projection  
  ): Promise<Array<T>> => {  
    const result = await this.table.find(filter as FilterQuery<T>, project);  
    return result as unknown as Promise<Array<T>>;  
  };  
}  

export class UserTable extends MongoDataSource<IUserModel\> {  
  constructor() {  
    super(DB\_TABLES.USER);  
  }  
}

Simillar to above mongoDB queries we can create class for any type of database and can inject this layer (layer 5 — DB) to other layer (layer 4 — Repository) by just taking care that it implements single interface for all DB base classes.

I know this can be overwhelming for first time readers but trust me once your code repository is setup it will be very easy for you to scale your code, I request you to please go through code from here start from main.ts.

Conclusion

Research is formalised curiosity, it is poking and prying with a purpose. There is no hard and fast rule of setting up or efficiently structuring the code repository. Hence exploring, investigating and experimenting is the best way suggested.

The concise way of writing the code and structuring is the sole reason of this article. Any suggestions or corrections on this article are welcome. Will be back with another interesting article. Happy coding till then !❤

Building a Modular White Label Frontend with React and TypeScript

Aniket — Mon, 01 Jan 2024 08:19:07 +0000

Hello everyone! In this article, I’ll be discussing how you can design a white-label product for web-based applications using React and TypeScript.

Before we start do you want to learn software development? with personalised classes and mentorship from a seasoned professional. With 4 years of hands-on experience contributing to top products used by industry giants like Amazon, Flipkart, Urban clap, meesho, Dominos, Swiggy etc. I specialize in React, Node.js, TypeScript, and System design. Let’s elevate your career together! Reach out at aniket.chanana@gmail.com or connect on LinkedIn.

A white-label solution refers to a product or service created by one entity and made available for use by others to conduct business. For instance, if you desire an image editing capability on your website without developing a new image editor, you can acquire a white-label solution. By customizing it to match your theme, you can seamlessly integrate and leverage it to enhance your business offerings.

Before we delve deeper, let me highlight some of the key offerings of a white-label solution.

Easily integratable into any web application, enhancing its capabilities effortlessly.
Offers customizable theming options to seamlessly align with the aesthetics of the host website.
Facilitates smooth data flow between the host and child applications, ensuring seamless communication.
Designed for ease of use, requiring minimal or no configuration for any third-party developer.

Considering the points mentioned earlier, let me explain the process in a simple way. We will use a basic example — of a form submission application.

Let’s take a look at the diagram below to get a basic understanding of the flow and application structure.

Also there are various methods to integrate your forms-app UI with the host app UI, like

via javascript modules (npm module or tags).
via iFrame Integration by providing child app src

In this article we will follow the 2nd approach because iframes provide:

Isolation and Security.
Ease of Implementation
Cross-Domain Compatibility

Now Let’s jump into the code & build our white-label forms app — basically, it can plugged it into any app using an iframe and can be customised easily. you can check out the full code here: GitHub.

Here are the must-have things:

Keeping messages Structured: Every message to and from the iframe follows the same structure. So that user cannot mess around — strict validation for all messages. ref: Message validation function
Data Check: Our forms app checks any data that comes into the iframe before getting down to business logic. ref: Message handler hook
Easy Peasy Form Fields: Host apps can tweak form fields with a simple post iframe message. ref: Host app postMessage with field config
Style It Your Way: Our forms app supports some basic theming. So, if you’re integrating our iframe, you can make it look alike to match your app’s theme.

Out of Our Article’s Scope:

Fancy Theming: We will touching on the basics of adding theming.
Complex Logic: We will be skipping the complex logic. This article is all about the system design of a white-label frontend solution.
Forms app dashboard: We won’t be developing any backend support for our forms application in this article; the focus here is purely on the frontend solution.

This article you what’s necessary and how to turn your app into a white-label app. You can grab these ideas and apply in your application.

Froms app UI

Forms app UI and functionalities

After building out config driven (ref: FieldRenderer) UI lets setup our incoming messages handler.

Setting up communication for Forms app & Host app

We will be having a communication between both our applications, e.g we will have a postMessage function for sending messages to other froms-app and useMessageHandler hook handle incoming messages.

As of now both the apps are under us so we can setup communication as per our wish, later when our Forms app is consumed by any 3rd party Host app in that case they can setup postMessage functionality and message handler functionality as per their wish.

This hook will handle all the incoming message + validation to our forms app (iframe)

This hook will be responsible for all the validation of incoming message and our handleIncomingMessage will be invoked as callback post validation from validateMessage, and our handleIncomingMessage function is responsible for routing correct message type to its business logic implementation.

Our business logic will take payload from the message and make our app react accordingly e.g if message contains instructions to CHANGE_THEME our app will invoke appropriate function for this and will change our app theme based on the message received.

Similarly we will be having a postMessage functionality for sending message to other app in.

Now that our communication is setup between both the apps we can start sending message from host-app to forms-app

Function in host-app for sending message to froms-app

message recieved in froms-app from host-app

Now that we our INIT_FORM event is getting data from host-app which includes our theme details, fields config and other configurable parameters.

We will use this data to drive our forms app UI using our message handler function

Implementation for handling incoming messages to forms app

You can refer this file and understand how we are deriving our UI from the config sent via postMessage from our host app.

Now that our forms-app is ready to handle our incoming data from host-app from here we can do what ever we want (i have console logged fieldValues), what you can do is

Send this data back to host-app from post message communication of iframe.
Or Make an API call to froms app server and store data in the dashboard

It totally depends on the Client usecase.

onSubmit method gets invoked on form submission

Conclusion

This is one way to create a user interface based on configuration settings. After working in software engineering for four years, I’ve found it to be a widely used approach in real-world applications because it offers:

Easy Maintenance: It’s simpler to manage and update.
Serve Multiple Clients: You can use a single application to serve multiple clients (like in a SAAS scenario). Everything is controlled through configuration settings.
Effortless Updates: You can deliver updates without requiring users to run npm install or upgrade modules.

I hope you find this article on configuration-driven UI and how to white label any frontend application. Any suggestions or corrections for this article are welcome. Stay tuned for more articles. Happy coding till then !❤