In this article, we will explore the API lifecycle, a crucial aspect of modern software development that ensures the effective management and utilization of Application Programming Interfaces (APIs).

The API lifecycle encompasses various stages, from planning and design to deployment, monitoring, and retirement. Understanding this lifecycle is essential for developers, product managers, and organizations looking to leverage APIs for their applications and services.

Stages of the API Lifecycle

1. Planning

The first stage involves identifying the need for an API. This includes understanding the target audience, defining the purpose of the API, and determining the resources required. During this phase, stakeholders should gather requirements and outline the expected functionalities.

2. Design

Once the planning is complete, the next step is to design the API. This includes defining endpoints, data formats, authentication methods, and error handling. Tools like Swagger or OpenAPI can be used to create API specifications, which serve as a blueprint for development.

3. Development

In this stage, developers write the code for the API based on the design specifications. This includes implementing the backend logic, setting up databases, and ensuring that the API adheres to the defined standards. Version control systems are often utilized to manage changes during this phase.

4. Testing

After development, thorough testing is essential to ensure the API functions as intended. This includes unit testing, integration testing, and performance testing. Automated testing tools can help streamline this process and ensure consistent results.

5. Deployment

Once testing is complete, the API is ready for deployment. This involves making the API accessible to users, which may include setting up servers, configuring load balancers, and ensuring security measures are in place. Documentation should also be published to guide users on how to interact with the API.

6. Monitoring

Post-deployment, continuous monitoring is crucial to ensure the API performs well and remains reliable. This includes tracking usage metrics, error rates, and response times. Monitoring tools can help identify issues early and provide insights for future improvements.

7. Maintenance

APIs require ongoing maintenance to address bugs, implement new features, and ensure compatibility with other systems. Regular updates and versioning are important to keep the API relevant and functional.

8. Retirement

Eventually, an API may become obsolete or be replaced by a newer version. The retirement phase involves deprecating the API, notifying users, and providing alternatives. Proper planning for retirement can minimize disruption for users.

Understanding the API lifecycle is vital for anyone involved in API development and management. By following these stages, organizations can create robust, reliable, and user-friendly APIs that meet the needs of their stakeholders.

Whether you are a developer, product manager, or business leader, grasping the intricacies of the API lifecycle will empower you to make informed decisions and drive successful API initiatives.

Life of an API was originally published in The Plumber on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you are into Cloud Computing or DevOps engineering, you may have heard of multi-cloud at some point. It has become a buzzword which for some people, may mean flexibility, high availability, resilience or even innovation.

Businesses more often than not envision an ideal world where workloads seamlessly operate between Google Cloud, AWS, Azure and others. The thought process usually involves leveraging each platform’s unique abilities and strengths.

But in reality, Multi-cloud often introduces more headaches than benefits.

The Case for Multi-Cloud

The appeal of multi-cloud is undeniable, especially for enterprises. One of the major reasons to consider a multi-cloud strategy is to avoid vendor lock-in. This is a huge concern for big companies stuck deep into a single provider.

Vendor lock-in is a real problem, not so much with generic offerings on public cloud platforms as it is with a lot of independent service providers, but that age-old fear still propagates.

Another major motivation for organizations to go with multi-cloud is its promise of higher availability and enhanced resiliency. With workloads distributed across providers, the fear of outages at one provider causing a halt to a company’s operations goes away.

And lastly, for companies operating in some regulated industries, multi-cloud might be the only option to meet local compliance requirements.

The Challenges of Multi-Cloud

But here’s the catch: multi-cloud isn’t a silver bullet that’ll magically solve all your problems. The operational complexity alone is huge.

Managing workloads across two or more cloud platforms means maintaining multiple toolsets, monitoring systems, and workflows. Your DevOps team needs expertise in everything from IAM policies in AWS to monitoring in Azure and networking in GCP. This not only increases the learning curve but also escalates costs.

Speaking of costs, let’s talk about data transfer fees. Moving data between providers can quickly become a financial black hole. Add to this the overhead of securing workloads across diverse environments — each with its quirks — and the promise of resilience starts to feel like an operational nightmare.

Latency is another often-overlooked factor. Inter-cloud communication introduces delays that can impact application performance.

I can go on and on about this topic, but you get the idea.

When Does Multi-Cloud Make Sense?

Despite these challenges, multi-cloud has its place. Global organizations with a strong operational backbone may find it vital for their business.

