DEV Community: Hypertrace

Angular Router: Children or LoadChildren?

Anand Tiwary — Wed, 01 Sep 2021 05:38:31 +0000

(This article assumes basic awareness of routers and routers API. For in-depth understanding, please refer to Angular docs)

Angular Router is one of the most useful packages in the angular ecosystem. However, if you are new to Angular and just starting to work with routers, your goal would probably be to set up few basic routes. Moreover, with new developers, I have usually seen many questions around children and loadChildren properties. Therefore, this article will focus only on the differences between these two properties and when to use what.

Angular Route Interface

export interface Route {
  path?: string;
  component?: Type<any>;

  children?: Route[];
  loadChildren?: LoadChildren;

  ... few other properties
}

Let me start by quickly explaining the above four properties of the Route interface (that are in the scope of this article):

Path: The router API breaks down the entire URL into individual fragments. The path property could correspond to a combination of these fragments. It is mainly used to identify the angular component that should be instantiated and loaded in the parent's router outlet.
Component: This property refers to the angular component that should instantiate for this route.
Children: This property defines nested routes, and angular would load them upfront.
LoadChildren: It is also used to define nested routes, but Angular Router would lazily load them. You see the advantage here.

Now that we have defined relevant Route properties, let's take a look at when we should choose between childrenand loadChildren.

Use Children:

To add nested routes.
Angular would load all child components upfront.
Make sure you import all NgModules for each component defined in the nested route table. Otherwise, your code would not work.
To help with the readability and maintainability of your code, avoid this property if your route table's nesting is getting too long. My personal preference is < 3 levels max.
Ideal for simple routes.
Code example:

const routes = [ 
    { 
        path: '', 
        component: ApplicationFrameComponent, 
        children: [ 
            { 
                path: 'home', 
                component: HomeDashboardComponent, 
                children: [ 
                    { 
                        path: 'api-dashboard', 
                        component: ApiHomeDashboardComponent 
                    }] 
            }, 
            { 
                path: 'api-list', 
                component: ApiListComponent, 
                children: [ 
                    { 
                        path: 'internal', 
                        component: InternalApisListComponent 
                    }, 
                    { 
                        path: 'external', 
                        component: ExternalApisListComponent 
                    }] 
            }]
        }];

Use LoadChildren:

For lazy loading. Using this property will optimize your application's performance by only loading the nested route subtree when a user navigates to a particular URL that matches the current route path.
It helps in keeping the nested routes table separate.
You must specify a routing module for loadChildren. This module must define the routes and should import all relevant ng modules
If you use import(<module-path>).then(module => module.<routing-module>), Angular will create a separate js bundle that will be loaded only when a child route is activated. And you get better performance, code readability, and maintainability.
If you use () => <routing-module>, angular will not create a separate js bundle, but the routes table would be kept separate. The result is better code readability and maintainability. Performance would be the same as the children approach.
Code example:

const rootRoutes = [ 
    { 
        path: '', 
        component: ApplicationFrameComponent, 
        children: [ 
            { 
                path: 'home', 
                loadChildren: () => HomeDashboardRoutingModule 
            }, 
            { 
                path: 'api-list', 
                loadChildren: @import('./api-list.module').then(module => module.ApiListRoutingModule) 
            }] 
    }];

// In HomeDashboardRoutingModule
const homeRoutes = [ 
    { 
        path: '', 
        component: HomeDashboardComponent, 
        children: [ 
            { 
                path: 'api-dashboard', 
                component: ApiHomeDashboardComponent 
            }] 
    }]; 

// In ApiListRoutingModule 
const apiListRoutes = [ 
    { 
        path: '', 
        component: ApiListComponent, 
        children: [ 
            { 
                path: 'internal', 
                component: InternalApisListComponent 
            }, 
            { 
                path: 'external',
                component: ExternalApisListComponent 
            }]
    }];

I hope this article was helpful! A quick question for my audience. What would happen if we pass a component for a route with loadChildren property?

{ 
    path: 'home', 
    component: HomeDashboardComponent, 
    loadChildren: () => HomeDashboardRoutingModule 
}

Would you please reply in the comments section below?

Getting started with Observability

Jayesh Bapu Ahire — Mon, 09 Aug 2021 13:12:06 +0000

