标签：#backend

LIA is a hyperlocal employability platform I'm building for an isolated coastal district in Brazil — think fixed retail jobs, gigs, and a reputation layer, all matched by proximity instead of routed through a national job board. This post is about the implementation: the actual folder structure, the real RegisterUserUseCase, and the Argon2id decision — pulled straight from the repository, not reconstructed from memory. The Clean Architecture folder structure LIA's backend is organized in four layers, and the direction of dependency is non-negotiable: outer layers depend on inner layers, never the other way around. backend/src/ ├── domain/ │ ├── entities/ │ └── repositories/ # interfaces only ├── application/ │ ├── dto/ │ └── use-cases/ ├── infrastructure/ │ ├── database/ │ └── repositories/ # Prisma implementations ├── presentation/ │ ├── controllers/ │ └── routes/ └── shared/ └── errors/ Let's walk through the registration feature end to end, following that exact order. Domain — the entity and the repository contract The User entity is a plain interface. No decorators, no ORM annotations, no framework leaking in: typescript// domain/entities/user.ts export interface User { id: string; name: string; email: string; password: string; createdAt: Date; updatedAt: Date; } The repository is defined as a contract, not an implementation. The domain doesn't know — and doesn't care — whether it's backed by PostgreSQL, an in-memory map, or something else entirely: typescript// domain/repositories/user.repository.ts import { RegisterUserDTO } from '../../application/dto/register-user.dto.js'; export interface UserRepository { create(data: RegisterUserDTO): Promise<{ id: string; name: string; email: string; createdAt: Date; updatedAt: Date; }>; findByEmail(email: string): Promise<{ id: string; name: string; email: string; password: string; createdAt: Date; updatedAt: Date; } | null>; } Notice create() never returns the password hash. That's not an accident — it's the same "strip

Intro An MCP server can look like another API layer: expose existing REST endpoints as tools and call it a day. Both receive input, execute backend logic, and return a result. But they operate under different assumptions. This two-part series explains why directly wrapping REST APIs is a bad default. This first article covers the differences in their runtime environments. The second will discuss how those differences should affect MCP design (you already know how to design a good REST API ). We can see those differences more clearly by comparing the two across several dimensions. Dimensions The consumer With REST, developers encode control in application logic. The application knows when to call an endpoint, what arguments to send, and how to handle the response. Those decisions are made during development. With MCP tools, much of that control moves to the AI agent. The model interprets the request, chooses a tool, constructs its arguments, evaluates the result, and decides what to do next. The harness can restrict it, but the model is still part of the control flow. A REST client already knows why it is making a call. An agent must first decide whether a tool is relevant at all. MCP tools The context A REST application can draw from application state, cookies, memory, and user input. Code written by a developer determines which parts become request parameters. An agent can draw from the current request, conversation history, and previous tool results. The MCP server does not see this context automatically, but the model may turn parts of it into tool arguments at runtime. The difference is who selects what reaches the backend: predetermined code or a model reasoning over a changing conversation. The action model REST APIs tend to expose focused, fine-grained operations that application code can compose. Keeping endpoints simple and stable limits regressions because a developer has already written and tested the workflow that connects them. With MCP, the agent often

