Book Image

Scalable Data Architecture with Java

By : Sinchan Banerjee
Book Image

Scalable Data Architecture with Java

By: Sinchan Banerjee

Overview of this book

Java architectural patterns and tools help architects to build reliable, scalable, and secure data engineering solutions that collect, manipulate, and publish data. This book will help you make the most of the architecting data solutions available with clear and actionable advice from an expert. You’ll start with an overview of data architecture, exploring responsibilities of a Java data architect, and learning about various data formats, data storage, databases, and data application platforms as well as how to choose them. Next, you’ll understand how to architect a batch and real-time data processing pipeline. You’ll also get to grips with the various Java data processing patterns, before progressing to data security and governance. The later chapters will show you how to publish Data as a Service and how you can architect it. Finally, you’ll focus on how to evaluate and recommend an architecture by developing performance benchmarks, estimations, and various decision metrics. By the end of this book, you’ll be able to successfully orchestrate data architecture solutions using Java and related technologies as well as to evaluate and present the most suitable solution to your clients.
Table of Contents (19 chapters)
1
Section 1 – Foundation of Data Systems
5
Section 2 – Building Data Processing Pipelines
11
Section 3 – Enabling Data as a Service
14
Section 4 – Choosing Suitable Data Architecture

Introducing GraphQL – what, when, and why

In this section, we will explore what GraphQL is. According to graphql.org, the official definition of GraphQL is that “GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data.” Let’s dive a bit deeper to understand GraphQL.

Representational State Transfer (REST) has been the standard way of publishing data across systems, which is platform, device, and tool/language-agnostic. However, there are two major bottlenecks with REST:

  • For fetching different related entities, we need multiple REST requests. We must also be mindful of different versions of the API. Having different endpoints and their versions for each entity of functionality is a maintenance headache.
  • The request and response parameters are always fixed in REST. For example, there is a REST API that returns 100 fields. Suppose there is a consumer who only needs 10 fields. However, since responses...