Most of the tech giants including companies like Amazon, Netflix, started to build their systems using a monolithic architecture because back in the time it was much faster to set up a monolith and get the business moving. But over time as the product matures or fat growth happens, with growing systems the code gets more and more complicated. They all faced this problem and looked at microservices as a solution. One of the biggest benefits of microservices is that each microservice can be developed, scaled, and deployed independently.

With great power comes great responsibility and that’s what happened when organizations switched to microservices from more monolithic application architectures, they got significant benefits in delivery speed and scalability but on the flip side now they have to deal with the operational complexity in managing, monitoring and securing the new distributed architecture.

One of the benefits of working with older technologies was the limited set of defined failure modes. Yes, things broke, but you would pretty much know what broke at any given time, or you could find out quickly because a lot of older systems failed in pretty much the same three ways over and over again.


Microservice interactions at Amazon and Netflix (Image by divante.com)

Adopting a single deployment platform can address some of the concerns regarding operational complexity but it goes against the philosophy that makes microservice architectures effective. Using APIs to expose core business functionality and facilitate service-to-service communication gives us several control points and makes it easier to deal with complex modern applications. API-driven applications come with their issues like design complexity, visibility, communication, security, etc. which we discussed in detail in this blog post.

In a nutshell, Operating distributed systems is hard, not only because of their inherent complexity of the number of components and their distribution but also because of the unpredictability of their failure modes: there are plenty of unknown unknowns. We are left with an imperative to build systems that can be debugged, armed with evidence instead of conjectures.

With the growing complexity of systems and fast-moving software delivery trains due to modern cloud-native architectures, the possible failure modes became more abundant. Monitoring tools helped us for a while in keeping track of application and infrastructure performance analytics but it isn’t very suitable for modern distributed applications. As we discussed above, developers these days don’t know what their software failure modes are and more unknown unknowns means we won’t put any effort into fixing something because we don’t know the problem exists in the first place. Standard monitoring can only help you with tracking known unknown and it’s very relative. Your monitoring is only as useful as your system is monitorable.

This monitor-ableness of your modern applications is what we call "Observability".

In control theory,

Observability is defined as a measure of how well internal states of a system can be inferred from knowledge of that system’s external outputs. Simply put, observability is how well you can understand your complex system.

Metrics, events, logs, and traces—or MELT—are at the core of Observability. But, Observability is about a whole lot more than just data.

Observability is all about the ability to ask abstract questions to your system and find the answer without the need of opening a black box. Like, consider your process of placing an order on Amazon failed due to query timeout so What characteristics did the queries that timed out at 500ms share in common? Service versions? Browser plugins? Here, Instrumentation produces data which is what we call telemetry, and querying that data answers our questions.

Whenever we talk about Observability, we also talk about metrics, logs, and traces which are three pillars of Observability.

Metrics: Aggregated summary statistics.
Logs: Detailed debugging information emitted by processes.
Distributed Tracing: Provides insights into the full lifecycles, aka traces of requests to a system, allowing you to pinpoint failures and performance issues.

We will discuss all three of these in detail in the upcoming articles in this series.

In a nutshell,

This blog post was about giving you a brief overview of Observability and help you understand why you need Observability. In the upcoming blog posts, we will talk about metrics, logs, and traces and also see different applications of modern Observability for modern distributed applications.

Until then, if your organization is using microservice architecture and exploring Observability solutions, feel free to check out Hypertrace, which is a modern API Observability platform. join our slack community to interact with folks who are on the same microservice transition journey and are exploring Observability.

References

Challenges with Microservice and API ecosystem

Jayesh Bapu Ahire — Tue, 01 Jun 2021 10:59:34 +0000

In the last post of this series, we discussed the evolution of microservices and API ecosystems and what are the different benefits microservices and APIs offer when it comes to building large, scalable, and efficient systems. As I said in the last part (actually as uncle Ben said this), with great power comes great responsibility and the same thing applies to microservices and API architectures. These complex systems bring a lot of challenges with them and we will discuss those challenges in this part.

There are many challenges when it comes to adopting microservices or dealing with microservice architectures. We will be discussing a few of the important ones in this blog post.

