DEV Community: Decentro

Minimize Downtimes in Financial Services with RDS Blue Green Deployment

Decentro — Tue, 27 Jun 2023 03:10:57 +0000

It was just another deployment cycle.

A housekeeping exercise.

A planned two-hour maintenance window turned into a six-hour nightmare as the update script took more time than expected.

Unfavorable? Yes.

Unacceptable? Not as much.

If you’ve spent a decent amount of time in software development, chances are you have encountered similar downtimes at least once in your career. As much as it’s a nightmare for the entire engineering team, its impact on the business is also pretty significant.

To put things into perspective, according to Information Technology Intelligence Consulting (ITIC), 40% of enterprises said a single hour of downtime could cost between $1 million and over $5 million – exclusive of any legal fees, fines, or penalties. In a Gartner survey, 98% of companies stated the cost of IT downtime ranged from $100,000 to $540,000 per hour.

Now imagine the same in the context of working in the Fintech domain.

No enterprise has ever wanted downtime of their services, especially in the financial services industry. When your business use case relies on trust and funds, downtime’s impact snowballs into skewed customer experience, loss of trust, and brand value in the market.

So what is the way around it?

Downtime happens. It’s critical to acknowledge and accept. But there are steps companies can take to reduce and mitigate the risk. They can build resilient infrastructure and implement disaster recovery and redundancy across their infrastructure.

In the case of Decentro, it was a simple yet effective RDS Blue/Green Deployment.

What is RDS Blue/Green Deployment

Downtime can be a significant headache if you’re running a production database. Not only does it disrupt business operations, but it can also result in lost revenue, frustrated customers, and a tarnished reputation. Many organizations are turning to RDS Blue/Green deployments to minimize the impact of downtime. And so have we.

The general idea is that when you have an RDS instance, the tool will take the production DB environment (known as “Blue”) and create a read-replica (clone) of it in a new staging environment (also known as “Green”).

This clone is kept in sync with production by replicating all data updates. You can change the staging environment, like upgrading server types or applying security patches. When satisfied with the changes, you can switch the servers over in minutes, with minimal downtime and complete confidence that no data will be lost.

As it’s a managed service by AWS, you essentially are delegating the internal housekeeping to the AWS team, taking a significant load off your shoulders.

So if we had to make a checklist of its benefits, we would have

1. Managed service: You don’t have to worry about maintenance, which eventually saves you time.

2. Minimized downtime: By having two separate environments, you can switch between them as needed, minimizing the rest that your customers experience.

3. Ease of deployment: With RDS Blue/Green deployments, you can deploy changes to the green environment and test them thoroughly before making them live. This helps to ensure that your changes are working as expected and reduces the risk of downtime.

4. Reduction of risk: With RDS Blue/Green deployments, a fully functional production environment is always available. If anything goes wrong during the deployment, you can switch back to the blue background, ensuring your customers are not impacted.

5. Increased confidence: By testing changes in a separate environment before making them live, you can improve your faith in the changes and reduce the risk of bugs or other issues cropping up in production.

Now that we have sold its benefits to you allow us to walk you through its seamless set-up!

Setting up RDS Blue-Green Deployment

We will use the AWS console to set up RDS Blue-Green Deployment.

Step 1: Log in to the AWS console, go to the RDS section, and click on the database for which you want to configure RDS Blue Green.

Step 2: You will see Create Blue/Green Deployment under Actions. Let’s open that.

Step 3: A form opens, and we must fill in a few basic details about our RDS Blue green setup.

Blue/Green Deployment identifier – Identifier for our setup. Let’s put “blue-green-setup.”

Engine version for your Green database – We can upgrade the engine version. Major upgrades can introduce changes that are not compatible with existing applications. A minor upgrade includes only changes that are backward compatible with existing applications. To reduce complexity, select the same version in our central RDS instance.

Parameter Group – A parameter group is a collection of engine configuration values you set for your RDS database instance. We will be using the same parameter group of our central RDS instance.

Step 4: It will take some time to provision the Green setup for our database. We have our blue-green setup ready. AWS will configure that replica of the db setup.

Applying changes

As our blue-green setup is ready, we can connect to our green database and apply the necessary changes. The URL for the green database can be found in the RDS console. The username and password will remain the same as the blue (current database).

The Switchover

