Know a Knolder – Gaurav Kumar Shukla


Image | Posted on by | Leave a comment

GraphQL – The Better REST

Over the past few years, the REST has become a de-facto architecture for the web services, which emphasize to communicate through the textual data. The user is given a URI of the resource and user can perform various operations (GET, POST, DELETE etc) defined on that address, as simple as that. There are several architectural points that reflect upon the ideology of the REST. These points deserve a short review before we move on to the Graphql:

  1. Starting with the Null Style: When a developer starts developing a service or application, she might have an image of what she is going to create but still, she has to start from zero. She can design this application in any way, expand it with no boundaries, having the final interfaces of the application in her mind.
  2. Client-Server: The client and server implementations must be developed and flourished independently. The user interface should not be aware of the implementation of the server side services. Though there should be a mechanism through which client requests the server for some resources and get exactly what she needs. REST does this by providing the URIs.
  3. Stateless: The request from a client to server must contain the necessary information in it so that server can understand what the client needs but it should not depend on any previous information shared between the two. This is a trait inherited from the early web architecture. The modern web can store the session information on server and client sides. The request information can also be stored in the cookies.
  4. Cache: The cache on the user side can improve the network efficiency. In REST, each response can be labeled as cacheable or non-cacheable. The cached response can be used for the response of the request rather than asking the server so we can eliminate the communication between the server and client up to some degree. Though, the shortcoming of this feature is that if a server has some new information for a cached request the client might not get the updated information.
  5. Uniform Interface: Through the uniform interface of the application, the architecture of the application is simplified in a generalized manner. The application of the interface can be altered in many ways but the interface remains intact. With uniform interface, there come four constraints –
    • Resource identification in requests: The resources can be identified in requests, like with URIs in web APIs.
    • Resource manipulation through representations: The client can inform the server to perform some operations on the resource, like GET, POST, DELETE, PUT etc in web-based APIs.
    • Self-descriptive messages: The request can have the information about the message through their formats attached with the request, like MIME Types in web-based APIs.
    • Hypermedia as the engine of application state: The initial URIs given to the client to access the APIs can be used to pass the hyperlinks of more APIs available or newly created. It’s analogous to the HTML pages which include the hyperlinks to more pages available on the server. Hence it makes the APIs dynamic that can evolve over time and client can leverage that.
  6. Layered System: The REST further can be extended to build layers of the communications. There can be layer(s) which can talk to just one layer and not beyond that. It hides the details of the system implementation. In modern scenario, we can see the service locators, load balancers, proxy servers, layers within server farm etc.
  7. Code-On-Demand: The REST allows the client to get the code from the server to execute on its end. It extends our system and delegates some processing from the server to the client. Though, it’s an optional constraint of the REST architecture.

Continue reading

Posted in graph, Scala | Tagged , , , , | Leave a comment

Exploring JEST: Java HTTP REST Client

Elasticsearch is a real-time distributed and open source full-text search and analytics engine. To integrate Elasticsearch to our application, we need to use an API. Elasticsearch gives us two ways, REST APIs, and Native clients. It’s easy to get confused about all the different ways to connect to Elasticsearch and why one of them should be preferred over the other. Available Elasticsearch clients are:

  • Node client
  • Transport Client
  • HTTP client

We will be exploring Java HTTP REST client i.e. JEST. Jest can be used when you need a lightweight client in your application (regarding jar size or memory consumption). Jest provides an implementation of the Elasticsearch REST API. It is a Java HTTP Rest client for ElasticSearch.  It’s API is similar to Elasticsearch API.

Continue reading

Posted in Elasticsearch, knoldus, NoSql, sbt, Scala | Tagged , , , , , | Leave a comment

A Step-by-step guide for setting MultiNode Mesos Cluster with Spark and Hdfs on EC2

Apache Mesos is open source project for managing computer clusters originally developed at the University Of California. It sits between the application layer and operating system to manage the application works efficiently on the large-scale distributed environment.

In this blog, we will see how to setup mesos client and master on ec2 from scratch.

Step1: Launch ec2 with the configuration below :

Ami Server: Ubuntu server (ami-41e0b93b)
Instance Type: Minimum requirement for Mesos is t2.medium.
Network: VPC default
Subnet: Choose any area of us-east
Number Of Instances: Depends On requirement.
Security Group: Make sure all the instance uses the same security group to make configuration easier.
Monitoring: Depends on usage.

Continue reading

Posted in Scala | Leave a comment

Jinja2 Template: The modern design friendly templating engine

Jinja2 is a modern and design friendly templating engine for Python programming language. Jinja2 is a library for Python that is flexible, fast and secure.Jinja can generate any text-based format (HTML, XML, CSV, JSON, etc.). It can generate different documents based on one or more predefined templates. It is also used as a part of the backend of the websites where we need to create many similar pages.



  • Compiles down to the optimal python code just in time
  • Easy to debug
  • Configurable syntax
  • Sandboxed execution
  • Powerful automatic HTML escaping system


Continue reading

Posted in Devops, Scala | Tagged , , , , , | Leave a comment

Java High-Level REST Client – Elasticsearch

