DEV Community: Garrett Hamelin

Improve application performance: How to find and fix slow function calls, HTTP requests, and SQL queries

Garrett Hamelin — Fri, 21 Jul 2023 16:53:43 +0000

Runtime analysis is the latest and greatest way for developers to find, flag, and fix software flaws before production. Our series on rules and their impact is focused in this article on Slow Function Calls, HTTP Requests, and SQL Queries.

I will review what these rules mean and how to enhance your application performance using AppMap.

If you learn better through video you can check out a walkthrough of these rules here:

Slow function calls

In this first example, let’s use AppMap to locate a performance finding related to slow function calls and use the new flame graph view to see the duration of each function call. It's crucial to optimize those long-running functions, as they can significantly impact performance. Often slow function calls are caused by poor code practices, inadequate algorithms, or excessive resource consumption, leading to scalability issues, bottlenecks in system responsiveness, and even user frustration

To illustrate this, let's examine code snippets related to slow renders and highlight the usage of partials. Repeated rendering of partials within loops can significantly impact performance.

For some context, the example we are dissecting today is an e-commerce merch store. To make sure we are all on the same page, the AppMap we are looking at outlines the user interaction of a user selecting featured products to view. The function in question ActionController::Renderers#render_to_body can be plainly seen in the flame graph.

When we dig a little deeper and see what is actually happening.

We can see that Render_to_body calls render_to_body_with_renderer which gets passed a series of options. Looking into the function itself we see the _renderers.each do ...which, when passed a file with a lot of partials that need to be rendered, some containing caching operations themselves, we start to understand exactly why this function runs for such a long time.

Looking at the trace view, we can see just how many children are spawned and will complete before we can return from the original calling function.

To mitigate this we may want to reduce the number of partials that we are individually working with. Good coding practices encourage abstraction and code reuse but doing so may have introduced a performance concern. We need to be careful that we don’t abstract which can impact the performance of our application at runtime.

Slow HTTP requests and SQL queries

Slow HTTP requests and SQL queries often stem from a range of situations, ranging from suboptimal coding practices, inefficient schemas and configuration, or lack of indexing to lack of resources available, and high network congestion. We need to be aware of potential causes, such as the lack of caching HTTP requests or leveraging a content delivery network (CDN) for faster content delivery.

Find and fix performance issues

To address slow function calls, HTTP requests, and SQL queries, we can implement effective mitigation strategies by updating our coding practices and improving resource management. For slow renders, alternative home or index views can be used to minimize the number of function calls. Additionally, you can leverage caching techniques and pre-render pages that don't require dynamic data, as well as load-balancing techniques to reduce the pressure on our network.

In summary

To improve application performance, it’s important to identify and optimize slow function calls, HTTP requests, and SQL queries.

AppMap’s flame graphs and other tools like the interactive sequence diagram make it easy to pinpoint performance bottlenecks and implement appropriate mitigation strategies.

Links

⬇️ Download AppMap for VSCode and JetBrains: https://appmap.io/download

⭐ Star AppMap on GitHub: https://github.com/getappmap

🐦 Follow on Twitter: https://twitter.com/getappmap

💬 Join AppMap Slack: https://appmap.io/slack

ℹ️ Read the AppMap docs: https://appmap.io/docs

📺 Watch AppMap Tutorials: https://www.youtube.com/@appmap

📸 Cover Photo by Robert Linder on Unsplash

Garrett HamelinFollow

I love technology and everything about it. I'm a software engineer who enjoys helping others succeed and building communities of like minded people.

Introducing Flame graphs: It’s getting hot in here

Garrett Hamelin — Fri, 14 Jul 2023 18:47:50 +0000

Flame graphs help developers identify code bottlenecks and understand code execution patterns, so we’re excited to announce they are now available within the AppMap extension for VS Code and JetBrains editors like IntelliJ.

“Flame graphs are a visualization of hierarchical data, created to visualize stack traces of profiled software so that the most frequent code-paths to be identified quickly and accurately.”

In this article, I explore how they work, and how to generate and use them with AppMap.

How to read a flame graph

Flame graphs are read from bottom to top, left to right, providing a holistic view of function execution. In this video, you can see how I identify time-consuming functions and visualize the sequence of operations.

To make sense of the flame graphs, we must first understand the color scheme.

Purple represents SQL queries
Blue indicates classes, methods, or functions that follow in the execution flow
Yellow denotes external service calls (absent in this video)
Teal is the name of the AppMap

What you get with flame graphs

Flame Graphs reveal crucial insights about application performance. Each function in the graph is labeled with its corresponding execution time in milliseconds or microseconds. This detailed breakdown allows developers to pinpoint long-running queries and functions, optimizing code efficiency.

Zooming in on the graph or selecting a specific function provides a deeper understanding of the call stack and execution sequence. For example, the demonstration showcased the occurrence of a selector before an active support call, shedding light on the execution flow. This level of granularity empowers developers to tackle complex performance issues head-on.

Revealing performance issues

By examining the graph, developers can detect common issues like N+1 queries, a notorious problem in application development. The ability to visualize the duration of each query or function provides actionable insights, highlighting areas for improvement.