A switchover refers to redirecting the traffic from the blue environment (current production environment) to the green environment (updated environment) once the green environment is thoroughly tested and validated. The switchover is pivotal when the green environment becomes the new live production environment.

When you are ready for the switchover, start your downtime, as the database won’t be available during the switchover.

RDS gives you the option to configure the timeout for your switchover. The timeout setting in switchover refers to the duration for switching traffic from the blue to the green environment. It defines the maximum time the deployment process can take before timing out. If the switchover doesn’t complete within the configured time, the process will be aborted, and the original RDS instance will continue to serve traffic.

Now for the things that need a little more attention,

Things that should be kept in mind while performing the switchover.

1. Replication lag: Make sure there is no replication lag when switching over. This will increase the chances of the switchover not timing out.

2. Validation: Once the traffic is redirected, monitoring the green environment is crucial to ensure it functions correctly and handles the incoming traffic as expected. This validation phase helps confirm that the deployment was successful and that the green environment operates as intended.

3. Rollback option: It’s essential to have a rollback option available during the switchover procesIfase any unexpected issues arise with the green environment, you can quickly revert the traffic to the blue environment to minimize the impact on users.

4. Post-switchover activities: After the switchover, it’s essential to conduct post-deployment activities, such as monitoring the system’s performance, analyzing logs, and performing any necessary cleanup tasks.

The following salient features also help you navigate the switchover seamlessly.

RDS Blue/Green deployment does not mean Zero downtime deployment. As mentioned earlier, during the switchover, the database connection in your application will fail.
Thoroughly test the DB instances in the green environment before switching over.
When using a blue/green deployment to implement schema changes, make only replication-compatible changes.
For example, you can add new columns at the end of a table, create indexes, or drop indexes without disrupting replication from the blue deployment to the green deployment. However, schema changes, such as renaming columns or re-naming tables, break binary log replication to the green deployment. Click here for more details.
Please ensure your setup supports RDS Blue/Green deployment. In our setup, we were using RDS proxy, and RDS Blue/Green doesn’t support it, so we have to remove the RDS proxy from our setup to use this feature. You can find detailed limitations here.

Conclusion

To conclude, RDS Blue/Green Deployment is a powerful strategy for reducing database downtime during updates. Organizations can minimize the customer impact and ensure uninterrupted service by maintaining two identical environments and carefully testing changes in the green environment before switching traffic.

With its minimal downtime approach, easy rollback capability, and simplified deployment process, RDS Blue/Green Deployment offers a reliable and efficient solution for managing database updates in production environments.

With that, we have come to the end of another immersive experience of the production world.

If you wish to read more such blogs, please check our website’s [Blogs] section. We have previously covered topics like JsPDF, Locust, and much more.

Jest: The Fast and Effective Framework for Unit Testing

Decentro — Mon, 23 Jan 2023 06:38:11 +0000

Unit testing is a crucial part of the software development process. It allows developers to verify that individual code units are working as expected.

This blog post will discuss how to perform unit testing in a ReactJS application using the Jest testing framework.

Some critical aspects of Unit testing for ReactJS:

The chances of code failure are less. It prevents unexpected errors even at the time of production
It allows developers to focus on their current task rather than worrying about the previous task.
It reduces the need for manual testing.

Well, now we know why we need unit testing, let’s look at what the market offers in terms of great durability, stability, and performance.

Enzyme:
Enzyme is a JavaScript Testing utility for React that makes it easier to assert, manipulate, and traverse your React Components’ output.

Enzyme, created by Airbnb, adds some great utility methods for rendering a component (or multiple components), finding elements, and interacting with elements.

It must be installed in addition to tools already bundled with CRA.

Enzyme has many more traversal and interactive methods (including first and setProps).

Cypress:
Cypress is a free and open-source automation tool, MIT-licensed and written in JavaScript. As of this writing, it has over 19.3K Stars on Github and is used by organizations such as NASA and DHL. With the help of Cypress End to End test, integration and unit tests are easy to write and debug.

Cypress is built and optimized as a tool for local development. Cypress also offers a visual interface to indicate what all tests and which all commands are running, passed, or failed. It allows us to test highly interactive applications and carry out different tests, such as

Manipulating the DOM
Asserting that some element is available or present on the screen,
Reading or writing data into/from fields
Submitting forms, and
Redirection to a different page without actually making direct modifications to your code.
In fact, after using Cypress for some time, you may be tempted to do all of your development within it since it provides a platform to debug and maintain your code easily and quickly.

