标签：#back

O contrato do cliente tá numa URL que qualquer um adivinha A tarefa parecia simples: o cliente precisa baixar a nota fiscal dele. Você salvou em storage/app/public/notas/ , rodou php artisan storage:link , mandou o link e foi feliz. https://app.com/storage/notas/nota-1042.pdf . Semanas depois cai a ficha. Aquele arquivo está aberto na internet . Sem login, sem nada. E o nome é sequencial: quem baixou a nota-1042.pdf só precisa de curiosidade e cinco segundos pra tentar a 1041 . E a 1040 . Então você faz a coisa certa: tira do disco público e cria um sistema pra controlar acesso. Tabela download_tokens , model, geração de UUID, coluna expires_at , controller que valida, e um comando no scheduler pra limpar os vencidos. Sessenta linhas depois, funciona. E aí alguém comenta no PR: "por que você não usou uma URL assinada?" O sistema que você não precisava construir // ❌ migration + model + controller + command. tudo isso pra um PDF. Schema :: create ( 'download_tokens' , function ( Blueprint $table ) { $table -> id (); $table -> uuid ( 'token' ) -> unique (); $table -> string ( 'path' ); $table -> foreignId ( 'user_id' ); $table -> timestamp ( 'expires_at' ); $table -> timestamps (); }); public function gerarLink ( NotaFiscal $nota ): string { $token = DownloadToken :: create ([ 'token' => Str :: uuid (), 'path' => $nota -> arquivo_path , 'user_id' => auth () -> id (), 'expires_at' => now () -> addMinutes ( 10 ), ]); return route ( 'download' , $token -> token ); } Não tem nada de errado tecnicamente. O problema é o custo: mais uma tabela crescendo pra sempre, mais um comando no scheduler, mais um caminho pra testar. E você vai manter isso enquanto o projeto existir. O Laravel resolve o mesmo problema com uma assinatura criptográfica na própria URL. Sem estado, sem tabela, sem limpeza. Como uma URL assinada funciona A ideia é bonita de simples: o Laravel monta a URL com os parâmetros que você quer, calcula um hash disso tudo usando a APP_KEY e cola o hash no final. /not

