Skip to main content

The ever changing client requirements and a need for a plug and play system.

Recently I was the backend dev for a client-side project, which was quite challenging based on the use case it has. Now I cannot go and ramble it over here, due to obvious reasons.
But what I can tell you is how I fixed a particular problem that I faced while working on the project.

See every new project will come with a new set of challenges, in my case it was the case of third-party integrations. Now integrating a third party application is not a challenge, but in my case, it turns out to be challenging one because of the way it needs to be integrated.
The issue with my case was that I have multiple third-party integrations I want to use based on the user's choice. This choice is stored in the database when a user gets registered in the application. So for example, if User A wants to use ONE and User B for the same use case wants to use TWO. Now we have a single dashboard for both User A and User B, and the same set of functionalities even if one use ONE or the other TWO. So how do we cope up with that?

So to solve this issue of different integration for different users, and a possibility of other third-party integration in the future. So we seek the help of the good old idea of dependency injection, to manage the integrations on a separate area altogether while managing the business logic separately.


Please note that the real integrations are not named "ONE" and "TWO" (yes I follow good coding principles and give meaningful names).

Here, as you can see the corresponding integrations will call the respective files and call their respective business logic behind them.

Now one other question remains. How do we call the corresponding integration?



Above is a screenshot of the "fetchProject" method. The "_fetchService" method calls the "User" collection and fetch the corresponding integration of a particular User and return it within the variable called "service".
And then the corresponding method of "fetchProject" will be called which is in alignment with the user's integration service.

So for example, if User A is the one requesting the "fetchProject" method, then his integration of ONE will be called since the "service" variable now will be "ONE".
Now later if another set of integrations are also introduced all I need to do is write the set of business logic for that particular integration and all is done.

How cool is that ?!

Hope you gained something from this small snippet of mine, happy coding!!!

Comments

Popular posts from this blog

AI. Will it replace us or...?

AI!! The buzzword is too hot in the market nowadays. Do you have a technical product or an idea? If it doesn't have AI in it, then chances are it's not going to be sold like hot cakes. That is how things have changed lately. It is no wonder why me and my colleagues at Gelato want to see what AI can do in a niche department like customer support and service. And that is exactly what we did. For a company like Gelato, which is in the market for production-on-demand, there are a lot of customer questions you need to answer. It can be related to products, queries about shipping and pricing, and so on and so forth. Thus, our customer support team is always happy to help with these recurring questions. Let's take one example. A customer asked us, "Do you ship to Norway?" Now that is an easy question to answer if you have the knowledge written somewhere where you could refer to it and say, "Yes! As a matter of fact, we do." Following the same thread, the next q...

Replication and transactional guarantee in MongoDB

One of the projects I am working on is using MongoDB as the database solution. And the project makes use of the nifty ORM mongoose to do the heavy lifting of data orchestration. It was high time I implemented transactions to the equation but because of a time crunch I was not able to start with one and the situation merely demands it at times. But come with an architectural change and the way the project was heading it was high time I implemented transactions by using MongoDB. According to MongoDB documentation, transactions are used when the situation requires, “atomicity of reads and writes to multiple documents (in single or multiple collections)”. MongoDB supports multi-document transactions. With distributed transactions, transactions can be used across multiple operations, collections, databases, documents, and shards. Now the piece of code to implement the same was pretty straightforward. // For a replica set, include the replica set name and a seedlist of the members in the URI...

My experience with the Golden signals

In June 2022, I embarked on a quest for a new job opportunity. Fortunately, this endeavor began just before the global job market experienced a significant downturn. I must admit, I faced my fair share of rejections during this period, but I also had an epiphany. It became evident that there was so much more to learn and understand in the world of technology. Coming from a small service-based company, I had encountered limitations in terms of how much I could learn on the job. However, during interviews and conversations with senior developers, I gained valuable insights into the architectural and technical decisions made by teams in various companies. One such company that left a lasting impression on me was Delivery Hero. Their technical blog posts provided a wealth of information, especially for someone like me, transitioning from a smaller company where projects had minimal daily active users compared to the scale of Delivery Hero. One particular blog post that caught my attention ...