Flame graphs also expose the impact of long-running functions on overall performance. While some functions, like renders to body, are intended to run longer, others such as support services and callbacks, should be optimized for efficiency. The graph's tally of execution times offers a comprehensive overview, ensuring developers can focus their efforts where they matter most.

AppMap improves on flame graphs by highlighting the flaws in your application and shows you the direct impact of a specific flaw on your application. No more searching to figure out where an N+1 query happened or how many times it ran!

Flame graphs, sequence diagrams, and more

Try AppMap today to help you identify issues with your code or refactor an existing code base. Use our new flame graph and sequence diagram views. We also have traditional dependency and trace views.

Links

⬇️ Download AppMap for VSCode and JetBrains: https://appmap.io/download

⭐ Star AppMap on GitHub: https://github.com/getappmap

🐦 Follow on Twitter: https://twitter.com/getappmap

💬 Join AppMap Slack: https://appmap.io/slack

ℹ️ Read the AppMap docs: https://appmap.io/docs

📺 Watch AppMap Tutorials: https://www.youtube.com/@appmap

Garrett HamelinFollow

I love technology and everything about it. I'm a software engineer who enjoys helping others succeed and building communities of like minded people.

Exploring" Too Many Updates": How to find and fix a code issue for a large number of outward calls

Garrett Hamelin — Fri, 07 Jul 2023 18:59:37 +0000

Whether you're a software engineer looking to optimize your code or just eager to understand runtime analysis, this article will help you think about rules as they relate to code analysis.

In this article, I explore a maintenance rule called "Too Many Updates" and discuss its implications, causes, and mitigation strategies.

Understanding the rule

At AppMap, we define the "Too Many Updates" rule as a verification process that examines the number of SQL and RPC updates executed by a command function or method within your application. This rule sets a default threshold of five updates in our default.yml file. Any function or method that exceeds this threshold triggers the "Too Many Updates" finding to appear in the runtime analysis results.

In technical terms, this finding corresponds to CWE-1048, which refers to an “invokable control element with a large number of outward calls” [sic]. For simplicity, we'll refer to it as "Too Many Updates" throughout this article.

Applying the rule

To illustrate the concept, let's consider a real-world example using a Spring Pet Clinic application implemented with Java and the Spring framework. This application allows us to manage owners, pets, and visits for a veterinary clinic. Imagine we have created an owner, and a pet, a bird we have given the name of Jimmy, and added a recent visit to the veterinarian. Now, let's take a closer look at the code and explore the consequences of the "Too Many Updates" finding.

Setting custom overrides

Before diving into the code, let's first understand how to customize the default threshold for the "Too Many Updates" rule. By creating an appmap-scanner.yml file, and running the command, you can override the default settings.

$ npx @appland/scanner \
    --appmap-dir tmp/appmap \
    --config appmap-scanner.yml \
    ci

In the example provided, the warning limit is set to one for demonstration purposes.

checks:
  - rule: authzBeforeAuthn
  - rule: http500
  - rule: illegalPackageDependency
    properties:
      callerPackages:
        - equal: actionpack
      calleePackage:
        equal: app/controllers
  - rule: insecureCompare
  - rule: missingAuthentication
  - rule: missingContentType
  - rule: nPlusOneQuery
  - rule: secretInLog
  - rule: slowFunctionCall
    properties:
      timeAllowed: 0.2
      functions:
        - match: Controller#create$
  - rule: slowHttpServerRequest
    properties:
      timeAllowed: 0.5
  - rule: slowQuery
    properties:
      timeAllowed: 0.05
  - rule: tooManyJoins
  - rule: tooManyUpdates
        properties:
            warningLimit: 1
  - rule: unbatchedMaterializedQuery
  - rule: updateInGetRequest

However, in practical scenarios, it's recommended to set a more appropriate threshold based on your application's requirements. Now that we can control our threshold let's jump over and view our findings.

Analyzing findings

To analyze the findings, we'll use AppMap to navigate to the runtime analysis section. The findings table provides a comprehensive overview of all the identified issues.

You can also group the findings by project, date, or category to gain better visibility into your application's maintainability.

Examining Example 1

Open the findings report for the "Too Many Updates" finding to understand its causes and implications. In this example, the command performs 47 SQL or RPC updates, as indicated in the event summary.

When we examine the map, we can observe a sequence diagram representing the execution flow. The presence of this finding suggests potential poor coding practices or architectural flaws in the application.

It highlights the need to consolidate multiple calls into a more efficient and maintainable structure. In this particular application, this is the result of database migrations being performed during the setup phase for development.

Examining Example 2

Now, let's explore another example to compare and contrast the findings. In this case, the threshold is set to two, and we examine the sequence diagram for the corresponding map finding an action that performs to “updates” in the same function call.

This specific scenario involves adding a pet to an owner. We can observe that two updates are performed: one to INSERT the pet's information…