Complexity: Complexity comes in different forms, either it can be design complexity or operational complexity. In the case of microservice architecture design, you have to deal with both of those.
- Design: When it comes to distributed systems, complexity is given. But, one way to mitigate this complexity is to create optimal abstractions. The effective modularization of the complex monolith can be done with proper and accurate service boundary definitions but creating those service boundary definitions is hard as well. That’s where design thinking comes into the picture. Defining clear boundaries and responsibility for each service is complicated and developers have to use a data-centric approach to arrive at a proper conclusion here. As compared to microservice design, API design is mature and has defined standard practices. API design thinking helps to identify the right service boundaries and helps to establish loose coupling between services so that implementation details don’t leak through.
- Operational: The main benefit of using microservices is you can develop, deploy and upgrade every service independently. This same benefit becomes the biggest pain point for many small teams who are trying to adopt microservice architectures as now there are maybe 60 services to be managed by 10 people and that operational load is very high. Maintaining, and continuously monitoring these complex architectures becomes very hard after some point. Some of the major pain points in operations management are:
  - Monitoring
  - Optimizations and scaling
  - Fault tolerance
Communication: Microservices have to communicate with each other to get desired things done. There need to be some infrastructure layer configs to enable resource sharing across services which ultimately enables these microservices to talk to each other. These configurations, if not optimized properly can result in high latency and error rate.
Security: As discussed in the above point, microservices use infrastructure layer configs to talk to each other. This along with multi-environment (multi-cloud as well as on-prem) deployments, results in even less visibility and creates many vulnerable points. This collectively increases the risk of a security attack.

Microservice frameworks in general come with many challenges when it comes to security, some of them are as follows:
- Data is distributed so maintain privacy, confidentiality, and integrity is hard.
- Setting up access control and service level authentication is tricky and makes services more prone to attack sometimes.
- Finding the origin of the attack and affected services can be tricky depending on the size of the architecture.

Most of the challenges we discussed above have some common origins and the most common one being less visibility in the system due to complex architectures and infrastructure. Observability into these microservice architectures and APIs can help us to understand these complex interactions better and help us solve design issues, operational issues, communication issues as well as security issues.

How? Going forward in this series, we will discuss API Observability and how we can use it to solve these complex but very important issues in API and Microservices ecosystem.

Until then, if your organization is using microservice architecture and exploring Observability solutions, feel free to check out Hypertrace, which is a modern API Observability platform. If you are in transition and want to learn more about Observability and instrumentation, join our slack community to interact with folks who have been through this transition or going through this transition.

References:

4 Easy Ways to Contribute to an Open Source Project

Jayesh Bapu Ahire — Thu, 20 May 2021 10:35:30 +0000

Want to contribute to an Open Source project but don't know where to start? You're in luck! This article will explain 4 easy ways you can contribute to an Open Source project as well as a few Hypertrace contributions you can make as examples.

Let's get started, shall we?

Documentation

Do you like to write. Do you like to share with people? As the face of an open source project, documentation is one of the most important contributions. Every open source project welcomes contributions to documentation. If you are just getting started with Distributed Tracing or Hypertrace and felt that we were missing some documentation details especially on our Getting Started page, you can go ahead and raise a pull request in Hypertrace-docs. We will be more than happy to review and add your suggestions.

Here are few important documentation categories you can contribute to:

Getting Started and Installation
FAQs
UI & Platform Overview
Anything else users can see

Code/ Features/ Bug fixes

You like to code and would love to contribute code to an open source project? Here are the few ways to find an issue you want to fix or a feature you want to add.

Go to the GitHub Issues tab of the open source project repository you would like to contribute to. For Hypertrace, you can find open issues here
If you are contributing for the first time,, look for issues with the good first issue label. Otherwise just find something that interests you and start working on it.
Do you have a feature/enhancement idea that you want to work on? Open an issue or start a discussion thread. Once you get some feedback, then start working!
If you can't find something then you can also write unit tests if they are missing. No maintainer will say no to more/better tests in the suite. Here's an article to help you get started: https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters
While trying the project, if you find a bug, report them right away as that itself is a nice contribution.

If you are first time contributor, here are few articles which might help you:

Evangelism

Would you like to share your experience using an open source project? Enterprise products use marketing teams to get the word out about themselves but open source projects depend upon users. You can join the Hypertrace user community here. Once you join the community, you can talk with other users about their experience and perhaps even chat with the creators of the project. Once you are comfortable, you can write a blog post explaining how the project helped you and what problems it solved.

Similarly, you can also share your experience in a meetup or online event or create a tutorial video which will help others learn about the project.

If you want to write a blog post about Hypertrace, take a look at blog.hypertrace.org and let us know what you are interested in writing about. You can reach in the Welcome channel on Slack

Helping others

