Search the Community

Developing cloud-native applications involves establishing smooth and efficient communication among diverse components. To kick things off, let's delve into how a range of tools, from XML to gRPC, enable and enhance these critical interactions. XML (often with SOAP):<order> <bookID>12345</bookID> <quantity>2</quantity> <user>JohnDoe</user> </order>PositivesHighly structured: XML's structure ensures consistent data formatting. For instance, with <bookID>12345</bookID>, you're certain that the data between the tags is the book's ID. This reduces ambiguity in data interpretation. Self-descriptive: The tags describe the data. <user>JohnDoe</user> clearly indicates the user's name, making it easier for developers to understand the data without additional documentation. NegativesVerbose: For a large order list with thousands of entries, the repeated tags can significantly increase the data size. If you had 10,000 orders, that's 10,000 repetitions of <order>, <bookID>, and so on, leading to increased bandwidth usage. Parsing can be slow: For the same 10,000 orders, the system would need to navigate through each start and end tag, consuming more processing time compared to more concise formats. JSON (commonly with REST):{ "order": { "bookID": "12345", "quantity": 2, "user": "JohnDoe" } }PositivesLightweight and easy to read: The format is concise. If you had an array of 10,000 orders, JSON would handle it without the repetitive tags seen in XML, resulting in smaller data sizes. Supported by many languages: In JavaScript, for instance, JSON is natively supported. You can convert a JSON object to a JavaScript object with a simple JSON.parse() function, making integration seamless. NegativesDoesn't support data types natively: In our example, "bookID": "12345" and "quantity": 2 look different, but JSON treats both as text. This can lead to potential type-related bugs or require additional parsing. No built-in support for streaming: If you wanted to update book prices in real-time, JSON wouldn't support this natively. You'd need workarounds or additional technologies. GraphQL:Query: { order(id: "5678") { bookID user } }Response: { "data": { "order": { "bookID": "12345", "user": "JohnDoe" } } }PositivesFetch exactly what you need: If you had a mobile app with limited screen space, you could fetch only the necessary data, like bookID and user, optimizing bandwidth and load times. Single endpoint: Instead of managing multiple endpoints like /orders, /books, and /users, you'd manage a single GraphQL endpoint, simplifying the backend architecture. NegativesOverhead of parsing and processing queries: For each query, the server needs to interpret and fetch the right data. If you had millions of requests with varied queries, this could strain the server. Might be overkill for simple APIs: If you only needed basic CRUD operations, the flexibility of GraphQL might introduce unnecessary complexity. gRPC:Protocol Buffers definition: message OrderRequest { string id = 1; } message OrderResponse { string bookID = 1; int32 quantity = 2; } service OrderService { rpc GetOrder(OrderRequest) returns (OrderResponse); }PositivesEfficient serialization with Protocol Buffers: If you expanded globally, the compact binary format of Protocol Buffers would save significant bandwidth, especially with large datasets. Supports bi-directional streaming: Imagine you are having a feature where readers could chat about a book in real-time. gRPC's streaming would allow instant message exchanges without constant polling. Strongly-typed: With int32 quantity = 2;, you're ensured that quantity is always an integer, reducing type-related errors. NegativesRequires understanding of Protocol Buffers: Your development team would need to learn a new technology, potentially slowing initial development. Might be unfamiliar: If the team was accustomed to RESTful services, transitioning to gRPC might introduce a learning curve. Let's get to today's topic. What is gRPC?Imagine you have two computers that want to talk to each other. Just like people speak different languages, computers also need a common language to communicate. gRPC is like a special phone line that lets these computers chat quickly and clearly. In technical terms, gRPC is a tool that helps different parts of a software system communicate. It's designed to be fast, efficient, and secure. Instead of sending wordy messages, gRPC sends compact, speedy notes. This makes things run smoothly, especially when you have lots of computers talking at once in big systems like online shopping sites or video games. gRPC, which stands for Google Remote Procedure Call, is an open-source communication framework designed for systems to interact seamlessly. At its core, gRPC is about enabling efficient communication between computer programs, particularly when they're located on different servers or even across global data centers.Simplified Guide to gRPCImagine you have two friends, one who knows a secret recipe (let's call them the Chef) and another who wants to learn it (let's call them the Learner). However, there's a catch: they live in different towns. gRPC is like a magical phone that doesn't just let them talk to each other but also allows the Learner to watch and learn the recipe as if they were standing right next to the Chef in the kitchen. In the world of computer programs, gRPC does something quite similar. If you've created an app (which we'll think of as the Learner) that needs to use functions or data from a program on another computer (our Chef), gRPC helps them communicate effortlessly. Here's how it works: Defining the Menu: First, you tell gRPC about the dishes (or services) you're interested in, along with the ingredients (parameters) needed for each one and what you hope to have on your plate in the end (return types).The Chef Prepares: On the server (the Chef's kitchen), the menu is put into action. The server prepares to make those dishes exactly as described, ready to whip them up on request.The Magical Phone (gRPC): This is where gRPC comes in, acting as the phone line between the Learner and the Chef. It's not just any phone; it's a special one that can transmit tastes, smells, and cooking techniques instantly.Ordering Up: The Learner (client) uses a copy of the menu (known as a stub, but it's simpler to think of it as just a "client menu") to place an order. This "client menu" knows all the dishes the Chef can make and how to ask for them.Enjoying the Dish: Once the Learner uses the magical phone to request a dish, the Chef prepares it and sends it back over the same magical connection. To the Learner, it feels like the dish was made right there in their own kitchen.In technical terms, gRPC lets different pieces of software on different machines talk to each other as though they were part of the same program. It's a way of making remote procedure calls (RPCs), where the Learner (client) calls a method on the Chef (server) as if it were local. This magic makes building and connecting distributed applications much simpler and more intuitive. Technical AspectsHere's a closer look at its technical aspects. We'll consider a cloud-native application for a food delivery service. A user wants to order food from a restaurant using this app. Protocol Buffers: To represent an order, instead of a lengthy JSON, we use a concise Protocol Buffer definition. This ensures that the order details are transmitted efficiently between the user's device and the restaurant's system. message FoodOrder { string dishName = 1; int32 quantity = 2; string specialInstructions = 3; }gRPC uses Protocol Buffers (often shortened to "protobuf") as its primary mechanism for defining services and the structure of the data messages. Protobuf is a binary serialization format, making it both smaller and faster than traditional text-based formats like JSON or XML. Streaming Capabilities: As the restaurant prepares the order, the user can receive real-time updates on the cooking status. This is achieved using gRPC's streaming. This means the user gets instant notifications like "Cooking", "Packing", and "Out for Delivery" without constantly asking the server. rpc OrderUpdates(string orderId) returns (stream StatusUpdate);Language Agnostic: The user's app might be written in Java (for Android) or Swift (for iOS), but the restaurant's system uses Python. Thanks to gRPC's multi-language support, when the user places an order, both systems communicate flawlessly, irrespective of their programming languages. Deadlines/Timeouts: Imagine you're exploring new restaurants on the app. You don't want to wait indefinitely for results to load; you expect a prompt response. Here, gRPC's deadline feature plays a crucial role. When the app requests a list of restaurants from the server, it sets a deadline. This deadline is the app saying, "I can wait this long for a response, but no longer." For example, the app might set a deadline of 3 seconds for fetching the restaurant list. This deadline is communicated to the server, ensuring that the request is either completed in time or terminated with a DEADLINE_EXCEEDED error. This approach respects the user's time, providing a fail-fast mechanism that allows the app to quickly decide on an alternative course of action, such as displaying a helpful message or trying a different query. response = client.GetRestaurantList(timeout=3.0) In others, you might set a deadline based on the current time plus a duration: Deadline deadline = Deadline.after(3, TimeUnit.SECONDS); List<Restaurant> response = client.getRestaurantList(deadline); Closing RemarksWe've taken a trip through the world of communication tools in cloud-native app development, exploring everything from the structured world of XML, the simplicity of JSON, the flexibility of GraphQL, to the efficiency of gRPC. Each of these tools plays a key role in helping our apps talk to each other in the vast world of the internet. Diving into gRPC, we find it's more than just a way to send messages. It's like a bridge that connects different parts of our digital world, making it easy for them to work together, no matter the language they speak or where they are. To master the fundamentals of Cloud Native and Kubernetes, enroll in our KCNA course at KodeKloud: Explore the KCNA Learning Path. View the full article

Great post about application authentication and authorization on AWS; https://blog.cloudcraft.co/application-authentication-and-authorization-on-aws/

Amazon API Gateway now supports disabling the default, auto-generated REST API endpoint. The default REST API endpoint in API Gateway looks like https://{restapi_id}.execute-api.{region}.amazonaws.com. This feature is intended for customers who use custom domain names for REST APIs and want to ensure that all traffic to their API only goes through the custom domain name and not the default endpoint. This feature was already available for HTTP APIs. Now, it is available for REST APIs too. View the full article