INSERT INTO pets (id, birth_date, name, type_id)`

…and another to associate the pet with its owner.

UPDATE pets SET owner owner_id=? WHERE id=?

Unlike the previous example, this finding emphasizes a design choice rather than inherent flaws in the application's architecture. It prompts us to evaluate if these two calls can be consolidated into a single call for improved efficiency and simplicity.

Selecting a strategy

To address the "Too Many Updates" finding, we have several mitigation strategies at our disposal.

The first and simplest approach is refactoring the code to consolidate multiple updates into a single call. Often we find that “Too Many Updates” isn’t the result of some large flaw in the design of our application, but rather the result of poor implementation of coding standards and common best practices.

By reviewing the code and analyzing the sequence diagrams, we can identify opportunities to optimize the number of updates performed. Additionally, if we do find a larger issue at play we can consider architectural changes. Such as reevaluating the structure of services and abstractions, to ensure a more streamlined approach.

Alternatively, if these issues uncover a security risk in our application, we can employ the use of rate limiting to ensure our application remains performant and secure. These mitigation strategies enhance maintainability, improve code readability, and reduce potential security risks.

Watch the video:

Summary

In this article, we explored the "Too Many Updates" maintenance rule and its impact on software engineering practices.

By understanding the causes, implications, and mitigation strategies, you can effectively optimize your code and ensure a more efficient and maintainable application.

Remember to review your findings, analyze sequence diagrams, and implement the appropriate refactoring techniques and architectural changes. By doing so, you'll enhance the overall quality and performance of your software.

Links
📸 Cover Photo by Karl Pawlowicz on Unsplash

⬇️ Download AppMap for VSCode and JetBrains: https://appmap.io/download

⭐ Star AppMap on GitHub: https://github.com/getappmap

🐦 Follow on Twitter: https://twitter.com/getappmap

💬 Join AppMap Slack: https://appmap.io/slack

ℹ️ Read the AppMap docs: https://appmap.io/docs

📺 Watch AppMap Tutorials: https://www.youtube.com/@appmap

Garrett HamelinFollow

I love technology and everything about it. I'm a software engineer who enjoys helping others succeed and building communities of like minded people.

How to streamline and focus your sequence diagrams

Garrett Hamelin — Wed, 28 Jun 2023 19:38:01 +0000

AppMap’s new feature gives developers greater control over their sequence diagrams to enhance code reviews.

The value of sequence diagrams, especially for code reviews, is growing. And AppMap is at the cutting edge, creating new tools and capabilities for developers to generate and use sequence diagrams for designing and improving code quality from writing to reviewing. In this article, I’ll share a new filtering feature of our sequence diagram tool in AppMap.

Taming the complexity of sequence diagrams

As software projects grow in size and complexity, so do the sequence diagrams generated from them that represent their inner workings. These diagrams often become extensive and overwhelming, making it challenging to decipher the flow of interactions and identify critical components. The AppMap user community has requested a way to declutter their automatically-generated sequence diagrams in order to focus on the essential elements of their application.

We heard you, and we’re excited to share this new feature release. Read on for the details, and watch this walkthrough video to see it in action.

Advanced filtering for unparalleled control

With our latest release, we added an enhanced filtering system that empowers developers to take control of their sequence diagrams by eliminating unnecessary noise and tailoring your diagrams to display only the information that matters most to you and your team.

3 key functionalities

Live filtering: Instantly reduce complexity by hiding specific components, such as external code or framework-related elements. With just a few clicks, you can create a clean, focused view of your sequence diagram.
Customizable views: Once you have refined your diagram to your liking, you can save that view as a filter. This means you can apply the filter to future app maps, whether you want it as a default setting for all diagrams or selectively choose where to apply it.
Seamless switching: Switching between different views is effortless. Just select the desired filter, and the diagram will dynamically update to display your preferred elements. No need to rebuild or navigate complex menus.

Benefits and advantages

AppMap's enhanced filtering feature goes beyond simplifying your sequence diagrams.

Persistence: Your custom filter views persist as long as the diagram remains open. This allows you to revisit and analyze your diagrams without losing your customized settings. If a diagram has been closed, getting that view back is as simple as reapplying the filter. If you find yourself applying the same filter to a majority of your sequence diagrams, set a previously saved filter as the default, providing a seamless experience across any sequence diagram you choose to open or share. Changing or setting a default view becomes as simple as clicking a button.
Intuitive interface: Our user-friendly interface ensures that applying filters and customizing your view is a breeze. With our configure-as-you-go model, developers spend less time configuring and more time gaining insights from their diagrams.
Increased efficiency: By decluttering your sequence diagrams and focusing on the relevant elements, you can make quick decisions on things that matter most, improving your code analysis efficiency and gaining a deeper understanding of your application's behavior on whatever scale you choose to view.

Getting Started + community

Sequence diagrams are particularly useful for designing and testing software systems that involve multiple components, asynchronous events, or complex control flows. Learn more about the common use cases for sequence diagrams and how to interpret them in this post.

To try out our new filtering feature, download AppMap into your favorite IDE and use our handy docs to get started. We hope you enjoy exploring the possibilities, experimenting with different views, and revolutionizing how you analyze and understand your code!

To chat with us and other users about it and get your questions answered, join our community.

Cover Photo by Luca Bravo on Unsplash

Garrett HamelinFollow

I love technology and everything about it. I'm a software engineer who enjoys helping others succeed and building communities of like minded people.

Understanding Authorization Before Authentication: Enhancing Web API Security

Garrett Hamelin — Fri, 23 Jun 2023 21:44:12 +0000

In today's digital landscape, where data breaches and cyber attacks have become increasingly prevalent, ensuring the security of web applications and APIs is critical. While most developers are familiar with the concept of authentication, a crucial aspect that often gets overlooked or misunderstood is authorization. We'll explore a real-world scenario, identify common security risks, and discuss mitigation strategies. So let's get started!

Authorization vs. Authentication: Clarifying the Terminology

Before we jump into the specifics, let's clarify the difference between authorization and authentication. Authorization is the process of determining what resources or functionalities a user can access within an application. It revolves around identifying and granting appropriate permissions. On the other hand, authentication involves verifying the identity of a user and ensuring that they are who they claim to be. So it makes sense that you wouldn't want to give someone access to things before you know who they are.

Unveiling Security Risks in Development Environments

Let's examine a practical example to understand this better. Consider an e-commerce store built on a Ruby on Rails framework, a fork of the Spree e-commerce platform.

When looking at a sequence diagram of cart interaction you’ll notice that the authentication step is missing when accessing the cart functionality. Clicking on the cart with an item already added to it does not prompt the user to sign in.

While this may be by design because the cart does not contain any personally identifiable information, the very next step in the purchase process does.

The application asks for a shipping address. In my opinion, a good rule of thumb is that any time we are capturing personally identifiable information once the information has been submitted the application should be authenticating that user. Any time that type of information is presented a user must be authenticated and authorized before viewing or updating.

AppMap: A Powerful Runtime Analysis Tool

It can be challenging and time-consuming to uncover and address these security concerns. Often times software teams look to tools or audits to provide us with a direction on what is causing the issue, which can be complex and require hours of investigation. The AppMap runtime analysis tool can give us a comprehensive look at the problem, what is causing it, and where it comes from in a matter of minutes. AppMap provides insights into how our applications behave at runtime, allowing us to analyze their execution flows and detect potential issues. With AppMap, we can identify and potentially fix security vulnerabilities, such as authorization-before-authentication problems.

Analyzing

Analyzing the code using AppMap, we discover that the violation of authorization-before-authentication occurs in multiple instances within the application. Specifically, we observe the use of CanCan, a library for authorization, which performs authorization before any authentication check.

Inspecting the trace view and sequence diagram in AppMap, we trace the flow of events leading to the violation. We find that the "get cart" process triggers the authorization step without first authenticating the user. This type of behavior could allow unauthenticated users to access restricted resources.

As we explore the dependency map, we notice that the authorization call is sent to the Spree Order controller, which resides outside of our application's codebase. This presents a challenge since we lack direct control over Spree's authentication process.

To address this security risk, we need to modify the order of operations and ensure that authentication occurs before authorization. In this specific case, the README of the application states that every request is assumed to come from an admin user, which is a major red flag. To mitigate this, we can implement the following strategies:

Authenticate Before You Authorize: Flip the order of authentication and authorization, ensuring that users are authenticated before granting them access to restricted resources. In our case, we may want to know who a user is or perform a basic authentication before adding something to a cart on the off chance that a user would like to save that cart for later or to prevent abuse of the cart system for exclusive limited release items (I'm just spitballing here there are a ton of reasons it may be a good idea to establish a user identity before performing an action).
Validate Credentials in Development Environments: Even in development or QA environments, enforce authentication to replicate real-world scenarios and identify potential vulnerabilities early on.
Employ Anomaly Detection and Adaptive Access Control: Utilize artificial intelligence or machine learning techniques to create anomaly detection systems, threat protection mechanisms, and adaptive access control. This hybrid approach allows for flexibility in development environments while providing robust security controls in production.

By adopting these strategies, you can strengthen the security of your web APIs and prevent unauthorized access to sensitive resources. It is crucial to prioritize security throughout the development lifecycle to avoid compromising user data and maintain the trust of our users.

Summary

Authorization before authentication is a vital security principle that ensures users are properly identified and granted access to resources. By leveraging tools like AppMap and following best practices, we can proactively identify and address security vulnerabilities early on, ultimately building more secure and reliable web applications.

Thank you for joining me in this exploration of authorization before authentication in web API security. Stay tuned for more articles, and if you have any questions or suggestions, feel free to leave a comment below!

Garrett HamelinFollow

I love technology and everything about it. I'm a software engineer who enjoys helping others succeed and building communities of like minded people.

How AppMap's runtime analysis finds performance and security flaws

Garrett Hamelin — Fri, 16 Jun 2023 21:13:26 +0000

Cover image credit: Photo by Kevin Ku on Unsplash

Software and application development is difficult. Producing code that is flaw and error-free is even harder, sometimes finding the problems in our software can be half the battle of creating applications that are secure, reliable, and performant. We spend an enormous amount of time and money running, testing, and monitoring our code trying to find the root cause of an issue that has popped up either before or after the application went live, hoping that the next issue doesn’t rear its ugly head in production. So to prepare for the inevitable we implement tools everywhere, trying everything we can to catch it when it does. But what if we could reduce that overhead, and give ourselves a “head-start” to finding issues while we are still in the development phase? In this article, I’ll introduce runtime analysis and describe what it’s good for. I’ll also give you a tour of how AppMap uses runtime analysis to identify hard-to-find issues within your application.

What is runtime analysis?

Runtime analysis is a process of analyzing code while it is running, capturing how your code behaves when it is living and working with actual data. Traditionally, developers use static code analysis tools to examine patterns and create a model of their code and how the data flows through and application without actually executing it. Usually, if we want to watch processes and see what happening in our live running applications we employ Application Performance Monitoring Tools running in our production environment. This option is expensive and rarely shows where the problem occurred in the source code, which can make it challenging to integrate a solution back into the code. Runtime analysis gives us a “best of both worlds” scenario. When runtime analysis is done within the development environment, developers have an easy and accessible way to observe running processes, analyze code patterns responsible for those processes, see how and what data is affected by our coding patterns, and identify potential hot spots directly in the source code of that application. This in turn gives us the opportunity to resolve issues before we even submit our code for a code review.

Flaws vs. bugs

Runtime analysis identifies flaws, which are different from bugs. Bugs are usually the result of a logic error, such as forgetting to initialize a variable or causing a race condition. Flaws, on the other hand, are fundamental structural issues within the code. They pertain to problems with code design, code behavior when handling data, or deeper structural aspects of code implementation.

Benefits of runtime analysis in the dev environment

While there are monitoring tools available for the production environment, runtime analysis in the development environment offers three superior benefits:

Cost effectiveness

Production monitoring tools can be expensive, especially if your application has high traffic or complex architectures. Not to mention that it can be hard to tailor these tools for what you need and to leave out what you don’t.

Early issue detection

By analyzing your code at runtime during the development phase, developers are able to identify flaws and weaknesses early on before it goes to production or is seen by a customer. In a study published last year by Meta, they found that finding issues during the development phase makes them more likely to get fixed and makes the fix more likely

Seamless integration with the development workflow

With runtime analysis, you can deploy your application to different testing environments and stages, catching and addressing issues at various points in the development lifecycle. This enhances code quality and reduces potential risks.

Using AppMap for runtime analysis

AppMap performs runtime analysis within your IDE. Unlike static code analysis, which creates a model of your code's behavior, AppMap watches your code run, giving it the ability to reason about it much more accurately and definitively compared to static analysis.

To identify flaws, AppMap sources its default list of 12 rules from the OWASP top 10 found on the Common Weakness Enumeration (CWE) forum. CWE is a community-developed list of software and hardware weakness types governed by high-level organizations and companies with a focus on security, maintainability, and performance. Additional rules are available for use as well, and a full list of available rules and their definitions can be found in our documentation.

The cherry on top of this rule based runtime analysis is that it is fast. With static code analyzers, we have a wait time for the tool to parse code, build a model, and evaluate it. AppMap takes a slightly different approach. Since we can actually run your code we have the ability to dynamically instrument your code. Doing so provides additional insight into what is happening in your application, where and which processes our running. We flag certain events as they occur and add labels with additional information about what is actually happening in your application at the moment in time that the event occurred. AppMap’s Runtime Analysis Scanner then utilizes those flags and labels to identify potential issues or to spot patterns that may be problematic.

How to setup AppMap Runtime Analysis

After you install AppMap, record your application, and create your first AppMap we will add these default rules by creating or modifying the appmap-scanner.yml file. This extends the functionality of the scanner and allows you to include custom rules that suit your specific needs.

Our documentation also provides insights into how the rules are constructed, which labels we use in instrumentation, and how the scanner works with flags to match patterns and find flaws.

example 1: appmap-scanner.yml

checks:
  - rule: authz-before-authn
  # - rule: circular-dependency
  - rule: deprecated-crypto-algorithm
  - rule: deserialization-of-untrusted-data
  - rule: exec-of-untrusted-command
  - rule: http-500
  # - rule: illegal-package-dependency
  # - rule: incompatible-http-client-request
  # - rule: insecure-compare
  # - rule: job-not-cancelled
  - rule: logout-without-session-reset
  # - rule: missing-authentication
  - rule: missing-content-type
  - rule: n-plus-one-query
  # - rule: query-from-invalid-package
  # - rule: query-from-view
  # - rule: rpc-without-circuit-breaker
  # - rule: save-without-validation
  - rule: secret-in-log
  #  - rule: slow-function-call
  #  - rule: slow-httpServer-request
  #  - rule: slow-query
  - rule: too-many-joins
  - rule: too-many-updates
  # - rule: unbatched-materialized-query
  - rule: unauthenticated-encryption
  - rule: update-in-get-request

Results

Once a configuration has been created, you get all sorts of information about what possible issues may arise in your application at runtime.

Example 2: Analysis Overview

When run against an example application, we set our configuration to look for N+1 queries that are causing performance issues that are difficult to find using traditional static code analysis. We can see in the findings that not only did we find two N+1 queries, we found 69 other flaws in our application, 28 of which are potential security risks. In full transparency, this example application was built to be deliberately insecure so those security findings aren’t all that surprising, but what is surprising is the wealth of information available to us about the flaws that were found.

Understanding runtime analysis findings

When we drill down into one of these findings, we can see a link to the definition of the flaw with more information about it (ex. 3.1), the number of times it occurs (ex. 3.2), the stack trace to know how it occurred (ex.3.3), and how which “paths” a user could take to encounter that flaw (ex. 3.4). With these insights we are able to determine if a fix is necessary, where the fix needs to happen, and we can design and implement a fix before our feature ever goes into review.

Example 3: Findings

This presents us with real actionable information about just how negatively this flaw could impact the performance of our application. Imagine the cost and user interruption this would cause if it was found in production or, worse, not found at all.

Runtime analysis FTW 🏆

By leveraging runtime analysis in the development environment, you can save on costs, detect issues early, and integrate the analysis into your workflow. Using AppMap for your runtime analysis empowers developers to deliver better and more reliable software.

We love to hear what our users have to say. Let us know what you think in the comments below. Also, check out our AppMap integration for your IDE and other AppMap-related content at the links down below.

For an in depth look at the default rules check out this article: How to ensure your web APIs are Safe

Links

⬇️ Download AppMap for VSCode and JetBrains: https://appmap.io/download

⭐ Star AppMap on GitHub: https://github.com/getappmap

🐦 Follow on Twitter: https://twitter.com/getappmap

💬 Join AppMap Slack: https://appmap.io/slack

ℹ️ Read the AppMap docs: https://appmap.io/docs

📺 Watch AppMap Tutorials: https://www.youtube.com/@appmap

Garrett HamelinFollow

I love technology and everything about it. I'm a software engineer who enjoys helping others succeed and building communities of like minded people.

Share your AppMap files and findings with your team

Garrett Hamelin — Fri, 09 Jun 2023 21:51:07 +0000

AppMap is a powerful tool for developers to find and fix performance issues. Write and run your code, and then AppMap generates findings that save you and your business time and money upfront instead of down the line.

If you’re a developer running AppMap on your code, you may want to share your files and findings with your team or manager. In the upper right-hand corner, there is a share arrow that allows you to generate an SVG file of your AppMaps

Because AppMaps help developers and teams describe their code design and architecture, you are able to use them to help explain the decisions you made.

Once you have your SVG file, you can embed it in many different places, for many different uses. Here are some examples:

Add to a presentation for a design and/or planning meeting
Add to a status update on where you or your team are on a feature update
Add to documentation for onboarding a new team member or company to your code
Add to the internal documentation for a feature to show the logical structure of the code

Using AppMap SVG files to share your findings? Tell us how and share with our community.

Garrett HamelinFollow

I love technology and everything about it. I'm a software engineer who enjoys helping others succeed and building communities of like minded people.

How to ensure your web APIs are safe

Garrett Hamelin — Fri, 09 Jun 2023 17:21:29 +0000

Cover image credit: Photo by Nick Fewings on Unsplash

This article explores how to ensure your APIs are safe. Specifically, we address a critical issue that arises when incorrect database actions are coupled with inappropriate HTTP request verbs creating an “unsafe API method.”

“Request methods are considered safe if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource.” (The RFC Documentation)

GET and HEAD requests should be idempotent, which means they shouldn’t cause any side effects on the resources on the server. For most API endpoints, this means that calling them once will return the same values as calling them multiple times. For some APIs (like one that can GET the current time, or look up a stock’s latest market price) it might return different data each time, but still be idempotent as long as it isn’t the API that causes those changes in the server’s data values.

If a supposedly safe API breaks the idempotency rule, it can cause a lot of issues for a system. Clients of the API need to be 100% sure that their read-only calls truly are read-only. After all, nobody would trust an ATM if the act of checking their bank balance caused it to drop in value each time!

Code reviewers are doing their job well when they check read-only APIs to be safe. However, they can sometimes miss things, especially with library-generated database interactions like those found in frameworks like ActiveRecord or Hibernate.

In this example, I find and fix a similar issue in a Ruby on Rails application.

I noticed an unexpected database insertion alongside the expected SELECT statement. Instead of manually digging through the codebase, I used AppMap to scour the application for flaws and present me with comprehensive information about the exact locations of the issues within the codebase. Armed with this valuable insight, we are able to initiate fixes effectively.

If we open the Runtime Analysis tab in the AppMap plugin, we can see that it identified aINSERT into the analytics database, complete with IP addresses and other relevant information. A closer inspection reveals that this INSERT statement is occurring within a GET request. Oftentimes this is not the desired behavior and needs to be fixed. In our example, there are no side effects and the INSERT is simply logging traffic analytics data and may not need to be removed, however for purposes of our demonstration I will treat this as an issue that needs resolving.

Please note that not every INSERT in a GET request handler is a side effect and may be valid because it has no effect on the response; these types of side effects are not against spec. It’s perfectly fine to log API calls in your database or increment your API usage counter and still keep that API safe.

To pinpoint the source of this issue, click on the caller function link in the side panel. Doing so jumps to the call stack within the trace view, and we can see more information about the calling function in our side panel. By selecting the source path in the gray box, we are led to the code section we need to investigate. In our case, active_support/callbacks.rb

Active Support, a core dependency of Ruby on Rails, played a crucial role in initiating the action that causes the rogue INSERT to occur. While this is framework-dependent code and nothing we wrote, we don’t want to change it. However, the invoke before function does give us a clue as to what is happening. The function looks like this:

def invoke_before(arg)
  @before.each { |b| b.call(arg) }
end

From this, we know that before any incoming request is processed, some function or action is getting called by one of our controllers to perform some action. Knowing that we need to find where the action gets created, by viewing which services the HTTP request “talks to” we can get a hint as to where the real issue might be

Tracing our steps further, we explore the HTTP request by switching to the dependency map, focusing on the GET /request and its connection to ActionPack, Active Support, and other parts of our code. Although most paths were internal or beyond our control, one of them led us to controllers/dashboard_controller.rb. We can navigate directly to it by clicking to expand the app/controllers box, then clicking on the DashboardController node and using the gray navigation box in the left panel.

Inside the DashboardController, I discover two important pieces of information:

1) That this controller is inheriting attributes from application_controller.rb

2) There is a skip_before_action method that skips actions that are invoked before the rest of the controller code executes

I would like to look at the parent controller to see what this controller is inheriting and what actions are being run. Upon examining the application controller, I observe the problematic before_actionmethod responsible for triggering a create analytic method which actually performs the work. This is the exact spot where the issue originates.

# frozen_string_literal: true
class DashboardController < ApplicationController
  skip_before_action :has_info, :create_analytic
  layout false, only: [:change_graph]

By adding this particular action to the skip_before_action list in our dasboard_controller and saving the changes, I am able to eliminate the unwanted INSERT behavior. It's worth noting again that in some cases, such as when logging user activity, leaving the INSERT intact might be preferable as it doesn’t cause any side effects.

This entire process of identifying and fixing the issue was made possible by utilizing AppMap to find and navigate our application’s runtime behavior, quickly guiding us to the resolution. Doing this without AppMap would have required a lot more time for investigation with multiple tools. But only AppMap can detect this kind of issue in the first place without us even knowing that there is an issue.

Links

⬇️ Download AppMap for VSCode and JetBrains: https://appmap.io/download

⭐ Star AppMap on GitHub: https://github.com/getappmap

🐦 Follow on Twitter: https://twitter.com/getappmap

💬 Join AppMap Slack: https://appmap.io/slack

ℹ️ Read the AppMap docs: https://appmap.io/docs

Garrett HamelinFollow

I love technology and everything about it. I'm a software engineer who enjoys helping others succeed and building communities of like minded people.

Find and fix non-Restful APIs with runtime analysis

Garrett Hamelin — Tue, 06 Jun 2023 20:53:37 +0000

Go beyond static code analysis: Understand how your data flows through a process from start to finish

Garrett Hamelin — Fri, 12 May 2023 19:02:33 +0000

A tutorial for process recording for Java with AppMap.

Once you’ve recorded a process, AppMap allows you to get a bird's eye view of everything going on in a process from start to finish by drilling down into the individual functions and classes. This allows you to understand how data flows through the whole process.

This article teaches how to set up process recording in Java with AppMap. We will use IntelliJ IDEA and a pet clinic application as the example repo.

First, let’s configure.

To do this, we're going to take a look at run configurations. Run configurations are a convenient way to run your application using different environments with different environment variables. In addition, run configurations allow you to set up multiple scenarios or situations your app could run in.

Edit your run configuration by adding a specific variable to the virtual machine environment.
To do that, click on the drop-down in the upper right corner of your editor and select edit configurations.
From here, you should see a field labeled “VM options” under the "build and run" section. The field may be hidden by default, so if you don't see it, select modify options, then under Java, select add "VM options."
A new field should appear labeled "VM Options," inside of which we are going to place this option: -Dappmap.recording.auto=true

Next, let’s start a recording.

Select the run configuration you created, and click the "Start with AppMap” button.
Once the application is running, AppMap will record the process.

It is not readily apparent, but there is a process recording running. You can verify that by looking at the bottom left-hand corner next to the AppMap logo. You should see a green dot indicating that a recording is active.

Finally, interact with your application

Visit the application running in your browser and use it as you normally would.
Once you have interacted with your application, press the "Stop" button to end the process.

The AppMap recording will stop as well. Soon you will see a new recording designated by a number in your list of AppMaps, it will be named by the date.

How to use your maps

View your maps, and use them to navigate to code and make changes. You may find behavioral and performance issues by opening the runtime analysis option. Use sequence diagrams, or generate OpenAPI documentation based on this new flow.

Process recording can be done with Python, Javascript, and Ruby as well. Find AppMap in the VS Code marketplace as well as JetBrains.

How to navigate a new codebase with AppMap

Garrett Hamelin — Fri, 28 Apr 2023 21:04:28 +0000

In the tech industry, changing jobs feels inevitable. Whether moving on to advance your career or being caught up in an unfortunate layoff. But, eventually, just about everyone will find themselves staring at an unfamiliar code base at some point or time in their career.

Starting fresh can be both exciting and slightly unnerving. There's often a feeling of: "Oh no, I don't understand any of this" that we know will go away with time, but it can be daunting.

For me, even if I've worked in the language for several years or I am familiar with the framework, that uncertainty happens. And, the longer I work in the industry, the more I realize I'm not alone.

There are tons of articles and blogs out there that give steps for how to learn a new codebase quickly, but what if there was a way you could get an overview very quickly to see how things work together? Or a way to show how the features we were responsible for connect to the rest of the application?

In this article, I will show you an unconventional way to use AppMap, an incredible mapping tool. Rather than using it to map your application to refactor it or fix issues, we will use it to get familiar with a new codebase.

To follow along, the example project we are using can be found here.

Before we start, here's a brief intro to AppMap.

What is AppMap?

AppMap is an open-source tool that automatically generates a visual representation of your code behavior. It allows you to see the relationships between different components, understand how they interact with each other, and identify potential issues.

How does it work?

AppMap works by analyzing your code as it runs. It records every method call and visually represents the code flow. This visualization can be used to identify specific areas of code that may need attention or to better understand how the code works.

How can I use it?

Using AppMap is easy. Download the AppMap agent and add it to your Java application. Once the agent is running, it will start recording method calls and generating the visual representation of your code. You can then use this visualization to explore your code base and better understand how it works.

Get started learning a new codebase

Let's say we just started at a software company specializing in Veterinary Clinic software. Our software is a Java application that uses the Spring framework, and we are using IntelliJ IDEA for our development environment. We've been given access to the repo, have our first ticket, and we need to add a nickname attribute to a pet when it gets created. We have yet to learn what the codebase looks like or how the application works, so let's get started.

To follow along, the example project we are using can be found here.

First, pull down the repo and open it inside your IDE. Then, install the AppMap plugin if you haven’t already. Here's a quick how to to get you up to speed. Next, install the correct Java versions (I'm using v17), then we will map the application. AppMap's integration with IntelliJ is thorough, and mapping an application is pretty straightforward.

To the tests

A mentor once told me: "If you don't know what's going on in a codebase, start with the tests. If there are no tests. Run."

Starting with tests is a decent strategy and has worked out many times before, so let's map some tests. In the IDE open:

test > java > org.springframework.samples.petclinic > PetClinicIntegrationTests

Next, from the three dots menu in the upper right-hand corner near the run button, select Start PetClinicIntegrationTests with AppMap

Open the AppMap plugin by selecting the icon from the right-hand menu bar.

AppMap automatically generates maps for us. If you're following along, you should see two tests. One is for a "find all" action, and one is for "owner details." We can select either to view it. Let's take a look at “owner details.”

This map is great but we need to update the pet, not the owner which isn’t on the list. Let's create another map and see if we can learn more about our application.

Recording application interactions

The best way to learn an application and how it works is to use it, so let's actually use it. While we use the application, we will record what we do in the app with AppMap.

To do this, start the application with AppMap. In IntelliJ, open

src > main > java > org.springframework.samples.petclinic > PetClinicApplication.

Next, we will start the application the same way we did when mapping tests, but this time select "Start PetClinicAppliactaion with AppMap."

From the AppMap plugin menu, click the round gray record button in the upper right-hand corner.

A pop-up menu should appear, select the remote URL from the drop-down menu and click start recording.

The pet clinic application should open a new tab in your browser with the application running; if it does not, open a browser and navigate to the remote URL you selected. If you're following along, the remote URL is

http://localhost:8080/.

Now that the application is running, we can start using it. First, let's add an owner. Select find owners and then click the "Add Owner" button.

Fill out the form with whatever data you would like and add the owner.

On the next screen, select "Add Pet" fill in the details, and add the pet.

Once we have added a pet successfully, we will see this screen.

Let's head back to our IDE and stop the recording by selecting the grey square button in the AppMap plugin menu.

A new pop-up should appear. Let's name our map "add pet" and select stop recording.

Congrats, you just generated your first map.

It takes a moment for AppMap to process, then once complete, you should see the new map open in your IDE. The map itself is stored locally in a tmp folder in the root directory of your project.

The default view is a sequence diagram of the entire process we just went through. The sequence diagram is the heart of an AppMap and tells you exactly what happened from start to finish. The sequence diagram view is one of the most useful views you can look at and it gives a ton of detail about the app. If you have never used one, take the time to learn about them and what they do.

There are many ways to take advantage of this view in the future, but for this example, we are looking for a more general view of the application. There are two other map views you can look at that give more insight into what is happening in your application under the hood and how everything is connected. Each can be viewed by clicking the tabs at the top of the AppMap view. They are the trace view and dependency map.

Making updates with AppMap

These views are great, but if you can't use them to your advantage, they are just cool pictures. With that in mind let's use them. The real power of your maps comes from recording interactions and being able to follow connections from one part of your application to another.

First, open the dependency map and click the plus buttons to expand the colored boxes until you see the owner controller. When you click on the PetController, the left-side menu will update. This menu lists functions, inbound connections, queries, and the file path to the PetController. We can even see the creation form we need to change.

We can open the controller to change it right from here. We click the open in a new tab icon in the file path box, or we can click on the function we want to change, then the open icon and your controller will open. We can make any edits, commit, and push. Plus, we can export the sequence diagram of the new behavior as an SVG and attach it to our pull request for our team to check over which helps them understand my new code as well.

Now, we completed our first ticket without digging through hours of documentation and directories to find what you were looking for! We found the controller we needed to work on, understand how it works, understand what it's connected to, and made a change. The more we view and study these maps, the better we will know how they work and are connected.

Summary

Starting a new job can be daunting, but with the help of AppMap, you can quickly get up to speed and easily navigate any new codebase.

Whether you're a seasoned developer or just starting, AppMap is a valuable tool to have in your arsenal. Try it out today and see how it can help you become more productive and efficient in your new role.

Check out some other amazing things AppMap can do like OpenAPI documentation generation or runtime analysis on the AppMap Documentation. If you find something awesome or use it in an exciting way I’d love to hear about it. I always hang out in the AppMap community Slack and am stoked to hear people's stories.