Every so often when a new technology comes up we believe that it should replace the old one, with which I don’t agree completely.

For example, we have Apollo GraphQL which handles your async calls, state caching … so it looks like it is all you need. Well, what if you are a bit old school and you want your async away from your components, and your state-controlled by you, lets see how we can do that with apollo and redux.

Since I want the GraphQL client to be in charge just of my API calls, I will make it…

If you have node application, and it is about to, or is already in shipped to production, chances are you need to run it in cluster mode!

First of all, let’s go through the basic needs of our project, imagine that you have some API written in NestJS and you wanna run it in cluster mode as you should. And also for sake of this conversation lets assume that as every project so far, your project needs to be able to expand, by adding new microservices from your mono-repo code base.

First, we should create ConfigService as it will be…

If you are not living under a glass, and you have seen a React code in the past two years you have seen the React Context in action. Context is such a powerful feature, and for all of us that are doing React for a while, it meant salvation from prop drilling and removal of container class components, and dare I say Redux as well 😱.

However, it’s quite easy to get lost in Context provider hell, because before you blink your code will start to look like this:

<ContextProvider1>  <ContextProvider2>    <ContextProvider3>      <ContextProvider4>        ....      </ContextProvider4>    </ContextProvider3>  </ContextProvider2></ContextProvider1>

This is…

Due to the complexity of the ABAC model, and the “oversimplification” of the RBAC model there is a need to build hierarchies between RBAC and ABAC models. This approach is called EBAC (Entity Based Access Control)

EBAC is a simple subset of ABAC and doesn’t bring to the table any new concepts rather than a simplified model of ABAC.

Under the EBAC model, we will first use the RBAC engine in order to quickly determine the user’s first access layer and then we will operate the ABAC model in order to evaluate the requested entity.

Dynamic Roles

  • The role is just a…

There are a couple of use cases for using canvas to optimize, change, resize or just show the user uploads. Since the React is our library of choice, let’s dive into how we can create a simple but powerful hook to achieve expected app behavior.


Let us imagine that we are building some sort of web app with React and it happens that our app has a user profile section where users can add cover/profile photos in order to personalize their profiles. …


Infinite scroll is one of those really nice to have and really hard to make features, here I will show you hao you can do just that in two lines of code with a little helper library called react-use-infinite-scroll.


So assume that we already have a React project set up, let’s install this library

npm install react-use-infinite-scroll


yarn add react-use-infinite-scroll

If we say that we have some home page that needs to load more entities, we will usually track the position of the scrollbar on the screen, we will have to worry about subscribing/unsubscribing on window events and…

By now we have all heard to so many times that components should not handle async actions as Http requests, that that should be abstracted from them in some higher layer. If you are using Redux you will probably use thunks or sagas, if you are using Context you will do the actual Http calls in that context provider layer.


That is all clear, I guess, for reference, I wrote about handling state with async actions and http calls with context while implementing redux like architecture before

Now let’s focus on the subject of this post, and that is how…

image used from https://www.robinwieruch.de/static/dbb6b6b256b589aad81a3ed374590f4d/2b1a3/banner.jpg

We have a simple task here, we need to implement state management with React Context, handle some async calls, do so while sticking to redux concepts, and at the end combine everything in a single-store provider.

Let’s say that for example, we have a web app, that has some user authentication, some website configuration and of course error handling.

Overall architecture and principles

We want to achieve that components are free of async calls, that state is changed through reducers and that we combine providers so code is cleaner and easier to reason about.

Folder structure


This is often not the case, let’s say in 95% of the time your frontend app will have only one GraphQL endpoint that resolves data. But I have recently come across a project where our frontend app needed to talk to two different GraphQL servers. So we came up with a solution that worked in our case.

This is actually fairly simple, what we need to do is to create an abstraction around ApolloProvider with our own provider, and control the actual client that is being used inside of that context.

Let’s create a file ApolloContext.tsx

import React, { createContext…

So we always hear how important is to keep your app modular and separate the concerns throw modules so your frontend can be properly layered. With that in mind, probably the most important thing is how you handle state management and asynchronicity in your app.

Redux Sagas is one way to go, throughout my career I’ve mostly worked with thunks (redux-thunk) but I can definitely see advantages of sagas and cleaner separation of concerns. So let’s create a small app and focus on the store layer, and see how can we get a scalable modular store with ease.

Folder structure…

Radovan Stevanovic

Highly motivated, dedicated developer. I’m also a functional programming enthusiast and that is something that I’m exploring in the last couple of years.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store