zuplo 6.67.32 → 6.68.0

package/docs/articles/step-5-dynamic-rate-limiting.mdx

@@ -0,0 +1,167 @@
+---
+title: Step 5 - Dynamic Rate Limiting
+sidebar_label: "5 - Dynamic Rate Limiting"
+---
+
+Fortune favors the bold. In this bonus getting started guide - we'll show you
+how to add dynamic rate limiting to your API.
+
+To follow this tutorial you'll need to have completed
+[Step 1](./step-1-setup-basic-gateway.mdx) for a Zuplo project,
+[Step 2](./step-2-add-rate-limiting.mdx) to add rate limiting to that route, and
+[Step 3](./step-3-add-api-key-auth.mdx) to add API key authentication to that
+same route.
+
+:::info{title="What's Dynamic Rate Limiting?"}
+
+Traditionally, rate limits are static and the same for everyone. This approach
+doesn't let you tailor your rate limiting to your API user - you might want to
+offer higher rate limits for customers that pay more. Dynamic rate limiting
+allows you to determine an appropriate rate limit at request time.
+
+:::
+
+Let's get started.
+
+<Stepper>
+
+1. Add Consumer Metadata
+
+   Let's make our rate-limiting policy more dynamic, based on properties of the
+   customer. [Create a new consumer](./step-3-add-api-key-auth.mdx) (Services ->
+   API Key Service -> Configure -> Create Consumer), and in the Metadata field,
+   set the following:
+
+   ```json
+   {
+     "customerType": "free"
+   }
+   ```
+
+   Update the metadata of your other API Key consumer (3-dot menu -> Edit) from
+   Step 3 to
+
+   ```json
+   {
+     "customerType": "premium"
+   }
+   ```
+
+   ![Customer Metadata](../../public/media/step-3-add-rate-limiting/image-2.png)
+
+   Now that there are users with different `customerType`, this information can
+   be used to rate limit them differently.
+
+1. Add a Custom Code Module
+
+   Navigate back to the Code tab. Now add a new module to the files section by
+   clicking the `+` next to the **modules** folder and choose new empty module.
+   Name the module `rate-limit.ts`.
+
+   ![New module](../../public/media/step-3-add-rate-limiting/image-3.png)
+
+   :::info{title="What's a Module?"}
+
+   Modules are TypeScript functions that you can execute within Zuplo. They're
+   typically used to add custom code within the request/response pipeline (ex.
+   custom policies or request handlers). You can even perform network requests
+   and use libraries within these modules.
+
+   :::
+
+   Add the following code to your module.
+
+   ```ts
+   import { ZuploContext, ZuploRequest } from "@zuplo/runtime";
+
+   export function rateLimit(request: ZuploRequest, context: ZuploContext) {
+     const user = request.user;
+
+     // premium customers get 1000 requests per minute
+     if (user.data.customerType === "premium") {
+       return {
+         key: user.sub,
+         requestsAllowed: 1000,
+         timeWindowMinutes: 1,
+       };
+     }
+
+     // free customers get 5 requests per minute
+     if (user.data.customerType === "free") {
+       return {
+         key: user.sub,
+         requestsAllowed: 5,
+         timeWindowMinutes: 1,
+       };
+     }
+
+     // everybody else gets 30 requests per minute
+     return {
+       key: user.sub,
+       requestsAllowed: 30,
+       timeWindowMinutes: 1,
+     };
+   }
+   ```
+
+1. Update your Policy
+
+   Now we'll reconfigure the rate-limiting policy to wire up our custom
+   function. Find the policy in the **Route Designer** and click **Edit**.
+
+   ![Edit Policy](../../public/media/step-3-add-rate-limiting/image-4.png)
+
+   Update the configuration to
+
+   ```json
+   {
+     "export": "RateLimitInboundPolicy",
+     "module": "$import(@zuplo/runtime)",
+     "options": {
+       "rateLimitBy": "function",
+       "requestsAllowed": 2,
+       "timeWindowMinutes": 1,
+       "identifier": {
+         "export": "rateLimit",
+         "module": "$import(./modules/rate-limit)"
+       }
+     }
+   }
+   ```
+
+   By changing the `rateLimitBy` to `function` you are indicating the rate limit
+   will be determined by a module at runtime. The `identifier` property is used
+   to indicate the module and function to run. Make sure to save once you've
+   made your changes.
+
+1. Test your Policy
+
+   Using the Test modal, you can try your dynamic rate limiting. You can grab
+   the key for each consumer back in the Services tab where you created them.
+   Like [Step 3](./step-3-add-api-key-auth.mdx), you can fill in the keys into
+   the `Authorization` header and start making calls until you hit your rate
+   limit. Try out the other key and observe the difference in rate limits.
+
+</Stepper>
+
+## Wrapping up
+
+Congratulations - you've just successfully built an API that's:
+
+- Protected by API key Authentication
+- Dynamically Rate Limited
+- Deployed to the Edge for superior performance
+- and fully documented via your Developer Portal
+
+This is an API experience most companies dream of, and you've just built it in
+less than an hour.
+
+### Next Steps
+
+- Continue exploring our docs to learn about customizing your
+  [Developer Portal](../dev-portal/introduction.mdx), or explore our various
+  [Integrations](https://zuplo.com/integrations)
+- [Grab time](https://zuplo.com/meeting) with the Zuplo team to have your
+  questions answered
+- Start generating revenue from your new API with our
+  [Monetization tutorial](./monetization/index.mdx)

package/docs/articles/support.mdx

@@ -0,0 +1,144 @@
+---
+title: Support
+---
+
+This document explains the Zuplo support plans, communication methods,
+severities, and response times provided by Zuplo support. The following features
+are provided with every support plan:
+
+- Answer questions concerning usage issues related to Zuplo platform-specific
+  features, options, and configurations.
+- Provide initial and high-level suggestions regarding the appropriate usage,
+  features, or solution configurations for the particular type of reporting,
+  analysis, or functionality.
+- Isolate, document, and find alternative solutions for reported defects.
+- Work with Zuplo Operations, Product, Software Development, and QA staff to
+  submit change or enhancement requests, and provide fixes for the Zuplo
+  platform as necessary.
+- Address your concerns with online or printed documentation, providing
+  additional examples or explanations for concepts requiring clarification.
+- Access to online release notes for updates.
+- Access to Zuplo's online library of support webinars and knowledge base.
+- Access to Zuplo's customer community forums to collaborate with fellow Zuplo
+  customers.
+
+## Support Plans
+
+Zuplo offers the following support plans:
+
+| Support Offer     | Available to                                                                   |
+| ----------------- | ------------------------------------------------------------------------------ |
+| Community Support | All customers                                                                  |
+| Standard Support  | Customers with any paid subscription plan or those in the initial trial period |
+| Premium Support   | Customers who have purchased support as part of an enterprise plan             |
+
+### Community support
+
+Customers with Zuplo's free subscription plan can seek support through the Zuplo
+Community. Response times may vary and aren't guaranteed.
+
+### Standard support
+
+Customers with a paid Zuplo subscription plan receive standard support which
+offers access to the following channels:
+
+- Zuplo Community
+- Zuplo Email Support (best effort response times)
+
+### Premium support
+
+Customers on a Zuplo enterprise plan can choose from premium support offerings
+that can optionally include specific SLAs for response time as well as
+additional means of contact such as a private Slack channel.
+
+As part of premium support, Zuplo can also offer:
+
+- Assistance migrating or onboarding to Zuplo
+- Guidance implementing custom policies
+- Advice on best practices for designing your Zuplo API
+- Troubleshooting
+
+Contact sales to explore adding these options to your agreement.
+
+## Contact Methods
+
+Zuplo offers multiple methods to contact support detailed below.
+
+The following table describes the different contact methods available for each
+plan:
+
+| Support Feature               | Community | Standard | Premium   |
+| ----------------------------- | --------- | -------- | --------- |
+| Community Support             | Yes       | Yes      | Yes       |
+| Email Support                 | No        | Yes      | Yes       |
+| Emergency Phone Support       | No        | No       | Available |
+| Private Discord/Slack Channel | No        | No       | Available |
+
+For customers with an enterprise contract, your sales contract will indicate the
+specifics of your premium support offering.
+
+### Community Support
+
+Every customer may join the Zuplo Discord forum and chat with other customers or
+Zuplo employees.
+
+### Email Support
+
+For customers with email support, you can contact us at `support@zuplo.com`.
+Tickets will be responded to as quickly as possible and prioritized based on
+your support offering.
+
+### Private Discord/Slack Channel
+
+Enterprise support contracts can optionally chat directly with the Zuplo team in
+a private Discord or Slack channel. These channels are useful for posting
+feature requests, asking questions, or general troubleshooting. Contact sales
+for more info.
+
+:::caution
+
+Private channels shouldn't be used for urgent/business critical support requests
+as the team may not be immediately notified. For urgent requests use phone
+support.
+
+:::
+
+### Emergency Phone Support
+
+Customers with emergency phone support can call +1 833-681-6018 to open an
+emergency support ticket. After dialing the number, enter the five-digit
+enterprise support code that has been provided to you.
+
+:::warning
+
+Calling this number will alert our on-call team at any hour. Please call for
+urgent and business-critical issues only.
+
+:::
+
+We will open a ticket and our on-call support team will reach out to you within
+a few minutes.
+
+We also suggest you sign in to Discord so we can start a real-time chat.
+
+## Response Times
+
+For premium support plans, Zuplo offers SLAs on response times based on the
+severity of issues and the level of the plan.
+
+Zuplo uses four categories to define a technical issue:
+
+| Severity |                                                                                                                                                                                        | Premium           | Premium Plus       | Premium Custom   |
+| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | ------------------ | ---------------- |
+| Level 0  | Zuplo's services are down resulting in a critical and immediate impact on the Customer's production environment with a major business impact.                                          | 2 business hours  | 2 hour (24x7x365)  | Custom agreement |
+| Level 1  | Zuplo's services are impaired resulting in a severe impact on the Customer's production environment with a partial business impact.                                                    | 4 business hours  | 4 hours (24x7x365) | Custom agreement |
+| Level 2  | Zuplo's services are operational but have minor functional issues resulting in a partial impact on the Customer's production or staging environment with a low impact business impact. | 8 business hours  | 4 business hours   | Custom agreement |
+| Level 3  | Issues or questions related to development and testing.                                                                                                                                | 16 business hours | 8 business hours   | Custom agreement |
+
+**Business Hours** means 8:00 AM Eastern Time (UTC−05:00) to 8:00 PM Eastern
+Time (UTC−05:00), Monday through Friday, excluding local, state, and federal
+holidays.
+
+**Response Time** means the time required for a support engineer to respond
+confirming receipt of the support notification and informing the customer if
+additional information is needed to proceed with the analysis.

package/docs/articles/terraform.mdx

@@ -0,0 +1,114 @@
+---
+title: "Native GitOps: Better Than Terraform"
+sidebar_label: "GitOps vs Terraform"
+---
+
+<!-- vale Vale.Spelling["declaratively"] = NO -->
+
+Unlike legacy API management solutions that rely on imperative APIs and require
+tools like Terraform for infrastructure as code, Zuplo takes a fundamentally
+different approach. Zuplo was built from day one with GitOps at its core, making
+Terraform unnecessary and redundant.
+
+## Configuration as Code by Design
+
+Traditional API management products like Kong, Azure API Management, and others
+were designed with imperative APIs as their primary interface. These systems
+require you to:
+
+- Make API calls to create resources
+- Maintain state files to track what exists
+- Use tools like Terraform to bridge the gap between code and infrastructure
+- Handle complex state reconciliation and drift detection
+
+Zuplo eliminates this complexity entirely. Every aspect of your API gateway
+configuration is stored as human-readable code and configuration files in your
+repository:
+
+- **Routes** are defined in `config/routes.oas.json`
+- **Policies** are configured declaratively
+- **Custom code** lives alongside your configuration
+
+## True Atomic Deployments
+
+When you deploy with Zuplo—whether through `zuplo deploy` or our source control
+integrations—you get true atomic deployments:
+
+:::tip
+
+Every deployment either succeeds completely or fails entirely. There are no
+partial states, no drift, and no manual cleanup required.
+
+:::
+
+This atomic deployment model means:
+
+- **No half-deployed states**: Your API gateway is always in a known, consistent
+  state
+- **Simple rollbacks**: Just revert your Git commit and redeploy
+- **No state management**: Git is your single source of truth
+- **No reconciliation**: What's in your repository is what's deployed
+
+## Version Control Built In
+
+Since all configuration is code, you automatically get:
+
+- **Full version history** through Git
+- **Code review workflows** through pull requests
+- **Branching strategies** that match your development process
+- **Audit trails** of who changed what and when
+- **Easy rollbacks** by reverting commits
+
+## Why Terraform Would Add Complexity
+
+If Zuplo offered a Terraform provider, it would simply be a wrapper around our
+existing GitOps functionality. This would:
+
+- Add an unnecessary abstraction layer
+- Introduce state management complexity
+- Create potential for drift between Terraform state and actual configuration
+- Require learning and maintaining additional tooling
+- Provide no additional capabilities beyond what Zuplo already offers
+
+## The GitOps Advantage
+
+Zuplo's native GitOps approach provides significant advantages:
+
+1. **Simplicity**: One system to learn, not two
+2. **Reliability**: No state file corruption or drift issues
+3. **Speed**: Direct deployments without intermediate tooling
+4. **Transparency**: Configuration is exactly what you see in your repository
+5. **Integration**: Works seamlessly with your existing Git workflows
+
+## Getting Started with Zuplo's GitOps
+
+To experience the simplicity of Zuplo's GitOps approach:
+
+1. Create a new Zuplo project
+2. Clone the repository
+3. Make changes to your configuration files
+4. Commit and push to deploy
+
+```bash
+# Clone your Zuplo project
+git clone https://github.com/your-org/your-zuplo-project.git
+
+# Make changes to your API configuration
+# Edit config/routes.oas.json, add policies, etc.
+
+# Deploy your changes
+git add .
+git commit -m "Add rate limiting policy"
+git push origin main
+```
+
+Your changes deploy automatically through our GitHub integration, or you can use
+`zuplo deploy` for manual deployments.
+
+## Conclusion
+
+Zuplo's native GitOps approach represents a fundamental advancement over legacy
+API management solutions. By eliminating the need for imperative APIs and
+external infrastructure-as-code tools, Zuplo provides a simpler, more reliable,
+and more developer-friendly experience. Terraform isn't missing from Zuplo—it's
+simply not needed.

package/docs/articles/testing-graphql.mdx

@@ -0,0 +1,34 @@
+---
+title: Testing GraphQL Queries
+description:
+  Learn how to test GraphQL API routes using the Zuplo Portal and third-party
+  tools like Postman.
+tags:
+  - testing
+  - dev-portal
+---
+
+If you write a route that proxies a GraphQL API, you can test your route using
+the following methods:
+
+## 1/ Using the Zuplo Portal
+
+The fastest way to test your GraphQL endpoint using the Zuplo Portal is via the
+API Test Console.
+
+1. Navigate to **Code** and open the API test console, then create a new "Code
+   Test"
+2. Fill in the method, path, and headers you need. Leave the `content-type` as
+   `application/json`
+3. Convert your GraphQL Query and GraphQL Variables into a JSON body. You can
+   use [this tool](https://datafetcher.com/graphql-json-body-converter) to do so
+   easily
+4. Paste the JSON Body into the test's Body field and click the **Test** button
+
+![Docs Folder](../../public/media/guides/testing-graphql/test-request.png)
+
+## 2/ Using a Third-Party Request Tool
+
+Various third-party tools have tighter integrations to make GraphQL requests.
+You can check out this
+[article from Postman](https://learning.postman.com/docs/sending-requests/graphql/graphql/#using-json-in-the-request-body).