Blog

Source:   microsoft/typescript-go: Staging repo for development of native port of TypeScript In a recent podcast episode, the creators of TypeScript, Anders Hejlsberg and Daniel Rosenwasser, shared groundbreaking news about the future of the TypeScript compiler. They announced that they are porting the TypeScript compiler and toolset to native code using the Go programming language, promising a significant performance boost—up to 10 times faster than the current JavaScript implementation. JavaScript, while powerful and widely used, has inherent limitations that affect performance, especially for compute-intensive tasks like compiling and type checking. The TypeScript compiler, originally built in JavaScript, has faced challenges due to: Single-threaded Execution: JavaScript's runtime environment is primarily single-threaded, which means it cannot efficiently utilize modern multi-core processors. This limitation leads to longer compile times, especially for large codebases. Garbage Collection Overhead: JavaScript's garbage collection can introduce latency, as it periodically pauses execution to reclaim memory. This can slow down the compilation process, particularly in large projects. Inefficient Memory Management: JavaScript's dynamic nature means that every object allocation can lead to performance overhead. The lack of control over data structures can result in inefficient memory usage. Complex Type Checking: TypeScript's structural type system, while powerful, can be computationally expensive. The need to recursively check types across potentially large and interconnected codebases can lead to slow performance. The Go port of TypeScript aims to address these issues by leveraging the strengths of the Go programming language: Native Code Execution: By compiling TypeScript to native code, the new compiler can run significantly faster than its JavaScript counterpart. This allows for better performance on multi-core processors, enabling the compiler to handle tasks in parallel. Efficient Memory Management: Go's support for structs allows for more efficient data representation, reducing the overhead associated with object allocations in JavaScript. This leads to better memory usage and faster execution. Concurrency: The Go port takes advantage of Go's built-in concurrency features, allowing multiple parsing and type-checking operations to occur simultaneously. This is particularly beneficial for large projects, where tasks can be distributed across available CPU cores. Improved Type Checking: The new compiler will maintain the same error messages and behavior as the existing TypeScript compiler while improving performance. The port aims to optimize type checking by allowing multiple type checkers to operate in parallel, reducing the time taken to resolve types across large codebases. Future-Proofing with AI: The TypeScript team is also looking to integrate AI capabilities into the language service, enhancing features like refactoring and code suggestions. This could lead to a more intelligent development experience, where the compiler not only checks types but also assists developers in writing better code. The Go port of TypeScript represents a significant leap forward in addressing the performance limitations of the current JavaScript-based compiler. Source: A 10x Faster TypeScript - TypeScript | MicroSoft By harnessing the power of native code execution, efficient memory management, and concurrency, the TypeScript team aims to provide developers with a faster, more responsive tool for building large-scale applications. As the project progresses, the team encourages the community to engage with the new compiler, providing feedback and contributing to its development. The future of TypeScript looks promising, with the potential for enhanced performance and new features that leverage the latest advancements in technology. Github: microsoft/typescript-go: Staging repo for development of native port of TypeScript

Mar 14, 2025

Streams are a fundamental concept in Node.js, allowing data to be read or written in chunks instead of loading everything into memory at once. This makes them especially useful for handling large files or continuous data. Examples of streams in Node.js include: HTTP requests and responses: When a server processes an HTTP request, it works as a readable stream. The response it sends back is a writable stream. File operations: Reading from or writing to files using the fs module can be handled as streams. Network communications: Sockets use streams to send and receive data. How Many Things in Node.js Are Streams? Node.js provides a variety of streams, which are core building blocks for handling data flow. These streams are categorized into four main types: Readable, Writable, Duplex, and Transform. 1. Readable Streams Streams from which data can be read. fs.createReadStream() for reading files. HTTP request (http.IncomingMessage). Process standard input (process.stdin). Network socket (net.Socket) in read mode. 2. Writable Streams Streams to which data can be written. fs.createWriteStream() for writing to files. HTTP response (http.ServerResponse). Process standard output and error (process.stdout and process.stderr). Network socket (net.Socket) in write mode. 3. Duplex Streams Streams that are both readable and writable. net.Socket (TCP socket connection). zlib compression streams (e.g., zlib.createGzip()). stream.Duplex for custom implementations. 4. Transform Streams Special duplex streams that can modify or transform data as it is written and read. zlib.createGzip() or zlib.createGunzip() for compression and decompression. crypto streams like crypto.createCipher() or crypto.createDecipher(). stream.Transform for custom transformations. Other Notable Stream Implementations File System (fs): Readable and writable streams for file operations. HTTP: Incoming requests (Readable stream). Server responses (Writable stream). Child Processes: child_process.spawn() and related methods provide streams for stdin, stdout, and stderr. Streams in Libraries: Streams used in third-party libraries like axios or request for handling data. WebSocket Streams: Some libraries like ws or Socket.io use streams for real-time communication. While there is no single definitive number because streams can be custom-implemented, the core Node.js API has several dozen implementations of streams across various modules. Why Use Streams for Large CSV Files? Processing large CSV files can be memory-intensive if the entire file is read into memory at once. By using streams, you can process the file line by line or chunk by chunk, keeping memory usage low and improving performance. Reading a Large CSV File Here is an example of how to read a large CSV file using streams: const fs = require('fs'); const readline = require('readline'); const readStream = fs.createReadStream('largefile.csv'); const rl = readline.createInterface({ input: readStream }); rl.on('line', (line) => { console.log(`Line: ${line}`); }); rl.on('close', () => { console.log('Finished reading the file.'); }); In this example, the fs.createReadStream method reads the file in chunks, and the readline module processes each line. Writing a Large CSV File Here is how you can write to a CSV file using streams: const fs = require('fs'); const writeStream = fs.createWriteStream('output.csv'); writeStream.write('Name,Age,Location\n'); writeStream.write('John,30,New York\n'); writeStream.write('Jane,25,London\n'); writeStream.end(() => { console.log('Finished writing to the file.'); }); The fs.createWriteStream method allows data to be written in chunks to the file. Transforming Data with Streams Sometimes, you may want to transform data while reading or writing. This can be done using transform streams: const fs = require('fs'); const { Transform } = require('stream'); const readStream = fs.createReadStream('largefile.csv'); const writeStream = fs.createWriteStream('output.csv'); const transformStream = new Transform({ transform(chunk, encoding, callback) { const modifiedChunk = chunk.toString().toUpperCase(); callback(null, modifiedChunk); } }); readStream.pipe(transformStream).pipe(writeStream); In this example, the transform stream converts all data to uppercase before writing it to the output file. Benefits of Streams Efficient memory usage Faster processing for large data Allows for real-time data processing

