Rest Api | Techlist.io

cloudflareAug 7, 20263 min readCurated summary

Unifying Workers AI and AI Gateway into a single AI control plane

AI Gateway and Workers AI are converging into a unified control plane for accessing models across Cloudflare and external providers. A single Workers binding or REST API can now provide inference, observability, logging, security, and billing without requiring users to choose a product upfront. Cloudflare’s longer-term goal is model-first routing, where applications request capabilities or models while the gateway handles provider selection, failover, and load balancing. ## Unified Bindings and API - The Workers AI binding and AI Gateway now share the same entrypoint. - Requests can use the built-in `default` gateway or a named gateway for separate applications and customized policies. - The unified REST API routes requests through `/ai/` endpoints, using the `cf-aig-gateway-id` header. - This removes the need to decide between Workers AI and AI Gateway before building an application. ## Automatic Observability for Workers AI - Passing `default` as the gateway ID automatically creates an AI Gateway on the first authenticated request. - Requests receive built-in: - Full request and response logging - Token tracking by model - Cost attribution - Latency and error metrics - Developers can begin with the default gateway and later switch to a named gateway for features such as custom caching or application-specific traffic separation. - The AI Gateway dashboard provides detailed visibility into prompts, responses, latency, token usage, and failures. ## Unified Billing with AI Gateway Credits - AI Gateway credits can now pay for Workers AI usage in addition to providers such as OpenAI and Anthropic. - Users can maintain one prepaid credit balance across supported providers. - Workers AI users who use unified billing receive elevated rate limits, subject to current Cloudflare policies and documentation. ## Model-First Routing - Cloudflare plans to route requests based on the desired model rather than requiring users to select a specific provider. - The gateway could handle: - Provider selection - Failover - Load balancing - Capacity management - For example, a request for a model such as Kimi K2.7 Code could be served by Workers AI, the model’s original provider, or another vetted provider hosting the same weights. - Applications could remain available if one provider is overloaded or unavailable. - Users will still be able to restrict traffic to a single provider when necessary. - Routing is intended to preserve requirements such as Zero Data Retention and maintain model quality. Cloudflare recommends using the unified binding or REST API with the default gateway to gain observability and centralized billing immediately. As model-first routing develops, applications can rely less on provider-specific infrastructure and gain greater resilience through automatic provider management.

Read original

Rest Api Observability Ai Gateway Load Balancing+3

cloudflareJul 17, 20262 min readCurated summary

Cloudflare WAF protects WordPress applications from two high-severity vulnerabilities

Cloudflare has deployed WAF protections for two serious WordPress vulnerabilities: a high-severity SQL injection and a critical unauthenticated remote code execution flaw. The rules protect proxied WordPress sites on both free and paid Cloudflare plans, but they only reduce exposure while sites are patched. WordPress updates remain essential, with fixes available in versions 6.8.6, 6.9.5, 7.0.2, and 7.1 Beta 2. ## Vulnerabilities and Affected Versions - **CVE-2026-60137 — SQL injection** - Affects WordPress 6.8 and later. - Crafted input can alter database queries. - Rated High. - **CVE-2026-63030 — Unauthenticated RCE** - Affects WordPress 6.9 and later. - Exploits the REST API batch endpoint when persistent object caching is not enabled. - Requires no authentication or user interaction. - Rated Critical. - Versions earlier than 6.8 are not affected. - WordPress 6.8.6 fixes the SQL injection; later listed releases fix both vulnerabilities. ## Cloudflare WAF Protections - Cloudflare deployed the protections at **17:03 UTC on July 17, 2026**. - Both rules are enabled with a default **Block** action: - SQL injection rule: `1c060d3a371549219ee290d7ed933fcc` for Managed Rules and `db003b39b7774859a8d588ce33697a1a` for the Free Ruleset. - RCE rule: `7dfb2bd4708d4b88b9911dc0550664b6` for Managed Rules and `ebd3f2df15c74ddcbf6220c9b5ec246a` for the Free Ruleset. - The SQL injection rule blocks malicious parameter values before they reach WordPress. - The RCE rule targets requests attempting to access the vulnerable REST API path. ## Customer Actions - Pro, Business, and Enterprise customers should ensure Cloudflare Managed Rules are enabled. - Free-plan customers receive protection automatically through the Free Ruleset. - Review ruleset overrides, especially configurations that change blocking to logging. - Monitor Cloudflare Security Events for requests matching either rule. - Confirm that WordPress automatic updates succeeded and that the site runs a patched release. ## Ongoing Protection Cloudflare will monitor matching traffic and refine detections as attackers develop new variations. The WAF rules provide defense in depth, but they cannot repair vulnerable WordPress code. Administrators should patch WordPress immediately, verify that both WAF rules remain active with the **Block** action, and investigate suspicious requests if updating is temporarily impossible.

Read original

Rest Api Cloudflare Vulnerability Management Web Application Firewall+3

netflixJun 19, 20263 min readCurated summary

The Data Canary: How Netflix Validates Catalog Metadata

