Prisma

TypeScript in Production: Architecture, DDD and design patterns in real TypeScript Have you heard of the SOLID principles? Domain Driven Design, or design patterns in general? Probably, but how often do you see them in real-world TypeScript? We’re bringing together experts to share their experience writing durable, maintainable TypeScript projects. We’re not here for a CompSci lecture, we’re here to look at real code that shipped to production and learn from each others’ hard-won lessons. In our upcoming meetups we’ll look at different topics each time, grounded in reality, with techniques and snippets you can walk away from and try in your projects. Since this is 2026, we’ll also look at how these practices make working with AI safer and more effective. When an LLM is a significant contributor to your project, and changes ship fast, good architecture is what separates a spaghetti-code mess from a healthy, maintainable codebase. Some topics we’ll look at include: - SOLID principles - Clean / Hexagonal architecture, Ports and Adapters - Domain-Driven Design - Unidirectional dependencies in monorepos - and more We’ll release a specific agenda once the speakers are confirmed. Do you have experience you can share? Register to present! We’re eager to share how we apply these principles at Prisma, but the best meetups hear from people with totally different projects and constraints. Never spoken before? No worries! We’ll help you get started. Signup form link in comments below, or DM me if you’re interested. #TypeScript #developer #meetup #berlin #architecture #learning #community

I first got interested in Bloom filters because I thought they had something to do with flowers. Spoiler alert: "They don't". But they turned out to be one of the coolest data structures I’ve learned about. It's tiny, fast, probabilistic, and surprisingly practical. A Bloom filter can tell you two things: “This item is definitely not present." or “This item is probably present.” That “probably” is the important part. Bloom filters trade exactness for size, which makes them useful when a small chance of false positives is acceptable. Then I found out Postgres has a Bloom index 🤯 A Bloom index can be useful when you have wide tables with many equality filters, and you don’t want to maintain a stack of B-tree indexes for every possible query shape. In the post, I compare one Bloom index against six B-tree indexes on a realistic cache table. The Bloom index was about 60% smaller while still covering the same equality lookup patterns. The tradeoff is that Postgres has to recheck matching rows, because Bloom indexes can produce false positives. I wrote an interactive post that explains the following: * what a Bloom filter is * why false positives can be okay * how Postgres turns the idea into an index * how it compares with B-trees * when Bloom indexes are useful * when you should avoid them Read it here: https://lnkd.in/dXjicErs I’m planning to write more posts like this on underrated Postgres features and database architecture tradeoffs. What should I cover next? 👀