"Deu erro ao salvar, umas duas da tarde" É a única informação que você tem. O cliente não lembra o que clicou, não tirou print e já fechou a aba. Você abre o laravel.log . Quarenta mil linhas no dia. Faz um grep por "erro". Aparecem 1.200 ocorrências, e a maioria é isso: [2026-08-14 14:03:11] production.INFO: entrou [2026-08-14 14:03:11] production.INFO: erro aqui [2026-08-14 14:03:12] production.INFO: passou [2026-08-14 14:03:12] production.ERROR: Erro ao salvar Erro ao salvar o quê ? De qual usuário? Qual pedido? Qual valor? Aquele entrou da linha de cima é do mesmo request ou de outro cliente que estava usando o sistema no mesmo segundo? Você tem log. Você não tem informação. São coisas diferentes. O problema não é a falta de log. É o excesso de log inútil. public function emitir ( Pedido $pedido ) { Log :: info ( 'entrou no emitir' ); try { $nota = $this -> sefaz -> emitir ( $pedido ); Log :: info ( 'emitiu' ); } catch ( Throwable $e ) { // parabéns, você registrou que algo deu errado em algum lugar 🎉 Log :: error ( 'Erro ao emitir nota' ); return back () -> withErrors ( 'Falha na emissão' ); } } Repara no que esse catch jogou no lixo: a mensagem da exceção, o stack trace, o ID do pedido, o CNPJ, o retorno da SEFAZ. Tudo estava ali, na mão, e foi substituído por uma frase genérica. E os Log::info('entrou') espalhados? Aquilo foi debug que virou permanente. Hoje eles só servem pra empurrar as linhas úteis pra fora da tela. Duas perguntas que todo log precisa responder Um log serve pra duas plateias: você, com sono, às 3h da manhã — e uma máquina , filtrando milhões de linhas. As duas querem a mesma coisa: O que aconteceu , numa mensagem que não muda nunca. Com quem aconteceu , em dados separados da mensagem. Essa separação é o pulo do gato. Repare na diferença: // ❌ mensagem única pra cada pedido. impossível agrupar ou contar. Log :: error ( "Falha ao emitir nota do pedido { $pedido -> id } do cliente { $cliente -> nome } " ); // ✅ mensagem estável + contexto est

Ele começou com um if . Hoje tem 80 linhas. Sabe como é: precisava barrar quem não tem assinatura ativa. Um middleware, três linhas, resolvido. Depois entrou o período de teste. Depois o plano legado que tem regra diferente. Depois "aproveita que já buscou a assinatura e desconta um crédito". Depois o e-mail de aviso quando faltam 3 dias pro vencimento. Hoje esse arquivo tem 80 linhas, faz quatro queries, altera dado no banco e dispara e-mail. Ele não é mais um middleware. É um Service que mora na pasta errada e roda em todo request. E o pior: essa regra não existe pro resto do seu sistema. O middleware que virou gerente class VerificarAssinatura { public function handle ( Request $request , Closure $next ): Response { $assinatura = $request -> user () -> assinatura ; if ( ! $assinatura || $assinatura -> venceu ()) { return redirect () -> route ( 'planos' ); } // "aproveita que já tá aqui" 🙃 if ( $assinatura -> creditos < 1 ) { return redirect () -> route ( 'planos' ) -> withErrors ( 'Sem créditos' ); } $assinatura -> decrement ( 'creditos' ); $assinatura -> update ([ 'ultimo_acesso' => now ()]); if ( $assinatura -> vence_em -> diffInDays ( now ()) <= 3 ) { Mail :: to ( $request -> user ()) -> send ( new AssinaturaVencendo ( $assinatura )); } return $next ( $request ); } } Funciona. Passa nos testes de feature. E tem quatro problemas escondidos que só aparecem meses depois. Problema 1: middleware só existe no HTTP Esse é o grande. Middleware é uma camada de request HTTP . Ela não roda em outro lugar nenhum. Então: O comando php artisan relatorio:gerar não desconta crédito. O job na fila não desconta crédito. Sua rota de API que você esqueceu de agrupar não desconta crédito. O tinker passa por cima de tudo. Você não criou uma regra de negócio. Criou uma regra da porta da frente . Qualquer outra entrada no sistema ignora ela. E, sério, isso não é hipótese: um dia alguém vai criar um endpoint novo, esquecer o middleware, e a assinatura vira um detalhe decorativo. Probl

The Model Context Protocol (MCP) has been evolving quickly. One of the most interesting changes in the latest MCP specification is the move toward a stateless protocol model . I recently updated my MCP currency converter server to work with the newer stateless behavior and the new split TypeScript SDK packages, particularly @modelcontextprotocol/server . In this article, I'll explain: What MCP sessions were doing What "stateless MCP" actually means Why the change matters for production systems How Streamable HTTP changes with the new specification How I migrated my currency converter MCP server What this means for scaling MCP servers What Is MCP? If you're new to MCP, the Model Context Protocol is a standard for connecting AI applications to external tools, resources, and data. Instead of building custom integrations between every AI application and every external service, MCP provides a common protocol. For example, an AI assistant can use an MCP server exposing a tool like: convert_currency The model can then request: Convert 100 USD to EUR. The MCP client communicates with the MCP server, which performs the actual operation and returns the result. MCP servers can expose several primitives, including tools, resources, and prompts. For my example, the server is intentionally simple: it exposes currency-conversion functionality. The Old Mental Model: MCP Sessions Before the stateless changes, Streamable HTTP could maintain a protocol-level session. Conceptually, the flow looked something like this: Client | | POST /mcp | initialize v MCP Server | | Mcp-Session-Id v Client | | POST /mcp | Mcp-Session-Id: abc123 v MCP Server The server creates a session during initialization. Subsequent requests contain the session identifier. That means the server can associate requests with the session that was established earlier. This isn't necessarily bad. Session state can be useful when an application genuinely needs conversational or connection-level state. But it creates an a

Unlock Seamless Idempotent Processing Without Coding Hurdles As a seasoned integration mentor, I'm here to walk you through a simple, no-code/low-code method to tackle the thorny issue of idempotent consumers in MuleSoft Anypoint. You’ve likely struggled with pre-built connectors and complex data transformations, but let’s take this one step at a time—no Java or XML required. The 3-Click Path: From Complexity to Simplicity Define Your Idempotency Key : Start by selecting the unique identifier in your message that will serve as your idempotency key. This could be an order ID, transaction number, or any field that uniquely identifies each event. Set Up Object Store Configuration : Navigate to MuleSoft’s Object Store configuration within Anypoint Studio and configure it for storing these keys. Here, you can choose between In-Memory or Persistent storage options depending on your scalability needs. Apply Idempotent Filter Component : Drag the “Idempotent Filter” component into your flow where you want to enforce idempotency. Configure this filter by specifying the object store and the key field that uniquely identifies each incoming event. And just like that, you’ve set up a system that ensures even when an integration event is delivered multiple times, it will only process once—eliminating double-charges or redundant data entries in your downstream systems. Why This Matters for Low-Level Beginners For many of us working with MuleSoft and similar platforms, the complexity around ensuring message processing integrity can seem daunting. Yet, by simplifying this process through intuitive component usage, we ensure that each event is processed exactly once, maintaining system accuracy without diving into complex scripting or configuration. Conclusion: Empowering Automators As you continue on your journey of automating data flows and enhancing business processes, remember—MuleSoft’s capabilities extend far beyond what rigid pre-built connectors might suggest. Embrace these n

Here's the full flow the way I've built it, using Notify as the email API. The shape of this is the same regardless of which provider you pick — generate a token, send a link, verify it on submit — so most of this applies no matter what you're using; I'll flag the one part that's specific to Notify. The Flow, End to End User requests a password reset Your backend generates a secure, short-lived reset token Your backend stores a hashed version of that token Your backend sends an email with the reset link, through an email API User clicks the link and submits a new password Your backend verifies the token, updates the password, and invalidates the token Step 1: Generate the Reset Token Use a cryptographically secure random value, not anything guessable, and store only a hashed version in your database — if your database ever leaks, the raw tokens aren't exposed alongside it: const crypto = require ( ' crypto ' ); function generateResetToken () { const token = crypto . randomBytes ( 32 ). toString ( ' hex ' ); const tokenHash = crypto . createHash ( ' sha256 ' ). update ( token ). digest ( ' hex ' ); return { token , tokenHash }; } Give it a short expiration — 15 to 60 minutes is typical. Step 2: Build the Reset URL https://yourapp.com/reset-password?token=RESET_TOKEN The token goes in the link the user clicks; the hash is what you store and check against later. Step 3: Send the Email This is the Notify-specific part. There's no SDK to install — it's a single HTTP request with your API key in the header: async function requestPasswordReset ( email ) { const user = await findUserByEmail ( email ); // Don't reveal whether the email exists if ( ! user ) return ; const { token , tokenHash } = generateResetToken (); const expiresAt = new Date ( Date . now () + 1000 * 60 * 30 ); // 30 minutes await saveResetToken ( user . id , tokenHash , expiresAt ); const resetLink = `https://yourapp.com/reset-password?token= ${ token } ` ; await fetch ( ' https://notify.cx/api/email/send

A generated route can remove repetitive Express handlers without removing the API contract. That distinction becomes concrete when one endpoint is deliberately broken in five small ways. Each break below changes either shape construction, request validation, emitted Prisma arguments, or execution-time projection. The status code alone is not enough to identify which layer moved. The examples use prisma-guard 1.33.0, Prisma 6.19.3, and Zod 4.4.3. Those versions are pinned because several observations concern exact runtime behavior. The goal is a test you can rerun during upgrades, not a rule inferred from one successful response. Start with a small tenant model. Nursery is the scope root, and Plant carries the foreign key that the guard extension can constrain. /// @scope-root model Nursery { id String @id @default(cuid()) name String plants Plant[] } model Plant { id String @id @default(cuid()) name String priceCents Int isPublished Boolean @default(false) nurseryId String nursery Nursery @relation(fields: [nurseryId], references: [id]) } The generated router still needs an extended Prisma client and trusted request context. Authentication remains application code. The important detail is that the tenant ID comes from the authenticated session, not from the query string or body. import { AsyncLocalStorage } from ' node:async_hooks ' import { PrismaClient } from ' @prisma/client ' import { guard } from ' ./generated/guard/client ' type RequestContext = { nurseryId : string ; audience : ' public ' | ' seller ' } const requestStore = new AsyncLocalStorage < RequestContext > () const prisma = new PrismaClient (). $extends ( guard . extension (() => { const context = requestStore . getStore () return { Nursery : context ?. nurseryId , caller : context ?. audience } }), ) Now define one public read contract. In a guard shape, true means the client may choose a value. A literal means the server chose it. force(true) is required to pin a Boolean to true because bare true is

Access tokens, refresh token rotation, and theft detection: the parts most Node.js tutorials leave out. A friend messaged me about his side project a few months ago: "Someone else is logged into my account. I changed my password. They're still in." He had followed the tutorials to the letter. Sign a JWT on login, send it to the frontend, keep it in localStorage , attach it to every request. Done. What none of those tutorials mentioned is that this setup has no way to un -log anyone in. A JWT is a signed piece of paper. Once you hand it over, it stays valid until it expires, and his expired in 30 days. Changing the password accomplished nothing, because the token had already been signed and nothing about it depended on the password. There was no list of active sessions to delete from. There was nothing to revoke. His only remaining move was rotating the signing secret, which logged out every user on the platform at once. That was his entire kill switch: burn it all down. This is the walkthrough I wish someone had handed me the first time I built auth. Token design, storage, refresh rotation, theft detection, the Express code, the Axios interceptor on the frontend, and the specific mistakes that turn a working login into an incident. It's long. Auth is one of those areas where the missing ten percent is the part that gets you. What the standard tutorial leaves out Nearly every "JWT authentication in Node.js" post ends in the same place: sign a token, put it in localStorage , send a Bearer header. That gets you a demo. Four things stand between that and production. localStorage is readable by any JavaScript on the page. That includes the analytics snippet you added last week, the npm package that got compromised upstream, and any XSS hole in your own code. One call to localStorage.getItem('token') and an attacker holds a working credential they can replay from their own machine. You can't detect it and you can't stop it. There is no revocation. The appeal of JWTs is st

For a long time, my mental model of observability was this: you import an SDK, sprinkle some calls through your code, each call fires off data to a server somewhere, and a dashboard reads it back. A logging system with extra steps. That model is wrong in a specific, interesting way. And I couldn't see how it was wrong until I stopped looking at the dashboards and started looking at what actually gets emitted, and how. The seductive wrong model The wrong model is seductive because the plumbing really does look identical. Logging: emit, store, search. Observability: emit, store, query. Same loop, right? So my working theory became: observability is logging plus some fancy logic to analyze the logs. Close. But no. The difference isn't in the analysis. It's in the emission — and it splits into three mechanisms that have almost nothing in common with each other. Descent one: metrics aren't events at all A metric is not a record you write. It's a number sitting in your app's memory . requests_total . increment () // 1, 2, 3... request_duration . record ( 0.23 ) // adds to a histogram Nothing is sent when this line runs. The number just changes in RAM. Periodically — every 15 seconds, say — either a backend scrapes an endpoint your app exposes, or a collector ships the current values out. That's why metrics are absurdly cheap: a million requests is one counter reading "1,000,000", not a million records. You could never reconstruct a clean p99 latency graph by parsing log text. The histogram was built for it at write time. And the stateless-container objection answers itself: the in-memory counter is disposable. Each instance flushes to the backend on a schedule (on serverless, a sidecar collector even does a final flush at shutdown), and the backend sums across instances. The durable truth never lived in your app. Descent two: logs are the familiar part Logs work exactly the way I always assumed everything worked: an event, written out, shipped, searched. The only upgrade

Tim O’Reilly built a publishing empire that AI is helping to destroy. Yet he loves AI—as long as it’s open source.

Adding online payments to a web application can make it easier for customers to purchase products, subscribe to services, book appointments, or pay invoices. But payment integration involves more than adding a payment button to a website. A reliable integration needs a payment gateway, backend APIs, secure authentication, payment status handling, webhooks, and proper error management. This guide explains the basic process of integrating a payment gateway into a web application, using Razorpay as an example. 1. Understand How Payment Gateway Integration Works A typical payment flow looks like this: Customer → Web App → Backend → Payment Gateway → Bank/Payment Network The customer starts the payment from your website. Your backend creates the payment order through the gateway. The customer then completes the payment using a supported payment method. After the transaction, your application needs to confirm whether the payment was successful before providing the product or service. A simplified flow is: Customer selects a product or service. Your backend creates an order. The payment gateway generates the required payment details. Checkout opens for the customer. Customer completes the payment. The gateway returns payment information. Your backend verifies the payment. A webhook can update your system about payment events. Your database records the final payment status. The application confirms the order. 2. Choose the Right Payment Gateway Before starting development, compare payment gateways based on factors such as: Supported payment methods Transaction fees API documentation Developer tools Settlement process Refund support International payment support Webhook capabilities Security requirements Customer support For an Indian web application, gateways such as Razorpay can support common payment methods including UPI, cards, net banking, and wallets, depending on the account and applicable availability. The important thing is to choose a gateway that fits your applic

Rate limiting sounds like a solved problem until you actually implement one and watch it fail in a way your load test didn't predict: legitimate bursts getting rejected, or a limiter that lets through 2x its stated limit at window boundaries. The failure modes are specific enough that it's worth working through the two dominant algorithms — token bucket and sliding window — with actual code, not just the diagrams. The problem with fixed windows The naive approach almost everyone reaches for first is a fixed window counter: pick a window size (say, 60 seconds), count requests in that window, reset the counter when the window rolls over. import time class FixedWindowLimiter : def __init__ ( self , limit : int , window_seconds : int ): self . limit = limit self . window_seconds = window_seconds self . count = 0 self . window_start = time . time () def allow ( self ) -> bool : now = time . time () if now - self . window_start >= self . window_seconds : self . window_start = now self . count = 0 if self . count < self . limit : self . count += 1 return True return False This is simple and cheap, and it's also broken in a specific, exploitable way. Say the limit is 100 requests/minute. A client can send 100 requests in the last second of window N, then another 100 in the first second of window N+1. That's 200 requests in roughly two seconds, well within the letter of "100/minute" as the code enforces it, but nowhere near the spirit of it. This is the classic boundary-burst problem, and it's the reason fixed windows get replaced once traffic is adversarial or bursty enough to find the seam. Sliding window: smoothing the boundary A sliding window log fixes this by tracking actual timestamps instead of a single counter, and counting how many fall within the trailing window at the moment of the request: from collections import deque import time class SlidingWindowLogLimiter : def __init__ ( self , limit : int , window_seconds : float ): self . limit = limit self . window_seco

The new order sweeps away decades of existing U.S. cybersecurity policy prohibiting private companies from conducting 'hack back' attacks or offensive cyber operations.

Imagine this: It's salary day. It's 2 PM. Millions of people across India suddenly open their UPI apps and start paying rent, sending money to family, paying credit-card bills, and shopping online. Now here's the system-design interview question: If millions of people make payments at almost exactly the same time, is every request hitting one central server? What prevents the entire payment system from freezing? At first glance, it sounds like a scaling problem. It isn't just a scaling problem. It's a combination of: horizontal scaling concurrency distributed systems database consistency retries idempotency backpressure failure isolation downstream bottlenecks And that's what makes payment systems such an interesting system-design problem. First: Don't Imagine One Giant UPI Server A common mental model looks like this: Millions of users | v +-------------+ | UPI Server | +-------------+ | v Bank If that were literally true, we'd have a pretty serious problem. One machine cannot safely process the country's entire payment traffic. Instead, think about a distributed system: Users | v +---------------+ | API / Gateway | +---------------+ / | \ / | \ v v v [S1] [S2] [S3] | | | +------+------+ | Payment Services | +--------+--------+ | | Bank A Bank B The exact implementation of a real payment network is much more complicated than this diagram, but this is the right system-design mental model . The important idea is: The system is distributed across many machines and participating institutions. Step 1: The First Problem — Traffic Spikes Let's take a concrete example. You want to pay your landlord: ₹25,000 At the same moment, millions of other people are doing something similar. Suddenly: Normal traffic: 100K requests/sec Salary day: ████████████████████████ 1M+ requests/sec The first question is: How do we handle the additional traffic? Naive Solution: One Powerful Server We could buy a massive machine. 1M requests/sec | v +---------------+ | HUGE SERVER | | 256 CPU core

Welcome to Part 1 of the Go Distributed Systems Lab series! Over the course of 20 hands-on projects, we are building core distributed systems primitives from the ground up using Go 1.22+ and the standard library ( net , sync , context , log/slog , encoding/binary ). Before jumping into raw socket framing, gossip protocols, or Raft consensus, we need to master the foundational concurrency building blocks inside a single process: Goroutines, Channels, and Communicating Sequential Processes (CSP) . 💡 The Philosophy: Share Memory by Communicating In traditional concurrent programming (like C++ or Java), thread synchronization often relies on shared memory protected by mutexes, lock-free queues, or read-write locks. Go flips this model with a core design principle: "Do not communicate by sharing memory; instead, share memory by communicating." By passing ownership of data structures through Go channels, each pipeline stage operates on isolated memory. This eliminates data races by design without requiring explicit lock management ( sync.Mutex ). 🏗️ Architecture & Component Design In this first module ( 01-message-passing ), we construct a 3-stage data processing pipeline: +------------------+ Job Channel +------------------+ Result Channel +-------------------+ | Producer | -------------------------> | Worker | ------------------------> | Collector | | (Generates Jobs) | (Buffered, cap=10) | (Isolated State) | (Buffered, cap=10) | (Aggregates Data) | +------------------+ +------------------+ +-------------------+ 1. Ingestion Stage (Producer) Generates typed Job values and pushes them into a direction-constrained buffered channel ( chan<- Job ). When generation finishes, it closes the channel to broadcast an end-of-stream signal. 2. Processing Stage (Worker) Consumes from <-chan Job using Go's for job := range in construct. The worker maintains internal execution metrics (e.g., processedCount ) entirely within its local stack scope—no locks required. 3. Collector Stage R

Short answer: move marketplace review summarization, tagging, and extraction to batch LLM jobs when no customer is waiting, but keep realtime calls for interactive work and attribute every job to a tenant before it enters the queue. This is a deadline decision before it is a vendor decision. A nightly policy scan can wait; a seller asking why a listing was rejected cannot. Batch processing removes peak-time synchronous handling from the first case and gives the team a status-and-results workflow for backfills. It does not make latency disappear. The other constraint is accounting. A marketplace that pools every review into one opaque job may lower operational friction while making chargeback, abuse investigation, and budget alerts much harder. The useful unit is therefore a tenant-scoped batch with an internal ledger entry, not merely a large file of prompts. Treat every finding as governed evidence Create the ledger record before dispatch. It should connect an immutable internal job ID to the tenant, workload kind, input count, model choice, submission time, deadline, and estimated token total. Keep the provider job ID as a later mapping rather than using it as your primary key. That leaves audit history and cost attribution intact if the team changes providers. For review-code analysis, require structured findings such as severity, file, line, rule, and explanation. Summarization can tolerate some prose variation; compliance tagging and extraction usually cannot. Validate the result schema before marking a job complete, and quarantine individual invalid items instead of silently accepting a partially malformed export. The same instinct that keeps an OTP system from treating "accepted" as "delivered" applies here: provider acceptance, job completion, export retrieval, schema validation, and downstream application are separate states. Keep it boring. Really. A practical ledger can have one parent row per tenant batch and one child row per review. The parent holds fo

Querydsl is one of those libraries that everyone used for years and then quietly stopped updating. The 5.0 release has been "coming soon" since 2019. The GitHub shows commits but no milestone. The issue tracker has a thread titled "Is Querydsl dead?" with hundreds of comments. It's not dead. But if you're starting a new project in 2026 and you're picking between Querydsl and something that's actively maintained, has Spring Boot 4 support, works with MongoDB and in-memory collections, generates OpenAPI docs automatically, and has companion frontend libraries... well, you see where I'm going. This isn't a "Querydsl bad, Spring Filter good" article. Querydsl pioneered type-safe querying for Java and it deserves credit. But migrations happen, and if you're considering one, here's what the conversion looks like. Side-by-side: basic filtering Querydsl: QCar car = QCar . car ; BooleanExpression filter = car . year . gt ( 2020 ) . and ( car . km . lt ( 50000 )) . and ( car . color . eq ( Color . RED )); List < Car > results = new JPAQuery <>( entityManager ) . select ( car ) . from ( car ) . where ( filter ) . fetch (); Spring Filter (query string): @Filter Specification < Car > spec // URL: ?filter=year > 2020 and km < 50000 and color : 'red' List < Car > results = carRepo . findAll ( spec ); Spring Filter (programmatic builder): FilterNode filter = fb . field ( "year" ). greaterThan ( fb . input ( 2020 )) . and ( fb . field ( "km" ). lessThan ( fb . input ( 50000 ))) . and ( fb . field ( "color" ). equal ( fb . input ( Color . RED ))) . get (); Specification < Car > spec = converter . convert ( filter ); List < Car > results = carRepo . findAll ( spec ); Spring Filter (type-safe builder): FilterNode f = CarFilter . where ( fb ) . year (). greaterThan ( 2020 ) . and () . km (). lessThan ( 50000 ) . and () . color (). equal ( Color . RED ) . build (); Specification < Car > spec = converter . convert ( f ); List < Car > results = carRepo . findAll ( spec ); The type-safe bui

If you have ever needed to send an email, process a payment, or generate a report without making your user wait, you have probably run into Celery. Celery is a tool that lets you run jobs in the background, away from your main app. This article breaks down how it works, step by step, in plain language. What Is Celery, In Simple Terms Think of Celery like a restaurant kitchen. Your app (the waiter) takes an order from a customer. Instead of cooking the food itself, the waiter drops the order into a queue (the kitchen order rail). A cook (the worker) picks up the order from the rail and prepares it. When the food is ready, it goes to a pickup counter (the result backend) where anyone can come check if it's done. Celery has four main players: The Producer - your app, the one that creates tasks. The Broker - the message queue that holds tasks until a worker is free. The Worker - the process that picks up and runs the tasks. The Result Backend - where results are stored, if you need them later. In short: your app sends a task message to the broker. The broker holds it until a worker is free. The worker picks it up, runs the actual function, and (if you set one up) writes the result to the result backend. Your app can then go back and check that result backend to see what happened. Now let's go through each part. 1. How Tasks Get Registered Before Celery can run a task, it needs to know the task exists. This is called registration , and it happens the moment your Python code is imported - not when the task runs. The @app.task decorator You create a Celery app instance, then decorate any function with @app.task . That decorator does not run the function immediately. Instead, it wraps the function and adds it to a task registry - basically a dictionary that Celery keeps internally, mapping a task name to the actual function. from celery import Celery app = Celery ( " myproject " ) @app.task def send_welcome_email ( user_id ): # logic to send an email print ( f " Sending wel

Receiving a webhook is easy. Building a webhook pipeline that survives duplicate deliveries, delayed events, missing messages, invalid signatures, and seller authorization changes is the real engineering work. This guide explains how to build a production-ready pipeline for TikTok Shop Customer Service messages—from HTTPS ingress to history reconciliation. First, Understand the Scope TikTok Shop Customer Service API is designed for conversations between buyers and sellers in a TikTok Shop. It is not an API for reading ordinary TikTok direct messages. Before implementation, confirm that: Your application has access to the required Customer Service API scopes. The seller has authorized your application. The target shop is correctly mapped to your internal workspace or tenant. Your webhook endpoint is publicly accessible over HTTPS. Customer Service API access is inactive by default and requires approval. See the official Customer Service API overview and app features documentation . If these prerequisites are missing, changing webhook code will not solve the problem. Recommended Architecture A reliable implementation separates webhook acknowledgement from business processing: TikTok Shop | v HTTPS webhook ingress | +-- Verify signature using raw request body | +-- Insert event into a durable inbox | +-- Return HTTP 200 within 3 seconds | v Message queue | v Normalize, deduplicate, and route | v Customer service workspace ^ | History reconciliation worker The webhook request should not wait for: CRM updates AI-generated replies Media downloads Ticket creation Search indexing External notifications Persist the event, acknowledge it, and process it asynchronously. Subscribe to the New Message Event For incoming customer service messages, subscribe to NEW_MESSAGE , identified as event type 14 . You can configure the subscription in TikTok Shop Partner Center or through the webhook configuration API. The official event reference is available in the New Message webhook docu

Introduction Tennis players often find themselves in a feedback vacuum. Without a coach physically present, pinpointing what’s wrong with a stroke becomes a guessing game. This gap in immediate, stroke-specific guidance is a silent killer of progress, leaving players to rely on sporadic coaching sessions or self-diagnosis, which often misses the mark. The problem isn’t just about lack of access to coaches—it’s about the inability to see and correct subtle technique flaws in real time. Enter Rallylens , a web app born out of personal frustration. As a student and tennis player, I built this tool to address the disconnect between practice and feedback. It uses video analysis powered by AI to break down uploaded tennis videos frame by frame, identify stroke types (forehand, backhand, serve), and compare them against ideal technique benchmarks. The system doesn’t just flag errors—it explains them. For instance, if a backhand stroke shows an inconsistent racket angle, the feedback highlights this deviation and suggests adjustments, focusing on mechanics like wrist rotation or body alignment. The Mechanism Behind the Feedback Rallylens operates through a multi-step process that mimics a coach’s eye but with the precision of machine learning: Video Segmentation: Uploaded videos are split into frames, allowing the AI to analyze micro-movements that might be invisible to the naked eye. Stroke Classification: Using computer vision techniques , the model identifies the stroke type with an accuracy rate currently at 85%, though unusual playing styles can still cause misclassification. Pattern Analysis: The algorithm compares detected patterns against biomechanical benchmarks , flagging deviations like improper weight transfer or late racket contact. Feedback Generation: Instead of generic advice, the system generates actionable insights , such as “Adjust your shoulder tilt by 10 degrees to optimize power transfer.” Edge Cases and Limitations While Rallylens bridges a critical g