Dec 21, 2024

Columnar vs Row-Based File Formats When working with large datasets, choosing the right file format can have a significant impact on performance and storage efficiency. The two common types of data formats are row-based and columnar-based formats. Each has its own strengths, depending on your use case, whether it's for transaction processing or analytical queries. What Are Row-Based and Columnar File Formats? Row-based file formats (like CSV or JSON) store data by rows, meaning each record is stored sequentially. On the other hand, columnar file formats (like Parquet or ORC) store data by columns, grouping values from the same column together. Key Differences Between Row-Based and Columnar Formats 1. Data Storage Layout Row-based: Data is stored as complete rows, meaning all fields for a record are stored together. Columnar: Data is stored by columns, meaning values for a particular column are grouped together. 2. Use Case Row-based: Best for transactional systems where entire records need to be written or read at once, such as in OLTP (Online Transaction Processing). Columnar: Ideal for analytical queries that focus on specific columns, commonly used in OLAP (Online Analytical Processing). 3. Read/Write Performance Row-based: Fast writes as entire records are stored together, but slower for analytical reads as it reads all columns even if only a few are needed. Columnar: Fast reads for analytics, since only the necessary columns are read. However, writes are slower as columns are written separately. 4. Data Compression Row-based: Less efficient for compression since rows contain diverse data types, making compression harder. Columnar: Highly compressible because each column typically contains similar data, which can be easily compressed. 5. Storage Efficiency Row-based: More efficient for small datasets or systems where full records are accessed at once. Columnar: More efficient for large datasets, especially in systems where only a few columns are frequently accessed. 6. Common Usage Scenarios Row-based: Frequently used in real-time applications, transactional databases, and systems that require fast row-level access. Columnar: Commonly used in data warehouses and big data systems that perform heavy analytical queries over specific columns. Example: Reading Data Let’s say you have a dataset with 1 million rows and 50 columns, but you only need to analyze two columns: Row-based: The system would read all 50 columns for each of the 1 million rows, even if only two columns are needed. This is inefficient for analytical queries. Columnar: The system only reads the two required columns, resulting in faster query times and lower I/O costs. Conclusion Row-based formats are best suited for applications that require frequent access to entire records, such as transactional databases. On the other hand, columnar formats excel in analytical environments where queries involve aggregating or filtering on specific columns. Understanding the differences will help you choose the right format for your project, depending on whether you need fast transactional processing or efficient data analysis.

Oct 15, 2024

Creating REST APIs: AWS API Gateway vs Direct AWS Lambda If you're looking to build a REST API on AWS, you can do it either with AWS API Gateway or directly using AWS Lambda. Both methods can serve your API needs, but they work a little differently, especially when it comes to features, management, and scalability. What is AWS API Gateway? AWS API Gateway is a service that helps you manage APIs easily. It’s designed to handle everything around API management, like security, traffic control, and logging. It works with backend services, like Lambda, to run your API smoothly. What is AWS Lambda? AWS Lambda is a serverless compute service. It lets you run code without worrying about servers, and you only pay when your function is running. It’s great for event-driven tasks, and you can use it to expose REST APIs, but you’ll need to manage more things manually compared to API Gateway. Key Differences 1. API Management and Features API Gateway: It’s built for managing APIs, giving you features like authentication, rate limiting, request validation, and caching right out of the box. You can set up different versions of your API and even deploy them to different environments (like production or testing). Lambda: When you use Lambda directly, you don’t get all those API management tools. You’ll need to code things like routing and request validation yourself. It’s simpler for small or internal services, but lacks the robust features of API Gateway. 2. Security and Access Control API Gateway: It offers a lot of built-in security. You can control who accesses your API with AWS IAM, API keys, or even create custom authorization through Lambda functions. It also supports HTTPS by default. Lambda: Lambda gives you some security options, but without API Gateway, you'll need to do more work to secure your API. You can still use IAM roles, but things like request signing and token management would require extra setup. 3. Costs API Gateway: API Gateway charges based on how many API calls are made, data transferred, and features like caching. For high-traffic applications, costs can rise, especially if you have many endpoints. Lambda: Direct Lambda is more cost-effective for small or simple applications since you’re only paying for Lambda execution time and data transfer. No extra costs for API management features you might not need. 4. Request Routing and Processing API Gateway: It acts as the middle layer between the client and your backend, routing each request to the right Lambda function or another backend service. You can easily create different routes and methods (like GET or POST). Lambda: If you're using Lambda URLs, you'll need to handle routing manually inside your Lambda function. This works well for simple, single-purpose APIs, but can get complicated as you add more endpoints. 5. Monitoring and Logging API Gateway: It automatically integrates with CloudWatch to log requests and metrics. You can easily track how your API is performing, look at errors, and even trace specific requests. Lambda: Lambda also integrates with CloudWatch, but doesn’t provide as much detailed API data unless you manually add logging in your code. 6. Performance and Latency API Gateway: It adds a small amount of latency because it sits between the client and Lambda. However, it’s usually not noticeable unless you need extremely low-latency performance. Lambda: Invoking Lambda directly is slightly faster since there’s no API Gateway in the middle, but the trade-off is that you lose the management features that API Gateway offers. When to Use API Gateway You should choose API Gateway if: You need to manage public-facing APIs with strong security features. Your API requires authentication, rate limiting, or caching. You want to monitor API performance closely and trace requests. You are managing multiple versions or environments for your API (e.g., development, production). When to Use Direct AWS Lambda Use Lambda directly if: You’re building a simple or internal service that doesn’t need all the features of API Gateway. You want to reduce costs and keep things lightweight. Low latency is a priority and you’re willing to manage the API logic manually. Conclusion In summary, if you need full API management with security, logging, and scalability, go with API Gateway. If you're building a small or internal service and want to keep things simple, direct Lambda might be the better choice. It all depends on your project’s needs, complexity, and scale.