Similarly, companies with stringent compliance needs — like financial institutions — might have no choice but to spread workloads across regions and providers. This is also a very common scenario.

But for most businesses, the decision should be a careful balance. If the complexity outweighs the value, it might be time to reconsider.

I see startups which are just building their user base asking for multi-cloud deployments, just because it is fancy to do so. It should be avoided so early in a companies technical journey.

What’s the alternative?

Embrace cloud-agnostic tools like Kubernetes, Terraform, open-source tools with some kind of paid/premium support and independent service providers. These technologies allow you to build portable workloads without committing to a full-blown multi-cloud strategy.

For those who are already using on-premises, a hybrid cloud strategy may be one option, but it has its own challenges which I’ll discuss some other time.

Conclusion

Here’s my take:

Multi-cloud is often a solution looking for a problem. For most organizations, it introduces unnecessary complexity, skyrocketing costs, and operational challenges.

Unless there’s a compelling reason — like regulatory compliance or the need for specific features across providers — it’s usually better to focus on optimizing a single cloud provider.

The cloud landscape is already complex. Adding multiple providers to the mix can derail your team’s focus, slow down delivery, and ultimately dilute the value you’re aiming to create.

Choose simplicity, and let the business — not the buzzwords — drive your strategy. Simplicity often beats complexity.

What’s your stance on multi-cloud? Share in the comments or on X

Multi-Cloud: A Strategy or a Headache? was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR

• Develop: Git, GitHub, GitLab, BitBucket
• Infrastructure management: Terraform, Ansible
• Build and Deploy: GitHub Actions, GitLab CI, ArgoCD, Jenkins
• Monitor: Grafana + Prometheus

Develop

Collaboration on the code is essential, and you must be familiar with version control systems, the most popular of which is Git.

• Learn how Git works.
• How to implement branching strategies and branch protection.
• How to work with pull requests.

Tools: Git, GitHub, GitLab, BitBucket

Build and Test

This is where you do the CI(continuous integration) part of a CICD pipeline. You bundle your code with language-specific tools such as Maven/Gradle for Java, npm for node projects etc.

Testing is also dependent on the languages you are using. Some common tools for testing are Cypress, JUnit, and PyTest.

Container-based applications are very common, and you need to learn how to build container images. Docker is the most popular, and I would suggest learning that. After that, you can also explore Podman.

You automate such building and testing tasks in a CICD pipeline.

Tools: GitHub Actions, Jenkins, GitLab CI

Release

Once you have built the artifacts, you’ll need a place to store and version these artifacts. Examples of common artefacts: Docker Images, JAR files, Python modules, Node Modules, Go binaries etc.

Tools: JFrog Artifactory, Nexus, DockerHub

Deploy

Deployment of a particular application depends on its type and how to run that artifact in different machines. However, you should know common deployment strategies such as in-place, blue-green and canary deployments.

Tools: ArgoCD, Helm, Spinnaker + tools tools mentioned in Build and Test

Operate

Deployment of applications is done on some kind of infrastructure, either cloud-based or on-premises.

You should know the basics of cloud computing and how it works, you can start with any of Google Cloud, AWS, or Azure.

Apart from that you need to know the tools to manage the infrastructure on Cloud or on-premises. Apart from Infrastructure as Code, you will also need Configuration as Code for application/server configuration management.

Tools: Terraform, Ansible, Chef, Pulumi, Crossplane

Monitor

Finally, you need to understand monitoring and observability.

If something breaks, you want to know before your users do. For example, a spike in response times might indicate an issue. With proper monitoring, you can catch and fix it before it escalates.

Tools: Prometheus, Grafana, Datadog, SigNoz

The DevOps toolchain isn’t just about tools — it’s about creating a streamlined process that supports collaboration, automation, and continuous improvement.

By choosing the right tools and using them effectively, you’ll build systems that are not only resilient but also a joy to work with.

What’s your favorite DevOps tool? Or do you have a unique toolchain setup? Let me know — I’d love to hear your thoughts!

Understanding the DevOps Toolchain was originally published in The Plumber on Medium, where people are continuing the conversation by highlighting and responding to this story.

DevOps Engineering is a multi-faceted role. It bridges the gap between development and operations by streamlining processes, automating workflows and improving system reliability.

While it is rewarding, it comes with several challenges.

Tool Overload

The DevOps ecosystem is vast, with multiple tools for CI/CD, configuration management, IaC, observability, orchestration and whatnot. Selecting tools is confusing and mastering the right ones is necessary.