Episode 1 established the mindset: failure is normal, not a sign of bad engineering. Episode 2 gets specific — you can't detect or handle a failure you can't even name. Saturday, Round 2 👦 Nephew: Uncle, last time you convinced me failure is basically guaranteed. Fine, I accept it. So what actually fails ? 👨‍🦳 Uncle: You tell me. Start listing things that could go wrong in your app right now. 👦 Nephew: Uh... the server could crash. The database could go down. My code could have a bug. 👨‍🦳 Uncle: Keep going. 👦 Nephew: The network? Someone could deploy the wrong thing? Payment gateway dies mid-checkout? 👨‍🦳 Uncle: You just named six of the seven categories without trying. You already know this. You've just never sorted it. 1. Hardware Failure 2. Software Failure 3. Network Failure 4. Database Failure 5. Third-Party Failure 6. Human Error 7. Resource Exhaustion 👦 Nephew: Then why do we need the list at all, if I already know it instinctively? 👨‍🦳 Uncle: Because "instinctively" isn't fast enough at 2 AM. Let's trace each one properly. Part 1 — Hardware Failure 👦 Nephew: This one's obvious anyway — I deploy to AWS. The cloud hides hardware failure from me. 👨‍🦳 Uncle: Does it? 👦 Nephew: ...doesn't it? That's the whole point of paying for EC2 instead of buying a server. 👨‍🦳 Uncle: Let's trace it. Your app sits on an EC2 instance. What's underneath the instance? 👦 Nephew: Virtual machine stuff, I guess? 👨‍🦳 Uncle: And underneath that ? 👦 Nephew: ...an actual physical machine somewhere. In a data center. 👨‍🦳 Uncle: There it is. Your app | "Virtual" server (EC2/Droplet) | ACTUAL physical hardware somewhere in a data center | Still capable of failing — just less visible to you 👦 Nephew: So it's not hidden. It's just one layer further away than I thought. 👨‍🦳 Uncle: Exactly. AWS absorbs a lot of it — that's part of what you're paying for — but disks still fail, instances still get abruptly terminated, whole availability zones still go down. That's Hardware Failure . Hardware Fa

Reddit looks simple and hides two genuinely hard problems. Comments nest arbitrarily deep, and a naive tree structure makes loading a busy thread slow. The front page reorders itself constantly, so ranking cannot just count votes or old posts would never leave. Both problems have well-known answers, and both are good lessons in choosing the right model. The core problem A comment thread is a tree. Each comment can reply to any other, so depth is unbounded. If you store only "this comment's parent id" and then try to load a whole thread, you walk the tree one level at a time, one query per level, which gets slow for deep or wide threads. Loading a popular post with thousands of nested comments should not take thousands of queries. Ranking is the second problem. If the front page sorted by raw vote count, the highest-voted post of all time would sit at the top forever. If it sorted by newest, quality would drown in noise. You need a score that blends how good a post is with how fresh it is, so good new posts can climb and old ones fade even if they were once popular. Key design decisions Store the parent pointer, but do not traverse at read time. The simple model is a parent_id per comment, which is easy to write but expensive to read as a tree. To load a thread cheaply, fetch all comments for the post in one query, then assemble the tree in application memory. One read, in-memory tree building. This works because a single post's comments, while numerous, fit in memory to assemble. Consider a path or closure model for deep trees. For very deep threads, some systems store a materialized path on each comment, an encoded ancestor chain, so you can fetch an entire subtree with a single prefix query and sort by the path to get correct display order. Another option is a closure table that records every ancestor-descendant pair, which makes subtree queries direct at the cost of extra write work. The right choice depends on how deep threads get and how often you read subtrees

Searching billions of documents for a phrase and getting ranked results in tens of milliseconds looks like magic. It is not. It comes down to two ideas working together: an index that maps words to documents instead of scanning documents for words, and a way to spread that index across machines so each holds only a slice. Understand both and full-text search stops being mysterious. The core problem A database scans rows. If you ask a plain database to find every document containing a word, it reads documents and checks them, which is linear in the amount of data. That is fine for exact key lookups and hopeless for free-text search across huge corpora. You need the opposite mapping. Instead of "given a document, what words does it have", you want "given a word, which documents have it". That inversion is the whole trick. The second problem is size. One machine cannot hold the index for billions of documents, and one machine cannot serve the query load. So the index has to be split across nodes, and a query has to find the right nodes and combine their answers. Key design decisions Build an inverted index. At index time, each document is broken into tokens by an analyzer that lowercases, splits on word boundaries, and often strips or stems words. For every token, the engine keeps a posting list: the set of document ids that contain it, often with positions for phrase matching. A query for a word becomes a direct lookup of its posting list, not a scan. A multi-word query intersects or unions posting lists, which is fast because the lists are sorted. Store the index in immutable segments. New documents go into small new segments rather than editing existing ones. Segments are immutable, which makes them cache-friendly and safe to read without locks. A background process merges small segments into larger ones over time. A delete is just a marker; the document is removed for real during a later merge. Split an index into shards. An index is divided into shards, each a sel