Mocha
Mocha is a feature-rich JavaScript test framework running on node.js and the browser, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting while mapping uncaught exceptions to the correct test cases.

Jest
And finally, the crowd favorite, Jest.

Unit testing in ReactJS is typically done using a combination of the React Test Renderer and the Jest testing framework. The React Test Renderer library allows developers to render React components and perform assertions on their output.

Now, Wait a minute, is it that Fast ?!

Well yes!

Like a 500-horsepower car, Jest has out-of-the-box features that can be integrated immediately. It is as simple as creating a file with the suffix “.spec.js” file.

Let’s break down exactly how the Jest framework has an advantage over the other tools that we have in the market for unit testing React Js applications. Real speed is determined by Performance, Snapshot Testing, and finally, Test Isolation and sandboxing.

Here is how Jest is a superior tool in the given three parameter

Performance: (Engine)
Jest is made for scale to support both vast and little projects. It’ll always be fast because it runs tests in parallel. It’s simply not helpful to attend for a code base to be built before tests are often run and not scalable for more significant projects.

Jest can execute the tests and provide feedback on whether they passed or failed. If any tests fail, Jest will provide detailed information about the failure, including the expected and actual values, so you can troubleshoot and fix the issue.

In a nut-shell unit, testing is an integral part of the software development process, and By writing and running tests using Jest, you can ensure that your ReactJS components are working as expected, helping to prevent bugs and other issues in your application

Now that we know what’s under this powerful Framework jest, let’s look into how we can use it and read the user’s manual.

Snapshot Testing (Brakes)
Yep take a snap, and voila, your test cases are done.

As oversimplified, the statement made above looks that is the basic idea behind it.

Jest supports snapshot testing, which can be handy for preventing accidental UI regressions when doing React development. These tests record snapshots of rendered component structure and compare them to future renderings. Your test fails when they don’t match, indicating that something has changed. You can quickly tell Jest to update the snapshot if this change is expected (e.g., for a newly added feature).

A similar approach can be taken when testing your React components. Instead of rendering the graphical UI, which would require building the entire app, you can use a test renderer to quickly generate a serializable value for your React tree

Best practices to make snapshots easier
Best practices to make snapshots easier
There are a few basic practices that make creating snapshots easier

Treat snapshots as code
Tests should be deterministic
Use descriptive snapshot names

Test isolation and sandboxing: (Transmission)
No two tests will ever conflict with one another, nor will there ever be any global or module local state that’s getting to cause trouble.

So let’s say we have three components in the react tree, and we are creating two to three test cases for each element that may create conflict, but in jest, as we have test isolation and also every test file is sandboxed, the execution of these test cases are uniquely handled, and the interference of two cases is not likely to happen

How to drive Jest Fast! (Users manual)
To write unit tests in Jest, you will need to have a basic understanding of the following concepts:

Test case: A test case is a single scenario you want to test. For example, you might have a test case that checks if a user can log in to your application.
Test suite: A test suite is a collection of test cases grouped because they test the same functionality or feature.
Assertion: An assertion is a statement that checks whether the output of a particular piece of code matches the expected result. Jest provides many built-in assertions that you can use to make assertions about the values of your code.
Mocking: Mocking replaces a function or module with a fake implementation used to control the code’s behavior under test. This can be useful when testing how a code reacts to different inputs or scenarios. To start unit testing in Jest, you first need to install the jest npm package. You can do this by running the following command:

npm install --save-dev jest

Once Jest is installed, you can create a test file for your React component by adding a .test.js file in the same directory as your component. For example, if your component is called MyComponent, you might create a test file called MyComponent.test.js.

To write a test case, you will need to use the test function provided by Jest. This function takes two arguments: a string that describes the test case and a callback function that contains the code for the test case.

For example, the following code shows a simple test case that checks if a user can log in to your application:

test('User can login', () => {
  // Code for the test case goes here
});

Inside the callback function, you can use Jest’s built-in assertions to make assertions about the values of your code. For example, the following code shows how you might assert that a user’s name is displayed after they have logged in:

test('User can login', () => {
  // Code for logging in the user goes here

  // Assert that the user's name is displayed
  expect(user.name).toBe('Decentro');
});

