When your application grows quickly, so do the demands on your infrastructure. AWS Lambda offers automatic scaling by design, but without the right configuration, it can lead to cold start latency, manual overhead, and escalating costs. As part of our Fractional CTO Service, we’ve worked with clients to address challenges like cold start latency and scaling in AWS Lambda, so we wanted to highlight an example where we were able to successfully implement Lambda auto scaling.

In this guide, we’ll walk through how our team tackled these challenges by implementing **Lambda auto scaling with provisioned concurrency**—a move that significantly improved both performance and cost-efficiency.

------

## The Problem with AWS Lambda Cold Starts and Manual Scaling

Our client’s application was built using AWS Lambda, but their serverless architecture had a major bottleneck: As more users joined, Lambda functions experienced cold starts, leading to sluggish response times. To compensate, we manually increased provisioned concurrency before major events. This fixed performance—but introduced human error and high costs when concurrency was left high after traffic dropped.

---


## Understanding Lambda Auto Scaling with Provisioned Concurrency

A common misconception is that AWS Lambda always scales instantly. While it can spin up new instances as requests come in, each new instance introduces **cold start latency**.

**Provisioned concurrency** solves this by keeping a set number of Lambda instances warm and ready. But provisioning too many functions 24/7 can be expensive.

<a href="/assets/blog/2025-04-30-how-we-solved-aws-lambda-scaling-with-auto-scaling-and-provisioned-concurrency/ProvisionedvsColdStart.png" target="_blank" rel="noopener noreferrer">
 <img src="/assets/blog/2025-04-30-how-we-solved-aws-lambda-scaling-with-auto-scaling-and-provisioned-concurrency/ProvisionedvsColdStart.png" 
 alt="Provisioned vs Unprovisioned Lambda Concurrency Chart" 
 style="max-width: 100%; height: auto; border-radius: 10px;" />
</a>

That’s where **AWS Application Auto Scaling** comes in. It dynamically adjusts provisioned concurrency based on real-time metrics—scaling up during traffic spikes, and scaling down when demand slows. This gives us the performance benefits of warm Lambdas without the cost of over-provisioning.



## Real-World Lambda Scaling: Our Configuration in Practice
Here’s how we implemented it using the Serverless Framework:
<ul style="list-style: initial; padding-left: 1.2em;">
 <li style="margin-bottom: 0.5em;">Provisioned concurrency is configured for high-traffic endpoints.</li>
 <li style="margin-bottom: 0.5em;">CloudWatch alarms monitor usage and trigger scaling actions.</li>
 <li style="margin-bottom: 0.5em;">We maintain a buffer by targeting 70% utilization—this keeps 30% of provisioned Lambdas in reserve for surges.</li>
 <li style="margin-bottom: 0.5em;">Scaling thresholds are evaluated over a 3-minute trailing window to smooth out short-term spikes.</li>
</ul>



Instead of manually maintaining 100 Lambdas 24/7, we now start with a baseline and **let the system scale intelligently**. This configuration is version-controlled, reproducible, and deployable through code.

## Key Benefits of Lambda Auto Scaling

This technical refactor of our client's serverless architecture solved real business problems and alleviated serious developer painpoints, all while enabling their application to scale further.

In summary, the core benefits were that now their application had:

<ol style="list-style-type: decimal; padding-left: 1.2em;">
 <li style="margin-bottom: 1.2em;">
 Reduced Cold Start Latency 
 With warm Lambdas available before traffic arrives, users no longer experienced delays during onboarding events or high-concurrency scenarios.
 </li>

 <li style="margin-bottom: 1.2em;">
 Lower AWS Costs Without Sacrificing Performance 
 We eliminated the need to keep high concurrency levels running 24/7. The system automatically scales down during quiet periods, cutting unnecessary spend.
 </li>

 <li style="margin-bottom: 1.2em;">
 Automation Replaced Human Guesswork 
 No more manual adjustments to concurrency settings. CloudWatch and Application Auto Scaling now handle scaling based on real usage, reducing operational overhead and human error.
 </li>

 <li style="margin-bottom: 1.2em;">
 Infrastructure That Grows with Demand 
 The system now scales with actual traffic patterns. Whether we have 10 users or 10,000, Lambda concurrency adjusts dynamically to meet demand.
 </li>
</ol>

<a href="/assets/blog/2025-04-30-how-we-solved-aws-lambda-scaling-with-auto-scaling-and-provisioned-concurrency/PerformanceComparison.png" target="_blank" rel="noopener noreferrer">
 <img src="/assets/blog/2025-04-30-how-we-solved-aws-lambda-scaling-with-auto-scaling-and-provisioned-concurrency/PerformanceComparison.png" alt="Lambda Scaling: Before vs After Auto Scaling" style="max-width: 100%; height: auto; border-radius: 10px;" />