Netflix built an automated “data canary” system to validate catalog metadata changes with real production traffic. The system compares a new catalog version against a known-good baseline, detects customer-impacting regressions in under 10 minutes, and blocks corrupted data before it reaches most members. The effort treats data deployments with the same rigor traditionally applied to code deployments. ## Why Catalog Data Needs Canarying - Catalog metadata defines available titles, artwork, playback eligibility, and regional availability. - A previous incident corrupted a feed without any code or configuration change. - The resulting empty data for some titles prevented manifest generation and caused playback failures. - Existing code canaries detected nothing because the failure occurred in transformed data, not application code. - Validating individual upstream feeds was insufficient because corruption could emerge during final transformation. ## Challenges of Fast, Production-Level Validation - Data cycles occur frequently, leaving only one cycle to detect problems and block publication. - Traditional canary analysis requires 30–60 minutes to reach statistical confidence. - Shadow traffic could replay catalog requests but could not reproduce the full playback lifecycle across services. - Real production traffic was necessary to expose actual customer impact. - The system also needed to contain regressions so that validation itself did not create a large outage. ## The Data Canary Orchestrator - Netflix created a dedicated canary environment with: - An orchestrator instance coordinating validation. - A permanent baseline cluster serving the latest production catalog. - A canary cluster receiving the new catalog version. - Before testing, the orchestrator verifies that both clusters are healthy and version-synchronized. - It then triggers a chaos experiment that compares customer behavior across the two versions. - Results are returned to the transformer through a generic REST endpoint, allowing other data sources to adopt the pattern without transformer-specific changes. ## Extending the Chaos Platform - Experiment thresholds were customized to meet the 10-minute detection requirement. - Separate tests were run for major client types because they have different traffic patterns and dependencies. - Playback traffic was especially effective at revealing failures. - Sticky canaries used session affinity to keep each user on either the baseline or canary cluster, enabling a clean comparison. - Starts Per Second (SPS) became the primary metric because it measures successful playback attempts more directly than latency or catalog-service error rates. - Metrics are streamed in real time, and experiments abort immediately when a regression appears. - This prioritizes rapid protection over maximum statistical confidence, which is appropriate given the strong customer-impact signal. ## Production-Hardened Reliability - The orchestrator resumes polling experiments after restarts instead of abandoning active validation cycles. - Leader election prevents multiple orchestrator instances from triggering duplicate experiments during deployment. - Version tracking ensures baseline and canary clusters are aligned across tenants with different data-consumption schedules. ## Controlled Failure Injection - Netflix validated the validator by deliberately corrupting catalog data. - Tests included denylisting prominent titles and simulating realistic data-corruption scenarios. - These experiments demonstrated whether the canary could identify meaningful playback regressions before corrupted metadata was broadly released. Netflix’s approach shows that high-velocity data pipelines require deployment safeguards distinct from code canaries. Teams managing critical data should validate final transformed outputs with representative production traffic, use direct business-impact metrics, and automatically stop publication when regressions appear.

Read original

Rest Api Data Pipelines Chaos Engineering Data Canary+3

githubMay 7, 20264 min readCurated summary

Improving token efficiency in GitHub Agentic Workflows

GitHub’s Agentic Workflows can quietly accumulate substantial token costs because they run automatically in CI. GitHub improved efficiency by instrumenting token usage, auditing workflows, pruning unused MCP tools, and replacing many MCP data-fetching calls with deterministic GitHub CLI commands. Early results show that reducing context and removing unnecessary LLM reasoning can save thousands of tokens per run, though measuring true efficiency requires accounting for model choice and workload quality. ## Logging Token Usage - GitHub runs hundreds of agentic workflows against real GitHub Actions limits. - Different agent frameworks produced incompatible usage logs, so GitHub used its API proxy to normalize data across Claude CLI, Copilot CLI, and Codex CLI. - Each workflow now emits a `token-usage.jsonl` artifact containing: - Input, output, cache-read, and cache-write tokens - Model and provider - Timestamps - One record per API call - These records make it possible to compare historical runs and identify recurring sources of waste. ## Automated Auditing and Optimization - A daily **Token Usage Auditor** aggregates recent usage by workflow and reports: - Significant increases in token consumption - The most expensive workflows - Anomalous runs, such as a workflow taking 18 LLM turns instead of its usual four - A daily **Token Optimizer** examines flagged workflows, their source YAML, and recent logs. - It creates GitHub Issues with concrete inefficiencies and recommended fixes. - The auditing workflows also consume tokens, creating a feedback loop in which their own costs are monitored. ## Removing Unused MCP Tools - MCP tool names and JSON schemas are typically included in every stateless LLM request. - A GitHub MCP server with roughly 40 tools can add 10–15 KB of schema to every turn. - If a workflow uses only two tools, the other 38 create repeated overhead without adding value. - GitHub compares configured tools with actual tool calls and recommends removing unused registrations. - In smoke tests, pruning tools reduced each call’s context by 8–12 KB and saved several thousand tokens per run without changing behavior. ## Replacing MCP Calls with GitHub CLI - GitHub found larger savings by replacing MCP calls for predictable data retrieval—such as pull request diffs, file contents, and review comments—with `gh` commands. - MCP calls require an additional reasoning cycle: the model chooses a tool, constructs arguments, and processes the response. - Commands such as `gh pr diff` make deterministic API requests without involving the LLM in the retrieval step. Two migration patterns were used: - **Pre-agentic downloads** - Workflow setup steps run `gh` commands before the agent starts. - Results such as diffs and changed-file lists are saved to workspace files. - The agent reads the files directly, eliminating MCP round trips. - **In-agent CLI proxy substitution** - When data must be selected dynamically, the agent runs commands such as `gh pr view --json`. - A transparent proxy routes CLI requests to GitHub’s API without exposing credentials. - This preserves the zero-secrets security model while avoiding MCP overhead. ## Measuring Efficiency - Lower token counts do not necessarily mean better workflows; a workflow may simply be doing less work. - Model selection also affects cost. Claude Haiku and Sonnet may use similar numbers of tokens, but Haiku is substantially cheaper. - GitHub therefore uses an **Effective Tokens (ET)** metric that weights usage by token type and model cost: ```text ET = m × (1.0 × I + 0.1 × C + 4.0 × O) ``` - `m` represents the model multiplier: Haiku `0.25×`, Sonnet `1.0×`, and Opus `5.0×`. - `I` is newly processed input, `C` is cache-read tokens, and `O` is output tokens. - Output tokens receive greater weight because they are typically the most expensive component. GitHub’s experience suggests that agentic workflow authors should measure usage continuously, remove tools that workflows do not actually use, and move routine API retrieval outside the LLM reasoning loop wherever possible.