Are you experienced but don't have time to invest? Be a part of Slack and GitHub communities and answer questions there. Or share your thoughts on open issues and feature ideas.

You can also help in reviewing PRs, moderating discussions or reporting bugs.

Videos are very popular these days. A short tutorial or sample app can help others build deeper understanding about the project. Even your smallest contribution can have a bigger impact on an open source project.

So, what are you waiting for? Pick up any of these ideas and dive into the world of Open Source. If you ask me, I will tell you to get started with documentation as it will give you a deeper understanding of the project and help you build confidence too.

On that note,

We are looking for contributors to help us build Hypertrace, an Open Source distributed tracing and Observability platform. And any contributions you make are greatly appreciated. Feel free to reach out to us on GitHub Discussions or join us on slack to learn more.

Evolution of API and Microservice ecosystem

Jayesh Bapu Ahire — Tue, 18 May 2021 14:30:04 +0000

In this first installment in a series on the evolution of API and microservices ecosystem, we will learn about how microservices and APIs became industry standards and what are different benefits microservices offer. We will explore different challenges with this ecosystem and how to solve them in the second part of this series.

But, what is microservice architecture? As called out by James Lewis and Martin Fowler, The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
I hope it’s not that hard to guess but these microservices talk to each other via APIs and two of the most commonly used protocols are HTTP request-response with resource APIs and lightweight messaging. Although as I mentioned above, companies like Netflix and Amazon have been using microservices for quite a long time, many small organizations have also started adopting API first or microservice driven architectures recently, because APIs have become the heart of the global tech industry in the past decade.

Rise of Microservices

Let’s dive more into the origins of APIs and Microservices as they share a common origin story.

Rise of service-oriented architectures
Rise of cloud computing and managed services
Rise of decentralization movement
Rise of Agile movement

Rise of service-oriented architectures

As we all know, building distributed systems is hard and managing them is even harder. The rise of the web back in the days opened the doors to innovate the way we build distributed systems and that’s where Service based architecture came into the picture. SOA was defined as a style of multi-tier computing that helps organizations share logic and data among multiple applications and usage modes. [as defined by Gartner ]

Though a failed movement back in the time, SOA surely helped a lot in initiating microservice movements, and even organizations like Netflix and Amazon were calling their architectures SOAs before the microservice movement. Due to the centralized nature of ESB topology and some other reasons, SOAs increased complexity and introduced bottlenecks, and the costs of implementing an SOA infrastructure (based on the ESB, registry, and service platform template) were excessive.

Due to these problems, people started looking for better alternatives.

Rise of cloud computing and managed services

The rise of RESTful Web APIs arose as a lighter-weight alternative to SOAP services. -- a style of interconnecting applications that had evolved organically on the Web --. The distributed nature of cloud infrastructure challenged the placement of the centralized ESB topology.
Everyone started adopting microservices due to the benefits they provided and here we are today looking at complex modern architectures. Cloud computing helped in removing barriers for deployment and provided a variety of new use-cases for APIs. It worked out as a novel platform for deploying more granular API-fronted application components. Cloud services provided another reason to move towards more service-oriented and modular deployment architectures.

Rise of decentralization movement

As we discussed earlier, at one point in time, service-oriented computing became an increasingly popular paradigm for modeling and building distributed systems in open and heterogeneous environments. However, proposed service-oriented architectures are typically based on centralized components, such as service registries or service brokers, that introduce reliability, management, and performance issues.

During this whole time, the capabilities and scale of distributed systems have increased. The trend towards decentralization in both the system itself as well as the supporting organization started to catch up and the decentralization moment started.

Rise of Agile movement

In his blog post titled “Coding the Architecture”, Simon Brown pointed out that agile architecture does not naturally emerge from agile development practices. Rather, it must be consciously sought. Note that his description of agile software architecture is a perfect match for microservice architecture.

If we look at the characteristics of agile software architecture, we tend to think of something that is built using a collection of small, loosely coupled components/services that collaborate together to satisfy an end-goal. This style of architecture provides agility in a number of ways. Small, loosely coupled components/services can be built, modified, and tested in isolation, or even ripped out and replaced depending on how requirements change. This style of architecture also lends itself well to a very flexible and adaptable deployment model, since new components/services can be added and scaled if needed.