In this example, the expected function is used to assert the value of the user.name property. The toBe function is used to check if the value of user.name is equal to the string ‘Decentro’.

If the value of user.name is not equal to this string, the test case will fail. You can use Jest’s mocking capabilities to control the behavior of your code under test. For example, the following code shows how you might mock a function called login that is used for logging a user in

test('User can login', () => {
  // Mock the login function
  const login = jest.fn();

  // Code for logging in the user goes here

  // Assert that the login function was called
  expect(login).toHaveBeenCalled();
});

There are functions that allow you to test different aspects of the component, such as whether it renders correctly or whether it responds to user input as expected. For example, the following code shows how to test a simple ReactJS component that displays a message:

import React from 'react';
import { shallow } from 'enzyme';
import MyComponent from './MyComponent';

describe('MyComponent', () => {
  it('renders the correct message', () => {
    const wrapper = shallow(<MyComponent />);
    const message = wrapper.find('.message');
    expect(message.text()).toBe('Hello, Decentro!');
  });
});

In this example, we are using Jest’s description and it functions to organize our tests. The describe function groups together related tests, while it function specifies a single test. In this case, the test checks that the component renders the correct message by using Jest expect a function to compare the actual message with the expected message.

Once you have written your tests, you can run them using the following command:

npm test

This test imports the MyComponent component and renders the Shallow method from the enzyme library. The shallow method allows us to render the component without rendering any of its children. This is useful for isolating the component and ensuring that our test only covers its behavior and not the behavior of any child components.

Once the component has been rendered, we can use the expected function from Jest to make assertions about its output. In this case, we are using the

toMatchSnapshot

method that will take a snapshot of the component’s output and save it to a file. This snapshot can be used as a reference for future tests, allowing us to verify that the component’s output has not changed unexpectedly.

To run your tests, you can use the

npm test

command. This will execute all of the tests in your project and report on their results.

You can also use the

--watch

flag to automatically run your tests whenever a file in your project is changed.

In addition to the shallow method, the enzyme library provides several other practical methods for rendering and testing React components. For example, the mount method will render the component and all of its children, allowing you to test the component in a more realistic environment. On the other hand, the render method will return an HTML string representation of the component, which can be helpful for testing components that generate HTML output.

Testing a login component(Test Drive!)

After reading the user’s manual and understanding the basics let’s put this knowledge to use.

The scenario? To test a login component that has two input fields and two buttons.

Test cases

To check whether we have two buttons
To check whether the input type of the password field is the password
To check whether the email verification takes place Let’s get coding

To check whether we have two buttons submit and reset