</a>


## Tips for Implementing Auto Scaling with the Serverless Framework

If you’re looking to implement something similar, here are some key recommendations:
<ul style="list-style: disc; padding-left: 1.2em;">
 <li style="margin-bottom: 1em;">
 Use the Serverless Framework with the <code>serverless-provisioned-concurrency-autoscaling</code> plugin.
 </li>

 <li style="margin-bottom: 1em;">
 Define your min/max concurrency values clearly to prevent over- or under-scaling.
 </li>

 <li style="margin-bottom: 1em;">
 Monitor with CloudWatch and adjust based on real traffic, not estimates.
 </li>

 <li style="margin-bottom: 1em;">
 Tune your buffer and utilization targets based on observed load patterns.
 </li>
</ul>



## Final Thoughts: Smarter Scaling, Lower Costs, and Better Performance

By combining **AWS Lambda provisioned concurrency** with **auto scaling**, and isolating our environments, we created a system that is more resilient, cost-effective, and scalable.

If your team is manually adjusting concurrency or struggling with cold start latency, this pattern could save you time, money, and headaches.

Want a more detailed walkthrough or help applying this in your stack? Get in touch <a href="https://www.olioapps.com/contact-us" style="color: blue; text-decoration: underline;" target="_blank" rel="noopener noreferrer">here.</a>

## Resources Mentioned
<ol style="list-style-type: decimal; padding-left: 1.5em; margin: 1em 0;">
 <li><a href="https://docs.aws.amazon.com/lambda/latest/dg/welcome.html" style="text-decoration: underline;" target="_blank" rel="noopener noreferrer">AWS Lambda</a></li>
 <li><a href="https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html" style="text-decoration: underline;" target="_blank" rel="noopener noreferrer">Lambda Provisioned Concurrency</a></li>
 <li><a href="https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html" style="text-decoration: underline;" target="_blank" rel="noopener noreferrer">AWS Application Autoscaling</a></li>
 <li><a href="https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html" style="text-decoration: underline;" target="_blank" rel="noopener noreferrer">CloudWatch Alarms</a></li>
 <li><a href="https://www.serverless.com/plugins/serverless-plugin-optimize" style="text-decoration: underline;" target="_blank" rel="noopener noreferrer">Serverless Provisioned Concurrency Plugin</a></li>
</ol>

In this guide, we’ll walk through how our team tackled these challenges by restructuring our AWS environments and implementing Lambda auto scaling with provisioned concurrency—a move that significantly improved both performance and cost-efficiency.

How We Solved AWS Lambda Scalaing with Auto Scaling and Provisioned Concurrency

As a software developer with little background in design and color theory, you might find yourself tasked with creating visually appealing web pages. Without a solid foundation in design principles, especially color theory, this can seem daunting. You might wonder how to quickly and effectively choose colors that create a cohesive and aesthetically pleasing design. I'll explore how I used AI, specifically ChatGPT-4o, to solve this problem by leveraging color theory principles to generate color schemes mathematically.

As a developer with a background in art, I've always relied on traditional watercolor theory to create visually striking color palettes. The theory is simple: take your primary color, find its contrasting color, and mix the two to get a neutral tone. This neutral tone helps other colors pop on the canvas or page. However, applying this theory to website design can be challenging, especially for those without an art background. I wondered if there was a mathematical way to reproduce these watercolor results using hex codes, making the process more accessible for everyone.

I started with a watercolor study, using an orange as my primary color and blue as its contrasting color. By mixing these two, I obtained a neutral tone. I scanned these watercolor samples and used an eye dropper tool to extract their hex codes. With these hex codes, I styled a dummy app, incorporating the primary color, complementary color, and neutral tones for text and drop shadows.
<img src="/assets/blog/2024-09-09-utilizing-LLMs-to-mathematically-determine-color-themes-for-websites/Pallette.png" alt="Colors" style="display: block; max-width: 100%;">
<img src="/assets/blog/2024-09-09-utilizing-LLMs-to-mathematically-determine-color-themes-for-websites/Headers.png" alt="Headers" style="display: block; max-width: 100%;">

Next, I turned to ChatGPT. I provided it with the hex codes: the starting color (orange), the contrasting color (blue), and the neutral tone obtained from my watercolor study. My goal was to see if ChatGPT could replicate this process mathematically.