But..

The problem doesn't end there, you need to ensure that the tools you’ve selected work well together, which may not be the case always. You’ll end up writing custom code adding to a lot of complexity.

Speed vs Stability

Balancing the two is hard. Delivering new features quickly without compromising system reliability is a constant challenge.

On top of this, handling on-call duties and troubleshooting outages under pressure get stressful very fast.

Observability

Crucial, but very tricky. Monitoring and observability in modern architectures involving microservices and distributed systems is complex and difficult.

With distributed systems, finding the root cause of an issue can feel like searching for a needle in a haystack — only the haystack is on fire, and everyone’s yelling at you to fix it.

Scaling

Scaling is another beast altogether. It’s not just about making systems bigger, you also need to keep them fast, efficient and cost effective while they grow.

Infrastructure scaling is one thing, your applications need to be scalable as well and that requires tight collaboration with developers which gets difficult quite often.

Automation

Over time, CI/CD pipelines tend to get brittle and prone to breaking as systems evolve. You are also required to put in lots of tests and automation while also keeping small build and deploy times.

Automating tests for complex scenarios, particularly for stateful systems or edge cases, is non-trivial.

Knowledge and Skill Gaps

DevOps engineers must understand coding, system design, networking, cloud platform and many more.

On top of knowing all these tools, you need to keep up with the ever evolving DevOps landscape. That is a full-time job in itself.

Cost Management

Managing unpredictable costs in cloud-native environments can be challenging without proper cost monitoring.

Resource optimization is a regular activity. Ensuring infrastructure is used efficiently without over-provisioning or under-provisioning is crucial.

Burnout

Finally, there’s the human side of it all. Burnout is real. Constant on-call rotations, high expectations, and the pressure to keep everything running smoothly can take a toll.

The “always-on” nature of DevOps can create pressure to deliver under tight timelines.

So yeah, DevOps is hard. But that’s also what makes it rewarding.

You’re solving real problems, creating systems that scale, and making life easier for everyone around you. It’s a tough job, but for those of us who thrive on challenges, it’s worth it.

DevOps is harder than you think! was originally published in The Plumber on Medium, where people are continuing the conversation by highlighting and responding to this story.

Everyone has a rough idea about what it means for something to be reliable. For software systems, following can be considered as reliable expectations:

• The software is working as per the user expectations with required performance that the user needs.
• If the user makes any mistakes, it still continues to work. Same is true for using the software in unintended ways.
• Only allows authorized access and prevents abuse

A system is can be said as reliable when it continues to work correctly even if things go wrong. These can be hardware failures, software errors, human errors or even if it is used in a way that is not intended.

Importance of reliability

Reliability is not just important for critical things like vehicles, food quality etc. It is also important for software systems.

Imagine you are storing all your photos(read memories) in a cloud based service and suddenly the data gets corrupted, how would you feel?

Apart from a bad user experience, this may result in loss of revenues for businesses. For example, a payment gateway going down directly affecting payment transactions, or an e-commerce website not able to show products, which indirectly causes reduction in sales.

This may also result in legal/monetary implications if data is reported incorrectly or system is down for more time than what was agreed to(read more about Service Level Agreements or SLAs).

Can you compromise on reliability?

When you are launching something new, or testing the product with an MVP, then it makes sense to focus on shipping the software as soon as possible and compromise on reliability to save costs.

But for systems where you already have a user base which is consuming services from your application, then it becomes absolutely necessary to keep the application reliable. Anything apart from that is a bad consequence.

How to make your systems reliable?

Once you have decided that your application needs to be reliable, which is going to be in most of the cases, following few approaches can be considered.

Testing

When you are trying to build reliable applications, incorporating testing helps a lot. Automated testing ensures you are not pushing code with bugs, breaking changes etc and therefore you’ll have more confidence when making changes to your application.

Many organizations follow test-driven development, where you write the tests first, and then write the actual code to pass those tests. This is usually done for Unit testing. Along with this, to ensure reliability even further, you should incorporate functional and integrations testing in your applications.

Introduce Chaos

Chaos engineering is a fairly new concept but is an effective one. It is the practice of intentionally injecting faults into a system to check its resiliency.

Chaos Engineering is similar to how a vaccine works. You inject your body with small amount of potentially harmful things to build resistance.

The goal of chaos engineering is to find potential issues early on which will allow you to mitigate them and prevent outages and disruptions.