Oct 15, 2024

Understanding Serverless Functions and Their Execution Credits: Serverless Architectures with AWS Lambda Serverless computing has transformed the way applications are developed and deployed. It abstracts the underlying infrastructure, allowing developers to focus on writing code without worrying about server management. One of the core components of serverless computing is the concept of "serverless functions." In this article, we'll explore what serverless functions are, how they work, and how they are executed in a serverless environment. What are Serverless Functions? Serverless functions are small, single-purpose code snippets that are triggered by events, such as HTTP requests, database changes, or message queue updates. These functions are typically stateless, meaning they do not retain any data between executions. The term "serverless" is somewhat misleading because there are still servers involved; however, the cloud provider manages them, and the developer is abstracted from server maintenance. Popular serverless function platforms include: - AWS Lambda - Azure Functions - Google Cloud Functions - IBM Cloud Functions Credits: AWS Support Need Server explanation in Visualization? How Serverless Functions Work Serverless functions are event-driven, meaning they are executed in response to specific events. The process can be broken down into several key steps: 1. Event Trigger: The execution of a serverless function begins when a predefined event occurs. This event could be an API call, a file upload to a cloud storage service, a new message in a queue, or any other event configured by the developer. 2. Function Invocation: Once the event occurs, the cloud provider invokes the corresponding serverless function. The function is isolated and runs independently in a container or virtual machine. 3. Execution Environment: The cloud provider dynamically provisions the resources required to run the function. This environment includes the necessary runtime (e.g., Node.js, Python, Java) and the execution context, which contains information like environment variables and execution time limits. 4. Code Execution: The function code executes, processing the event data and performing the desired operations, such as database queries, API calls, or data transformations. 5. Return Response: After the function completes its task, it returns a response, which is typically sent back to the event source. For example, in an HTTP-triggered function, the response would be sent back to the client that made the request. 6. Scaling and Concurrency: One of the key benefits of serverless functions is their ability to scale automatically. If multiple events occur simultaneously, the cloud provider can instantiate multiple instances of the function to handle the load, each running independently. This ensures that functions can handle high concurrency without manual intervention. 7. Teardown and Cleanup: Once the function has finished executing, the cloud provider tears down the execution environment, freeing up resources. This process is entirely managed by the cloud provider, and the developer doesn't need to worry about resource cleanup. Execution Flow in Detail To further understand the execution of serverless functions, let's consider a common use case: an image processing service. 1. Event Trigger: A user uploads an image to a cloud storage service like AWS S3. 2. Function Invocation: The upload triggers an event in the cloud storage service, which invokes an AWS Lambda function designed to process images. 3. Execution Environment: AWS Lambda provisions an environment with the required memory, CPU, and the runtime (e.g., Python) to execute the function. 4. Code Execution: The Lambda function retrieves the image, applies filters, resizes it, and then stores the processed image back in the cloud storage. 5. Return Response: The function completes its execution and sends a confirmation response to the user or logs the success in a monitoring service. 6. Scaling: If multiple users upload images simultaneously, AWS Lambda automatically scales by creating additional instances of the function, ensuring each image is processed without delay. 7. Teardown: After each function instance completes its task, AWS Lambda tears down the environment, and the resources are made available for future use. Advantages of Serverless Functions - Cost Efficiency: You only pay for the compute time your function consumes. There’s no cost for idle time, unlike traditional server-based architectures. - Automatic Scaling: Serverless platforms handle scaling automatically, ensuring that functions can meet demand without manual intervention. - Simplified Management: Developers don’t need to manage servers, operating systems, or infrastructure. The cloud provider handles all of this, allowing developers to focus solely on writing code. - Flexibility: Serverless functions can be written in various programming languages, and they can be triggered by a wide range of events. Challenges and Considerations While serverless functions offer many benefits, they also come with some challenges: - Cold Starts: The first invocation of a serverless function after a period of inactivity can take longer due to the time required to provision the execution environment. This delay is known as a "cold start." - Statelessness: Serverless functions are stateless by design, which means developers need to use external services like databases or caches to store state between function invocations. - Execution Limits: Most serverless platforms impose limits on execution time, memory usage, and payload size. Functions exceeding these limits may fail or incur additional costs. Conclusion Serverless functions represent a powerful paradigm shift in cloud computing, enabling developers to build scalable, cost-efficient applications without the overhead of managing servers. By understanding how serverless functions work and how they are executed, developers can leverage this technology to create responsive and resilient applications that can handle varying workloads with ease. As the serverless ecosystem continues to evolve, it will likely become an even more integral part of modern application development.