Initially, ChatGPT calculated the contrasting color and the neutral tone. However, the neutral tone was always a perfect gray (hex code: #888888), which didn't match the nuanced neutral tones I observed in my watercolor samples. I realized that the mathematical approach needed refinement to account for the blending of colors in a more realistic manner, since with this mathematical approach the exact contrasting color was achieved every time, which, in color theory, means that the neutral tone will always be a perfectly neutral gray.

I queried ChatGPT to explore if using light filters or different blending techniques could achieve a more accurate neutral tone. This led to the discovery of alpha blending, which involves overlaying colors with varying transparency levels. By applying a 60% filter for the primary color and a 40% filter for the contrasting color, I achieved a neutral tone that leaned more towards the primary color, mimicking the watercolor effect.

<img src="/assets/blog/2024-09-09-utilizing-LLMs-to-mathematically-determine-color-themes-for-websites/equation.png" alt="equation" style="display: block; max-width: 100%;">

With this refined approach, I developed an equation where I input a single color, and ChatGPT calculates the complementary and neutral tones. This method allows me to create harmonious color palettes mathematically, making the process accessible to those without an art background. For example, in a scenario where a client's logo color is orange, I can now generate a visually appealing color scheme for their website with ease.

<img src="/assets/blog/2024-09-09-utilizing-LLMs-to-mathematically-determine-color-themes-for-websites/colors.png" alt="equation" style="display: block; max-width: 50%;">
<img src="/assets/blog/2024-09-09-utilizing-LLMs-to-mathematically-determine-color-themes-for-websites/Headers2.png" alt="Headers2" style="display: block; max-width: 100%;">

Traditionally, determining color themes relied heavily on artistic intuition and manual blending techniques. While effective, this approach can be challenging for those without a strong art background. By leveraging AI and mathematical principles, we can automate and simplify this process, making it accessible to developers without design teams or time to get a Master's in Fine Art. This new approach not only saves time but also ensures consistency and accuracy in color theme generation for websites. And it's fun!

You might wonder how to quickly and effectively choose colors that create a cohesive and aesthetically pleasing design. I'll explore how I used AI, specifically ChatGPT-4o, to solve this problem by leveraging color theory principles to generate color schemes mathematically.

Using AI To Create Website Color Themes

At Olio Apps we understand the challenges organizations adopting cloud for the first time or experimenting with serverless development run into when it comes to designing and deploying scalable and cost effective architecture on AWS.

Seldom does an organization have the time and resources to commit to learning a new tech stack while developing features.

At Olio Apps we regularly support clients who are in need of talent specialized in specific AWS services who can disperse that knowledge throughout the organization.

This is why we support our team members in developing their knowledge of cloud and serverless best practices when it comes to AWS Infrastructure.

Today, we are excited to announce and celebrate Aaron Whitaker’s recent AWS Solutions Architect Certification.

The AWS Solutions Architect Certification validates proficiency in designing and deploying scalable and cost-efficient cloud solutions on AWS. Individuals with this expertise are able to tailor AWS infrastructure to an organization’s needs while optimizing performance and cost-effectiveness. Additionally, those who achieve AWS Certification in general can be assured they are up to date with Amazon’s best practices and innovation standards.

## AWS Solutions Architect Associate Bolsters Technical Abilities

Aaron found that the process of studying and learning for the AWS Solutions Architect Certification exam reinforced his practical knowledge while exposing him to additional best practices:

> Getting the solutions architect certification helped to reinforce the knowledge I’ve gained through practical experience working in AWS for the past two years. It also gave me more insight into best practices and patterns I hadn’t previously known about. It's given me more confidence to design well-architected cloud systems

Aaron is a Fullstack Engineer at Olio Apps who specializes in fullstack and serverless applications. You can learn more about the team at Olio Apps <a href="https://www.olioapps.com/team">here.</a>

Congratulations again Aaron, we are excited to see how this new knowledge from the AWS Solutions Architect Certification encourages your further learning.

At Olio Apps we acknowledge that Amazon Web Services (AWS) is an industry leader when it comes to providing reliable and scalable cloud services for companies across all domains.

Celebrating Aaron Whitaker’s AWS Solutions Architect Certification

At Olio Apps EventBridge has become a huge topic of conversation ever since we’ve been using it with one of our clients. Initially, our client’s architecture followed a synchronous inline model where you give the server a request and then it does A, B, C, D, and E.

As the app continues to grow, it becomes harder to manage all of these different threads and if-thens. So we've shifted to utilize AWS event-driven architecture, a first for this client. Initially, we integrated with SQS queues (Amazon Simple Queuing Service) to manage asynchronous job processing. Since then we have begun to shift more and more to event driven architecture patterns.

## Facilitating Event Driven Architecture Evolution using Amazon EventBridge

Some of you may recognize this paradigm. Initially, we needed to trigger notifications based on specific factors like the day of the week, how long it had been since a certain event happened, or a user’s relationship to one another.

So we began to utilize a serverless event bus, Amazon EventBridge, to listen, schedule, & trigger these events. EventBridge Listener would wait for specific events to enter the event bus. Once they did, this would trigger a corresponding lambda function to take the event to an SQS queue where it would then be processed asynchronously.

The above description is essentially the base use case described by AWS’ official illustrations. This image shows the event bus and the different events being pumped into it from specific sources.

<img src="/assets/blog/2024-09-04-facilitating-event-driven-architecture-evolution-using-amazon-eventbridge/eventbridgediagram.png" alt="EventBridge Diagram" style="display: block; max-width: 100%;">

And as stated in <a href="https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-service-event-list.html">AWS’ documentation</a> EventBridge can handle input from a variety of AWS sources or from a custom event bus.

In particular, we provisioned our AWS resources using the serverless framework and used a combination of EventBridge’s rules, event matching, and routing capabilities to enable a user experience informed by the context of these specific events.

## Value of Eventbridge

In summary this is how EventBridge functions as we have events flowing into the pipeline with the following orchestration.

**Rules**: We define rules within EventBridge that act as event filters. These rules can listen for specific events, like "user created" or "user updated."

**Event Matching**: Each rule is configured with an event pattern. This pattern specifies the data characteristics and the rule it is looking for. For instance, a rule might match events where the "detail-type" property equals "user-updated" and the "source" property equals "staging-API."

**Routing Events**: When an event matches a rule's pattern, EventBridge routes it to a designated target. This target can be a Lambda function that we've previously defined to handle the event.

Imagine a rule named "user-updated-event-bridge-rule." This rule intercepts events flowing through the pipeline, searching for events that match its criteria (detail-type="user-updated" and source="staging-API").
If an event doesn't match, it's simply passed along. However, if a match occurs, the event is directed to the Lambda function associated with that rule. This Lambda function executes the desired logic based on the received event data.

A major reason EventBridge has been so valuable for our client’s event driven architecture is because of EventBridge’s robust flexibility, including:

**Multiple Rules per Event**: A single event can be matched by multiple rules, allowing for diverse processing paths.

**Multiple Targets per Rule**: Each rule can route events to up to five different targets, enabling parallel processing or sending events to various services.

**Event Data**: We can include any relevant data within the event itself. This allows Lambda functions to perform actions based on the differences between old and new data (e.g., detecting a user's change in profile information).

This ability to define custom rules and targets empowered us to make intricate event workflows that fit our client’s needs. Currently, we have Lambda functions that trigger additional events based on the processed data, sending them back into the EventBridge pipeline for further processing of 3rd party APIs. This is one example where we are able to leverage the vast capabilities of EventBridge for enabling event driven architecture. for building sophisticated event-driven architectures using EventBridge.

Overall, this EventBridge architecture has allowed us to offload all these semi-heavy computational side effects when there is a profile update to the cloud. So we're not taking a bunch of performance hits by running everything in line on individual requests.

We hope you enjoyed our discussion on how Olio Apps is utilizing EventBridge to meet customer needs using event driven architecture on AWS. If you have any questions about using EventBridge yourself or have any questions about how your application may be able to utilize EventBridge, please don’t hesitate to contact us.

At Olio Apps, EventBridge has become a huge topic of conversation ever since we’ve been using it with one of our clients. As the app continues to grow in complexity and perform more complex functions, it becomes harder to manage all of these different threads and if-thens

Facilitating Event Driven Architecture Evolution Using Amazon EventBridge


When prototyping, designing, and building software applications for clients it’s essential to have a firm grasp on emerging technology. However, technology itself is seldom what drives value for a business; it’s knowing how, when, and where to apply the technology in question that brings maximum value. 

At Olio Apps, we value the skillful application of emerging technology to SMB and enterprise business problems and that’s why we encourage our team members to continually expand their knowledge in all areas of software development.

This is why we are excited to announce and celebrate today Dustin Herboldshimer’s recent AWS Technical Accreditation.

The AWS Technical Accreditation provides training and assessment opportunities for individuals to demonstrate their proficiency in implementing AWS services, solutions, and best practices. It covers a range of topics related to AWS cloud computing, including architecture, security, operations, and migration.

## AWS Technical Accreditation Bolsters Technical Abilities

Dustin has found the process of studying and learning for his accreditation meaningful:

> Through my AWS Technical Accreditation course, I gained a deeper understanding of the full range of AWS services and their applications. I also learned more about the significant business benefits of adopting serverless technologies, enhancing my ability to prescribe efficient and innovative cloud solutions based on customer requirements.

Dustin is one of our Engineering Managers and developers focused on React Web Applications and Full Stack Development. You can learn more about the team at Olio Apps here.

Congratulations again Dustin and we encourage you to continue developing your breadth of expertise. 


Celebrating Dustin Herbolshimer’s AWS Technical Accreditation


At Olio Apps we acknowledge that Amazon Web Services (AWS) is an industry leader when it comes to providing reliable and scalable cloud services for companies across all domains.

Knowing this, we make it our mission to support our team members in growing their knowledge base and expertise regarding the suite of AWS services and use cases so we can suggest the best practices and architectures when it comes to solving client problems. This is why we are excited to announce and celebrate Laurie Waller’s recent AWS Developer Associate Certification.

The AWS Developer Associate certification validates expertise in developing cloud-based applications on AWS and ability to design, develop, and deploy applications on AWS. Those who achieve an AWS Certification can be assured they are up to date with Amazon’s best practices and innovation standards.

## AWS Developer Associate Bolsters Technical Abilities

Laurie found that the process of studying and learning for the AWS Developer Associate exam bolstered her technical skills:

> Securing the AWS Developer Associate certification significantly enhanced my proficiency in deploying, managing, and operating scalable systems on AWS. It not only bolstered my technical skills but also built up my strategic approach to cloud solutions, fostering both personal and professional growth and ensuring our team can deliver top-notch results...

Laurie is a Fullstack Engineer at Olio Apps and a self described lifelong learner. You can learn more about the team at Olio Apps here.

Congratulations again Laurie, we are happy to hear you learned so much by studying for your AWS Developer Associate Certification.


Celebrating Laurie Waller’s AWS Developer Associate Certification


Since the launch of serverless AWS services in 2006 with S3 and general availability of AWS Lambda in 2015 there has been steady adoption of serverless architectures across all industry verticals.

Building serverless applications alongside our SMB and enterprise clients, we at Olio Apps have seen a clear differentiator between an organization that skillfully applies serverless best practices on AWS and those that don’t. Those that do are able to maximize the agility, scalability, and cost-effectiveness of AWS architectures.

This isn’t surprising. As when it comes to the market share of Cloud Service Providers, AWS is still the leader in 2024 due to the benefits its infrastructure provides.

Getting to serve clients during these critical moments of prototyping, architecture design, and development with our serverless expertise and experience is a key pillar of pride and motivation for our organization.

“Olio Apps successfully delivered a functioning product, which received positive feedback on its quality, stability, and ease of use. The team delivered on time and within budget and worked in sprints to ensure a seamless workflow. They impressed with their flexibility and prototyping skills” -Trevor Dryer, CEO Carbon Title

In light of this, we see the general availability of Amazon Bedrock as the next wave of highly impactful and influential services offered by AWS. Amazon Bedrock represents a paradigm shift where all companies have access to the possibility of accelerating the performance of their organization with high-performing foundational models of leading AI companies.

However, like with serverless, for companies to maximize the benefits of Generative AI they select the right technology for the job and have the knowledge, experience and expertise to implement the technology correctly.

This can prove challenging since the field of Generative AI is relatively new and growing in popularity. Its novelty means that true Generative AI development expertise is scarce and choosing technical decisions because they are popular and not the best solution can become a costly mistake.

That is why we have decided to grow our partnership with Amazon Web Services through the Amazon Partner Network, focusing on designing, prototyping, and building Generative AI solutions with Amazon Bedrock and serverless development on AWS.

We aim to offer our seasoned leadership to companies having to make critical decisions regarding the use of Generative AI and serverless infrastructure to achieve their business goals.

In step with this commitment, we are empowering our team to invest in their education and knowledge base in the areas of Generative AI and serverless infrastructure on AWS.

Today we are honored and excited to announce that seven of our team members have already taken charge and received Accreditation and Certification from AWS in Q1.

Congratulations to Laurie Walker, Dustin Herboldshimer, Aaron Whitaker, Aron Glenn, Scott Becker, Aron Racho, and Joshua Proto for their recent achievements.

At Olio Apps we value a growth mindset that supports continuous learning and development. Having knowledge is essential to ensure the experience driven execution of mission critical projects.

Whether an organization is considering implementing Amazon Bedrock or serverless for the first time, or looking to scale their usage of these services on AWS, Olio Apps looks forward to being your trusted technology partner.


We have decided to grow our partnership with Amazon Web Services through the Amazon Partner Network, focusing on designing, prototyping, and building Generative AI solutions with Amazon Bedrock and serverless development on AWS.

Olio Apps Commits to AWS Partnership in 2024


This is a collection of techniques and tools we use at Olio Apps to make UI application development faster and more efficient!

## Atomic Design
https://bradfrost.com/blog/post/atomic-web-design/

The UI is an aggregation of discrete, composable components. These components are concerned *only* with presentation, eg. styling and content -- not logic.
- Smallest reusable elements are called Atoms
- They are designed to be generally agnostic of their environment

Atomic components have well defined contracts (eg. props). This expands to their containers.

Global atoms are composed into global, reusable molecules. Global atoms and molecules form the basis of feature-specific Molecules and Atoms. Molecules and Atoms are composed into pages

### Why?

- Separation of concerns -- you can focus on a single domain and be maximally effective
- Reuse -- need to "bless" every button in the app with a spinner? Update the basal Atom for it
- Parallelization -- folks can be divided into focusing on the pure presentational UI components, while others work on the "logic" pieces
- You can use storybook. More on this below

## Storybook

https://storybook.js.org/

Storybook is a rapid-development environment for pure presentation components. It is a framework for exercising / displaying all the behavioral variations for components as controlled by their props.

### Why?

- With storybook, you get an immediate feedback on the components as they are developed
- No need to "hack" the live environment that the components are going to be used in
- Sometimes there is NO live environment yet -- but you will not be blocked because you can use storybook to view your components
- Storybook is to UI component development as test-driven unit-test development is to non-ui component development
- Developers can use storybook to interact with the design team, publishing the full range and variation of components in an easy to access way
  - You don't need to seed an environment to show all the permutations of particular components and even whole pages
  - Designers can easily manipulate the storybook to see what things look like by simulating conditions such as size of that page, values of the props

## TypeScript

https://www.typescriptlang.org/

TypeScript is JavaScript 2.0 -- a strongly typed flavor of JavaScript. It can be incrementally added to a pure-JavaScript environment.

### Why?

Compile-time checking of errors. In larger apps, sometimes you will only know that a shape going into a function is incorrect once its in production.

Contract-driven development. Think of types will get developers to start thinking and planning about how pieces interact, first at the function level; next at the module level; finally at the systems level.

Without types, you can only know what the "valid" shape of an object is from its consumers.

- There are infinitely more consumers, and they change all the time
- Without a type or interface, I would have to inspect ALL the consumers of an object to know what its valid attributes are!
- Without types you cannot efficiently describe how a system interacts with itself, or other systems

## Redux

https://redux.js.org/

Redux is global state management for large scale appplications.

### Why?

Larger scale UIs often need to cache server side state. For example:

- Logged in user
- Incoming unread chat notifications
- Synced media

It is useful to cache this state because you don't want to pull it down all the time. If your app is going to work offline sometime, caching the data from disk in memory in redux is often useful. When some region in that state tree is changed, other interested parts of the UI can "listen" and react to those changes.

[Redux toolkit](https://redux-toolkit.js.org/) and Olio's own [Sitka framework](https://github.com/olioapps/sitka) are syntactic sugar built atop redux

## UI Backend Modularization

Just as the pure presentational components are organized into modules of specific Atoms, Molecules, and Pages. The "backend" of the frontend is also separated out into modules by feature/responsibility area. These pieces are NOT concerned with presentational concerns But are instead concerned with:

- Navigation (routing)
- Interaction with the API
- Interaction with the device (local storage, services such as bluetooth, push notifications, etc)

Modules are concerned with the management of their particular subslice of the global state (or have their own private state); and the operations against that state -- and nothing else.

### Why?

Parallelization

- Folks can work on and concentrate on the "backend" of the app while others work on the frontend
- Folks can work on different feature modules within the backend tree

Separation of concerns

- The logical and UI layers can change without breaking each other
- The backend feature modules are less likely to have regressions when they change, as their logic is self contained with the module

Reuse

- The backend modules may reuse each other using well defined contracts
- For instance we can have a module purely concerned with activity tracking
- That can be integrated with the navigation module which can record activity using the aforementioned module

Testability

- The entire functionality of a logical feature / module is easily unit testable because its possible to mock their state without having to mock out the rest of the system

## Sitka

https://github.com/olioapps/sitka

Sitka is an opinionated framework built atop of Redux and Redux Saga. It encapsulates UI backend modules into classes that control both state and operations of those modules.

### Why?

Sitka ticks all the items of the UI Backend Modularization section. You can safely modify module state via callbacks from the UI.

Sitka implements pub-sub mechanism:

- One module does something
- Other modules can "subscribe" and react to those

Sitka implements background "jobs" - recurring polling tasks.

Sitka is very powerful, and has been implemented in 10+ projects across multiple customers. Alternatives include redux toolkit.

## Summary

This collection of tools and techniques forms the basis for fast productive UI development projects at Olio Apps. We continue to iterate and build on our toolset every day.


This is a collection of techniques and tools we use at Olio Apps to make UI application development faster and more efficient!

UI Architecture Powerups - What, and Why

![Stairs](/assets/blog/2021-04-14-practical-recursion-with-react-components/recursion.jpg)

## What Is Recursion, and When Is It Useful?

In computer science, recursion is a key programming technique in which a function calls itself one or more times until a specific condition is met. It can be particularly useful when working with deeply nested structures that prove too complex for an iterative solution.

Though recursion seldom appears in an average programmer's day-to-day work, there are real-world use cases in frontend web applications, like the one we'll go over here.

## A Practical Use for Recursion in React

My team was tasked with putting together a reusable, infinitely nested tree component. The nested data structure coupled with infinite depth presented an opportunity for a recursive approach. Follow along to understand the ins and outs of a working React Tree component powered by recursion + React rendering.

Giving our component nested data in the following shape, we’ll now have a functioning, modular, and recursive component ready for use!

```typescript
interface TreeBranch {
 readonly id: string
 readonly label: string
 branches?: Tree
 readonly selected?: boolean
}

type Tree = ReadonlyArray<TreeBranch>

const mockOrgTreeList: Tree = [
 {
 label: "Liberty Health",
 id: "1",
 branches: [
 {
 label: "Pacific Northwest",
 id: "2",
 branches: [
 {
 label: "East Portland Clinic",
 id: "3",
 branches: [],
 },
 {
 label: "Beaverton / Tigard",
 id: "4",
 branches: [],
 },
 {
 label: "Lake Oswego Regency",
 id: "5",
 branches: [],
 },
 ],
 },
 {
 label: "Alaska",
 id: "6",
 branches: [],
 },
 ],
 },
 {
 label: "Northstar Alliance",
 id: "7",
 branches: [
 {
 label: "Chicago",
 id: "8",
 branches: [
 {
 label: "Southwest Region",
 id: "9",
 branches: [
 {
 label: "Desplains",
 id: "10",
 branches: [],
 },
 {
 label: "Oak Lawn",
 id: "11",
 branches: [],
 },
 ],
 },
 {
 label: "Northwest Region",
 id: "12",
 branches: [
 {
 label: "East Morland",
 id: "13",
 branches: [],
 },
 ],
 },
 ],
 },
 {
 label: "New York",
 id: "14",
 branches: [
 {
 label: "Manhattan",
 id: "15",
 branches: [],
 },
 {
 label: "Queens",
 id: "16",
 branches: [],
 },
 {
 label: "5372 Arlington Heights",
 id: "17",
 branches: [],
 },
 {
 label: "The Earlmore Institute of Health",
 id: "18",
 branches: [],
 },
 ],
 },
 ],
 },
]
```

The end product:

![Tree gif](/assets/blog/2021-04-14-practical-recursion-with-react-components/tree.gif)

## Building a Reusable Component

First, we’ll import React and create some styled Material UI components.

```typescript
import React, { Fragment, useState } from "react"
import { styled, makeStyles } from "@material-ui/core/styles"
import ExpandMoreIcon from "@material-ui/icons/ExpandMore"
import ChevronRightIcon from "@material-ui/icons/ChevronRight"
import Box from "@material-ui/core/Box"

// styles

const StyledLabel = styled(Box)({
 height: "24px",
 "&:hover": {
 cursor: "pointer",
 },
})
const StyledTreeItem = styled(Box)({
 display: "flex",
 flexDirection: "row",
 alignItems: "center",
})
const StyledTreeChildren = styled(Box)({
 paddingLeft: "10px",
})
```

## Props

Here are the prop shapes that we’ll use to build our components:

```typescript
interface TreeItemProps {
 readonly id: string
 readonly onSelectCallback: (e: React.MouseEvent<HTMLInputElement>) => void
 readonly label: string
 readonly isSelected: boolean | undefined
 readonly children: ReadonlyArray<JSX.Element>
}

interface RecursiveTreeProps {
 readonly listMeta: Tree
 readonly onSelectCallback: (value: TreeBranch) => void
}
```

### TreeItem

This will be our most atomic component, reused anywhere an item is rendered by the data we pass to our tree. This component can contain more of itself in a nested fashion, allowing us to render them recursively.

#### This component needs:

1. **onSelectCallback** - to power what happens when we click the item.
2. **label** - to display names of organizations (in our case).
3. **children** - to display nested items if they exist.
4. **isSelected** - to specify pre-selected items in the fetched data (as opposed to clicking to select the item).

```tsx
const TreeItem = ({
 onSelectCallback,
 label,
 isSelected,
 children,
}: TreeItemProps) => {
 const [isOpen, toggleItemOpen] = useState<boolean | null>(null)
 const [selected, setSelected] = useState(isSelected)

 return (
 <div>
 <StyledTreeItem>
 {children.length > 0 && (
 <Box
 className="icon-container"
 onClick={() => toggleItemOpen(!isOpen)}
 >
 {isOpen ? <ExpandMoreIcon /> : <ChevronRightIcon />}
 </Box>
 )}
 <StyledLabel
 className="label"
 onClick={(e: React.MouseEvent<HTMLInputElement>) => {
 setSelected(!selected)
 onSelectCallback(e)
 }}
 style={{
 marginLeft: `${children.length === 0 ? "24px" : ""}`,
 background: `${selected ? "#d5d5d5" : ""}`,
 }}
 >
 {label}
 </StyledLabel>
 </StyledTreeItem>
 <StyledTreeChildren>{isOpen && children}</StyledTreeChildren>
 </div>
 )
}
```

### Recursive Tree

This will be the workhorse component where our recursive logic lives. We pass our data here through listMeta to recursively render our TreeItem component as follows:

#### This component needs:

1. **listMeta** - the shape of our tree data.
2. **onSelectCallback** - to be passed down to TreeItems.

```tsx
const RecursiveTree = ({ listMeta, onSelectCallback }: RecursiveTreeProps) => {
 const createTree = (branch: TreeBranch) =>
 branch.branches && (
 <TreeItem
 id={branch.id}
 key={branch.id}
 onSelectCallback={(e: React.MouseEvent<HTMLElement>) => {
 onSelectCallback(branch)
 }}
 isSelected={branch.selected}
 label={branch.label}
 >
 {branch.branches.map((branch: TreeBranch) => {
 return <Fragment key={branch.id}>{createTree(branch)}</Fragment>
 })}
 </TreeItem>
 )

 return (
 <Box>
 {listMeta.map((branch: TreeBranch, i: any) => (
 <Box key={i}>{createTree(branch)}</Box>
 ))}
 </Box>
 )
}
```

## Our Functional Tree in Use

Check out the [Github repo here](https://github.com/jIrwinCline/recursive-react-tree).

## Some Final Thoughts

Recursion can be a crafty tool in a developer’s arsenal. But as we build a recursive pattern to have a lot of moving parts, complexity and drawbacks can start to manifest. There’s no magic associated with this concept. Most of the problems that can be solved by recursion are likely able to be solved with iterative loops. When recursive solutions seem tempting, make sure to consider the potential drawbacks.

#### When Not to Use Recursion

There are generally more reasons not to use recursion than to do so. Yes, it can be exciting to delve into an abstract solution, but a good engineer weighs the potential downsides, which we'll go over here.

- Results in code that's harder to read or comprehend

Recursion isn’t a pattern developers come across every day. When implemented, you’re bound to catch future developers off guard, which is a noteworthy downside. Difficulty comprehending the pattern at a later date is likely to occur, not only when teammates peak at the code, but also when you happen to return to your own code six months later.

This can be mitigated by extensively documenting and commenting your code. Explain to future developers (and yourself) why and where recursion occurs. For example, above the function, add a doc comment including an obvious note, such as, "This function is recursive. It calls itself in order to render all descendents." A comment directly above the line where recursion occurs can also be helpful to call out.

- Can make maintenance and debugging a nightmare

Developers maintaining the codebase in the years to come could potentially see this pattern in a bad light. When others (or even you) come back to the code, the recursive solution may not be self-explanatory. If new features need to be added or bugs show up, getting to the bottom of what’s happening may be harder with a pattern like this.

- Can lead to performance issues when processing large amounts of data

Recursion can be a memory-intensive operation with larger data sets. A function repeatedly calling itself will consume more memory when compared to an iterative loop. If your data set is not large, then pay no mind. But if a recursive solution is implemented in an environment where resources are scarce and the data is hefty enough, you could run out of memory.
Recursion can also be slow unless implemented carefully. For example, if each call to the function recomputes some value, but the result is actually the same for every iteration, or the same for each level in the tree, the function will be doing unnecessary repeated computations that could be avoided by applying memoization techniques.

## In the End

There can be good reasons to avoid recursion. But if your case doesn't have any of these red flags and you know your data set will always comfortably fit within your available memory, it can be a great solution to have up your sleeve.

Create a modular and recursively rendering tree component in React

Reinforced Learning