Examples can include, terminating virtual machines or containers randomly, introducing memory leaks to cause resource exhaustion, introducing a flappy firewall or an unreliable network.

Security Hardening

Unreliability may be caused because of insecure on poorly guarded systems. Attackers can cause an outage such as a DDOS attack, or may exploit a known vulnerability to gain unauthorized access.

This is where hardening of the systems that are part of your applications is absolutely necessary.

Examples:

• Having a Web Application Firewall to protect against DDOS attacks, implementing OWASP top 10 best practices etc.
• Regularly scanning your code, OS and container images for vulnerabilities and taking action to mitigate those.
• Having security constructs such as authentication, authorization, encryption etc.

These are just very few ways for improving the security of your application, but security is not limited to just this and is a whole another topic on its own.

If you made it this far, be sure to check out other articles from me at Devashish Patil

Keep Learning.

About Reliability was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

But aside from the interviews, System Design is a skill one should excel at to become a better engineer.

In this article, I discuss how one can approach System Design.

Understand the problem statement

Collect information about the problem which needs a solution. The following points can be considered while defining the problem:

• Understand the requirements, such as the features, scale of the solution etc.
• Think from the users’ perspective and try to understand their needs.
• Finally, define any constraints or limitations of the system.
  For example: There may be compliance requirements based on demographics or the industry for which the solution is being designed.

Identify the scope of the system

Two things need to be defined to identify the scope of the system, what the system will do and what it won’t.

An example of this is: An e-commerce application needs to be built but the payments are to be handled by a third party. The system would be responsible for integrating the third-party payment service, but nothing will be of concern from developing, hosting or managing that service.

Look for existing references

Look at similar systems that have been built in the past and identify what worked well and what didn’t. Use this information to make your design decisions.

Create a high-level design

Outline the main components of the system and how they will interact with each other. This can include a raw diagram of the system’s architecture, or a flowchart outlining the process the system will follow.

Refine the design

Iterations and refinements will always be needed. One should not approach the system design process as a one-off scenario. During the initial design phase, iterate over the design until all requirements are met and there are no loose components.

Once the initial phase is over, further refinements may be needed with growth in the application.

Document the design

Proper documentation is necessary as part of the design process. The following few points can be considered during documentation.

• Document how the data flows between components. This can be in line with the user journeys.
• Document the connectivity between components. Make a note of what all traffic is allowed between components.
• Define the coupling between components.
• Document how error handling is performed. Also, document possible implications and mitigation steps in case a component goes down.

Continuously monitor and improve the system

The system design is not a one-time process, it needs to be continuously monitored and improved to meet the changing requirements.

Robust monitoring and logging are needed for the critical systems. This can include, system resource usage such as CPU, Memory, Disc space etc. Further, metrics in terms of latency, error rate, and response code analysis may also be required.

Consider the cost

One may be tempted to use multiple tools and resources for the points mentioned above and may successfully design robust and functional systems, but it may not be able to justify the cost.

Cost is a big factor for companies and one must be able to efficiently design systems with the minimum resources available at their disposal.

If content like this interests you, consider following me on Medium or hit me up on Twitter(X) here.

This is how you approach System Design was originally published in CodeByte on Medium, where people are continuing the conversation by highlighting and responding to this story.

Python os module

Python’s os module is often seen as a collection of basic file and directory manipulation tools, but it is a powerful gateway to the underlying operating system. It provides a plethora of features that can make one a better programmer. Check out this curated list

• Environment Variable Manipulation: os.environ dictionary
• Process Management: os.system() and os.popen()
• File Locking and I/O Control: os.lockfile() , os.unlockfile(), os.lseek()
• System Information Retrieval:
  For fetching system-level info such as current working directory, system name, user info
• Platform-Specific Operations
  Example: os.urandom() generates random numbers using the system’s random number generator.
• Path Manipulation and Expansion os.path.join() and os.path.expanduser()
• File Permission ControlL os.chmod() and os.chown()

Other use cases:

• Interfacing with System Services (like sending signals to processes)
• Debugging and Exception Handling
• Encoding and Decoding

History of Sets and Dictionary

Let’s understand a bit of history about Python Sets and Dictionaries

The set data structure in Python started off as a replica of the dict data structure, a key-value pair with dummy values.

Both use hashtables as the underlying data structure, which explains the average O(1) complexity for data lookup and insertion.