Sep 4, 2024

Node.js is a powerful platform that allows developers to build fast and scalable web applications using JavaScript. When a request hits a Node.js server, a series of complex processes take place. In this section, we will explore the journey of a request through a Node.js server and how it handles incoming requests. Node.js operates using a single thread and an event-driven, non-blocking architecture. It allows for efficient handling of I/O operations, which makes it an excellent choice for building real-time applications that require high concurrency. Key Takeaways Node.js operates using a single thread and an event-driven, non-blocking architecture It allows for efficient handling of I/O operations, making it an excellent choice for building real-time applications The request journey through a Node.js server involves reception, routing, middleware execution, and response generation Understanding Node.js Server Architecture When it comes to building web applications, choosing the right server architecture is crucial. Node.js is a popular JavaScript runtime that has gained traction among developers due to its unique architecture and performance benefits. Node.js is event-driven and non-blocking, meaning that it doesn't wait for I/O operations to complete before moving on to the next task. Instead, it efficiently handles multiple concurrent requests by using a single thread with an event loop. At its core, Node.js is made up of three main components: ComponentDescription V8 JavaScript engineNode.js is built on top of the V8 JavaScript engine, which is also used by Google Chrome. This engine compiles JavaScript code into machine code for faster execution. Libuv libraryNode.js uses the Libuv library to handle asynchronous I/O operations. Libuv provides an event loop and thread pool to handle events and work, respectively. Node.js coreThe Node.js core consists of built-in modules that provide functionality for common tasks, such as file system access and network operations. By using a single thread with an event loop, Node.js is able to handle a large number of concurrent connections with relatively low overhead. This architecture also allows for easy horizontal scaling by spinning up multiple instances of the Node.js server and placing them behind a load balancer. The Request Lifecycle in Node.js When a request hits a Node.js server, it goes through a defined series of steps known as the request lifecycle. Understanding this process is key to optimizing server performance and building scalable applications. The request lifecycle in Node.js can be broken down into three main phases: request reception, routing, and response generation. Let's take a closer look at each stage: Request Reception: When a request is received by the server, it is processed and parsed into an HTTP object. This object contains information about the request, such as the request method, headers, and URL parameters. Routing: Once the HTTP object has been created, it is passed to the server's routing system. The routing system matches the request to a specific endpoint based on the URL and HTTP method. Middleware Execution and Response Generation: If a matching endpoint is found, the server executes any relevant middleware in the order it was declared. Middleware can modify the HTTP object or generate a response. If no middleware generates a response, the server sends a default response (such as a 404 error). It is worth noting that middleware can be synchronous or asynchronous. Synchronous middleware is executed in a blocking way, while asynchronous middleware uses callbacks or promises to execute non-blocking operations. Pro Tip: By strategically placing middleware in your application, you can optimize performance and keep your code clean and modular. Event Loop in Node.js One of the key features of Node.js is its event-driven, non-blocking architecture. At the core of this architecture is the event loop, a mechanism for handling incoming events and executing the corresponding callbacks. When a request is received by a Node.js server, it is added to a queue of pending events. The event loop is responsible for processing these events in a timely and efficient manner. Under the hood, the event loop constantly iterates over this event queue, checking for any pending events that are ready to be processed. When an event is detected, its corresponding callback is executed, and the event is removed from the queue. It is worth noting that the event loop is a single-threaded mechanism. This means that while it is processing an event, it will not be able to process any other events that may be waiting in the queue. As a result, it is important to ensure that event handlers are lightweight and do not block the event loop for extended periods of time. The event loop is a crucial component of Node.js, enabling it to efficiently handle multiple concurrent requests while maintaining responsiveness. Understanding how it works is essential for building scalable and performant Node.js applications. Handling Incoming Requests in Node.js When a user makes a request to a Node.js server, the server listens to it and processes it using request listeners which are registered to handle specific types of requests. The request listeners are event emitters that emit an event every time a request is received by the server. These events are processed using the event loop and sent through the middleware chain to the appropriate route that handles the request. Request Listeners Request listeners are registered to handle specific types of HTTP requests. When the server receives a request, it emits the corresponding event and the associated listener is executed. For example, if a user is requesting a GET method, the request listener for that specific method will be triggered. The listener will then process the request, retrieve the relevant data, and send it back to the user as a response. It is important to note that request listeners are executed asynchronously, allowing the server to handle multiple requests at the same time without blocking the event loop. Middleware Chain Once a request is received and the corresponding event is emitted, it is passed through the middleware chain. The middleware functions are executed in the order in which they were added to the chain. The middleware functions have access to the request and response objects, allowing them to manipulate or modify them before passing them on to the next function in the chain. Middleware functions can perform functions such as logging, authentication, data validation, and error handling. The middleware chain is an important part of the request processing cycle in Node.js, allowing developers to write modular and reusable code. Overall, the way Node.js handles incoming requests is a crucial aspect of its performance and scalability. By utilizing request listeners and the middleware chain, developers can build fast and efficient web applications that can handle multiple concurrent requests without blocking the event loop. Node.js Middleware and Request Processing Middleware is a crucial concept in Node.js for processing incoming requests. In simple terms, it is a function that intercepts HTTP requests and performs operations on them. Middleware functions are executed in a sequential order when a request is received, and they can modify the request and/or the response objects. Consider a scenario in which a user submits a form on a web page. The submitted data is received by the server as an HTTP request. The server then registers a middleware function to process the request. This middleware function validates the data, checks for any errors, and then passes the request to the next middleware function. The next middleware function might authenticate the user or log the request details before passing it on to the route handler, which generates a response. Middleware functions can be used to perform a wide range of operations, such as data validation, error handling, authentication, logging, and more. They offer developers a high degree of flexibility and modularity, allowing them to easily modify and extend the functionality of their Node.js applications. Asynchronous and Non-Blocking Operations in Node.js One of the core features of Node.js is its asynchronous and non-blocking nature, which allows for efficient handling of I/O operations. Unlike traditional web servers that follow a synchronous model, where the server waits for a task to complete before moving on to the next one, Node.js follows an asynchronous model. This means that when a request is made, Node.js will initiate the request and move on to the next one without waiting for the first one to complete. When the first request finally returns a response, Node.js will pick up where it left off and continue processing the request. This asynchronous model makes Node.js highly performant, as it can handle multiple requests simultaneously without getting bogged down. It also allows Node.js to be responsive even when dealing with large amounts of data or complex operations. Callbacks To achieve its non-blocking nature, Node.js uses callbacks, which are functions that are passed as arguments to other functions and called when the other function has completed its work. In this way, Node.js can initiate a task and continue processing without waiting for the task to complete. "Callbacks are used to make sure that a function is not blocking the execution of other code." For example, when a file is read in Node.js, the reading process is initiated, and a callback function is passed as an argument to be called when the reading is complete. In the meantime, Node.js can continue processing other requests. Promises In addition to callbacks, Node.js also supports promises, which provide a way to handle asynchronous operations more cleanly and intuitively. Promises are essentially placeholders for a value that hasn't yet been computed, but will be at some point in the future. When a promise is created, it starts out in a "pending" state, meaning that it hasn't yet resolved to a value. Once the asynchronous operation is complete, the promise either resolves to a value or rejects with an error. For example, when a request is made to an external API in Node.js, a promise can be used to handle the asynchronous nature of the request. The promise will be resolved when the API returns a response, or rejected if there is an error. Non-Blocking I/O In addition to handling asynchronous operations through callbacks and promises, Node.js also uses non-blocking I/O operations to improve performance. Non-blocking I/O allows Node.js to initiate an I/O operation and continue processing requests without waiting for the I/O operation to complete. For example, when a file is written or read in Node.js, the operation is passed off to the operating system, and Node.js continues processing other requests. When the operating system has completed the operation, it will notify Node.js, which can then handle the response. Overall, the asynchronous and non-blocking nature of Node.js is a key component of its performance benefits. By handling multiple requests simultaneously and efficiently, Node.js can provide fast, scalable, and responsive web applications. Performance Benefits of Node.js Server One of the primary benefits of using a Node.js server is its ability to handle high levels of concurrency. This is due to its non-blocking, event-driven architecture, which enables the server to handle multiple requests simultaneously without getting bogged down by I/O operations. As a result, Node.js servers are highly responsive and can handle large volumes of traffic without sacrificing performance. In addition to its concurrency capabilities, Node.js also has a low memory footprint, meaning that it requires less system resources to run compared to traditional server-side technologies. This makes it an ideal solution for resource-constrained environments, such as cloud-based deployments or microservices architectures. Performance BenefitDescription Concurrent Requests HandlingNode.js allows servers to handle multiple requests simultaneously, improving their responsiveness and performance. Low Memory FootprintNode.js requires fewer system resources compared to other server-side technologies, making it well-suited for resource-constrained environments. ScalabilityNode.js can scale horizontally across multiple servers, allowing for easy expansion as traffic volumes increase. Finally, Node.js servers are highly scalable, both vertically and horizontally. They can be scaled vertically by increasing the available system resources, such as RAM or CPU, on a single server. Alternatively, they can be scaled horizontally by deploying multiple instances of the server across multiple physical or virtual machines. This allows for easy expansion as traffic volumes increase, without sacrificing performance or responsiveness. Overall, the performance benefits of using a Node.js server make it an ideal choice for building fast, scalable, and responsive web applications. Best Practices for Optimizing Node.js Server Performance Optimizing the performance of a Node.js server is critical for building fast and scalable web applications. Here are some best practices to follow: Code optimization: Write optimized code that is efficient and uses minimal resources. Use tools like Node.js's built-in profiler to identify performance bottlenecks. Caching: Implement caching of frequently accessed data to reduce the number of requests made to the server. Use caching solutions like Memcached or Redis. Load balancing: Use load balancing to distribute traffic evenly across multiple servers and avoid overloading a single server. Tools like PM2 or Nginx can be used for load balancing. Compression: Compress data sent from the server to reduce the size of the response and improve performance. Use compression libraries like Gzip or Brotli. Minification: Minify the code by removing transparentspace, comments, and unnecessary characters to reduce file size and improve performance. Optimize database queries: Optimize database queries to reduce the amount of time spent on I/O operations. Use indexing, batch processing, and caching to improve query performance. Use asynchronous methods: Use asynchronous methods and non-blocking I/O operations to prevent the server from blocking on long-running requests. Use a Content Delivery Network (CDN): Use a CDN to deliver static files quickly and reduce the load on the server. This ensures that files are served from a closer location to the user. Note: It's important to test the performance of your Node.js server and make adjustments based on the results. Use load testing tools like Apache JMeter or Artillery to simulate a high traffic scenario and evaluate server performance. Security Considerations for Node.js Server When using a Node.js server, it is crucial to consider its security implications. In this section, we will discuss some important security considerations to keep in mind. Input Validation One of the most critical aspects of securing a Node.js server is input validation. Any input received from external sources should be validated to ensure it is in the expected format and does not contain malicious code. Failure to do so can result in attacks such as SQL injection or cross-site scripting (XSS). Data Sanitization In addition to input validation, data sanitization is also crucial. This involves removing any potentially harmful data from user inputs, such as HTML tags or JavaScript code. Sanitizing data ensures that attackers cannot inject malicious code into the application. Protection Against Common Web Vulnerabilities Node.js servers should also be protected against common web vulnerabilities such as cross-site request forgery (CSRF) and denial-of-service (DoS) attacks. CSRF attacks can be prevented by implementing CSRF tokens, while DoS attacks can be mitigated through request throttling and load balancing. Securing Dependencies Another important consideration is securing dependencies, as vulnerabilities in third-party packages can be exploited by attackers to gain access to the server. Therefore, it is crucial to keep dependencies up-to-date and to perform regular security audits. By implementing these security considerations, developers can ensure a safe and secure Node.js environment for their applications. Scaling Node.js Server for High Traffic As your web application grows, you may encounter high traffic scenarios that put a strain on your Node.js server. In such situations, it's important to scale your server to ensure it can handle the increased load without compromising performance or stability. Here are some strategies you can use to scale your Node.js server: Clustering Node.js provides a built-in cluster module that allows you to create child processes to handle incoming requests. Each child process runs on a separate CPU core, which enables your server to handle more concurrent requests. Clustering is a simple and effective way to scale your Node.js server without requiring any additional tools or infrastructure. Load Balancing Load balancing involves distributing incoming requests across multiple servers to avoid overwhelming a single server. You can use a load balancer such as NGINX or HAProxy to distribute traffic among multiple Node.js servers. Load balancing requires additional infrastructure and configurations, but it can help you handle large amounts of traffic and ensure high availability. Horizontal Scaling Horizontal scaling involves adding more servers to your infrastructure to handle increased traffic. With horizontal scaling, you can distribute the load across multiple servers, which can result in better performance and reliability. However, horizontal scaling requires additional infrastructure, configurations, and management, and it may not always be the most cost-effective solution. By using a combination of these strategies, you can effectively scale your Node.js server to handle high traffic scenarios. It's important to monitor your server's performance and adjust your scaling strategy as needed to ensure optimal performance and scalability. Conclusion In conclusion, Node.js has become a popular platform to build fast and scalable web applications. By understanding its single-threaded architecture, event loop, request processing, and middleware functions, developers can build efficient and responsive applications. Furthermore, Node.js offers various performance benefits, such as high concurrency, low memory footprint, and scalability. However, to optimize Node.js server performance, developers should follow best practices like code optimization, caching, and load balancing. Security Considerations Security is a crucial aspect of any web application, and Node.js is no exception. Developers must consider input validation, data sanitization, and protection against common web vulnerabilities like cross-site scripting and SQL injection. Scaling for High Traffic As web traffic increases, Node.js servers must scale to handle the load. Clustering, load balancing, and horizontal scaling are some techniques used for scaling Node.js servers. By mastering the concepts of Node.js, developers can leverage its power to build high-performance and scalable web applications. FAQ Q: What happens when a request hits a Node.js server? A: When a request hits a Node.js server, it goes through a series of steps including request reception, routing, middleware execution, and response generation. Q: How does Node.js handle incoming requests? A: Node.js handles incoming requests by using request listeners that are registered and processed by the event loop. Q: What is the event loop in Node.js? A: The event loop is a crucial component of Node.js that allows it to efficiently handle multiple concurrent requests while maintaining responsiveness. Q: What is the role of middleware in Node.js? A: Middleware functions in Node.js intercept and modify the request/response objects, allowing for additional processing and customization. Q: How does Node.js handle asynchronous and non-blocking operations? A: Node.js utilizes its asynchronous and non-blocking nature to efficiently handle I/O operations, improving overall performance. Q: What are the performance benefits of a Node.js server? A: A Node.js server offers benefits such as high concurrency handling, low memory footprint, and scalability. Q: What are some best practices for optimizing Node.js server performance? A: Best practices for optimizing Node.js server performance include code optimization, caching, and load balancing techniques. Q: What security considerations should be taken into account when using a Node.js server? A: When using a Node.js server, important security considerations include input validation, data sanitization, and protection against common web vulnerabilities. Q: How can a Node.js server be scaled to handle high traffic? A: Strategies for scaling a Node.js server to handle high traffic scenarios include clustering, load balancing, and horizontal scaling techniques.