Read original

Rest Api Large Language Models Model Context Protocol GitHub Actions+3

gitlabMay 7, 20262 min readCurated summary

A leaked personal access token shouldn't expose every project its owner can reach. Fine-grained PATs scope each token’s permissions to the job.

Fine-grained personal access tokens (PATs) reduce credential exposure by limiting each token to only the projects, groups, resources, and actions required for a specific task. GitLab’s beta lets users replace broad `api` or `read_api` tokens with narrowly scoped permissions, reducing the impact of leaks. The feature is not yet recommended for production because coverage is still incomplete. ## Why Narrow PAT Privileges - Broad, user-scoped tokens can access every project the user can reach. - A leaked token might expose source code, pipelines, container images, or CI/CD variables across many projects. - Fine-grained tokens limit both access and potential remediation to the affected project or resource. - They complement lifetime limits and automatic revocation. ## How Fine-Grained Tokens Work - Scope access by location: - Personal projects - All projects and groups where the user is a member - Specifically selected projects and groups - Assign independent Create, Read, Update, and Delete permissions. - Supported resources include Issues, Merge Requests, Pipelines, Repositories, and Container Registry. - Example: a container-publishing pipeline can receive Create and Read access only to one project’s registry. ## Auditing and Beta Coverage - The token management table displays scopes and per-resource permissions for all tokens. - This makes over-privileged credentials easier to identify during reviews. - Fine-grained PATs currently support about 75% of REST API endpoints. - GitLab plans to add remaining REST endpoints and expand GraphQL support. - Existing traditional PATs continue working alongside fine-grained tokens during the beta. ## Getting Started - Go to **User Settings → Personal Access Tokens**. - Select **Fine-grained token** when generating a token. - Choose the permitted projects or groups and assign resource permissions. - GitLab recommends avoiding fine-grained PATs in production until general availability. Teams should begin evaluating fine-grained tokens for automation and adopt one token per job, with the smallest practical scope. Feedback during the beta will help shape broader endpoint coverage and future improvements.

Read original

Rest Api Gitlab GraphQL Api Security+3

slackMay 5, 20263 min readCurated summary

From SSH to REST: A Security-Driven Modernization of Slack’s EMR Data Pipelines

