SuprSend is a central communication stack for easily creating, managing and delivering notifications to your end users on multiple channels. Our single notification API has all the features set, which enables you to send notifications in a reliable and scalable manner and take care of end user experience, thereby eliminating the need to develop any notification service in-house for transactional/engagement notifications.

SuprSend

In the world of mobile and web apps, certain platforms use App Inbox to provide instant transactional updates and enhance user engagement. App Inbox seamlessly integrates WebSocket or server-sent events (SSE) to ensure immediate delivery of updates to users. These platforms rely on agile data storage solutions, frequently hinging on NoSQL/relational databases, which effectively manage the influx of messages and notifications. The outcome is a swift and frictionless experience for users, who can access critical information as soon as they access the app. Let’s check out the 5 most common transactional use cases for which mobile inboxes are being used. 1. Order Confirmation and Real-Time Updates in Trading Apps Investment platforms like Fidelity Investments have harnessed the capabilities of App Inbox to transform the way users receive order confirmations and real-time updates. In the fast-paced world of trading, every second counts, and App Inbox ensures that users stay connected to their investments. ‍ ‍ When a user places an order, the trading app sends an instant order confirmation through App Inbox. As the order progresses, users receive real-time updates on their order status, market changes, and execution. This immediate feedback loop keeps users informed, engaged, and in control of their investments. With every interaction, App Inbox reinforces the connection between user actions and transactional responses. 2. Booking and Reservations Made Effortless Companies like MakeMyTrip have recognized the convenience that App Inbox brings to booking and reservation management. Whether it's flight bookings, hotel reservations, or event ticket purchases, users can access critical details without the hassle of searching through multiple sections or screens. Upon booking, users receive a transactional confirmation in their App Inbox. As the date of their scheduled event approaches, a gentle reminder with all the necessary details is readily available in the same space. Users can retrieve these messages effortlessly, enhancing their experience and simplifying their journey. 3. Membership Status Updates: Amazon Prime Amazon Prime, a leading e-commerce and streaming service, offers a prime example of utilizing App Inbox for membership status updates. Prime members receive regular notifications in their App Inbox, keeping them informed about subscription renewal, new content releases, and exclusive deals. ‍ ‍ App Inbox ensures that members are always aware of their current status and any actions required. For example, a reminder of an upcoming subscription renewal includes payment options and associated benefits. Users can seamlessly renew their membership or explore exclusive content, all within the app. 4. Payment Reminders: CRED CRED, a credit card payment management app, leverages App Inbox to send payment reminders and transaction updates to its users. CRED members receive timely notifications in their App Inbox, reminding them of upcoming credit card bill payments. These reminders not only serve as transactional notifications but also ensure users never miss a payment deadline. With a simple tap, users can make their credit card payments directly from the App Inbox, creating a seamless and efficient transactional experience. 5. Social Platforms for User Activity: LinkedIn and Quora Social platforms like LinkedIn and Quora harness the potential of App Inbox to provide users with a centralized hub for user-related activity. Instead of cluttering the main feed with notifications, they use App Inbox to create a dedicated space where users can conveniently access updates, messages, connection requests, and more. Want An Easy Way To Integrate App Inbox? With SuprSend, you can get started with app inbox in under 10 minutes. Integrate your preferred SDK, copy a few lines of code, and you can get started. Check . documentation ‍ Conclusion Dynamic interaction between the product and the user is at the core of App Inbox's value proposition. It ensures that users are always in the loop, whether they are making a critical financial decision, planning a journey, or managing their subscriptions in real time. The bridge between user actions and transactional responses, facilitated by App Inbox, enhances user engagement and satisfaction. Frequently Asked Questions 1. What Is the Purpose of a Mobile In-App Inbox? A Mobile In-App Inbox is designed to keep users informed in real-time by providing a central location for transactional updates, messages, and notifications within a mobile or web app. 2. How Does a Mobile In-App Inbox Improve User Engagement? By offering instant access to critical information and updates, a Mobile In-App Inbox enhances user engagement by connecting user actions with transactional responses seamlessly. 3. Can You Provide an Example of a Real-World Use Case for a Mobile In-App Inbox? Certainly, in the world of trading apps, users receive instant order confirmations and real-time updates on their orders, keeping them informed, engaged, and in control of their investments. 4. What Benefits Do Mobile In-App Inboxes Offer to Users? Mobile In-App Inboxes streamline user experiences, making it easier for users to access important details, stay informed, and take necessary actions promptly. 5. How Do Businesses Implement Mobile In-App Inboxes in Their Apps? Implementing Mobile In-App Inboxes involves integrating technologies like WebSocket or server-sent events to ensure immediate message delivery and agile data storage solutions for managing message and notification influx. Specific methods may vary based on platform and requirements.

5 Mobile Inbox Transactional Use-Cases That Businesses Are Using To Improve Customer Engagement