RQ (Redis Queue) is a delightfully simple way to run background jobs in Python. That simplicity is also why teams under-monitor it: it just works, until a downstream API gets slow or a bad deploy ships, and jobs start failing in bulk — quietly. Here's what to watch and how to get alerted before a customer tells you. RQ failures don't announce themselves When a job raises, RQ moves it to the FailedJobRegistry and moves on. The worker keeps running; nothing crashes. If you're not looking at that registry, the failure is invisible — the same trap BullMQ, Celery, and every robust queue share. So the job is to reach into the queue's state and turn it into a signal. The four signals that matter for RQ Failure count / rate — jobs landing in the FailedJobRegistry over a window. Backlog — how many jobs are queued vs. being worked; is the worker keeping up? Latency — how long jobs take, and how long they wait before a worker picks them up. Worker liveness — are your workers actually alive and heartbeating? Where to read them RQ exposes queue and registry state directly: from redis import Redis from rq import Queue from rq.registry import FailedJobRegistry , StartedJobRegistry redis = Redis () q = Queue ( " default " , connection = redis ) queued = len ( q ) # backlog failed = FailedJobRegistry ( queue = q ) # failures started = StartedJobRegistry ( queue = q ) # in-flight print ( " queued: " , queued ) print ( " failed: " , len ( failed )) print ( " started: " , len ( started )) Poll this on an interval and store the series — a single snapshot hides the trend , which is the part that matters. For failures specifically, walk the registry to get the actual exceptions: for job_id in failed . get_job_ids (): job = q . fetch_job ( job_id ) print ( job . id , job . exc_info . splitlines ()[ - 1 ] if job . exc_info else "" ) Two gotchas: Group by exception, not by job. A thousand jobs failing with the same traceback is one incident. Normalize the message (strip IDs, timestamps, host

Why this series I love writing clean architecture . Not because it looks nice in a diagram, but because it survives change — new requirements, new team members, and now, AI-assisted development , where you want boundaries an AI can respect and tests that catch it when it wanders. The problem in most Flutter stacks is the seam between app and backend. You write Dart on the client, then switch to a different language, a hand-written REST layer, DTOs that drift out of sync, and serialization bugs nobody notices until production. Serverpod removes that seam. You write Dart on the server too, and the client-server communication code is generated for you — type-safe, end to end. What is Serverpod? Serverpod is an open-source backend framework that lets you build the entire stack in Dart. Instead of context-switching between languages, your models, your API, and your database logic all live in one language. What you get out of the box: Endpoints — server methods your Flutter client calls directly. The communication code is generated, so there's no hand-written REST/JSON glue. An ORM — type-safe, statically analyzed database access with migrations and relationships. No raw SQL required. Code generation — define a model once; get serialization and client bindings on both sides automatically. Real-time data — streaming over WebSockets, managed for you. Auth — integrations for Google, Apple, and Firebase. The extras enterprises actually need — file uploads, task scheduling, caching, logging, and error monitoring. And on the "is this serious enough for production?" question: Serverpod says it's battle-tested in real-world apps and secured by over 5,000 automated tests, scaling from hobby projects to millions of users without code changes. That's exactly the property you want in an enterprise foundation. The architecture at a glance Here's how the pieces fit. A Serverpod project is generated as three packages: myapp_server → your backend: endpoints, models, business logic, DB my

If you've ever built a search endpoint, you've hit this wall. Your query has filters, sort orders, a nested set of facets, maybe a geo bounding box. It doesn't fit in a URL, and cramming it into query string params is ugly and fragile. So you reach for POST /search , send the whole thing as a JSON body, and quietly accept that you've just lied about what the request does. It's not creating anything. It's a read. But POST is the only tool that lets you attach a body without fighting the platform. That gap finally got filled. In June 2026 the IETF published RFC 10008 , which defines the HTTP QUERY method: a new verb built for exactly this case. The two bad options Every read that needs structured input has been stuck choosing between GET and POST, and both are wrong in their own way. GET is the semantically correct choice. It's safe (the client isn't asking to change anything), it's idempotent (retrying it is fine), and it's cacheable. The problem is the body. RFC 9110 is explicit that content in a GET request has no defined semantics , and sending one may cause some implementations to reject the request. So your query has to live in the URI, where you run into unknown length limits across proxies and servers, encoding overhead, and the query landing in access logs and browser history. POST solves the body problem and creates a new one. It carries any payload you want, but it's neither safe nor idempotent by definition. Intermediaries won't cache it, clients won't retry it automatically after a dropped connection, and anything inspecting traffic has to assume the request might have side effects. You get the body, you lose everything that made the request honest. QUERY is the missing third option: a method that carries a body and keeps the semantics of a read. What QUERY actually is The spec, authored by Julian Reschke, James Snell , and Mike Bishop, describes it in one sentence: A QUERY requests that the request target process the enclosed content in a safe and idempo