Slack had more than 700 SSH-based operators running critical EMR workloads, creating security risks, operational failures, and barriers to infrastructure modernization. The company replaced these connections with REST-based job submission across eight data regions without downtime. YARN Distributed Shell was the key enabler for migrating arbitrary command-line jobs that lacked dedicated REST APIs. ## How Slack’s SSH Architecture Developed - Airflow originally connected directly to EMR master nodes using `SSHOperator`. - Over time, teams created more than 700 SSH-based jobs for: - Spark and MapReduce workloads - AWS CLI commands - Custom Python scripts - Data-transfer operations such as `hadoop distcp` - The approach was simple but tightly coupled orchestration workers to production clusters. ## Security and Operational Costs of SSH - Direct SSH access expanded the attack surface. - SSH keys had to be distributed and rotated across orchestration workers. - Auditing required correlating activity across multiple systems. - Permissions became complicated, often involving custom security groups and configurations. - Jobs ran on EMR master nodes, causing resource contention. - Restarted Kubernetes pods could break SSH connections. - Long-running processes could become orphaned “zombie” jobs. - Connection failures made job success or failure difficult to determine. - SSH dependencies blocked Spark-on-Kubernetes, EMR on EKS, AWS child-account migration, and better observability. - Slack’s search-indexing pipeline was especially sensitive because it processed terabytes of data daily and supported search for millions of users. ## REST-Based Job Submission - SSH creates a stateful connection whose failure can leave job status ambiguous. - REST APIs provide a durable, server-managed lifecycle: - `POST` submits a job and returns an ID. - `GET` retrieves its status. - `DELETE` cancels it cleanly. - Clients can crash or restart without terminating the underlying job. - Existing systems such as YARN, Trino, and Snowflake use this model. - YARN provides REST submission for Hadoop, Spark, Hive, and MapReduce workloads, but not arbitrary shell commands. ## YARN Distributed Shell - Spark and Hive already had REST-compatible options through Livy and HiveServer2. - The difficult cases were MapReduce and more than 300 CLI-based jobs. - Slack considered custom wrapper services, Ansible or Salt, and creating a new YARN job type. - These alternatives added complexity, security work, or long-term maintenance. - YARN Distributed Shell—implemented through `ApplicationMaster`—could execute arbitrary scripts inside YARN containers. - It used existing YARN APIs and authentication mechanisms, avoiding a custom security layer. ## The Distributed Shell Workflow - Upload a command script to S3, such as an `aws s3 sync` operation. - Submit a YARN application specifying: - The Distributed Shell application master - The S3 script location - Script metadata such as length and timestamp - YARN then: - Allocates a resource-managed container - Downloads and executes the script - Enforces memory and vCore limits - Provides isolation, retries, cancellation, and centralized logging By using REST submission and YARN Distributed Shell, Slack could remove SSH from its EMR data pipelines while preserving support for both standard data-processing jobs and arbitrary command-line workloads.

Read original

Rest Api Kubernetes Apache Spark Apache Airflow+3

cloudflareApr 30, 20263 min readCurated summary

Agents can now create Cloudflare accounts, buy domains, and deploy

Agents can now take an application from development to production by creating Cloudflare accounts, obtaining API tokens, purchasing domains, and deploying code. Cloudflare’s integration with Stripe Projects removes most manual setup while keeping humans involved for permissions, terms acceptance, and payment approvals. The underlying protocol combines service discovery, authorization, and tokenized payments so agents can provision infrastructure on a user’s behalf. ## Zero-to-production deployment - Users install the Stripe CLI, authenticate, and run: ```bash stripe projects init ``` - An agent can then build an application and deploy it to a new domain. - If no Cloudflare account exists, one is provisioned automatically. - If an account already exists, the user authorizes access through OAuth. - The agent can: - Create a Cloudflare account - Obtain an API token - Register a domain - Deploy the application to production - Humans are prompted only when approval, terms acceptance, or payment setup is required. ## The protocol: discovery, authorization, and payment - **Discovery:** Agents query a catalog of available provider services and select the resources needed for the user’s request. - **Authorization:** The orchestrating platform verifies the user’s identity and enables providers to create accounts, connect existing accounts, and issue credentials securely. - **Payment:** Tokenized payment credentials let providers charge the user without exposing raw card details to the agent. - The approach builds on OAuth, OIDC, and payment-tokenization standards. ## Service discovery through a catalog - Agents can inspect available services with: ```bash stripe projects catalog ``` - They can select Cloudflare Registrar with: ```bash stripe projects add cloudflare/registrar:domain ``` - Providers expose service catalogs through REST APIs returning JSON. - This gives agents the context to choose appropriate products without requiring users to know which provider offers them. ## Automatic account creation and authorization - Stripe acts as the identity provider and attests to the user’s identity. - Cloudflare creates a new account automatically when the user has none. - Credentials are securely stored by the Stripe Projects CLI but made available to the agent for authenticated Cloudflare API requests. - Existing Cloudflare users authorize the integration through a conventional OAuth flow. ## Controlled agent spending - Agents never receive the user’s raw credit card information. - Stripe supplies Cloudflare with a payment token for subscriptions and purchases. - Spending is initially capped at $100 per month per provider. - Users can raise the limit and configure Cloudflare Budget Alerts as needed. ## Broader platform integration - The protocol is not limited to Stripe Projects. - Any platform with signed-in users can act as the orchestrator and integrate with Cloudflare. - This enables coding-agent platforms to let users deploy directly to production without requiring separate dashboard logins, token copying, or manual account setup. - Cloudflare is also enhancing the experience through its Code Mode MCP server and Agent Skills. Cloudflare and Stripe’s integration makes infrastructure provisioning an agent-driven workflow while retaining safeguards around identity, consent, and spending. For platforms building coding agents, adopting the protocol could provide a frictionless path from generated code to a live, paid production deployment.

Read original

Rest Api Database Design Cloudflare Stripe+4

cloudflareApr 16, 20263 min readCurated summary

Artifacts: versioned storage that speaks Git