In the world of modern , building a resilient notification infrastructure is a strategic necessity. Senior developers and CTOs need to grasp the intricacies of notification systems, diving deep into why and how these components matter. software engineering Unveiling the Core of Notification Infrastructure and Architecture Let's unveil the fundamental components of notification infrastructure and architecture: 1. Message Queues and Brokers: The Backbone of Notifications Message queues manage the flow of notifications, ensuring asynchronous processing, preventing bottlenecks, and providing fault tolerance. They act as intermediaries that store, organize, and deliver messages. These messages can be notifications, tasks, or data. Message brokers like RabbitMQ and are pivotal in a notification system. They enhance reliability by guaranteeing message delivery and facilitating communication between infrastructure components. For instance, RabbitMQ implements the Advanced Message Queuing Protocol (AMQP), providing features like message acknowledgments and publish/subscribe patterns. Apache Kafka, on the other hand, is known for its high throughput and fault tolerance, making it an excellent choice for large-scale real-time data streaming. Apache Kafka 2. Real-time Communication Protocols: Enabling Low-Latency Communication Real-time communication protocols, including WebSocket and HTTP/2, are essential for low-latency communication. WebSocket is a full-duplex protocol that allows bidirectional communication between a client and server over a single, long-lived connection. This makes it ideal for scenarios where real-time updates are crucial, such as chat applications or live notifications. HTTP/2, an evolution of the traditional HTTP/1.1, offers multiplexing, header compression, and a binary framing layer. These technical enhancements significantly reduce latency and improve communication efficiency between clients and servers. 3. Database and Data Stores: The Heart of Personalization Databases and data stores are crucial for delivering personalized notifications based on user preferences and storing notification data. In a notification infrastructure, databases typically house user preferences, subscription data, and information related to notifications. Data stores like Redis, often used as an in-memory key-value database, facilitate fast data retrieval and caching, making them well-suited for real-time, personalized notifications. Redis is known for its lightning-fast read and write operations, enabling quick access to frequently accessed data, which is critical for real-time systems. 4. Scalable Server Clusters: Scaling for Workloads Scalable server clusters are essential to handle varying workloads, ensuring system reliability and high availability. When your application experiences increased demand, horizontal scaling allows you to add more servers to distribute the load effectively. Load balancing, a key scaling component, evenly distributes incoming network traffic across multiple servers. This ensures that no single server is overwhelmed, and it plays a critical role in maintaining the performance and reliability of a notification system. Furthermore, adopting a microservices architecture, where each component of your system operates as an independent service, enables flexible scaling and simplifies maintenance. The Technical Considerations in Crafting a Notification Infrastructure Let's delve into the specific technical factors that senior developers and CTOs should consider when crafting a notification infrastructure: 1. Reliability and Redundancy: Zero Downtime A notification infrastructure must prioritize reliability and minimize downtime. Redundancy and failover mechanisms ensure high availability. Redundancy involves creating backup systems, components, or data to ensure continuous operation in case of failures. Failover mechanisms are designed to automatically switch to a standby system or component when the primary one encounters issues. This ensures the notification system remains operational and reliable even when failures occur. With , you can access all your notification logs to identify the root cause for latency and resolve it on the go. SuprSend 2. Scalability: Coping with Workload Variations Scaling a notification system is a technical challenge, especially when faced with fluctuating workloads. Horizontal scaling, which involves adding more servers or resources, allows the system to accommodate increased demand. On the other hand, Microservices architecture breaks down the application into smaller, independent services, each capable of scaling independently. This approach enables fine-grained control over scalability and maintains high performance. 3. Customization and Personalization: Precision Matters Customization and personalization are key to delivering engaging notifications. Meeting user preferences and tailoring content to individual needs requires sophisticated technical solutions. Dynamic message customization is essential, where messages are generated and customized on the fly based on user data and behavior. Additionally, content personalization involves delivering relevant content to individual users, improving user engagement and satisfaction. 4. Security: Safeguarding Communication Security is a fundamental aspect of any notification infrastructure. Technical measures such as encryption, authentication, and data protection ensure that communication within the notification system remains secure. Encryption ensures that data is transmitted securely unreadably, protecting it from interception or tampering. Authentication mechanisms validate the identity of users or systems accessing the infrastructure, preventing unauthorized access. Data protection measures safeguard user data and sensitive information, ensuring compliance with privacy regulations. 5. Data Analytics and Monitoring: Real-time Insights Real-time analytics and monitoring are essential for tracking message delivery and system health. Monitoring tools like Prometheus and Grafana provide technical insights into the performance of the notification infrastructure. They allow senior developers and CTOs to diagnose technical issues, optimize system performance, and ensure seamless operation. Leveraging Specialized Services for Technical Excellence Specialized services, such as SuprSend, offer valuable technical advantages when architecting notification infrastructure: 1. Streamlined API Integration: Technical Simplicity SuprSend's APIs simplify integration with your app or website, offering a technical advantage. An API-driven approach ensures efficient communication by providing standardized endpoints and data formats for seamless data exchange. 2. Advanced Routing and Filtering: Precision Matters SuprSend's advanced routing and filtering options provide precise message targeting. These technical capabilities ensure that the right message reaches the right recipient, enhancing the efficiency and effectiveness of your notification strategy. 3. Push and Pull Mechanisms: Technical Flexibility SuprSend's push and pull mechanisms offer flexible communication, enabling efficient content updates and message retrieval. Push mechanisms are ideal for delivering real-time updates, while pull mechanisms allow recipients to retrieve content on-demand, reducing unnecessary network traffic. 4. Extensive Plugin Ecosystem: Technical Flexibility An extensive plugin ecosystem allows for customizing and extending functionality to meet specific technical needs. Developers can create custom plugins to add new features, integrate with external systems, or adapt the notification infrastructure to unique technical requirements. In Conclusion: Choosing the right notification infrastructure for your product application Crafting a notification infrastructure is a journey encompassing the art and science of communication. The technical parameters and strategies underpinning these systems are the foundations of successful digital engagement and user satisfaction. Also published here.

How to Choose the Right Notification Infrastructure for Your Website or App