Aug 24, 2023

Zomato is an India-based restaurant aggregator, food delivery, dining-out company with over 350,000 listed restaurants across more than 1,000 cities in India. The company relies heavily on data analytics to enrich the customer experience and improve business efficiency. Zomato’s engineering and product teams use data insights to refine their platform’s restaurant and cuisine recommendations, improve the accuracy of waiting times at restaurants, speed up the matching of delivery partners and improve overall food delivery process. At Zomato, different teams have different requirements for data discovery based upon their business functions. For example, number of orders placed in specific area required by a city lead team, queries resolved per minute required by customer support team or most searched dishes on special events or days by marketing and other teams. Zomato’s Data Platform team is responsible for building and maintaining a reliable platform which serves these data insights to all business units. Zomato’s Data Platform is powered by AWS services including Amazon EMR, Amazon Aurora MySQL-Compatible Edition and Amazon DynamoDB along with open source software Trino (formerly PrestoSQL) and Apache Druid for serving the previously mentioned business metrics to different teams. Trino clusters process over 250K queries by scanning 2PB of data and Apache Druid ingests over 20 billion events and serves 8 million queries every week. To deliver performance at Zomato scale, these massively parallel systems utilize horizontal scaling of nodes running on Amazon Elastic Compute Cloud (Amazon EC2) instances in their clusters on AWS. Performance of both these data platform components is critical to support all business functions reliably and efficiently in Zomato. To improve performance in a cost-effective manner, Zomato migrated these Trino and Druid workloads onto AWS Graviton-based Amazon EC2 instances. Graviton-based EC2 instances are powered by Arm-based AWS Graviton processors. They deliver up to 40% better price performance than comparable x86-based Amazon EC2 instances. CPU and Memory intensive Java-based applications including Trino and Druid are suitable candidates for AWS Graviton based instances to optimize price-performance, as Java is well supported and generally performant out-of-the-box on arm64. In this blog, we will walk you through an overview of Trino and Druid, how they fit into the overall Data Platform architecture and migration journey onto AWS Graviton based instances for these workloads. We will also cover challenges faced during migration, how Zomato team overcame those challenges, business gains in terms of cost savings and better performance along with future plans of Zomato on Graviton adoption for more workloads. Trino overview Trino is a fast, distributed SQL query engine for querying petabyte scale data, implementing massively parallel processing (MPP) architecture. It was designed as an alternative to tools that query Apache Hadoop Distributed File System (HDFS) using pipelines of MapReduce jobs, such as Apache Hive or Apache Pig, but Trino is not limited to querying HDFS only. It has been extended to operate over a multitude of data sources, including Amazon Simple Storage Service (Amazon S3), traditional relational databases and distributed data stores including Apache Cassandra, Apache Druid, MongoDB and more. When Trino executes a query, it does so by breaking up the execution into a hierarchy of stages, which are implemented as a series of tasks distributed over a network of Trino workers. This reduces end-to-end latency and makes Trino a fast tool for ad hoc data exploration over very large data sets. Figure 1 – Trino architecture overview Trino coordinator is responsible for parsing statements, planning queries, and managing Trino worker nodes. Every Trino installation must have a coordinator alongside one or more Trino workers. Client applications including Apache Superset and Redash connect to the coordinator via Presto Gateway to submit statements for execution. The coordinator creates a logical model of a query involving a series of stages, which is then translated into a series of connected tasks running on a cluster of Trino workers. Presto Gateway acts as a proxy/load-balancer for multiple Trino clusters. Druid overview Apache Druid is a real-time database to power modern analytics applications for use cases where real-time ingest, fast query performance and high uptime are important. Druid processes are deployed on three types of server nodes: Master nodes govern data availability and ingestion, Query nodes accept queries, execute them across the system, and return the results and Data nodes ingest and store queryable data. Broker processes receive queries from external clients and forward those queries to Data servers. Historicals are the workhorses that handle storage and querying on “historical” data. MiddleManager processes handle ingestion of new data into the cluster. Please refer here to learn more on detailed Druid architecture design. Figure 2 – Druid architecture overview Zomato’s Data Platform Architecture on AWS Figure 3 – Zomato’s Data Platform landscape on AWS Zomato’s Data Platform covers data ingestion, storage, distributed processing (enrichment and enhancement), batch and real-time data pipelines unification and a robust consumption layer, through which petabytes of data is queried daily for ad-hoc and near real-time analytics. In this section, we will explain the data flow of pipelines serving data to Trino and Druid clusters in the overall Data Platform architecture. Data Pipeline-1: Amazon Aurora MySQL-Compatible database is used to store data by various microservices at Zomato. Apache Sqoop on Amazon EMR run Extract, Transform, Load (ETL) jobs at scheduled intervals to fetch data from Aurora MySQL-Compatible to transfer it to Amazon S3 in the Optimized Row Columnar (ORC) format, which is then queried by Trino clusters. Data Pipeline-2: Debezium Kafka connector deployed on Amazon Elastic Container Service (Amazon ECS) acts as producer and continuously polls data from Aurora MySQL-Compatible database. On detecting changes in the data, it identifies the change type and publishes the change data event to Apache Kafka in Avro format. Apache Flink on Amazon EMR consumes data from Kafka topic, performs data enrichment and transformation and writes it in ORC format in Iceberg tables on Amazon S3. Trino clusters then query data from Amazon S3. Data Pipeline-3: Moving away from other databases, Zomato had decided to go serverless with Amazon DynamoDB because of its high performance (single-digit millisecond latency), request rate (millions per second), extreme scale as per Zomato peak expectations, economics (pay as you go) and data volume (TB, PB, EB) for their business-critical apps including Food Cart, Product Catalog and Customer preferences. DynamoDB streams publish data from these apps to Amazon S3 in JSON format to serve this data pipeline. Apache Spark on Amazon EMR reads JSON data, performs transformations including conversion into ORC format and writes data back to Amazon S3 which is used by Trino clusters for querying. Data Pipeline-4: Zomato’s core business applications serving end users include microservices, web and mobile applications. To get near real-time insights from these core applications is critical to serve customers and win their trust continuously. Services use a custom SDK developed by data platform team to publish events to the Apache Kafka topic. Then, two downstream data pipelines consume these application events available on Kafka via Apache Flink on Amazon EMR. Flink performs data conversion into ORC format and publishes data to Amazon S3 and in a parallel data pipeline, Flink also publishes enriched data onto another Kafka topic, which further serves data to an Apache Druid cluster deployed on Amazon EC2 instances. Performance requirements for querying at scale All of the described data pipelines ingest data into an Amazon S3 based data lake, which is then leveraged by three types of Trino clusters – Ad-hoc clusters for ad-hoc query use cases, with a maximum query runtime of 20 minutes, ETL clusters for creating materialized views to enhance performance of dashboard queries, and Reporting clusters to run queries for dashboards with various Key Performance Indicators (KPIs), with query runtime upto 3 minutes. ETL queries are run via Apache Airflow with a built-in query retry mechanism and a runtime of up to 3 hours. Druid is used to serve two types of queries: computing aggregated metrics based on recent events and comparing aggregated metrics to historical data. For example, how is a specific metric in the current hour compared to the same last week. Depending on the use case, the service level objective for Druid query response time ranges from a few milliseconds to a few seconds. Graviton migration of Druid cluster Zomato first moved Druid nodes to AWS Graviton based instances in their test cluster environment to determine query performance. Nodes running brokers and middle-managers were moved from R5 to R6g instances and nodes running historicals were migrated from i3 to R6gd instances.   Zomato logged real-world queries from their production cluster and replayed them in their test cluster to validate the performance. Post validation, Zomato saw significant performance gains and reduced cost: Performance gains For queries in Druid, performance was measured using typical business hours (12:00 to 22:00 Hours) load of 14K queries, as shown here, where p99 query runtime reduced by 25%. Figure 4 – Overall Druid query performance (Intel x86-64 vs. AWS Graviton) Also, query performance improvement on the historical nodes of the Druid cluster are shown here, where p95 query runtime reduced by 66%. Figure 5 –Query performance on Druid Historicals (Intel x86-64 vs. AWS Graviton) Under peak load during business hours (12:00 to 22:00 Hours as shown in the provided graph), with increasingly loaded CPUs, Graviton based instances demonstrated close to linear performance resulting in better query runtime than equivalent Intel x86 based instances. This provided headroom to Zomato to reduce their overall node count in the Druid cluster for serving the same peak load query traffic. Figure 6 – CPU utilization (Intel x86-64 vs. AWS Graviton) Cost savings A Cost comparison of Intel x86 vs. AWS Graviton based instances running Druid in a test environment along with the number, instance types and hourly On-demand prices in the Singapore region is shown here. There are cost savings of ~24% running the same number of Graviton based instances. Further, Druid cluster auto scales in production environment based upon performance metrics, so average cost savings with Graviton based instances are even higher at ~30% due to better performance. Figure 7 – Cost savings analysis (Intel x86-64 vs. AWS Graviton) Graviton migration of Trino clusters Zomato also moved their Trino cluster in their test environment to AWS Graviton based instances and monitored query performance for different short and long-running queries. As shown here, mean wall (elapsed) time value for different Trino queries is lower on AWS Graviton instances than equivalent Intel x86 based instances, for most of the queries (lower is better). Figure 8 – Mean Wall Time for Trino queries (Intel x86-64 vs. AWS Graviton) Also, p99 query runtime reduced by ~33% after migrating the Trino cluster to AWS Graviton instances for a typical business day’s (7am – 7pm) mixed query load with ~15K queries. Figure 9 –Query performance for a typical day (7am -7pm) load Zomato’s team further optimized overall Trino query performance by enhancing Advanced Encryption Standard (AES) performance on Graviton for TLS negotiation with Amazon S3. It was achieved by enabling -XX:+UnlockDiagnosticVMOptions and -XX:+UseAESCTRIntrinsics in extra JVM flags. As shown here, mean CPU time for queries is lower after enabling extra JVM flags, for most of the queries. Figure 10 –Query performance after enabling extra JVM options with Graviton instances Migration challenges and approach Zomato team is using Trino version 359 and multi-arch or ARM64-compatible docker image for this Trino version was not available. As the team wanted to migrate their Trino cluster to Graviton based instances with minimal engineering efforts and time, they backported the Trino multi-arch supported UBI8 based Docker image to their Trino version 359.  This approach allowed faster adoption of Graviton based instances, eliminating the heavy lift of upgrading, testing and benchmarking the workload on a newer Trino version. Next Steps Zomato has already migrated AWS managed services including Amazon EMR and Amazon Aurora MySQL-Compatible database to AWS Graviton based instances. With the successful migration of two main open source software components (Trino and Druid) of their data platform to AWS Graviton with visible and immediate price-performance gains, the Zomato team plans to replicate that success with other open source applications running on Amazon EC2 including Apache Kafka, Apache Pinot, etc. Conclusion This post demonstrated the price/performance benefits of adopting AWS Graviton based instances for high throughput, near real-time big data analytics workloads running on Java-based, open source Apache Druid and Trino applications. Overall, Zomato reduced the cost of its Amazon EC2 usage by 30%, while improving performance for both time-critical and ad-hoc querying by as much as 25%. Due to better performance, Zomato was also able to right size compute footprint for these workloads on a smaller number of Amazon EC2 instances, with peak capacity of Apache Druid and Trino clusters reduced by 25% and 20% respectively. Zomato migrated these open source software applications faster by quickly implementing customizations needed for optimum performance and compatibility with Graviton based instances. Zomato’s mission is “better food for more people” and Graviton adoption is helping with this mission by providing a more sustainable, performant, and cost-effective compute platform on AWS. This is certainly a “food for thought” for customers looking forward to improve price-performance and sustainability for their business-critical workloads running on Open Source Software (OSS).

Apr 25, 2023