Artifacts is a distributed, versioned filesystem designed for AI agents and other high-volume compute environments. It creates repositories programmatically while remaining compatible with standard Git clients, enabling isolated repositories for agent sessions, sandboxes, and large numbers of forks. Cloudflare argues that Git’s familiar data model—commits, history, diffs, and branching—can serve as a general-purpose state-management primitive beyond traditional source control. ## A Git-Compatible Filesystem for Agents - Artifacts repositories can be created through the Workers API or REST API. - Applications receive a Git remote and authentication token, allowing agents to clone and use repositories with ordinary Git commands. - Repositories can be created dynamically for: - Individual agent sessions - Sandbox instances - Large-scale forked environments - Non-Git clients such as Workers, Lambda functions, and Node.js applications can use the API directly or language-specific SDKs. - Existing repositories can be imported from sources such as GitHub, then independently forked for isolated or read-only work. ## Why Git Fits Agent Workflows - Most AI coding agents already understand Git, including common workflows and edge cases. - Git’s object and commit model works well for storing: - Source code and configuration - Session prompts and agent history - Other large collections of small, versioned data - Git provides built-in capabilities for: - Tracking state over time - Reverting changes - Comparing versions - Forking from historical points - Using Git avoids requiring agents to learn a new protocol, CLI, or specialized tool. ## Beyond Source Control - Artifacts can persist an entire agent session’s filesystem and history without requiring dedicated block storage. - Cloudflare uses per-session repositories to: - Restore sandbox state - Share sessions with other people - Time-travel through both prompts and filesystem changes - Fork a session from any point for collaboration or debugging - The same semantics can support non-code data, such as customer-specific configuration that needs rollback, cloning, or diffing. - Cloudflare expects non-Git use cases to be as important as conventional repository workflows. ## Implementation on Cloudflare - Artifacts are built on Durable Objects, which provide isolated, stateful compute capable of supporting millions of repository instances. - The system uses an in-house Git implementation written in Zig and compiled to WebAssembly for Cloudflare Workers. - The implementation was designed to be: - Small - Broadly Git-compatible - Extensible for features such as notes and Git LFS - Efficient in a Workers environment Artifacts is currently available in private beta for paid Workers customers, with a public beta planned for early May. It is intended as a practical way to give agents and applications disposable, persistent, and fully versioned environments without abandoning the Git ecosystem.

Read original

Rest Api Database Design TypeScript Cloudflare Workers+4

cloudflareApr 16, 20263 min readCurated summary

Cloudflare Email Service: now in public beta. Ready for your agents

Cloudflare Email Service is entering public beta as infrastructure for applications and AI agents that use email as a primary interface. It combines inbound Email Routing with outbound Email Sending, allowing agents to receive messages, perform asynchronous work, and reply without relying on separate email providers. Cloudflare argues this enables agents to move beyond instant chatbot responses and operate independently across support, billing, verification, and multi-agent workflows. ## Email as an Agent Interface - Email is universally available and requires no custom chat application or channel-specific SDK. - Developers already depend on email for: - Account signups - Notifications - Invoices - Customer support - Verification workflows - Agents increasingly need email to communicate with users and other systems. ## Cloudflare Email Service - **Email Routing** lets applications and agents receive email. - **Email Sending** enables replies and outbound notifications. - The service integrates with Workers and the Agents SDK. - The public-beta toolkit includes: - An Email Sending binding - An Email MCP server - Wrangler CLI email commands - Skills for coding agents - An open-source agentic inbox reference application ## Email Sending in Public Beta - Workers can send transactional email through a native `env.EMAIL` binding. - The binding requires no API keys or secret management inside the Worker. - Applications can also send email through a REST API or TypeScript, Python, and Go SDKs. - Cloudflare automatically configures SPF, DKIM, and DMARC when a domain is added, improving authentication and inbox delivery. - Since the service runs on Cloudflare’s global network, it is designed for low-latency delivery worldwide. - Combined with long-standing Email Routing, developers can receive, process, and send email within one platform. ## Email-Native Agents with the Agents SDK - The Agents SDK already provides an `onEmail` hook for processing inbound messages. - Previously, agents were limited to synchronous replies or messages sent to Cloudflare account members. - Email Sending removes those limitations, allowing agents to: - Process requests for extended periods - Query multiple systems - Schedule follow-ups - Escalate unusual cases - Reply asynchronously after completing work - This turns an agent from a simple chatbot into a system capable of acting independently. ## Support-Agent Workflow - The example `SupportAgent`: - Receives email through `routeAgentEmail` - Parses the raw message with `PostalMime` - Stores ticket details such as sender, subject, body, and message ID in agent state - Starts longer-running work or sends a task to a Queue - Replies using the Email Sending binding - Preserves the conversation with `inReplyTo` and a `Re:` subject - Address-based routing maps addresses such as `support@domain` or `sales@domain` to corresponding agent instances. Cloudflare’s recommendation is to use Email Service when an agent must communicate reliably with people over email, especially for workflows that require persistence, background processing, and delayed or follow-up responses.

Read original

Rest Api TypeScript Python Go+4

airbnbFeb 11, 20263 min readCurated summary

My Journey to Airbnb — Anna Sulkina