The agile software movement arose as a reaction to the same centralized approach to enterprise IT that hampered the SOA movement. Agile’s popularity and success in software development led to the CI/CD approach to software deployment, followed by the cultural philosophy of the DevOps movement. Between CI/CD, DevOps, agile development, and progressive delivery, the software delivery train also started speeding up.

Benefits of Microservices

Now that we have gone through the reasons behind the rise of Microservices, Let’s try to understand what business value microservices provide.

The main reason that drives the move to microservices in any organization is speed and agility at scale which helps in software delivery. Reducing cross-team coordination, building diverse language applications, flexible deployments, enhanced manageability are some of the additional perks that organizations with microservice architectures enjoy.

Many of the benefits which come with Microservice architectures are mostly due to the API-first nature of microservices and here are a few of them:

Composability: When services are published through an API, it is easier to use them in multiple business contexts to assist in various business processes
Testability: When services are accessible over a network boundary, it is easier to isolate tests and exercise individual components of the system
Scalability: Each microservice can be scaled autonomously without disrupting the other microservices that comprise the application. When demand increases, you only need to upgrade or divert more resources to the microservice affected by the increasing demands.
Evolvability: When services are exposed through an API, implementation details can be hidden from the consumer, making it easier to change components without impacting dependent parts of the system
Comprehensibility: When a complex system is broken down into modular APIs, it is easier to understand the overall business functionality of the system, which helps in both designing and maintaining the system
Automatability: Along with the data plane API benefits above, control plane APIs allow automation in the deployment and management of microservices, thus increasing the velocity of software delivery

But as we know with great power comes great responsibility and the same thing applies to microservices and API ecosystems as well. These complex systems bring a lot of challenges with them and we will discuss those challenges in the next part of this blog post.

Until then, if your organization is using microservice architecture and exploring Observability solutions, feel free to check out our Open Source Observability platform Hypertrace. If you are in transition and want to learn more about Observability or want to contribute to Hypertrace, join our slack community to interact with folks who have been through this transition or going through this transition.

References:

Introducing Hypertrace

Shubham Jindal — Mon, 17 May 2021 12:00:21 +0000

Hypertrace is a distributed tracing platform which digests distributed traces from different sources, provides deep observability into your microservices, and slice-and-dices your services, endpoints, traces and attributes.

A well loaded definition! And still it doesn't do it justice.

Microservices

Microservices are trendy these days. But the more microservices, the more the burden of managing, monitoring and debugging them. Microservices can be like a spider web, just waiting to tangle you up in its trap.


Monolithic vs Microservices Source: https://devopedia.org/microservices

Distributed Tracing

Distributed Tracing is a way to provide Observability into your services within your microservices architecture.

Monitoring tells you whether a system is working, observability lets you ask why it isn't working

— Baron Schwartz


Observability using Distributed Tracing

Distributed Tracing tells a story of what's already happened in your system so you can quickly identify your problem and find a solution.
Zipkin and Jaeger are currently the two most popular distributed tracing systems.

Why Hypertrace?

Hypertrace turns distributed traces into Services, APIs and Backends using a custom pluggable architecture. Any custom logic can be plugged to discover business specific entities with simple configuration changes and surfaces the data to be slice-and-diced, instead of constrained by generic tracing platform features.
Hypertrace supports all standard instrumentation libraries and agents. If your application is already instrumented with OpenTelemetry, Jaeger or Zipkin, Hypertrace will work out of the box with your application telemetry data.

In addition, Hypertrace provides:

A trace enricher which turns traces into a service dependency graph with endpoints, traces and attributes
Flexibility to carefully examine transactions
Observability for Services, APIs, and Backends (databases, cloud services, etc.)
Metrics and Visibility into Services, APIs, and Backends
Root Cause Analysis
Identification of Performance Bottlenecks


Slicing and Dicing Transactions


Distributed Tracing


Services, APIs and Backends

Hypertrace boasts of features like:

P50, P90, P99 metrics (Averages can be misleading)
Better data visualizations (Waterfall, Scatter Plot, Area Chart)
Wide range of filters, search, sorting, and grouping functionalities
Automatic discovery of Services, APIs, and Backends

Hypertrace is for you, if you are looking for the following information:

Traces with duration > 5 seconds
Traces with status code as 4xx or 5xx ️
Number of calls made to an API
APIs within a Service
Performance of Services, APIs, and Backends

To learn more, visit Hypertrace docs or Getting Started with Hypertrace.
Do check out Hypertrace on Github and join Hypertrace community on Slack