Blog
Blog
If Java Is Your Choice Of Programming Language – Spring Cloud Function + Serverless Framework Makes A Great Technology Stack. It Boosts Developer Productivity By Decoupling From Vendor Specific FaaS API, And Deployment Activities.
This Article Attempts To Demonstrate How Powerful Is Test Driven Development & Consumer-Driven-Contract When There Is A Dependency On An Internal/External Service. If There Is A Mix Of Microservices And Nanoservices This Approach Really Boosts Developer Productivity To Produce Quality Testable Code.
Introduction The main goal of this blog post is to provide necessary information to get started on using Cloud Foundry Logging Component. A little introduction to concepts like Cloud-Native Apps, 12 Factor Apps is needed to understand System and Application logging on Cloud. Here is the breakdown of this blog post. The purpose of aggregating logs from all running instances of an application on cloud. How the aggregation of logs is handled on Open-Source PaaS - Cloud Foundry. How easy it is to route the log streams to a specialized log management system - Papertrail. Prerequisite This article assumes you are familiar with Cloud foundry A brief understanding of Cloud Native Applications. A high-level understanding of 12 Factor Apps concepts. I have provided links to various resources at the end of this article to get an understanding of these concepts before you go on and read this blog post. Why do we need to aggregate logs? Cloud Native Apps Applications designed and developed to take advantage of cloud features are supposed to be called cloud native apps. Following constraints makes cloud native applications difficult to troubleshoot. Distributed applications like microservices hard to maintain, and debug. Applications on cloud run on Virtual machines and(or) Containers which are ephemeral. Container Instances are immutable. Because of these constraints storing, analyzing application and system log information is difficult. 12 factor Apps 12 factor apps is like a benchmarking to make sure your application is built for cloud (like microservices) and following certain recommendations. Among the 12 factors following four factors are pertinent to topic of this post. Processes - 12 factor apps are supposed to be state-less so that scaling is easy. Concurrency - For high availability multiple instances of an App are run and load is distributed across. Disposability - To scale-out and scale-in, Apps should be quick to boot-up and easy to be disposable. Logs - 12 factor apps recommends treating logs from all app instances as event streams, never store them inside containers or virtual machines. Logs should be streamed out and stored somewhere else and should be aggregated not to loose them. What component of Cloud Foundry handles logging? Cloud Foundry Loggregator Component A brief introduction to Cloud foundry Cloud Foundry is an open-source Platform-As-A-Service (Paas) to run applications on any cloud. Instead of focusing on Cloud infrastructure CF abstracts all the operational activities and provides a platform to speedup application development and deployment. Various components of CF address certain factors of 12 factor operations. Loggregator component of CF takes care of aggregation of logs from all running instances of an application. Following diagram explains various sub components within PCF Loggragator Component.
Dart’s StreamController and Flutter’s StreamBuilder are powerful tools to achieve a better design and intra-app communication. Prerequisites Basic understanding of Flutter SDK and Scaffold Material Widget. Dart Programming Language. (Basic idea of Streams). BLoC Pattern — (Writing logic separate from UI in a Dart class and sharing it among Widgets). Main focus is Scaffold Widget’s body and bottomNavigationBar sections. “The Scaffold widget takes a number of different widgets as named arguments, each of which are placed in the Scaffold layout in the appropriate place.” The most significant among those named arguments are appBar: (The top section) body: (Main body section) bottomNavigationBar: (Bottom section) Navigating between screens using Scaffold’s bottomNavigationBar can be achieved in many different ways. Most common way is Hold the current BottomNavigationBarItem index value inside the State of a StatefulWidget every time a BottomNavigationBarItem was tapped, and Call that State’s setState() to repaint the whole widget tree to reflect those changes. A slightly better approach can be using a combination of BLoC — to separate business logic from UI Dart’s StreamController — to communicate the UI intents. Flutter’s StreamBuilder — to trigger UI updates. Advantages Using BLoC we can achieve clear separation of business logic from UI. No need to store current BottomNavigationBarItem index inside the State. No need to call setState() every time which re-creates the entire widget tree. Use StreamBuilder to re-create only a sub-tree or widget(s) instead of entire widget tree. So, how can it be achieved? Two key things Communication between the Scaffold’s bottomNavigationBar and body sections is done using Dart’s StreamController. Use Flutter’s StreamBuilder to re-paint just the body section and the BottomNavigationBar. First thing we need a BLoC Let’s create a BLoC. This BLoC holds an enum to represent various BottomNavigationBarItems. a dart StreamController object. a default Navigation Bar Item enum for initial state. a function which can be attached to onTap() gesture of BottomNavigationBar on UI side. a method to close the stream. Lets go over each piece of BLoC in detail… an enum to represent various BottomNavigationBarItems.
2022-23 Newray LLC. All Rights Reserved.