Anna Sulkina’s career journey moved from hardware diagnostics and frontend development into backend infrastructure and engineering leadership. Her experiences at Twitter taught her to design distributed systems for failure and to build consensus around transformative technologies like GraphQL. She joined Airbnb in 2022 because it aligned her passion for travel with an opportunity to strengthen developer infrastructure, organizational strategy, and engineering collaboration. ## Discovering Technology in Post-Soviet Ukraine - Sulkina grew up in Eastern Ukraine as the Soviet Union collapsed. - Her older brother introduced her to computers by bringing home hardware components and assembling a machine that loaded programs from a cassette player. - Seeing how individual components formed a working system inspired her to pursue technology. ## Learning English While Building Technical Skills - She studied programming at a Ukrainian university before immigrating to the United States. - Although she understood written English and knew how to program, communicating in English was initially more difficult than learning programming languages. - She took ESL classes while studying C++ and Java through Berkeley Extension. - Her first job was in hardware diagnostics at a five-person company. - A language barrier caused her to run out of time on a technical interview, but an interviewer familiar with her Berkeley class gave her another opportunity. - She eventually transitioned from C++ to Java, which became her primary language for many years. ## Moving Down the Stack and Into Leadership - Sulkina’s career progressed from hardware diagnostics to frontend, backend, and infrastructure engineering. - At the same time, she increasingly took on leadership responsibilities. - At Caymas Systems, her manager recognized her leadership potential and showed her the difference effective leadership makes. - At Comcast, she moved from individual contributor to engineering manager. - Coaching engineers, building software collaboratively, and developing high-performing teams convinced her that leadership was the right path. ## Lessons from Twitter’s Distributed Systems - During nearly nine years at Twitter, Sulkina advanced from first-line manager to director. - She worked through major operational events, including the “fail whale” period and the tweetstorm surrounding Ellen DeGeneres’s viral selfie. - Twitter’s transition from a monolith to microservices taught her that failure is inevitable in complex systems. - Resilient distributed systems must be designed to handle failures rather than assuming failures can be prevented. - Her cultural lesson involved turning promising ideas into adopted technologies. - She helped bootstrap Twitter’s GraphQL API, replacing legacy REST services. - The effort required leadership support, cross-team consensus, and stakeholder alignment, but ultimately improved product teams’ development velocity. ## Choosing Airbnb - Airbnb contacted Sulkina in 2022, when she felt ready to move beyond a well-established organization at Twitter. - The company appealed to her because it combined her professional interests with her personal passion for travel; she had been an Airbnb guest since 2013. - Airbnb’s Developer Platform organization had strong work happening in separate silos but needed clearer strategy, direction, and trust across engineering. - Sulkina began by clarifying the organization’s purpose and future direction. - Her early priorities included strengthening the organization, coaching leaders, and creating alignment within the team and with the teams it supported. - Over the following years, this work produced a high-performing organization with clearer strategy, stronger execution, and a focus on delivering business value. Sulkina’s story emphasizes that technical growth, organizational leadership, and personal motivation can reinforce one another. Her experience suggests that successful engineering leaders design for failure, invest in alignment, and use clear strategy to turn fragmented efforts into meaningful platform-wide impact.

Read original

Rest Api Distributed Systems Microservices Java+3

tossNov 27, 2025Original article

Toss Payments' Open API (opens in new tab)

Toss Payments treats its Open API not just as a communication tool, but as a long-term infrastructure designed to support over 200,000 merchants for decades. By focusing on resource-oriented design and developer experience, the platform ensures that its interfaces remain intuitive, consistent, and easy to maintain. This strategic approach prioritizes structural stability and clear communication over mere functionality, fostering a reliable ecosystem for both developers and businesses. ### Resource-Oriented Interface Design * The API follows a predictable path structure (e.g., `/v1/payments/{id}`) where the root indicates the version, followed by the domain and a unique identifier. * Request and response bodies utilize structured JSON with nested objects (like `card` or `cashReceipt`) to modularize data and reduce redundancy. * Consistency is maintained by reusing the same domain objects across different APIs, such as payment approval, inquiry, and cancellation, which minimizes the learning curve for external developers. * Data representation shifts from cryptic legacy codes (e.g., SC0010) to human-readable strings, supporting localization into multiple languages via the `Accept-Language` HTTP header. * Standardized error handling utilizes HTTP status codes paired with a JSON error object containing specific `code` and `message` fields, allowing developers to either display messages directly or implement custom logic. ### Asynchronous Communication via Webhooks * Webhooks are provided alongside standard APIs to handle asynchronous events where immediate responses are not possible, such as status changes in complex payment flows. * Event types are clearly categorized (e.g., `PAYMENT_STATUS_CHANGED`), and the payloads mirror the exact resource structures used in the REST APIs to simplify parsing. * The system ensures reliability by implementing an Exponential Backoff strategy for retries, preventing network congestion during recipient service outages. * A dedicated developer center allows merchants to register custom endpoints, monitor transmission history, and perform manual retries if automated attempts fail. ### External Ecosystem and Documentation Automation * Developer Experience (DX) is treated as the core metric for API quality, focusing on how quickly and efficiently a developer can integrate and operate the service. * To prevent the common issue of outdated manuals, Toss Payments uses a documentation automation system based on the OpenAPI Specification (OAS). * By utilizing libraries like `springdoc`, the platform automatically syncs the technical documentation with the actual server code, ensuring that parameters, schemas, and endpoints are always up-to-date and trustworthy. To ensure the longevity of a high-traffic Open API, organizations should prioritize automated documentation and resource-based consistency. Moving away from cryptic codes toward human-readable, localized data and providing robust asynchronous notification tools like webhooks are essential steps for building a developer-friendly infrastructure.