Most AI incidents don't happen because the model gave a bad answer. They happen because nobody was...

Banking software cannot afford to be casual about anything. Every transaction needs to be verified, logged, protected from tampering, and traceable if something goes wrong. This is exactly the kind of environment where NestJS quietly shines, since its architecture was built around structure and discipline from the start, not added on as an afterthought. Financial institutions and fintech companies increasingly choose NestJS for banking applications, investment platforms, and trading systems, largely because it gives teams a consistent, testable structure for handling something as sensitive as money moving between accounts. Here is what that actually looks like underneath. Why structure matters more in banking than almost anywhere else In most applications, a messy folder structure or inconsistent error handling is annoying. In a banking application, it is a liability. If five different developers write five different ways of validating a transaction, you end up with five different ways something could slip through unnoticed. NestJS solves this by enforcing a consistent pattern across the entire application, modules, controllers, providers, all following the same shape no matter who wrote them. A new developer joining a banking backend built with NestJS already knows where to look for validation logic, where authorization happens, and where a transaction actually gets processed, because the framework itself dictates that structure. Guards, the first line of defense Every request that touches a bank account should be verified before it does anything else. NestJS handles this through guards, which run before a request ever reaches your actual business logic. @ Injectable () export class TransactionAuthGuard implements CanActivate { canActivate ( context : ExecutionContext ): boolean { const request = context . switchToHttp (). getRequest (); const user = request . user ; if ( ! user || ! user . isVerified ) { throw new UnauthorizedException ( ' Account verification req

I had a /image endpoint capped at 3 requests per minute. Simple express-rate-limit, keyed by IP,...

Meses atrás eu estava fazendo uma varredura de segurança no sistema multi-tenant da minha empresa, procurando vulnerabilidades. Afinal, já é um sistema que conta com diversos usuários e que a cada mês vem crescendo mais. Cyber security não é a minha área, então pedi um relatório com todos os achados pro nosso querido amigo Fable 5. O primeiro item veio destacado em vermelho, caixa alta, com a categoria mais grave possível: BOLA (Broken Object Level Authorization). Eu nunca tinha visto esse termo, e ele estava registrado como uma falha grave que eu nem sabia que existia. O sistema nasceu antes do advento da IA escrever código do jeito como faz hoje. Começou comigo codando na mão; meu foco era fazer funcionar para melhorar depois. Com a chegada da IA, parei de escrever código e passei a revisar e garantir qualidade. Só que, naquele relatório, eu não entendia metade dos erros listados. Não conhecia os nomes e muito menos sabia por que eram tão graves. E aí me caiu a ficha: eu sou um legítimo impostor. (Pelo menos era o que eu pensava e sentia.) Escrever código era onde eu sentia o esforço, a prova concreta de estar construindo algo com a minha criatividade. Como o Brooks escreve em O Mítico Homem-Mês: "a programação é divertida, porque satisfaz anseios criativos acalentados profundamente dentro de nós". Minha prioridade era resolver o problema, mas, pra resolver, eu tinha que entender onde estava pisando. O que é esse tal BOLA, e por que é tão grave? Este artigo é o que eu descobri. O que é BOLA A OWASP, que mantém a lista das falhas de segurança de API mais críticas, coloca o BOLA em primeiro lugar no ranking de 2023: a mais comum e a mais fácil de explorar. Ou seja, está em todo lugar e não exige um gênio pra abusar. A ideia central é simples. Toda vez que uma API recebe o ID de um objeto e faz alguma coisa com ele, seja POST, GET, DELETE ou o que for, ela precisa checar uma pergunta antes de responder: o usuário logado tem permissão pra acessar este objeto específic

Every application we use today—from banking apps to social media platforms—has something working behind the scenes. That hidden engine is called the backend. The backend is responsible for processing requests, storing data, handling authentication, enforcing business rules, and ensuring everything works as expected when users interact with an application. One of the first decisions backend developers make is choosing a framework. A framework provides the tools, structure, and best practices needed to build applications faster and more securely. Today, let's look at three popular backend frameworks: Django, Gin, and Ruby on Rails. Django (Python) Django is one of the most mature and feature-rich backend frameworks available. Built using Python, it follows the philosophy of "batteries included." This means many features developers need are already built into the framework, including: User authentication Admin dashboard Database ORM Security protections URL routing Form validation Because so much comes ready to use, developers can spend more time solving business problems instead of rebuilding common features. Best for: Content management systems E-learning platforms Business applications APIs Startups building products quickly Advantages: Fast development Excellent security features Large community Extensive documentation Scales well for many applications Trade-offs: The framework includes many components, so it can feel heavier than minimalist frameworks. Gin (Go) Gin is a lightweight web framework built for the Go programming language. Unlike Django, Gin keeps things minimal. It gives developers speed and flexibility while letting them choose many of the additional tools they want to use. One reason many developers enjoy Gin is its impressive performance. Since Go is a compiled language designed for concurrency, Gin can efficiently handle many requests simultaneously while using relatively few system resources. Best for: REST APIs Microservices High-performance syst

This is my first post here, so I'm going to use it as an introduction. I'm Usman, a software + data engineer who primarily works with data pipelines, backend systems. Not a huge fan of frontend development though. Although I do what I can, projects honestly feel incomplete without them, because at the end of the day you do have to showcase a working end to end system when you build something. I'm here after dozens of incomplete personal projects, and projects that never even got past the design phase, you know the drill. Procrastination and imposter syndrome kept stopping me from taking the next step, but I'm here now, gotta keep myself in check fr. I was scrolling through LinkedIn the past few days, and oh my god, the amount of AI-related brain rot there. Every single post written by AI, telling you how to use AI and how not to use AI. I mean I get it, yeah, the paradigm is shifting and AI is essential to development, but where are your personal anecdotes, stuff you solved, stuff you learned, the challenges you faced, how you overcame them. You know what maybe it's my fault, it's my algorithm after all. Anyway, here I am, looking to interact with like-minded engineers and learn from them. I'm also going to post regularly about my progress and what I am building, even though I have quite a bit of experience, and have built and contributed to large-scale production systems and pipelines, I'm going to start with something small, so I can stay consistent and keep myself in check. Software engineering fascinates me a lot, and there are so many domains that I wish to explore and have explored like game development, data engineering, web/app development. My significant other is graduating in a few days, and I'm thinking of making a small game for her, alongside which I'll be working on a small sales lead enrichment pipeline. Hoping to showcase my work and document it publicly, and hoping to get to know and learn from you all! Also, I'd love to know your thoughts on the am

Second in a series on using AI to review authorization — not to spray reports. Companion reference: AuthZ Smell Catalog . 1. Why AuthZ review is not vulnerability spraying The cheapest thing an AI can do in security is generate suspicion. Point a model at a codebase and it will hand you fifty "possible IDORs" before you finish your coffee. Almost all of them are wrong — guarded three lines up, scoped at the data layer, or protected at a boundary the model never saw. That flood is exactly why several bug bounty programs spent 2026 tightening or pausing: they were drowning in confident, plausible, wrong reports. So this review inverts the usual loop. The AI's job is not to find bugs — it is to over-generate hypotheses cheaply . My job is to kill them. What survives that killing is the only thing worth a human's time, and the record of what died is more useful than the record of what lived. The artifact of an honest review is therefore not a finding. It's a kill table . 2. Target and scope Target: Ory Kratos — an open-source identity and user-management server (login, registration, recovery, verification, sessions, self-service settings). Source-available, Apache-2.0. Why Kratos: it is exactly the shape where authorization goes wrong — multiple identities, a public API and an admin API, and (in Ory's hosted product) multi-tenancy. If a boundary is fragile, this is where it shows. Scope of this write-up: source reading only , on the public repository, single-tenant OSS build. No hosted target was touched. Nothing here is an undisclosed finding — the point is the method and the boundary design , and where relevant, how the design held against the hypotheses I tested. This maps to the reproduction tiers we track: everything below is repo_only , and I say so explicitly rather than implying it reaches a live product. What this review does and does not claim. In this limited, repo-only review, the hypotheses I tested were killed. This is not a claim that Kratos has no vulner

Cuando un SaaS quiere recuperar usuarios de prueba que se quedaron a medio camino, casi siempre empieza por email. El problema es que una sola prueva mal hecha puede mezclar cohortes, disparar métricas falsas y dejar a marketing discutiendo con backend sobre datos que nunca fueron confiables. Ese tipo de campaña merece más cuidado del que parece. A simple vista solo hay que revisar asunto, CTA y enlace final, pero en la práctica también hay que comprobar segmentación, ventanas de tiempo, estados de cuenta y eventos analíticos. Si alguien en tu equipo busca cosas como facebook temp email para crear usuarios rápidos, en el fondo está intentando resolver eso: probar sin tocar bandejas reales ni contaminar reportes. Por qué los correos de reactivación confunden más de lo que ayudan Un correo de reactivación no se envía a cualquiera. Sale cuando una persona creó cuenta, probó algo, se quedó quieta y entra en una regla específica. Si esa regla se valida con datos sucios, el equipo termina optimizando un mensaje para usuarios equivocados. En SaaS esto pega fuerte porque marketing y producto suelen mirar la misma campaña con preguntas distintas. Marketing quiere saber si el copy reabre interés. Producto quiere saber si el usuario vuelve al flujo correcto. Backend quiere confirmar que la automatización no reenvía a quien ya convirtió. Cuando esas capas no se prueban juntas, aveces el correo “funciona” y aun así el experimento sale mal. Si ya estás ordenando tus pruebas de onboarding en SaaS , el siguiente paso natural es tratar la reactivación como un flujo distinto. Tiene otra intención, otra ventana de tiempo y otro riesgo de mezclar datos. Paso a paso para probar una campaña sin mezclar cohortes La forma más segura es preparar un escenario por cohorte. En vez de mandar varios usuarios de prueba al mismo inbox, creá un usuario, asignale una condición clara y validá un solo recorrido de punta a punta. Este proceso suele ser suficiente: Crear una cuenta de prueba que realmen

Book: The Complete Guide to Go Programming Also by me: Hexagonal Architecture in Go — the companion book in the Thinking in Go series My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub You are wiring an HTTP router. You have a Server struct with a handler method, and you want to register it. So you write mux.HandleFunc("/users", srv.ListUsers) and it works. You never stop to ask what srv.ListUsers actually is as an expression. It is a method value. Go took the method, bound it to srv , and handed you back a plain func(http.ResponseWriter, *http.Request) . That binding is the thing doing the quiet work in half the handler wiring you write. There is a second form the Go spec gives you, and most Go developers never type it on purpose: the method expression, Server.ListUsers , which produces a function that takes the receiver as its first argument. Same method, different shape, different use. These two live in the Go spec and they are worth telling apart, because the compiler will happily let you reach for the wrong one. The two forms, side by side Start with a small type and one method. type Greeter struct { prefix string } func ( g Greeter ) Say ( name string ) string { return g . prefix + " " + name } A method value binds the receiver now: g := Greeter { prefix : "hello" } say := g . Say // method value, receiver g is captured fmt . Println ( say ( "ana" )) // "hello ana" say has type func(string) string . The receiver is gone from the signature because Go already stored g inside the closure. Call it later, from anywhere, and it still remembers g . A method expression leaves the receiver open: say := Greeter . Say // method expression, no receiver yet fmt . Println ( say ( g , "ana" )) // "hello ana" say here has type func(Greeter, string) string . The receiver became the first parameter. You supply it at the call site, every time. Same method name. g.Say reads the value g ; Greeter.Sa

Key Takeaways Oracle Backend for Microservices and AI 2.1.0 is a platform modernization release. It updates several shared backend concerns at once, including external access, observability, configuration, messaging, database deployment choices, workflow, samples, enterprise installation planning, and upgrades. Gateway API and Envoy Gateway are now the default external access direction. NGINX Ingress Controller is deprecated, disabled by default, and still available only when explicitly enabled. The release gives platform teams clearer building blocks. OpenTelemetry Operator, Java auto-instrumentation, Spring Config Server, Kafka through Strimzi-managed resources, and clearer database deployment choices supported by Oracle AI Database Operator for Kubernetes make important platform choices easier to see and discuss. Enterprise adoption still needs architecture review. Before adopting or upgrading, teams should review private registry needs, air-gapped installation requirements, multi-tenant installation goals, workflow implications, database deployment choices, and upgrade readiness. OBaaS 2.1.0 is a platform modernization release Oracle Backend for Microservices and AI , or OBaaS , is a backend-as-a-service style platform for teams building microservices and AI-enabled applications with Oracle AI Database as a core data foundation. It brings common backend platform concerns together: service access, telemetry, configuration, messaging, workflow, and database connectivity. That matters because most teams do not want every application squad to rebuild those pieces on its own. They want a platform shape that gives developers useful defaults while still giving architects, DBAs, security teams, and operators the control points they need. This article focuses on the Oracle Backend for Microservices and AI 2.1.0 update. The best way to read OBaaS 2.1.0 is not as a single-feature release. It is a platform modernization release. The update moves the default external access

SokoFlow Build Log — Month 1 of 4 Last semester I set out on a new strategic plan to level up my software development skills through deliberate, project-based learning. That work produced one of the most ambitious things I've built so far: Sim-Pesa , a local-first transactional appliance that lets developers working in the M-Pesa ecosystem test and simulate STK Push workflows entirely on their own machines, without depending on the Daraja sandbox. I documented that build in 16 weekly posts, which you can find here . This semester, the focus shifts — from fintech foundations to cloud-native integration and real-world systems. The flagship project is SokoFlow , a conversational ERP for small Kenyan shopkeepers to track inventory and record sales entirely through WhatsApp chat. No app to download, no training session required — just natural language. Where Sim-Pesa lived in a controlled, predictable transactional world, SokoFlow steps into the mess of cloud-native reality: third-party API failures, webhook signature verification, the statelessness of HTTP, and container orchestration. The target audience shifts too — Kenyan SMEs operating on infrastructure that is often unreliable by design, not by exception. It's an ambitious project, but the goal was always to learn as much as possible from it. With the plan in place, I got to work. 1. The Vision of a Headless ERP The first real question I had to answer before writing a line of code: what does "headless" actually mean? Headless architecture decouples the frontend — the "head," or user interface — from the backend, the "body" that holds the data and business logic. A conventional ERP bundles both: backend plus a dashboard or UI on top. A headless ERP, by contrast, is just the engine. The brain. There's no built-in screen. So how do users interact with a system that has no interface of its own? SokoFlow doesn't actually care. It could be: WhatsApp SMS A web app A mobile app A voice assistant In this case, the "frontend

Hello Dev Community! 👋 It is officially Day 89 of my 100-day full-stack engineering run! 🎯 Yesterday, I kicked off my competitive solving streak on HackerRank. Today, I advanced from standard linear filters into the powerful world of textual pattern recognition by mastering: SQL Regular Expressions (REGEXP) and String Anchors! 🔍🛡️ When processing real-world data pipelines—like validating structured phone inputs, email domains, or parsing specific text queries—standard LIKE operators can make your code messy and repetitive. Today, I solved these constraints elegantly. 🧠 Shifting from Bulky LIKE Statements to Sleek REGEXP As tracked inside my workspace files across "Screenshot (193).png" and "Screenshot (195).png" , I solved two distinct core challenges from the HackerRank series: 1. Match from the Start: Weather Observation Station 6 The Goal: Query the list of CITY names from STATION that start with vowels ( a , e , i , o , u ), ensuring no duplicates are returned. The Evolution: Instead of chaining multiple LIKE queries or cutting sub-strings with LEFT() , I utilized the caret anchor ( ^ ) inside a regular expression array to verify the string's starting boundary instantly: sql SELECT DISTINCT CITY FROM STATION WHERE CITY REGEXP "^(A|E|I|O|U)";