But since then the set’s and dict’s implementations have diverged from each other(e.g. arbitrary order in set vs insertion order in dict) and performance in various use cases differ.

If you like to see more such content, consider following.

Imagine having a frontend, a backend, a database for storing metadata, and a blob storage like Google Cloud Storage or S3 bucket for storing large objects like images, videos etc. Apart from these things, there will be services like load balancers, NAT gateways etc which will also constitute to hops and network traffic.

With the traditional approach, users would send the file from the client/frontend to the backend server. The file once uploaded to the server then needs to be uploaded to an object storage using some APIs or SDKs. This is how the architecture looks for such approach.

There are multiple issues with this architecture:

• Too many hops, that too with file objects
• File is travelling through all the components here and will result in high network costs.
• More processing power to handle uploads and long running requests.

What can be done instead?

The file should be uploaded directly from the browser to the object storage and the metadata such as the upload location, storage etc should be updated in the database.

But how can you do that?

There is a concept called signed URLs. Signed URLs are time limited endpoint to access a resource in S3, Google cloud storage etc., either for reading or writing.

The flow will look like this:

• Frontend will ask backend for a signed URL for a specific object for a limited time
• Backend will use the object storage service API to create the signed URL and respond back.
• Frontend will use this URL to upload the file and calls the backend again for the upload status.
• Based on the status, the backend will update the metadata server for information such as file location, upload status etc. This metadata can be used later for accessing the uploaded files.

This completes the whole flow of efficient file uploads, reduces the hops and network traffic thereby reducing the costs as well.

Let me know if you found this helpful, would love to know your feedback.

Follow for more.

Design efficient file uploads from browser was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article aims to explain how routing works in Apigee X. It is divided into 3 sections:

1. The first part explains how traffic comes to Apigee X from various clients.
2. The second part explains how to configure the traffic flow to backends in different networks and datacenters.
3. The third part focuses on two things.
4. First one is which proxy to execute based on the request hostname and base path
5. Second, how the request and response flow works inside an Apigee X proxy and how to customize the routing behavior for multiple backends.

Routing to Apigee X

Apigee X is a SaaS service which is hosted inside a Google Cloud managed project and VPC, implementation of which is invisible to the Google Cloud customer. The Google managed Apigee X VPC is peered with a customer managed VPC via service networking and thus accessible from that VPC. This holds true for all the service projects inside a shared VPC as well.

Each Apigee X instance comes with an IP address that is accessible from the customer VPC, and VMs/Clusters inside that VPC can hit that IP address to access the APIs exposed via Apigee.

This whole setup of traffic coming to Apigee is called Northbound Flow. There are few approaches to implementing northbound flow, 2 of the most common are discussed below.

Load Balancer + Managed instance group

In the architecture diagram above, there is a managed instance group which is responsible for IP forwarding and which acts as a backend service for the load balancer. All the requests coming from the clients through the load balancer are forwarded to the Apigee runtime.

Load Balancer + PSC NEG

In this approach, instead of the managed instance groups, there is a PSC NEG(Network endpoint group) which is responsible for forwarding requests to the Apigee runtime. This removes the need to manage compute engine instances.

In both of these cases, load balancer can be external and/or internal depending on the API clients.

Routing from Apigee X

The traffic going from Apigee X to the backends is called Southbound flow. There can be the following 4 scenarios based on where the backends are.

Apigee to backends in the same VPC

Backend in the same VPC will be accessible directly from Apigee if appropriate firewall rules are set.

Apigee to backends in different Google Cloud VPCs

If the backends are in VPCs different from the one Apigee is peered at, additional configuration is required. If VPC peering is set up between the Apigee VPC and the backend VPCs, the routing would work as it would for any other GCP service communication.

If peering can not be used, then another option is to use Private service connect(PSC). This would set up the connection between the two VPCs without any kind of peering.

Apigee to backends in on-premise or other clouds:

In case of networks residing in on-premise or multi-cloud systems, some type of VPN or Interconnect setup is required.

Apigee to backends on the internet

In this case, services hosted on the internet can directly be referenced by Apigee by their IP address or hostname.

Some internet services might require allowlisting of the IPs which are accessing those services. Apigee uses Cloud NAT for egress, and static IP addresses can be reserved for those. These IP addresses can be configured for allowlisting at the Internet service.

Routing inside Apigee X

Which Proxy deployment to execute?

Apigee has a construct for an Environment and an Environment Group. Each Environment group can contain one or more Environments.