Rest Api API Design Json Developer Experience+4

figmaNov 20, 20243 min readCurated summary

The Making of the Figma Pattern Library | Figma Blog

Figma rebuilt its internal design system during the UI3 redesign after years of growth had produced inconsistent components, detached instances, and a fragmented workflow. The resulting Figma Pattern Library (FPL) was created through close designer-engineer collaboration and uses variables, APIs, and shared standards to keep design intent aligned with shipped code. Its goal is to provide both a reliable source of truth and a flexible foundation for building consistent, accessible products across Figma’s product suite. ## Why Figma rebuilt its design system - Figma’s internal system had become increasingly fragmented as the company and product portfolio expanded. - Components that were intended to be identical had accumulated subtle but important differences. - Detached component instances made consistency difficult to maintain. - The upcoming UI3 rollout made these problems impossible to ignore. - The team needed a foundation that could support consistent, efficient development across all Figma products. ## A paired design-and-engineering approach - A five-person team of designers and engineers led the rebuild. - The team modeled its workflow on pair programming: - One discipline would actively build. - The other would review and provide immediate feedback. - This collaboration helped bridge the gap between design intent and technical implementation. - The system was designed to be both: - A source of truth for shared UI decisions. - A springboard for future product development. - The effort resulted in the new Figma Pattern Library, or FPL. ## Using variables as a shared language - The previous system relied on Figma styles for designers and a separate Google Sheet for engineers’ color tokens. - Because the spreadsheet often lagged behind product changes, designs and production code diverged. - FPL replaced this disconnected process with Figma variables and the Figma REST API. - Typography variables were introduced and aliased through existing typography styles. - Color styles were migrated to color variables as a centralized source of truth. - CSS definitions were added to color variables so Dev Mode could display the correct variable names during inspection. ## Primitive and semantic color systems - FPL organized colors into two main variable collections: - **Primitive variables:** Color ramps organized by hue and numbered from 100 to 1000. - **Semantic variables:** Contextual names based on Figma’s dark-mode schema. - Semantic variables support multiple themes and products, including: - Light and dark modes. - Figma Design. - FigJam. - Slides. - Dev Mode. - Semantic variables alias primitive variables, allowing colors to be changed across themes and products without manually updating every component. - This structure enables shared components to adapt to different contexts while preserving visual consistency. The practical lesson is that a scalable design system requires more than a component library: it needs shared ownership, synchronized design and engineering tokens, and variable-based foundations that can support multiple products and themes.

Read original

Rest Api Figma Design Systems Accessibility+4

figmaApr 15, 20242 min readCurated summary

How Carvana Fuels Consistency and Scale | Figma Blog

Carvana scaled its design operations by moving from scattered tools to Figma as a centralized source of truth. Its design systems team uses Figma variables to enforce consistency, support rapid rebranding, and reduce design-development friction. The approach helped Carvana adapt quickly during rapid growth and integrate acquired businesses such as ADESA. ## Creating a Single Source of Truth - By 2019, Carvana’s design system was fragmented across a PDF UI kit, Principle, and Sketch. - Designers relied heavily on copying and pasting, causing small changes to diverge across repeated components. - Moving the system to Figma centralized libraries and connected design and engineering workflows. - The transition became especially valuable during the pandemic, when car sales surged and Carvana needed to scale quickly without adding process friction. ## Using Variables to Improve Consistency - Rapid growth introduced inconsistencies in: - Colors - Spacing - Typography - Corner radii - Figma variables let Carvana define reusable values for design properties. - Number variables standardized spacing and corner radii, while color variables helped maintain brand accuracy. - Although setting up variables required an initial learning period, the team achieved more polished designs and fewer revision cycles. ## Supporting New Brands and Business Lines - Variables allowed Carvana to create new themes without rebuilding its component library. - After acquiring ADESA, Carvana added an ADESA theme and applied the new branding to existing designs quickly. - The redesign took less than a week instead of the estimated month required to restyle the component library manually. - Themed components also enabled the team to create ADESA design comprehensives three times faster than usual. ## Connecting Design and Development - Figma’s shared libraries and variable-based system help designers and developers work from the same standards. - Centralized component structure and functionality make handoffs clearer and reduce inconsistencies between design files and implementation. - Carvana’s 40-person design systems team uses these practices to support consistency across a 10,000-person organization. Carvana’s experience suggests that a centralized design system, combined with reusable variables and themes, can make rapid growth more manageable. Investing in the system early reduces rework while making future products, brands, and acquisitions faster to integrate.