Email notifications are a great way to keep your users informed about important events or updates in your application, such as a new message, a password reset, or a system failure. There are multiple methods for sending email notifications, and while the process may not be complex, it's important to choose the right approach for your needs. In this blog, we will be looking at how to send emails using Python with the help of code snippets. We will also compare the SMTP module used in Python with other popular solutions. Pre-Requisites Before getting started with this guide, there are a few things you will need to have to get the most out of it. Python installed on your machine Basic understanding of Python & CLI AWS account setup & understanding of AWS SES Working Suprsend account (with configured vendors) With these things in mind, you should be ready to get started! 4 Different Ways to Send Email Notifications with Python This section will discuss four different ways developers can send transactional emails using Python. Using Python Module smtplib The Python module can send emails using the Simple Mail Transfer Protocol ( ). SMTP is a protocol that is used to send and receive emails. The module includes functions that can be used to connect to an SMTP server and send emails. The module also includes functions that can authenticate with an SMTP server. smtplib SMTP smtplib ‍ Benefits of Using Python Module smtplib There are many benefits of using the module. For example, you can use to: smtplib smtplib Send emails from your Python program Send emails from a script (automated scripts, corn jobs, etc.) Send mass emails Send HTML emails Send attachments Drawbacks of smtplib Module There are a few potential drawbacks to using SMTP to send python emails. One is that it can be less reliable than other methods; sometimes, emails sent via SMTP get lost or end up in spam folders. Additionally, SMTP relies on several complex protocols, making it difficult to configure and troubleshoot. Maintaining and upgrading SMTP servers can also entail additional costs. ‍ Steps To Send Email via SMTP Python Module You can use MIMEText or EmailMessage module to create and format the message. Below are the steps to send an email using Python with the and module. smtplib MIMEText Import the and modules from the email library. smtplib MIMEText Create a new object and set the body of the email, the sender, the recipient, and the subject. MIMEText Establish a connection to the SMTP server using the function, passing in the server's hostname as an argument. smtplib.SMTP() Use the function to send the email. send_message() Use the function to close the connection to the server. quit() Use a try/except block to catch any exceptions that may be thrown during the sending process. Code Snippet Replace the SMTP server address (localhost) with your server address before running the below code. Note: ‍ Transactional Email Service Providers ‍ Transactional Email Service Providers (TESPs) enable businesses to send transactional emails. There are many options to choose from, including Amazon SES, Mailgun, Sendgrid, Postmark, and Sparkpost, each with its own benefits and features. ‍ It's important to select a TESP that meets your needs in terms of pricing, delivery rates, scalability, and support and also offers a strong API for integration into your system. ‍ Benefits of Transactional Email Service Providers Transactional Email Service Providers (TESP) offer several advantages over traditional email providers. TESPs are designed to provide a higher level of service and reliability for businesses that rely on email to communicate with their customers. TESPs can provide a cost-effective way to send transactional emails, as they typically charge based on the number of emails sent or received. TESPs typically offer several features that are not available with traditional email providers, such as dedicated IP addresses, real-time monitoring, and delivery reports. ‍ Drawbacks of Transactional Email Service Providers TESPs can be challenging to set up and use, leading to the need for developers. TESPs typically offer API-based integration; thus, the email content layout, such as HTML templates, must be integrated via APIs. TESPs can be cost-efficient when sending a relatively low volume of emails, yet as the volume increases, it may become an expensive option. Poor configuration can lead to emails being sent to spam folders. Certain TESPs may have suboptimal email-sending configurations, such as using IP addresses with a negative reputation that is shared among multiple users. This section will use Python with AWS SES to send emails. AWS SES is a cloud-based email service that lets you send and receive emails securely. It offers a cost-effective, pay-as-you-go pricing model and provides a scalable, reliable, and secure platform for email delivery. ‍ Steps To Send Email Using AWS SES We'll use the Boto3 library to interact with AWS SES. Here are the steps followed in AWS SES send email python process. ‍ Import the necessary libraries and modules: and ClientError from . boto3 botocore.exceptions Define the send_email() function, which takes six arguments: the sender and recipient email addresses, the subject and body of the email, and the name of the AWS region where the SES service is located. Create a new client for the SES service in the specified region using the function. boto3.client() Use the method of the SES client to send the email, specifying the contents of the email (subject, body, recipient) in the Destination and Message parameters. send_email() Catch any errors when emailing using a block and print the error message. try-except If the email is sent successfully, return . Otherwise, return . True False ‍ Code Snippet ‍ Using Suprsend Suprsend is a platform that allows developers to create and manage notifications across multiple channels, such as email, SMS, push notifications, inbox messages, and chat. SuprSend workflows simplify the process of building and managing complex notifications and performance tracking to monitor the effectiveness of the messages. Using a single API, streamlines the sending process and eliminates the need for developers to write their own notification service layer. ‍ Benefits of using Suprsend: It is highly scalable and can be used to develop notifications for any number of users. SuprSend has built-in integration with TESP(s) SMTP and Gmail SMTP, so developers don’t have to do setup or point-to-point API integration with them. This feature allows for seamless switching between vendors without the constraint of being locked into a specific one. allows developers to easily trigger multi-channel notifications with a single trigger. This can be extremely useful for applications that communicate with multiple channels or devices. SuprSend's Python SDK Suprsend doesn't require any infrastructure setup or maintenance. It's a cloud-based solution that's easy to use and scale. Steps To Send Emails Using SuprSend ‍ Installing Suprsend Python SDK To get started, first install Suprsend Python SDK using the following command: pip install suprsend-py-sdk To send notifications using Suprsend, you’ll need a (for authentication). You can modify the default workflow and notification template or can create a new workflow and template. Workspace Key & Secret ‍ Note: We have created a sample template and workflow on the SuprSend platform for this tutorial. Python Code to Send Email using SuprSend ‍ Adding Attachments with Email ‍ Adding python email attachments using Suprsend is a piece of cake. Add the following code snippets to an attachment via a file path directly. The workflow object will look something like this: ‍ Using Gmail SMTP Gmail is one of the most popular email providers, and for a good reason. It's free, it's easy to use, and it's packed with features. But did you know that you can also use Gmail with Python? Yes, it's true! You can use the Gmail API to send and receive emails with Python. And the best part is that it's not even that difficult. This section will show you how to send emails using Gmail with Python. ‍ Benefits of Gmail API There are many benefits to using the Gmail API to send emails. Perhaps the most obvious benefit is that it allows you to send emails directly from your Gmail account, which can be very convenient. Additionally, the Gmail API can provide a more reliable and responsive experience than other email-sending methods. And because the Gmail API is integrated with other Google services, it can offer some unique features and advantages that other email providers cannot match. ‍ Drawbacks of Gmail API There are a few drawbacks to using the Gmail API: To use Gmail API, you must use email credentials (username & password), which are less secure. Maintaining the account will always be an issue if you plan to use a separate service account. Gmail has the following hard limits on sending emails: Maximum messages per day: 2,000 (1,500 for multi-send & 500 for a trial account) Total recipients per day: 10,000 Companies avoid using Gmail as a scalable email solution because of its drawbacks. Learn more about . Gmail API usage limits Code Snippet ‍ Conclusion And with that, we hope we have given you a comprehensive guide on using Python to send emails. If you are looking for a multi-channel scalable notification solution and a way to make your development process more streamlined and efficient, check out SuprSend. #email #amazonses #pythonemail Disclaimer: The introduction part was AI-generated.‍

Using Python for Sending Email Notifications (Code Examples Included)

Uso de Python para enviar notificaciones por correo electrónico (ejemplos de código incluidos)

Utilisation de Python pour envoyer des notifications par e-mail (exemples de code inclus)

ईमेल सूचनाएं भेजने के लिए पायथन का उपयोग करना (कोड उदाहरण शामिल)

Python を使用して電子メール通知を送信する (コード例を含む)

Usando Python para enviar notificações por e-mail (exemplos de código incluídos)

Sử dụng Python để gửi thông báo qua email (Đã bao gồm mã ví dụ)

使用 Python 发送电子邮件通知（包括代码示例）

Frequent alerts can lead to notification fatigue, causing users to disengage. I knew that by batching notifications, we could maintain user attention and promote sustained interaction with our platform. However, setting up an efficient batching system required some complex workflows and significant development resources. You can explore the hands-on implementation through the following links:

GitHub: Github Social App
Deployed Application: Github Project Demo The Batching Concept The concept of batching notifications involves several technical components: Aggregation Engine: This engine efficiently aggregates related notifications, such as likes, shares, and comments, based on metadata attributes. For example, Instagram separates notifications for story likes and comments to ensure clarity.
Batching Window: The batching window can be fixed (e.g., every 30 minutes) or dynamic (e.g., user-specific intervals). For instance, LinkedIn batches email alerts for new messages every 30 minutes, while Google Docs batches comments based on user activity.
Scheduling: This determines the optimal time for delivering notifications. It could be immediately, at the end of a batching window, or at a strategic time. Many SaaS companies send a daily digest of activities the following morning.
Batched Message Presentation: Options range from simple counters to detailed summaries, balancing informativeness and engagement without overwhelming the user. For example, "Patrick and 3 others liked your photo" versus listing all activities.
Cancelling Aggregation: This adjusts the aggregation counter for counter-activities within the batching window. For example, if a user likes and then unlikes a post within the batching window, the counter is adjusted accordingly. Building the Demo Application To demonstrate this, I chose to build a React application using SuprSend's robust notification infrastructure. Here’s a step-by-step account of how I did it: Setting Up the Project:


I started by creating a React application and integrating SuprSend's SDK.


I set up a SuprSend account and ensured successful event calls were made to SuprSend with the necessary details.




Identifying Triggers:


I identified recurring events suitable for batching. For this demo, I used the Like_Event whenever someone likes a post. Using SuprSend’s JavaScript SDK, I sent these events to the backend.








Configuring Batch Parameters:

Using SuprSend’s workflow builder, I configured the batch parameters:


Batch Window: I set a fixed batch window of 15 seconds for quick testing.


Batch Key: I defined a custom batch key based on the userName variable to batch likes on different posts separately.


Retain Batch Events: I chose to retain 15 objects in the array for this demo.






Creating Notification Templates:


I created templates in SuprSend’s editor using Handlebar Helpers to format notifications based on the batched event count. The template looked like this:
{{#compare $batched_events_count '>' 1}} 
{{ $batched_events.[0].username }} and {{ subtract $batched_events_count 1 }} others liked your post. 
{{else}} 
{{ $batched_events.[0].username }} liked your post.
{{/compare}} The final result? A neat batched notification. Implementing Throttling While batching reduces the total number of notifications, I realized that introducing throttling could further enhance user experience by limiting the frequency of notifications. Users would not be overwhelmed even with multiple batches by setting an upper limit on daily notifications. Will tell in next tutorial how I implemented that. The Result The final demo application successfully demonstrated how batching notifications could improve user engagement. You can explore the hands-on implementation through the following links: GitHub: Github Social App
Deployed Application: Github Project Demo Frequent alerts can lead to notification fatigue, causing users to disengage. I knew that by batching notifications, we could maintain user attention and promote sustained interaction with our platform. However, setting up an efficient batching system required some complex workflows and significant development resources. You can explore the hands-on implementation through the following links: GitHub: Github Social App
Deployed Application: Github Project Demo You can explore the hands-on implementation through the following links: GitHub: Github Social App Deployed Application: Github Project Demo GitHub: Github Social App Social App Deployed Application: Github Project Demo Github Project Demo The Batching Concept The concept of batching notifications involves several technical components: Aggregation Engine: This engine efficiently aggregates related notifications, such as likes, shares, and comments, based on metadata attributes. For example, Instagram separates notifications for story likes and comments to ensure clarity. Batching Window: The batching window can be fixed (e.g., every 30 minutes) or dynamic (e.g., user-specific intervals). For instance, LinkedIn batches email alerts for new messages every 30 minutes, while Google Docs batches comments based on user activity. Scheduling: This determines the optimal time for delivering notifications. It could be immediately, at the end of a batching window, or at a strategic time. Many SaaS companies send a daily digest of activities the following morning. Batched Message Presentation: Options range from simple counters to detailed summaries, balancing informativeness and engagement without overwhelming the user. For example, "Patrick and 3 others liked your photo" versus listing all activities. Cancelling Aggregation: This adjusts the aggregation counter for counter-activities within the batching window. For example, if a user likes and then unlikes a post within the batching window, the counter is adjusted accordingly. Aggregation Engine : This engine efficiently aggregates related notifications, such as likes, shares, and comments, based on metadata attributes. For example, Instagram separates notifications for story likes and comments to ensure clarity. Aggregation Engine Batching Window : The batching window can be fixed (e.g., every 30 minutes) or dynamic (e.g., user-specific intervals). For instance, LinkedIn batches email alerts for new messages every 30 minutes, while Google Docs batches comments based on user activity. Batching Window Scheduling : This determines the optimal time for delivering notifications. It could be immediately, at the end of a batching window, or at a strategic time. Many SaaS companies send a daily digest of activities the following morning. Scheduling Batched Message Presentation : Options range from simple counters to detailed summaries, balancing informativeness and engagement without overwhelming the user. For example, "Patrick and 3 others liked your photo" versus listing all activities. Batched Message Presentation Cancelling Aggregation : This adjusts the aggregation counter for counter-activities within the batching window. For example, if a user likes and then unlikes a post within the batching window, the counter is adjusted accordingly. Cancelling Aggregation Building the Demo Application To demonstrate this, I chose to build a React application using SuprSend's robust notification infrastructure. Here’s a step-by-step account of how I did it: Setting Up the Project:


I started by creating a React application and integrating SuprSend's SDK.


I set up a SuprSend account and ensured successful event calls were made to SuprSend with the necessary details. Identifying Triggers:


I identified recurring events suitable for batching. For this demo, I used the Like_Event whenever someone likes a post. Using SuprSend’s JavaScript SDK, I sent these events to the backend. Configuring Batch Parameters:

Using SuprSend’s workflow builder, I configured the batch parameters:


Batch Window: I set a fixed batch window of 15 seconds for quick testing.


Batch Key: I defined a custom batch key based on the userName variable to batch likes on different posts separately.


Retain Batch Events: I chose to retain 15 objects in the array for this demo. Creating Notification Templates:


I created templates in SuprSend’s editor using Handlebar Helpers to format notifications based on the batched event count. The template looked like this:
{{#compare $batched_events_count '>' 1}} 
{{ $batched_events.[0].username }} and {{ subtract $batched_events_count 1 }} others liked your post. 
{{else}} 
{{ $batched_events.[0].username }} liked your post.
{{/compare}} Setting Up the Project: I started by creating a React application and integrating SuprSend's SDK.


I set up a SuprSend account and ensured successful event calls were made to SuprSend with the necessary details. Setting Up the Project : Setting Up the Project I started by creating a React application and integrating SuprSend's SDK. I set up a SuprSend account and ensured successful event calls were made to SuprSend with the necessary details. I started by creating a React application and integrating SuprSend's SDK. I started by creating a React application and integrating SuprSend's SDK. I set up a SuprSend account and ensured successful event calls were made to SuprSend with the necessary details. I set up a SuprSend account and ensured successful event calls were made to SuprSend with the necessary details. Identifying Triggers: I identified recurring events suitable for batching. For this demo, I used the Like_Event whenever someone likes a post. Using SuprSend’s JavaScript SDK, I sent these events to the backend. Identifying Triggers : Identifying Triggers I identified recurring events suitable for batching. For this demo, I used the Like_Event whenever someone likes a post. Using SuprSend’s JavaScript SDK, I sent these events to the backend. I identified recurring events suitable for batching. For this demo, I used the Like_Event whenever someone likes a post. Using SuprSend’s JavaScript SDK, I sent these events to the backend. I identified recurring events suitable for batching. For this demo, I used the Like_Event whenever someone likes a post. Using SuprSend’s JavaScript SDK, I sent these events to the backend. Like_Event Configuring Batch Parameters: Using SuprSend’s workflow builder, I configured the batch parameters:


Batch Window: I set a fixed batch window of 15 seconds for quick testing.


Batch Key: I defined a custom batch key based on the userName variable to batch likes on different posts separately.


Retain Batch Events: I chose to retain 15 objects in the array for this demo. Configuring Batch Parameters : Configuring Batch Parameters Using SuprSend’s workflow builder, I configured the batch parameters:


Batch Window: I set a fixed batch window of 15 seconds for quick testing.


Batch Key: I defined a custom batch key based on the userName variable to batch likes on different posts separately.


Retain Batch Events: I chose to retain 15 objects in the array for this demo. Using SuprSend’s workflow builder, I configured the batch parameters: Batch Window: I set a fixed batch window of 15 seconds for quick testing.


Batch Key: I defined a custom batch key based on the userName variable to batch likes on different posts separately.


Retain Batch Events: I chose to retain 15 objects in the array for this demo. Batch Window: I set a fixed batch window of 15 seconds for quick testing. Batch Key: I defined a custom batch key based on the userName variable to batch likes on different posts separately. Retain Batch Events: I chose to retain 15 objects in the array for this demo. Batch Window: I set a fixed batch window of 15 seconds for quick testing. Batch Window : I set a fixed batch window of 15 seconds for quick testing. Batch Window Batch Key: I defined a custom batch key based on the userName variable to batch likes on different posts separately. Batch Key : I defined a custom batch key based on the userName variable to batch likes on different posts separately. Batch Key Retain Batch Events: I chose to retain 15 objects in the array for this demo. Retain Batch Events : I chose to retain 15 objects in the array for this demo. Retain Batch Events Creating Notification Templates: I created templates in SuprSend’s editor using Handlebar Helpers to format notifications based on the batched event count. The template looked like this:
{{#compare $batched_events_count '>' 1}} 
{{ $batched_events.[0].username }} and {{ subtract $batched_events_count 1 }} others liked your post. 
{{else}} 
{{ $batched_events.[0].username }} liked your post.
{{/compare}} Creating Notification Templates : Creating Notification Templates I created templates in SuprSend’s editor using Handlebar Helpers to format notifications based on the batched event count. The template looked like this:
{{#compare $batched_events_count '>' 1}} 
{{ $batched_events.[0].username }} and {{ subtract $batched_events_count 1 }} others liked your post. 
{{else}} 
{{ $batched_events.[0].username }} liked your post.
{{/compare}} I created templates in SuprSend’s editor using Handlebar Helpers to format notifications based on the batched event count. The template looked like this: {{#compare $batched_events_count '>' 1}} 
{{ $batched_events.[0].username }} and {{ subtract $batched_events_count 1 }} others liked your post. 
{{else}} 
{{ $batched_events.[0].username }} liked your post.
{{/compare}} I created templates in SuprSend’s editor using Handlebar Helpers to format notifications based on the batched event count. The template looked like this: {{#compare $batched_events_count '>' 1}} 
{{ $batched_events.[0].username }} and {{ subtract $batched_events_count 1 }} others liked your post. 
{{else}} 
{{ $batched_events.[0].username }} liked your post.
{{/compare}} {{#compare $batched_events_count '>' 1}} 
{{ $batched_events.[0].username }} and {{ subtract $batched_events_count 1 }} others liked your post. 
{{else}} 
{{ $batched_events.[0].username }} liked your post.
{{/compare}} The final result? The final result? The final result? A neat batched notification. Implementing Throttling While batching reduces the total number of notifications, I realized that introducing throttling could further enhance user experience by limiting the frequency of notifications. Users would not be overwhelmed even with multiple batches by setting an upper limit on daily notifications. Will tell in next tutorial how I implemented that. The Result The final demo application successfully demonstrated how batching notifications could improve user engagement. You can explore the hands-on implementation through the following links: GitHub: Github Social App Deployed Application: Github Project Demo GitHub: Github Social App Github Social App Deployed Application: Github Project Demo Github Project Demo

Creating Batched Notifications in a Dedicated Time Window for Better UX and Saving Notification Cost

Creating Production Grade Microservices with Go and gRPC

In the realm of modern software engineering, establishing a robust notification infrastructure is not just a preference but a strategic imperative. Notification systems, whether tailored for web or mobile applications, are pivotal for ensuring user engagement. However, the complexities of building and managing these systems can pose substantial challenges. This article aims to delve into the advantages of harnessing within the context of notification systems, underlining concrete real-world instances and providing in-depth technical insights. serverless architectures The Advantages of Serverless Architectures for Notifications Here are some advantages of serverless architecture for notifications. 1. Enhanced Scalability and Elasticity The flow of notification traffic is inherently dynamic, often experiencing surges during specific events or at particular times of the day. Serverless architectures provide the requisite scalability and elasticity to gracefully handle these peaks. Let's dive into the implementation of serverless platforms like AWS Lambda for executing notification logic. Technical Implementation 1: AWS Lambda Function for Sending Notifications import boto3

sns = boto3.client('sns')

def send_notification(event, context):
    user_id = event['user_id']
    message = event['message']
    
    # Insert your custom notification logic here
    response = sns.publish(
        TopicArn='arn:aws:sns:us-east-1:123456789012:MyTopic',
        Message=message,
        Subject='Notification',
        MessageStructure='string'
    )
    
    return {
        'statusCode': 200,
        'body': f'Notification sent to user {user_id}'
    } This example demonstrates how an is triggered to send notifications. Notably, the serverless platform takes charge of scaling, allowing you to concentrate on refining the notification logic. AWS Lambda function Real-world Example: WhatsApp's New Feature Announcement Consider WhatsApp's recent introduction of a new feature. In a matter of hours, millions of users receive notifications. A serverless architecture seamlessly scales to accommodate this influx, ensuring that every user receives timely updates. 2. Cost Efficiency Traditional server-based architectures entail provisioning servers to handle the anticipated peak loads. Often, this results in underutilized resources and heightened operational expenses. Serverless architectures, in contrast, charge only for actual usage, rendering them cost-efficient. Real-world Example: Cost Reduction at Coca-Cola Coca-Cola, a global brand, significantly reduced operational costs within its notification system by transitioning to a serverless architecture. They now exclusively pay for executed function invocations, resulting in substantial cost savings. 3. Reduction in Operational Overhead The management of servers, software patching, and infrastructure maintenance can be resource-intensive. A serverless architecture alleviates these responsibilities by shifting them to the cloud provider, effectively reducing operational overhead. Technical Implementation 2: Streamlined Serverless Deployments with AWS SAM AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'

Resources:
  MyServerlessFunction:
    Type: 'AWS::Serverless::Function'
    Properties:
      Handler: index.send_notification
      Runtime: python3.8
      Events:
        MyNotificationEvent:
          Type: S3
          Properties:
            Bucket: my-bucket
            Events: s3:ObjectCreated:*

Outputs:
  NotificationFunction:
    Description: "My Notification Lambda Function ARN"
    Value:
      Fn::GetAtt:
        - MyServerlessFunction
        - Arn This AWS SAM (Serverless Application Model) template showcases the configuration of a serverless function with an S3 event trigger. This YAML-based setup automates deployments, effectively reducing the operational workload. Real-world Example: CloudCore's Shift to Serverless CloudCore, an enterprise entity, migrated to a serverless architecture, resulting in a 30% reduction in the workload of their operational team. They now channel more efforts into optimizing notification strategies as opposed to infrastructure maintenance. The Constituents of a Serverless Notification System A serverless notification system comprises a synergy of various components designed to deliver messages efficiently. Let's explore these components through tangible examples. 1. Lambda Functions AWS Lambda functions serve as the lifeblood of a serverless notification system, executing the notification logic upon activation. Real-world Example: Netflix's Content Recommendations Netflix harnesses Lambda functions for rendering personalized content recommendations. These functions trigger notifications about recommended shows when user preferences change, thereby elevating user engagement. Technical Implementation 3: Lambda Function with Event Trigger import boto3

sns = boto3.client('sns')

def send_notification(event, context):
    user_id = event['user_id']
    message = event['message']

    # Embed your custom notification logic here
    response = sns.publish(
        TopicArn='arn:aws:sns:us-east-1:123456789012:MyTopic',
        Message=message,
        Subject='Notification',
        MessageStructure='string'
    )

    return {
        'statusCode': 200,
        'body': f'Notification sent to user {user_id}'
    } This code example demonstrates the creation of a Lambda function that dispatches notifications upon event triggers. 2. API Gateway API Gateway bridges clients and serverless functions, facilitating secure and efficient communication with the notification system. Real-world Example: Spotify's API Gateway Spotify's API Gateway streamlines the integration of its notification system for developers. It provides endpoints for sending notifications, empowering developers to control the user experience effectively. Technical Implementation 4: Definition of an API Gateway Endpoint MyApi:
  Type: AWS::ApiGateway::RestApi
  Properties:
    Name: MyNotificationApi

  MyResource:
    Type: AWS::ApiGateway::Resource
    Properties:
      RestApiId: !Ref MyApi
      ParentId: !GetAtt MyApi.RootResourceId
      PathPart: 'notifications' This AWS CloudFormation template is dedicated to establishing an API Gateway endpoint for notifications. 3. Data Storage For notification systems, data storage serves as a fundamental requirement for preserving user preferences, subscription data, and notification details. While serverless systems are primarily event-driven, the need for data persistence arises, especially for personalization purposes. Technical Implementation 5: Leveraging Amazon DynamoDB for Storing User Preferences import boto3

dynamodb = boto3.client('dynamodb')

def save_user_preferences(user_id, preferences):
    response = dynamodb.put_item(
        TableName='UserPreferences',
        Item={
            'UserId': {'S': user_id},
            'Preferences': {'S': preferences}
        }
    )
    return response In this example, Amazon DynamoDB is employed to store user preferences, which are pivotal for tailoring notifications. Real-world Example: Airbnb's Personalization Engine Airbnb leverages DynamoDB for storing user preferences and booking history. This data forms the foundation for personalizing notification content, including travel recommendations and special offers. 4. Real-time Analytics and Monitoring The maintenance of a robust notification system necessitates real-time analytics and monitoring tools. Platforms like Amazon CloudWatch provide insights into performance and expedite the debugging process. Real-world Example: Uber's Real-time Analytics Uber effectively uses real-time analytics to monitor the delivery times and success rates of their notifications. This data is invaluable for fine-tuning their notification strategy and ensuring the prompt delivery of ride updates. Addressing Traffic Peaks During significant events or marketing campaigns, notification systems can experience a sudden surge in traffic. Serverless architectures are explicitly designed to manage such surges effectively. Auto-scaling Serverless platforms autonomously scale in response to the volume of incoming events. Be it Black Friday sales or breaking news updates, your system is equipped to manage the load. Concurrency Control While scaling is an automatic process, you can manage the maximum concurrency to prevent unexpected billing spikes. Define concurrency limits that align with your budget and expected traffic. Technical Implementation 6: Establishing AWS Lambda Concurrency Limits MyNotificationFunction:
  Type: 'AWS::Serverless::Function'
  Properties:
    Handler: index.send_notification
    Runtime: python3.8
    ReservedConcurrentExecutions: 100  # Set your desired limit In this AWS SAM template, we set a concurrency limit for an AWS Lambda function. Real-world Example: Zappy's Flash Sales Zappy, an e-commerce platform, conducts flash sales that generate a substantial surge in traffic. With the assistance of serverless auto-scaling and concurrency control, they adeptly manage the sudden influx of user activity. Security Considerations Given their frequent handling of sensitive user data, security assumes paramount significance in notification systems. The following are key security considerations and their corresponding technical implementations. Authentication and Authorization It is essential to ensure that only authorized users or systems can access your notification infrastructure. Authentication mechanisms like OAuth or API keys must be diligently implemented. Technical Implementation 7: OAuth Authentication for API Gateway MyApi:
  Type: AWS::ApiGateway::RestApi
  Properties:
    Name: MyNotificationApi

  MyResource:
    Type: AWS::ApiGateway::Resource
    Properties:
      RestApiId: !Ref MyApi
      ParentId: !GetAtt MyApi.RootResourceId
      PathPart: 'notifications'

  MyMethod:
    Type: AWS::ApiGateway::Method
    Properties:
      AuthorizationType: CUSTOM
      AuthorizerId: !ImportValue MyCustomAuthorizer
      RestApiId: !Ref MyApi
      ResourceId: !GetAtt MyResource.Id
      HttpMethod: POST This CloudFormation template showcases the configuration of OAuth authentication for an API Gateway endpoint. OAuth guarantees that only authenticated users can access notification endpoints. Data Encryption To safeguard against unauthorized access, data must be encrypted both at rest and in transit. Utilizing and serverless functions is indispensable for preserving data integrity and confidentiality. HTTPS for secure client communication Error Handling Robust error handling is a pivotal facet of security. Implementing comprehensive error handling mechanisms, including logging and auditing, facilitates the prompt detection and response to security threats, thereby averting potential breaches. Access Control The implementation of fine-grained access control is instrumental in restricting access to sensitive data and notification logic. By skillfully managing permissions and access policies, you can ensure that only authorized entities can interact with your notification system. In Conclusion Serverless architectures bring substantial benefits when constructing notification systems. They endow these systems with scalability, reduce operational overhead, and offer cost-efficiency. With the right design and security considerations, a serverless notification system can effectively engage users and dispatch timely updates. Serverless is more than just a buzzword; it represents a pragmatic approach to crafting robust and efficient notification systems capable of meeting the demands of contemporary applications and users. Whether you hold the role of a CTO or a senior developer, contemplating serverless architectures for notifications is a strategic choice capable of elevating user engagement and operational efficiency. The realm of serverless notification infrastructure, architecture, and system design harbors the potential to revolutionize how information is disseminated to users. Embracing this technology is not merely an option but imperative in today's rapidly evolving digital landscape. As you embark on your journey to explore serverless solutions for your notification system, remember the technical advantages and real-world illustrations elucidated in this article.

Building Serverless Notification Architecture Design Using AWS: A Step-by-Step Guide for Developers

In the , we figured out how to implement  server-side interceptors. In this article, we try to figure out how to log GRPC requests on the client side. We must implement three interfaces ClientInterceptor, ClientCall, and ClientCall.Listener. previous article There are default implementations such as SimpleForwardingClientCall and SimpleForwardingClientCallListener in which all methods are implemented. If we look at their implementation, we can see that they invoke a next implementation ClientCall or ClientCall.Listener. The Implementation Our implementation will be straightforward; we will store requests and responses in Queues, and then put this data to MDC. First, let’s implement ClientCall.Listener. import com.google.protobuf.GeneratedMessageV3
import com.google.protobuf.util.JsonFormat
import io.grpc.ClientCall
import io.grpc.ForwardingClientCallListener.SimpleForwardingClientCallListener
import io.grpc.Metadata
import io.grpc.Status
import org.slf4j.LoggerFactory
import org.slf4j.MDC
import java.util.Queue

class LoggingClientCallListener<ReqT, ResT>(
    delegate: ClientCall.Listener<ResT>,
    private val requestQueue: Queue<ReqT>,
    private val responseQueue: Queue<ResT>
) : SimpleForwardingClientCallListener<ResT>(delegate) {

    override fun onMessage(message: ResT) {
        responseQueue.offer(message)
        super.onMessage(message)
    }

    override fun onClose(status: Status, trailers: Metadata) {
        val request = requestQueue
            .filterIsInstance<GeneratedMessageV3>()
            .joinToString(separator = ", ", prefix = "[", postfix = "]", transform = PROTOBUF_TO_JSON_PRINTER::print)

        val response = responseQueue
            .filterIsInstance<GeneratedMessageV3>()
            .joinToString(separator = ", ", prefix = "[", postfix = "]", transform = PROTOBUF_TO_JSON_PRINTER::print)

        if (status.isOk) {
            MDC.put("request", request)
            MDC.put("response", response)
            logger.info("The request was processed successfully")
            MDC.clear()
        } else if (UNSUCCESSFUL_STATUS_CODES.contains(status.code)) {
            MDC.put("request", request)
            logger.error("An error occurred while processing the request", status.asRuntimeException())
            MDC.clear()
        }

        super.onClose(status, trailers)
    }

    companion object {
        private val logger = LoggerFactory.getLogger(LoggingServerCallListener::class.java)
        private val PROTOBUF_TO_JSON_PRINTER = JsonFormat.printer()
        private val UNSUCCESSFUL_STATUS_CODES = listOf(
            Status.INVALID_ARGUMENT.code,
            Status.INTERNAL.code,
            Status.NOT_FOUND.code
        )
    }
} We have overridden the two methods. First, we have overridden the onMessage method. The method will be invoked before the client will receive data. The method can be invoked from zero to n times if the method result is defined as Stream. Second, we have overridden the onClose method. The method will be called before the client closes the connection, and no data will be retrieved after that. After that, we must implement the interface ClientCall. import io.grpc.ClientCall
import io.grpc.ForwardingClientCall.SimpleForwardingClientCall
import io.grpc.Metadata
import java.util.*

class LoggingClientCall<ReqT, RespT>(
    delegate: ClientCall<ReqT, RespT>,
    private val requestQueue: Queue<ReqT>,
    private val responseQueue: Queue<RespT>
) : SimpleForwardingClientCall<ReqT, RespT>(delegate) {

    override fun sendMessage(message: ReqT) {
        requestQueue.offer(message)
        super.sendMessage(message)
    }

    override fun start(responseListener: Listener<RespT>, headers: Metadata) {
        super.start(LoggingClientCallListener(responseListener, requestQueue, responseQueue), headers)
    }
} We have overridden two methods also. First, we have overridden the sendMessage method. This method will be invoked before a message will be sent to a service. We push our message to the queue. In the next method, we create our implementation of our LoggingClientCallListener. This method will be invoked before all methods. Next, we must implement our client interceptor and register this interceptor in the stub. import io.grpc.*
import java.util.concurrent.LinkedBlockingDeque

class LoggingClientInterceptor : ClientInterceptor {
    override fun <ReqT : Any, RespT : Any> interceptCall(
        method: MethodDescriptor<ReqT, RespT>,
        callOptions: CallOptions,
        next: Channel
    ): ClientCall<ReqT, RespT> {
        return LoggingClientCall(next.newCall(method, callOptions), LinkedBlockingDeque(), LinkedBlockingDeque())
    }
} fun main(args: Array<String>) {
	val client = OurServiceGrpc
		.newBlockingStub(ManagedChannelBuilder.forAddress("localhost", 8080).build())
		.withInterceptors(LoggingClientInterceptor())
} I hope I managed to show you how to use server and client interceptors in GRPC.

How to Implement Client-Side Interceptors for Logging GRPC Requests

Once, I had a requirement to implement server-side logging for GRPC requests. GRPC has an interceptor mechanism that can be used for logging, GRPC request verification, authentication, etc. To intercept requests on the server side, it is necessary to implement ServerInterceptor. And inherit two abstract classes, ServerCall and ServerCall.Listener. First, let’s make our implementation of ServerCall.Listener. There is ForwardingServerCallListener that gives calls to the next listener in the chain. We will extend this class and override the method onMessage. We will use the ConcurrentLinkedQueue for storing received requests. This method might be invoked more than one time if using client-side streaming. Also, there are the onComplete and onCancel methods that will be invoked after completing the GRPC request or after the client’s cancelation. Our implementation uses the queue for storing sent requests. class LoggingServerCallListener<ReqT>(
    private val delegate: ServerCall.Listener<ReqT>,
    private val input: ConcurrentLinkedQueue<ReqT>
) : ForwardingServerCallListener<ReqT>() {

    override fun delegate(): ServerCall.Listener<ReqT> {
        return delegate
    }

    override fun onMessage(message: ReqT) {
        super.onMessage(message)
        input.offer(message)
    }
} Next, we need to implement the ServerCall class. There is the implementation SimpleForwardingServerCall that works as ForwardingServerCallListener for ServerCall.Listener. We will use the same instance of ConcurrentLinkedQueue for getting received requests. Also, we will use another instance of the queue for storing sent responses. We will implement the sendMessage method that invokes before a response is sent to a client. This method can be invoked more than once if the result is server-side streaming. We will also override the close method, which will be called after all data has been sent to the client or an error occurs. The method ensures that there will be no further calls to onMessage or sendMessage. import com.google.protobuf.GeneratedMessageV3
import com.google.protobuf.util.JsonFormat
import io.grpc.ForwardingServerCall.SimpleForwardingServerCall
import io.grpc.Metadata
import io.grpc.ServerCall
import io.grpc.Status
import org.slf4j.LoggerFactory
import java.util.concurrent.ConcurrentLinkedQueue

class LoggingServerCall<RequestType, ResponseType>(
    delegate: ServerCall<RequestType, ResponseType>,
    private val metadata: Metadata,
    private val input: ConcurrentLinkedQueue<RequestType>,
    private val output: ConcurrentLinkedQueue<ResponseType>
) : SimpleForwardingServerCall<RequestType, ResponseType>(delegate) {

    override fun sendMessage(message: ResponseType) {
        output.offer(message)
        super.sendMessage(message)
    }

    override fun close(status: Status, trailers: Metadata) {
        if (status.isOk) {
            val requestId = metadata.get(REQUEST_ID_METADATA_KEY)

            val printer = JsonFormat.printer()

            val request = input
                .filterIsInstance<GeneratedMessageV3>()
                .joinToString(separator = ", ", prefix = "[", postfix = "]", transform = printer::print)

            val response = output
                .filterIsInstance<GeneratedMessageV3>()
                .joinToString(separator = ", ", prefix = "[", postfix = "]", transform = printer::print)

            logger.info("The request with id: $requestId and request data $request returns $response")

        } else if (listOf(Status.INTERNAL.code, Status.NOT_FOUND.code, Status.INVALID_ARGUMENT.code).contains(status.code)) {
            val requestId = metadata.get(REQUEST_ID_METADATA_KEY)
            logger.error("An error occurred while processing the request with request-id $requestId", status.asRuntimeException())
        }

        super.close(status, trailers)
    }

    companion object {
        private val logger = LoggerFactory.getLogger(LoggingServerCall::class.java)
        private val REQUEST_ID_METADATA_KEY = Metadata.Key.of("x-request-id", Metadata.ASCII_STRING_MARSHALLER)
    }
} Our implementation is very simple. We use JsonFormater for converting protobuf to JSON and joining to the string. Also, we take a request ID from the metadata for emulating real logging situations. Then we log the message into the system out. If an error occurs, we will log it. After that, the onComplete/onCancel methods of the listener will be called. Next, we must implement our ServerInterceptor which uses both our ServerCall and ServerCall.Listener. class LoggingInterceptor : ServerInterceptor {
    override fun <ReqT : Any, RespT : Any?> interceptCall(
        call: ServerCall<ReqT, RespT>,
        headers: Metadata,
        next: ServerCallHandler<ReqT, RespT>
    ): ServerCall.Listener<ReqT> {
        val input = ConcurrentLinkedQueue<ReqT>()
        val output = ConcurrentLinkedQueue<RespT>()
        val loggingServerCall = LoggingServerCall(call, headers, input, output)
        return LoggingServerCallListener(next.startCall(loggingServerCall, headers), input)
    }
} To start the processing request, we must call the startCall method of the ServerCallHandler class. After that, we must register our server interceptor. fun main(args: Array<String>) {
	val server = ServerBuilder
        .forPort(8080)
		.addService(OurGrpcService())
		.intercept(LoggingInterceptor())
		.build()
	
	server.start()
} In the second part, we consider how to work with client interceptors. I hope the article can help you with how to work with the server-side interceptors in GRPC.

SuprSend

suprsend.com

11-50 employees

Since 2022

COMPANY RANKING

SUPRSEND

EVERGREEN INDEX #121

SuprSend WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

SuprSend

suprsend.com

11-50 employees

Since 2022

COMPANY RANKING

SUPRSEND

EVERGREEN INDEX #121

RELATED COMPANIESRANK

STORIES ABOUT SUPRSEND

SuprSend WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!