import {render,screen} from "@testing-library/react"
import {Login,validate} from "Login"
describe("Login component test",async()⇒{
test( 'render two buttons on the login page ',()⇒{
render(<Login/>)
const buttons = await screen.findAllByRole('button')
expect(buttons).toHaveLength(2)
})

To check whether the input type of the password field is the password

test('password input should be of type password ',async()⇒{
render(<Login/>)
const password = screen.getByPlaceholderText("password")
expect(password).toHaveAttribute('type','password')
})

To check whether the email verification takes place

test('email validation function to be tested ',async()⇒{
render(<Login/>)
const testmail = 'decentro.com'
expect(validate(testmail).not.toBe(true))
})

Let’s look at the code and see the results for the test cases

In the above image, you can see that the test suite of testing the login component has passed and the test cases have also passed

Let’s say we enter the right email address in the test email variable as decentro@gmail.com. This scenario should fail the test case as we have set it not to be true.

There you have it! A pretty smooth test drive.

How Jest helped Decentro cross the finish line.
Decentro’s ethos lies in building and making use of reusable components. These components have a lot of use cases that require them to have a different set of inputs, which render the desired outputs.

The best way to test them is to make use of the toMatchSnapshot method which is provided by Jest. The ability to test out the simulated outputs for the specific components for the particular use case furnishes the following advantages

It gives us a good overview of the component interaction
UX flows can be designed in a specific way when we know the use cases of the components
Development can be accelerated and fed into the feature rollout funnel. The ability to use cases and the components accordingly allows the Decentro team to fulfill client requirements in an accelerated yet precise timeline.

Conclusion (Finish Line!)

In conclusion, unit testing is an integral part of the software development process, and ReactJS and Jest provide a powerful combination of tools for performing unit tests. By using the React Test Renderer and the enzyme library, you can quickly render and test your React components and use the Jest testing framework to make assertions about their output.

It is a match made in speed heaven.

With that, we have reached the end of an immersive read elucidating the world of unit testing. The developers at Decentro, incessantly work on getting their subject matter expertise to you via these technical write-ups. Feel free to check out our workaround, Data Tables, and Next, and leave suggestions of what you wish to read next.

In case you wish to connect with us, Click Here.

The Pocket Guide To API Request Validation You Wish You Had Earlier

Decentro — Fri, 07 Jan 2022 06:27:25 +0000

Have you ever integrated with an internal/external service? Ever wondered how the service is returning different kinds of errors & issues so quickly? Or about the process that is happening behind the scenes to facilitate this?

Yes, you are right. We are talking about the validations!

Just imagine what a chaotic world it would be if there are no validations or prechecks in a service.

There would be just a successful response if you are very lucky, or there would be an arbitrary error, mostly internal server error or request timeout, which leaves you with no clue of what went wrong.

Thankfully someone has thought through this issue and found a way out of it.

What is API Request Validation?

API request validation is the process of checking the alignment of client requests with the laid-out API specifications.

It’s a very crucial process in the request lifecycle. An API request needs to be validated for correctness before processing further to avoid unexpected/wrong errors and slow/invalid responses.

Why do We Need API Request Validation?

In the context of REST APIs, a request body is deliberately designed based on the required parameters for the processes happening behind the scenes. If there is a miss in any mandatory parameter(s), the process will fail.

Now there is nothing wrong with the process failing. However, if we talk about scale, there is a cost involved both for the client and the server; just think of the cost as request latency and server resources. All that is because of a miss in the request body, which can be handled in a much better way at the beginning of the request.

In the coming sections of this blog, we will be exploring different ways to handle cases like these and how we at Decentro are dealing with them, then we will have a quick implementation of the same.

Our core application is on Flask; hence, the illustrations will be similar. Flask is a web framework for python. It is a small and easy to extend microframework without the native support of ORM.

API INIT – Initial part of the flow, where we check the credits, headers, auth, etc.
API Process INIT – The core flow is based on the business logic.

What are We Trying to Do Here?

Consider the following request body, we will be using the same throughout the blog post.

We want to validate the request body and transform in some cases, based on whether all the required parameters are received and all the values obtained for the parameters are of acceptable types and ranges. Consider the following validation rules for this request body.

name

It should be a json object
first and last are required
middle is optional
All nested values are string

date_of_birth

Should be a string, matching YYYY-MM-DD format.

gender

Should be a string.
Should match any of the following [M, F, O]
Should transform the value to upper case before checking the match.

address

It should be a json object
flat_number, locality, and pincode are required
landmark is optional
pincode should be of six-digit string
need to extract area, city, and state from pincode and add them to this object

social_presence

this is a list of object
the list can be empty
if an object is present then it should be mandatory to have site_name and site_url.

Now let’s have a look at some of the ways we can handle the verification and validation of the above request packet given the domain rules.

Different Ways to Implement API Request Validation

The Noob Way

You can write a method for this API to validate the request body and raise an exception if something goes wrong. For instance,

This type of implementation will work, but there are a few issues with it

This will not be easy to manage and maintain, and there will be more chances of missing a parameter validation.
The complexity of handling this will increase when we add more parameters to the request body, adding 2nd order nesting.
Think of a scenario where we need to add/update a parameter in one of the nested blocks in further API iterations. Then?

Is there any better way to do this job?

Yes, of course!

The Champ Way!

We can use serializers.

Serializers are built to convert data from one form to another; For instance, it can convert a queryset into a python dict or create a data class from a JSON object. We can leverage this functionality and add validations between the flow.
In serializers, we define a schema with validation rules and transformation methods. Then, we need to load the data in the serializer, and if there is an issue with the data, the serializer will raise an exception or return the transformed data.

We can even add a pre-serialization method and post-serialization to pre-process and post-process the data, which can be executed in the respective sequence.

These methods are also beneficial. Consider the case of gender parameter; it is a categorical variable and case insensitive, so we need to upper-case this before further validation check.

We will be using this approach to validate the request body in this blog post. And we at Decentro are following a very similar approach to deal with validations and transformation.

Here Comes Marshmallow!

Marshmallow is the object serialization library that we will be using. We will be resolving the nested blocks first.

Resolving Name Block

Resolving the Address

Resolving the Social Presence, Each Object

Now, since we have built subschemas for all the nested blocks, let’s build the schema for the parent block.

Finally, we just need to load the request data and handle the exception raised from the schema, if any, and handle it appropriately.

And, that’s all we have to do in order to validate the request body.

Just to complete things, this is how you will be seeing the errors, if there is a miss in the request body.

What’s Next?

This was a brief introduction to the serializer-based validation using marshmallow. There is a lot more to explore in this, many more cases to be handled, listing a few of them which are in my thoughts are following.

Conditional validation in the nested fields, think of the scenario where one parameter in a block has a direct relationship with a parameter in another block or consider parent block parameter relationship with the child block parameter.
Advanced pre-processing and transformation of the request body, optimizing the request body, consider it as taking a few parameters from the client and transforming them at the server end, like what we have done for the address field.
Reusing existing serializers in other APIs, think of name and address as nested fields in other APIs. We can even extend this without changing the base serializer; these are classes only. So let’s suppose you want to have a salutation field in the name block in one of the APIs. You can extend the name serializer and add salutation and related validations; the rest are already there. How amazing! Right?

We can use these API serializers to generate dynamic documentation of your API. These serializers hold everything you need for the API documentation, parameters, accepted values, accepted types, accepted ranges, error messages.
What would you like us to take up in this series? Let us know in the comments; we’re all ears! 😇

Final Words

So till now, I guess I was able to illustrate my point of using serializers for the request validation and how effective the whole process is in order to maintain and extend the API validations.

You can find the fully functional code of the example mentioned in this blog on Decentro’s GitHub page.

References

Marshmallow

Originally published at: https://decentro.tech/blog/pocket-guide-to-api-request-validation/

We DON’T Need NGINX Anymore. Hello, KONG API Gateway!

Decentro — Wed, 08 Dec 2021 07:29:35 +0000

API development has moved from a single stack monolithic architecture to the majestic microservices architecture.

This requires a gateway server that should manage redirection, proxying and security over multiple requests. This means our old faithful NGINX has become a little outdated. (Let’s not even talk about Apache HTTP Server here!)

Even if you run a monolithic application, The API Gateway is still a good pick. Apart from proxying, there are many other benefits.

The API Gateways should give us the developer the ability to:

Scale: As you grow, so should your application
Provide security: Applying SSL is just scratching the surface
Have a GUI: This would make life 10 times easier
Be Intuitive: Should be self explanatory

_“But what does it do?”
_
You may ask. Good question.

Suppose we have an API stack with multiple APIs spanning over a bunch of microservices. Let’s look at the diagram:

Here you can see the API Gateway being the lord and the savior for the application instances running behind it. It proxies the requests to the requisite application instance (as a reverse proxy). Now your endpoint can be independent of the microservice it caters to.

So if you want to have multiple endpoints (e.g., /docs, /documents, /documentation) connected to the same application, you can. Just reverse proxy it, baby!

Farewell, NGINX!
Here at Decentro, we used to work with NGINX as our reverse proxy server. But we grew out of it. We had to log in to our instance to reload NGINX via CLI and had to learn to manage configurations when using NGINX. It didn’t have consumer-level handling for API management.

We needed something extra. After logging our heads together for quick brainstorming and crossing the Is’ & Ts’ on the Pros/Cons list, we found the one!

Dhumm… Dhumm… Dhumm…

Did you feel it?

Here comes KONG!

Source: Github

As is evident from the image above, Kong provides a lot of features out of the box. No recompilation. No command-line configuration. No extra cost.

Kong comes with its own RESTful Admin APIs. It is built on top of OpenResty (an extension of NGINX) and LuaJIT. These provide access to all kinds of configurations that can be made available. We have done another addition on top of it by adding the Konga dashboard to manage Kong via a GUI.

Kong API Gateway Structure
The API structure in Kong is pretty simple:

Services – The logical representation of your microservice or monolithic application
Routes – The logical representation of endpoints that are accessible within the service.
Consumers – The clients that are going to be using the services.
Plugins – This is where the magic happens. Plugins can be applied to either of the above entities mentioned. So let’s talk about an example.

I have a microservice that takes care of sending emails. I will declare a Service with the name “emails” (Pretty innovative.. I know). This will contain the details of the application server, which it will reverse proxy for.

Now let’s make Routes for this service. So we have two kinds of emails to be sent.

Transactional – Sent by the API
Marketing – Sent by the marketing department to let the clients know about the new features of our awesome product.

Now, we will put an API Key authentication plugin on top of the “emails” service. This will ensure that no bad actors try to get access to our APIs.

Rate-limit Plugins

We will also add a rate-limit plugin (to limit the number of API hits) on the different routes.

Transactional (600 per minute) – Since this API is triggered by other flows, we need a high rate limit.
Marketing (1 per minute) – Since this is manually triggered, we don’t need to go beyond 1 per minute

In order to further enhance our security, we will allow only certain IP addresses to be able to access our transactional email route as it will be triggered only by our internal systems, and we know the IP address range for our internal systems.

We will set it open to the world (Potentially insecure) for the marketing emails as the marketing peeps should be able to access it from any cafe that they wish to work out of.

Now we want only authorized consumers to access the APIs, so we will set up a consumer and add the API authentication credentials for them to use.

Now our email service is ready to serve consumers. We can integrate it into our code and give it to the marketing peeps for them to use it manually.

Wrapping Things Up

As you can see, using Kong as an API Gateway is simple and takes the hassle of managing APIs. Kong provides many other features like upstreams, certificate management, request and response transformation, serverless code execution, logging, and CORS, which are very helpful when you wish to develop APIs quickly.

I rest my case!

NGINX and other reverse proxy servers are simply blown out of the water by the ease of configurability and sheer dexterity that KONG provides out of the box.

If you have the same love as we do for Engineering, we encourage you to check out the careers page . Be a part of our passionate journey towards making stellar products!

Until we see you next time with another tech story!

Originally published at: https://decentro.tech/blog/why-we-moved-from-nginx-to-kong-api-gateway/

Fragmented Databases: Access Easily With Utility APIs

Decentro — Thu, 08 Jul 2021 10:16:09 +0000

Earlier this year, we'd released a set of FREE utility APIs, which help individual developers, startups, and companies alike by being a one-stop-shop to check KYC IDs’ formats and search for an IFSC!

How about we dive deep and know about them?

Why Utility APIs?

For most start-ups today, a significant part of the product roadmap is driven by their collective knowledge, and the remaining learning occurs from the feedback given by early customers. However, to implement that knowledge, teams need access to information, sometimes at their fingertips, to make informed actions that impact the revenue positively.

At Decentro, we realized the importance of access to information when we started and realized its importance- not just for us but for any budding fintech.

Thus, we’ve taken the first step in our efforts to consolidate & share the knowledge that will go a long way in helping emerging fintech gather information without incurring any additional costs. We developed these no-cost utilities based on our interaction with our initial customers.

From January 5th, 2021, these common utility APIs will be available for everyone to access.
In phase 1, anyone can use these APIs to validate the format of a given ID (currently supported – Aadhar/PAN/GSTIN) or check the branch details for an IFSC of any bank in the country.

From our experience, we understand that consumers can easily make mistakes while entering their ID numbers or, in some cases, even enter junk data. This becomes a major blocker in ID verification as valuable time & money is spent to perform the task again. These utilities verify whether the entered ID is authentic by checking its format as prescribed by the Government of India.

In addition, IFSC search is also an important check not just from a business point of view but also from consumers’. Many a time, money transfer requests fail due to an incorrect IFSC. Having a preliminary check done for the same before initiating a money transfer eliminates any delay or loss.

More features are slated to join this set pretty soon. So, keep an eye peeled for our newsletters!

To know about the free utility APIs, here's the documentation. We hope our fellow fintech enthusiasts will find tremendous use from these. Do check them out and kindly shoot feedback & love in our general direction. It will help us make a better, more holistic product that you cannot stop raving about and recommending to your peers & colleagues.

As someone rightly said, “Knowledge grows only when you share it,” we hope to keep sharing our knowledge with you and make Fintech great again!

The dangers posed by the pandemic have not subsided yet. Do consider all the precautions suggested by the authorities and the medical experts to enjoy a safe onward journey to the future where these troubling times become just a passing topic of discussion.

We hope you remain safe, your family in the pink of their health, and your goals for the next year, super achievable.

From all of us here at Decentro. Thanks for reading!
Cheers!

Previously published on Utility APIs: Enabling Easy Access To Fragmented Databases