Read original

Rest Api Figma Design Systems User Experience+4

figmaJun 20, 20233 min readCurated summary

Config 2023 in Review: The Complete Recap | Figma Blog

Figma’s Config 2023 announcements reposition the platform as a workspace for the entire product development team, not just designers. The major launches—Dev Mode, variables, and advanced prototyping—aim to connect design more directly with code, development workflows, and real product behavior. Supporting updates to auto layout, fonts, and file discovery further improve everyday work, while Figma also signals a major investment in AI through its acquisition of Diagram. ## Dev Mode Connects Design and Development - Dev Mode is a dedicated Figma workspace designed around developers’ needs. - It helps developers: - Translate designs into code more quickly. - Connect Figma to Jira, GitHub, Storybook, and other tools through plugins. - Track designs and changes that need to reach production. - Inspect Figma files alongside code in VS Code. - Dev Mode launched in beta and was available free through 2023. ## Variables Bring Design Systems Closer to Code - Figma introduced variables to make design systems more flexible and scalable. - Variables can store reusable: - Colors - Numbers - Text values - Boolean values - They support aliasing and scoping, allowing teams to organize and contextualize values. - Variable modes enable themes such as light and dark designs. - Plugin and REST API support allows teams to manage variables programmatically. - The goal is to connect design tokens and systems more directly with the code that implements them. ## Advanced Prototyping Makes Designs More Dynamic - Variables can now be used in prototypes to represent changing application state. - Designers can use mathematical expressions and conditional logic, such as: - Increasing a number variable after each click. - Navigating to different screens depending on a variable’s value. - These capabilities let teams test realistic interactions before development begins. - In-context editing and inline preview allow designers to edit and play back prototypes in the same view. ## Quality-of-Life Improvements - Auto layout gained wrapping and minimum/maximum width and height controls. - The font picker now supports search, filtering, and previews displayed in each font. - The file browser makes it easier to locate files and projects shared by external teams. ## Figma’s Investment in AI - Figma expects AI to help people express ideas visually, speed up workflows, and create strong first drafts. - The company argues that turning a good draft into a world-class product will still require human judgment and expertise. - Figma acquired Diagram, founded by Jordan Singer, to accelerate AI development across the platform. - Diagram had previously built AI-assisted design tools on Figma’s platform. Overall, Config 2023 presents Figma as a shared environment spanning design, prototyping, development, and increasingly AI-assisted creation. Teams should consider Dev Mode and variables as the most significant changes for improving handoff, design-system management, and collaboration with engineering.

Read original

Rest Api Figma Design Systems Prototyping+4

figmaFeb 2, 20233 min readCurated summary

How Pinterest’s design systems team measures adoption | Figma Blog

Pinterest’s Gestalt design systems team created a “design adoption” metric to understand how widely its components are used during the design phase, not just after implementation. Code-based adoption metrics were limited to web components and often lagged behind design activity, while raw Figma instance counts lacked context. Using Figma’s REST API, the team built FigStats to measure Gestalt usage relative to all content in Pinterest design files. ## Why Code Adoption Wasn’t Enough - Gestalt’s existing adoption metric tracked component usage in code. - Code provided concrete data about which components shipped and whether teams modified them. - However, it had two limitations: - It only covered web components, not Gestalt’s iOS and Android components. - It took time for newly designed components to reach production code. - Measuring adoption in Figma provided earlier insight into whether designers knew about and used Gestalt components across all platforms. ## Defining a More Meaningful Adoption Metric - Figma’s built-in library analytics reported: - Component instances - Component insertions - Usage by team - These were useful counts but did not indicate whether usage was significant. - For example, 10 Gestalt components in a 1,000-node design represent only 1% adoption, even though the raw usage count is nonzero. - Pinterest therefore defined adoption relatively: Gestalt usage compared with the total content in a design file or page. - This approach helped distinguish isolated component use from meaningful reliance on the design system. ## Building FigStats with the Figma REST API - The Gestalt team used Figma’s REST API to inspect design files and identify layers originating from Gestalt libraries. - FigStats aggregated this information into a dashboard for visualizing component usage. - The dashboard enabled the team to explore adoption across Pinterest’s design work rather than relying only on manually selected examples. - Measuring actual file content also helped reveal whether designers were using complete Gestalt components or recreating and modifying patterns themselves. ## Using Adoption Data to Guide the Design System - Design adoption became a way to evaluate the value and reach of Gestalt. - Higher usage could demonstrate that investment in corresponding engineering components was justified. - Low adoption could indicate that: - Designers were unaware of an existing component. - The component did not meet their needs. - Documentation or discoverability needed improvement. - A component required redesign or better cross-platform support. - Because design precedes implementation, Figma usage could serve as an earlier signal than production code adoption. Figma’s native analytics provide a useful starting point, but meaningful adoption measurement requires context. Teams should compare design-system usage with the total design surface, use the data to identify gaps, and treat Figma adoption as a complementary metric to code adoption.

Read original

Rest Api Figma Design Systems Data Analytics+2