Elasticsearch is an open-source, highly scalable full-text search and analytics engine. Using this, you can easily store, search, and analyze a large amount of data in real time. Java REST client is the official client for Elasticsearch which comes in 2 flavors:

  1. Java Low-Level REST client – It allows communicating with an Elasticsearch cluster through HTTP and leaves requests marshalling & responses un-marshalling to users.
  2. Java High-Level REST client – It is based on low-level client and exposes API specific methods, taking care of requests marshalling and responses un-marshalling.

Our focus here will be to learn about High-Level REST client. I hope you are clear with the basics of Elasticsearch if not, you can go through its documentation here.


The Java High-Level REST client works on top of Java Low-Level REST client. It is forward compatible. It allows one to use API specific methods, that accept request objects as an argument and return response objects. Serialization & Deserialization of request & response objects is handled by the client itself. Each API can be called either synchronously or asynchronously.

Let’s discuss how we can use High-level REST client in our Scala-SBT application.

Continue reading

Posted in database, Elasticsearch, fulltextsearch, knoldus, NoSql, sbt, Scala | Tagged , , , | Leave a comment

The curious case of Cassandra Reads

In our previous blog, we discovered how Cassandra handles its write queries. Now it’s time to understand how it ensures all the read requests are fulfilled. Let’s first have an overall view of Cassandra. Apache Cassandra is a free and open-source distributed NoSQL database management system designed to handle large amounts of data across many commodity servers, providing high availability with no single point of failure.

Now Let’s jump to how Cassandra handles the read queries.


Reading in Cassandra 

In Cassandra, it is easy to read data because clients can connect to any node in the cluster to perform reads, without having to know whether a particular node acts as a replica for that data.
If a client connects to a node that doesn’t have the data it’s trying to read, the node it’s connected to will act as coordinator node to read the data from a node that does have it, identified by token ranges.

Cassandra reads are mostly dependent on Partitioners and Snitches :


A partitioner determines how data is distributed across the nodes in the cluster.Basically, a partitioner is a function for deriving a token representing a row from its partition key, typically by hashing. Each row of data is then distributed across the cluster by the value of the token.
Default Partitioner: Murmer3Partitioner (uniformly distributes data across the cluster based on MurmurHash hash values)


Snitches determine the proximity of Cassandra nodes. It determines which datacenters and racks nodes belong to It gathers network topology information and tries to route the request efficiently.
By default, a dynamic snitch layer is used for all snitches. It monitors the read performance and routes the request away from the slow nodes. It’s recommended to keep dynamic snitches enabled for most deployments. Continue reading

Posted in big data, Cassandra, database, NoSql, Scala | Tagged , , , , , , | 1 Comment

Exception Serializer in Lagom

In this blog, I will show you how to handle error responses from a Lagom service and convert them into well-defined exceptions using exception serializers.

Suppose we have an unmanaged service in Lagom. The unmanaged service hits a target service and the success response is deserialized into a POJO corresponding to the service call. But in the case of an error response, we get deserialization exception since the response with details of the error cannot be mapped to that POJO.

Using Lagom’s ExceptionSerializer, we can map all the responses with status codes in the range of 400-500 to appropriate exceptions specific to the service with a well-defined message. It allows the client of the service to take a suitable action based on the exception generated.

Continue reading

Posted in Java | Tagged , | Leave a comment

How to start with Vega:The web security scanner?

Vega – Web security scanner and web security testing platform.
Alright, Today I have come up with an interesting topic which is Vega and this blog is inspired by the last blog I wrote on web security. Vega is nothing but a tool, we will talk more about Vega in a while but let’s first talk ‘Why Vega’. So, next when you are done with your application from development to testing make sure you have tested it against attacks and vulnerabilities out there on the internet. You can protect your application from security attacks and vulnerabilities when you know about them.  Almost every web application has potential security risks and loopholes that are hidden until we run a security test on them. Now you must be wondering why I am talking so much about security testing so much. In order to prevent malicious and security attacks on your web application, It has to be well tested. How it can be done?

There are several tools available in the market which will be doing this for you and Vega is one of them. So Let’s talk about Vega in detail now. Vega is the web-application vulnerability tool which allows you to audit the security of your web-application.

Introduction to Vega

Vega is a free and open source web security scanner and web security testing platform to test the security of web applications. Vega can help you find and validate SQL Injection, Cross-Site Scripting (XSS), inadvertently disclosed sensitive information and other vulnerabilities. It is written in Java, GUI based and runs on Linux, OS X, and Windows.

Vega can help you find vulnerabilities

Vega can help you find vulnerabilities such as: reflected cross-site scripting, stored cross-site scripting, blind SQL injection, remote file include, shell injection, and others. Vega also probes for TLS / SSL security settings and identifies opportunities for improving the security of your TLS servers.

How does Vega work?

Vega includes an automated scanner for quick tests and an intercepting proxy for tactical inspection. The Vega scanner finds XSS (cross-site scripting), SQL injection, and other vulnerabilities. Vega can be extended using a powerful API in the language of the web: Javascript.

Features of Vega

  1. GUI Based
    Vega has a well-designed graphical user-interface.
  2. Multi-platform
    Vega is written in Java and runs on Linux, OS X, and Windows.
  3. Extensible
    Vega detection modules are written in Javascript. It is easy to create new attack modules using the rich API exposed by Vega.

Continue reading

Posted in Security, Security Audit, Security Guidelines, testing, Vulnerability Scanning, Web, web application | Leave a comment

Know a Knolder – Girish Chandra Bharti


Image | Posted on by | Leave a comment