https://www.example.com/shopping/cart/addItem
        |_____________| |___________| |_____|
               |             |           |
            hostname      basepath     resource

Proxies are deployed to an Environment while the hostnames on which the clients are going to access the API proxy are defined at an Environment Group level.

Each Environment Group can be configured to listen to requests from one or more hostnames but one hostname cannot be in more than one group.

The hostname and a proxy basepath(across multiple proxy deployments) makes a unique combination in Apigee. For more information on this, visit link

How does traffic flow work inside a proxy?

The diagram below shows how a request flows through Apigee.

• Each request goes through a bunch of flows inside Apigee
• The flow from Client to Server(left to right) is called request flow
• The flow from Server to Client(right to left) is called response flow
• An Apigee proxy is divided into 2 parts, proxy endpoint and target endpoint.
• Traffic passes through each endpoint twice, first during the request flow and second during the response flow.
• These flow executions are further divided into 3 parts, called PreFlow, Conditional Flow, PostFlow. Conditional flows only run if the underlying condition when defining the flow becomes true. Conditional flows are optional.

The code for a basic proxy endpoint looks like this.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <Flows/>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <HTTPProxyConnection>
        <BasePath>/mock</BasePath>
    </HTTPProxyConnection>
    <RouteRule name="default">
        <TargetEndpoint>default</TargetEndpoint>
    </RouteRule>
</ProxyEndpoint>

Parent blocks for PreFlow and PostFlow can be seen here which further contains request and response blocks, which are the actual containers for Apigee policies.

There is a block for HTTPProxyConnection, which defines the base path of the proxy on which Apigee expects the traffic. Route rule block follows this, which is responsible for routing of the traffic and will be discussed later in this article.

The code for a target endpoint looks like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TargetEndpoint name="default">
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <Flows/>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <HTTPTargetConnection>
        <URL>https://mocktarget.apigee.net</URL>
    </HTTPTargetConnection>
</TargetEndpoint>

The PreFlow and PostFlow blocks are similar to the ones in Proxy endpoint. Instead of HTTPProxyConnection, there is a block for HTTPTargetConnection here, which defines which backend(or target in Apigee’s nomenclature) to send the request to.

The diagram above shows 2 target endpoints, which is configured for 2 different backends.

There can be multiple target endpoints within the same proxy. These target endpoints are referenced in the proxy endpoint via route rules.

When a proxy is created from the console, 1 default proxy endpoint and 1 default target endpoint is created. This default proxy endpoint references the default target endpoint in its default route rule.

Additional target endpoints can be created, each one can point to different backend servers. Apart from the default route rules, additional rules can be created along with a condition which is responsible for the routing decision. Only the default route rule is without any condition.

A conditional route rule block in the proxy endpoint looks like this:

<RouteRule name="test">
    <TargetEndpoint>test</TargetEndpoint>
    <Condition>proxy.pathsuffix MatchesPath "/test"</Condition>
</RouteRule>

There are two sub-blocks here, first for the TargetEndpoint that the route rule is pointing to and the second defines the condition for the execution of the route rule which in this case is for a Path Match.

Example

Imagine having a microservice architecture for an e-commerce application. There are different services for catalog, cart, users etc with different hostnames. APIs can be exposed from a single endpoint via Apigee, and the routing decision will happen through the path suffix. The route rules for this use case will look something like this:

<RouteRule name="product">
    <TargetEndpoint>product-target-endpoint</TargetEndpoint>
    <Condition>proxy.pathsuffix MatchesPath "/product"</Condition>
</RouteRule>
<RouteRule name="catalog">
    <TargetEndpoint>catalog-target-endpoint</TargetEndpoint>
    <Condition>proxy.pathsuffix MatchesPath "/catalog"</Condition>
</RouteRule>
<RouteRule name="user">
    <TargetEndpoint>user-target-endpoint</TargetEndpoint>
    <Condition>proxy.pathsuffix MatchesPath "/user"</Condition>
</RouteRule>
<RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
</RouteRule>

Notice that the default route rule is defined last and doesn’t have any conditions. This should be followed while proxy development.

Route rules are one of the ways to handle routing, Any custom code or Apigee policies can be used to directly edit the target URL which can also be used for routing.

This is how routing works in and out of Apigee. I hope this article provides some clarity on the traffic flow to and from Apigee, any feedback would be appreciated.

How routing works in Apigee X was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.