Featured Issues

Crafting the Web: Tips, Tools, and Trends for Developers Advertise with Us|Sign Up to the Newsletter @media only screen and (max-width: 100%;} #pad-desktop {display: none !important;} } @media only screen and (max-width: 100%;} #pad-desktop {display: none !important;} } WebDevPro #126 Using AI in Development Without Losing Architectural Control Crafting the Web: Tips, Tools, and Trends for Developers Webinar: How to Build Faster with AI Agents Learn how full‑stack developers boost productivity by 50% with AI agents that automate layout, styling, and component generation through RAG and LLM pipelines. See how orchestration and spec‑driven workflows keep you in control of quality and consistency. Save your seat! Welcome to this week’s issue of WebDevPro. If you’ve written any meaningful amount of code recently, AI is already part of your workflow. It finishes your lines, scaffolds components, suggests refactors, and removes a lot of the friction from day-to-day implementation. At the same time, more teams are shipping AI-powered capabilities directly into their products. The productivity gains are real. Development moves faster. Experimentation becomes easier. But speed introduces a structural question that doesn’t get talked about enough. When implementation becomes this easy, AI can start shaping architecture by default. Not through dramatic failures, but through small decisions that slip in unnoticed. A suggestion becomes a pattern. A pattern becomes the norm. Over time, structure starts drifting, responsibilities blur, and the codebase becomes harder to reason about. This piece looks at how to prevent that. We’ll look at practical ways to keep architectural control while still using AI heavily: how to set guardrails before generating code, where AI logic should live once it becomes part of your product, and what to review so “correct” output doesn’t slowly weaken your design. AI should accelerate implementation, not quietly define structure or responsibility. When Implementation Speed Becomes the Default When AI integrates into the development environment, the nature of coding changes. Developers move from writing every line manually to reviewing and selecting generated suggestions. That shift is efficient, but it also changes what drives consistency in a codebase. Suggestions are generated from generalized patterns. They can be correct, but correctness is not the same as architectural alignment. A project’s structure depends on decisions that hold across features, not on what looks plausible inside a single file. Encode Guardrails Before You Generate One practical way to preserve architectural control is to define expectations before generation. In practice, this means writing down the constraints that matter in your codebase so the assistant consistently reinforces them. For example, a strong instruction set begins by defining the development role clearly: You are an expert in TypeScript, Angular, and scalable web application development. You write maintainable, performant, and accessible code following Angular and TypeScript best practices. From there, it becomes easier to add concrete constraints that prevent structural drift. Even a small rule can make a difference, such as discouraging weak typing: Avoid the any type; use unknown when type is uncertain This kind of guidance does not guarantee perfect output. It does something more important: it keeps the assistant working within a defined standard instead of inventing one through suggestion. When AI Becomes Part of the Application The architectural stakes rise when AI is not only assisting development but also powering feature behavior. At that point, the questions are no longer about scaffolding. They become questions of placement, responsibility, and cohesion. One useful pattern is to configure AI behavior deliberately through a system instruction and then route all interaction through a structured interface. Example model configuration and system instruction: const instructions = ` Welcome to citypass. You are a superstar agent for this car parking validator. You will assist users by submitting parking tickets. You can convert date phrases to ISO strings and act as a geocode service to convert a location or address to coordinates long/lat. `; const ai = getAI(firebaseApp); const model = getGenerativeModel(ai, { model: 'gemini-2.5-flash', systemInstruction: instructions, tools: [toolset] }); this.chat = model.startChat(); This approach makes two architectural decisions explicit. First, AI behavior is constrained by a clear instruction. Second, interaction happens through a controlled interface instead of being scattered across unrelated parts of the application. A Practical Boundary: UI for Input, Services for Processing When AI is exposed to users, architectural control often comes down to a simple boundary. The UI collects input and shows results. The AI processing stays encapsulated behind an interface that can be tested and evolved. A clean example is offering an “AI Creator” entry point near an existing workflow, opening a modal to capture a prompt: Ticket creation flow with an AI Creator entry point used to capture user input for AI-assisted ticket creation. AI Creator button and modal markup: <button nz-button nzType="link" type="button" (click)="isVisible.set(true)" >AI Creator </button> <nz-modal [(nzVisible)]="isVisible" nzTitle="AI Creator" (nzOnCancel)="isVisible.set(false)" (nzOnOk)="ok()"> <ng-container *nzModalContent> <textarea [(ngModel)]="prompt" rows="3" placeholder="Enter ticket details" nz-input> </textarea> </ng-container> </nz-modal> This interface design matters because responsibility stays clear. The component manages interaction and user input. The AI-driven work happens only when the user explicitly triggers it, and the application can decide where that processing belongs. The Drift Risk: Structure by Convenience AI rarely causes dramatic architectural failures. The more common risk is incremental drift. A generated approach is accepted, then repeated, and then becomes the default. Over time, similar features are built with slightly different patterns, responsibilities move across layers, and ownership becomes less obvious. This is why the guiding principle needs to be visible early in the workflow: AI should accelerate implementation, not make architectural decisions. Maintaining Architectural Control Architectural control in an AI-assisted workflow comes from a small set of repeatable practices: Define expectations before generation so the assistant reinforces standards Encapsulate AI-enabled behavior behind clear interfaces Review generated code for placement and responsibility, not only for correctness These practices keep speed from rewriting structure. Final words AI can absolutely increase velocity. It can also unlock product capabilities that would have been expensive or slow to build even a year ago. But long-term maintainability still comes down to structure. The difference is that AI changes how structure gets created. It can reinforce good decisions, or it can quietly introduce new patterns through convenience, repetition, and speed. That’s why boundaries matter. When they’re clear, AI becomes a multiplier for discipline. When they’re loose, drift becomes the default. AI should accelerate implementation, not quietly define structure or responsibility. Architectural control isn’t about resisting AI. It’s about staying deliberate while moving fast. Want to learn more? Get your copy of Angular Projects, 4th Edition now! This Week in the News 🧩TypeScript 6.0 beta and roadmap shift: TypeScript 6.0 beta introduces incremental improvements across type checking and configuration while laying groundwork for the long-discussed native rewrite in Go that promises serious performance gains. The team is clearly thinking beyond syntax tweaks and focusing on compiler architecture, which signals that large codebases and build speed are now central to the TypeScript story. For teams pushing monorepos or heavy CI pipelines, this roadmap matters more than any single feature flag. 📊 State of JavaScript 2025 survey results: The State of JavaScript 2025 survey provides a broad snapshot of how developers are working across the JS ecosystem. TypeScript continues to see strong adoption, reinforcing its position as a standard part of modern JavaScript development. In tooling, newer build systems and faster runtimes are gaining momentum, reflecting a clear preference for performance-focused developer experience. The survey also compares usage, satisfaction, and interest across frameworks, testing tools, browser APIs, and runtimes, highlighting which technologies feel stable and which are generating curiosity. Overall, the results show an ecosystem that is maturing around modern defaults while steadily evolving toward faster tooling and more streamlined workflows. ⚛️ State of React 2025: The State of React 2025 survey offers a data-backed look at how developers are building with React today. Core tooling remains strong: Next.js, React Router, and Redux continue to see widespread usage, while TanStack Query and Axios are common choices for data handling. On the build side, Vite has emerged as the dominant tool, reflecting the ecosystem’s shift toward faster development workflows. UI libraries like MUI and shadcn/ui show meaningful adoption, and modern state solutions such as Redux Toolkit are preferred when external state is needed. The results also highlight a practical trend: many teams still rely primarily on built-in React APIs for state management, reaching for external libraries only as complexity grows. Beyond the Headlines ⚡Running Next.js at Enterprise Scale:Next.js scales well, but enterprise usage needs more than default settings. This piece breaks down what changes when you’re running Next.js under real traffic: defining clear SLOs/SLAs, instrumenting performance monitoring, and understanding the framework’s request lifecycle so you can spot bottlenecks early. It also highlights practical architecture choices like using CDNs and caching effectively, picking the right rendering strategy (SSG vs SSR) per route, and planning for horizontal scaling with shared caches and load balancing. 🐢 Is Claude Code losing its engineering edge:This post critiques recent shifts in Claude Code’s behavior, arguing that guardrails and simplifications are reducing its usefulness for experienced developers who value precision and depth. It reflects a broader tension in AI tooling between safety, accessibility, and raw capability. For developers relying on AI as a serious engineering assistant, subtle model behavior changes can have an outsized impact on trust and workflow. 🧭 Debugging workflows that actually benefit from AI: An exploration of AI-assisted debugging workflows that break down how you can leverage models to trace issues, interpret stack traces, and accelerate root-cause analysis without feeling like you’re guessing at prompts. ⚛️ React Server Components performance insights: This piece examines how React Server Components behave in real world performance scenarios, moving past high level explanations to measure tradeoffs in rendering, hydration, and network boundaries. It challenges simplistic assumptions about automatic speed gains and highlights where architectural decisions still matter. For teams evaluating RSC adoption, the nuance here is critical before refactoring large parts of an app around the paradigm. Tool of the Week 🌀🛠️ OpenClaw — The AI Agent That Does Work for You OpenClaw is an open-source autonomous AI agent that goes beyond chat: it can execute real tasks like managing email, calendars, messaging apps, and other workflows by integrating with platforms such as WhatsApp, Telegram, and Slack. Developed by Austrian engineer Peter Steinberger, it grew from an experimental project into one of the fastest-adopted agent tools in the community because of its ability to act instead of just respond. Since its introduction in November, OpenClaw has seen a viral rise, surpassing 100,000 stars on GitHub and attracting 2 million visitors in a single week, signaling strong developer curiosity around agent-based systems. This week, OpenClaw made headlines when creator Peter Steinberger announced he’s joining OpenAI. Sam Altman highlighted Steinberger’s expertise in multi-agent systems as strategically important for building the next generation of personal AI assistants, and OpenClaw will continue as an open-source foundation supported by OpenAI. This move signals how quickly agent-centric tooling is becoming a central focus for major AI platforms. For anyone interested in trying OpenClaw yourself or seeing it in action, this tutorial walks through setup and use:📺 OpenClaw Full Tutorial for Beginners. That’s all for this week. Have any ideas you want to see in the next article? Hit Reply! Cheers! Editor-in-chief, Kinnari Chohan SUBSCRIBE FOR MORE AND SHARE IT WITH A FRIEND! *{box-sizing:border-box}body{margin:0;padding:0}a[x-apple-data-detectors]{color:inherit!important;text-decoration:inherit!important}#MessageViewBody a{color:inherit;text-decoration:none}p{line-height:inherit}.desktop_hide,.desktop_hide table{mso-hide:all;display:none;max-height:0;overflow:hidden}.image_block img+div{display:none}sub,sup{font-size:75%;line-height:0}#converted-body .list_block ol,#converted-body .list_block ul,.body [class~=x_list_block] ol,.body [class~=x_list_block] ul,u+.body .list_block ol,u+.body .list_block ul{padding-left:20px} @media (max-width: 100%;display:block}.mobile_hide{min-height:0;max-height:0;max-width: 100%;overflow:hidden;font-size:0}.desktop_hide,.desktop_hide table{display:table!important;max-height:none!important}} @media only screen and (max-width: 100%;} #pad-desktop {display: none !important;} } @media only screen and (max-width: 100%;} #pad-desktop {display: none !important;} }

Our Inside Data Engineering Newsletter gives data engineers and practitioners what they often lack today: clear, real-world insights—where every byte tells a story.Subscribe here to stay ahead in data engineeringIntroductionIn modern analytics environments, few modeling challenges are as important or as misunderstood as Slowly Changing Dimensions (SCDs). Business attributes do not stand still. Customers change status, relocate, upgrade tiers, and evolve over time. The real challenge is not just recording those changes. It is preserving the right version of history so that facts remain analytically correct.In Snowflake-powered data warehouses, modeling dimensions properly means balancing performance, maintainability, and historical accuracy. Should attributes be overwritten, versioned, split into mini-dimensions, or tracked with effective dates and surrogate keys?This article explores the full spectrum of SCD strategies from Type 0 through Type 7 using a practical CUSTOMER example. You will see how different change-tracking techniques impact reporting, how surrogate keys and validity intervals maintain point-in-time accuracy, and how Snowflake-native features can be used to implement these patterns efficiently.If you would like to follow along, the scripts used in these examples are available here: https://github.com/PacktPublishing/Data-Modeling-with-Snowflake2E/tree/main/ch14Dimensions overviewA dimension unifies (or conforms) similar attributes from one or various source systems into a single table under a common unique identifier known as a business key. A single surrogate key can also be used in place of multi-column business or primary keys. The unique key of a dimension table plays a critical role in identifying dimension records and allows the database team to track and maintain changes over time. A dimension table can be structured in predetermined ways to allow for different types of change tracking depending on the business requirement.SCD typesAttributes within a dimension have differing requirements for durability and change tracking. Some attributes are updated directly, while others require historical snapshots, yet others cannot change at all. This section will cover the types of SCDs, or update profiles, that a given attribute in a dimension can have.It’s important to note that the dimension type may not necessarily apply across all dimension attributes equally. Within the same dimension table, some attributes may be overwritten while others may not. By understanding SCD types and when to use them, database developers can implement the proper table structure and update techniques to satisfy the organization’s reporting and analytics requirements.Example scenarioTo explain the various SCD types, we will use a simplified CUSTOMER dimension as an example and track the change as it would appear under each configuration.Suppose our fact table stores order details from customer X, made on the first of every month in2022. Thanks to X’s patronage, their customer status went from new to active midway through the year. Not only do we want to track when the change occurred but we want to tie the correct status to the recorded sales facts (that is, the customer is active today, but half their orders were made with a status of new).The change in customer status is displayed here as it currently appears in the source system and data warehouse landing area:Figure: A changed record in the source system and data warehouse raw schema With this scenario in mind, let’s explore the SCD types.Type 0: Maintain originalIronically, the first SCD—Type 0—does not change. Type 0 dimensions are intended for durable attributes that cannot change due to their business nature. Examples of Type 0 attributes include birth dates, calendar dates, and any attribute recorded at record creation that needs to be tracked as a baseline, such as original price, weight, or date of first login.Type 1: OverwriteType 1 attributes do not require historical tracking and may be directly overwritten with an UPDATE statement. Sometimes, the latest attribute value is all that the business cares about. For example, our organization demands the latest customer status, and previous values are irrelevant. Maintaining a Type 1 dimension is relatively simple—for example, if the status changes, it is updated directly in the customer dimension, as illustrated here:Figure: New updated for STATUS change in a Type 1 SCDHowever, overwriting values is often not enough—a historical value must also be preserved.Type 2: Add a new rowFor some attributes, an organization must register the latest value and maintain prior historical records. Type 2 attributes generate a new row every time a change is recorded. Generating new rows for a given business key means that uniqueness is violated unless a time dimension (the effective date) is added to the primary key. The effective date of a Type 2 SCD not only separates historical values for a given business key but also allows those records to be tied to fact tables at a given point in time.Maintaining a Type 2 SCD requires creating new rows when record changes are detected and additional metadata columns to track them. A single record in our example would generate the following change in a Type 2 table:Figure: New row generated for a change in a Type 2 SCDThe following metadata fields make working with Type 2 attributes easier:Validity intervals: Because the business key is being duplicated with each change, another column must be added to the primary key to maintain uniqueness. Validity intervals (also named valid_from/to, start/end_date) provide the additional unique value for the primary key and timestamp when the change occurred, allowing facts to be linked with the correct point-in-time dimension value. The TO_DATE column also provides a flag for identifying the latest record using the standard surrogate high date of 9999-12-31.Hash: Using a hashing function, such as MD5, provides a quick and standard way to identify when record changes occur. This concept is borrowed from Data Vault (discussed in Chapter 18, Scaling Data Models Through Modern Techniques). When there are many Type2 attributes in a table, instead of checking for changes one by one, hash all of them into a single column and compare them in a single go, as follows:Create the hash field: SELECT MD5 (Col1 || Col2 || ... || ColN) AS hashCompare the hash field: IFF(hash_new = hash_old, 'same', 'changed')Type 3: Add a new columnType 3 dimensions track changes by adding a new column to store the previous value when a change occurs. The original column is updated and not renamed to avoid breaking any existing downstream references. An effective date metadata column records the time of the change, allowing analytics processes to use the new or historical value based on their validity period.An example of a status update in a Type 3 attribute is given here:Figure: New row column created for a change in a Type 3 SCDAlthough Type 3 is easier to maintain than Type 2, the limitation is storing multiple changes. While Type 2 attributes can change as often as needed, generating new rows each time, Type 3 can only show one change without creating additional columns—not a scalable design if regular changes occur.Type 4: Add a mini dimensionWhen SCDs become quickly changing dimensions—due to rapidly changing attributes—the number of records that Type 2 dimensions generate can cause performance issues. This is especially true with dimensions containing many records—as in millions of rows or more.In a Type 4 scenario, the solution is to split the frequently changing attributes into a separate mini dimension. To further curtail the number of records, the values in the mini dimension can be banded within business-agreed value ranges that provide a meaningful breakdown for analysis. The mini dimension has its own surrogate key and does not contain the main dimension foreign key—allowing both to retain a relatively low cardinality. However, to tie the main dimension to the mini, the mini dimension foreign key must be included in the fact table (as the main dimension appears at the time of the generated fact).On a diagram, the arrangement of a Type 4 dimension would look like this:Figure: A Type 4 SCD on a relational diagramFor our example, the business wants to track the length in months for how long a customer has been active, as well as their total yearly spend at the time of each sale. To avoid generating a record for each month and order placed, the business teams have agreed to group the MONTHS_ACTIVE attribute into two categories (less than or greater than five months) and band the sales volume into three groups. The mini dimension would need to contain every possible (or allowable by existing business rules) combination of groupings.Our example would look like this (notice how the profile ID changes throughout the year as a function of the customer’s attributes):Figure: Mini dimension and foreign key in a fact table in a Type 4 SCDWhile this arrangement satisfies the reporting requirement, bridging dimension tables via a fact encumbers analysis on the dimension itself. To unify the main and mini dimensions into one, a Type 5 SCD is used.Type 5: Type 4 mini dimension + Type 1A Type 5 SCD is an extension of the Type 4 mini-dimension technique—adding the mini-dimension key as a Type 1 attribute in the main dimension (hence the name, 4+1 = 5). This approach affords the performance gains of a Type 4 dimension by avoiding the explosive growth of rapidly changing Type 2 records and gives users a simple way to unify the main dimension with the mini dimension through a common join column.On a diagram, the arrangement of a Type 5 dimension would look like this:Figure: A Type 5 SCD and related view on a relational diagramNotice that to further simplify the user experience, a view is created over the main and mini dimensions to give the users a single entity to work with. Analysis of the fact table becomes more versatile by allowing users to join on one entity (the view) instead of the main and mini dimensions if historical values are not required.The same scenario described in the section on Type 4 would look like this under Type 5:Figure: Mini-dimension and a related view in a Type 5 SCDUnfortunately, Type 4, and by extension, Type 5, suffer from the inconvenience of calculating the mini-dimension value to include it as part of each fact. The performance implications involved in adding the mini-dimension foreign key to the fact table should outweigh the performance gain in reducing the number of dimension records through the use of the mini dimension.Type 6: The Type 1, 2, and 3 hybridA Type 6 SCD is so named because it combines the techniques of Type 1, 2, and 3 (1+2+3 = 6) dimensions into one table. Based on business needs, users will demand different levels of historical values to achieve a balance of detail and flexibility in their analytics.Suppose our customer X from previous examples began to relocate—moving headquarters to Mexico in 2023, then to Brazil in 2024. A Type 6 approach yields a dimension table that gives analysts every possible temporal attribute value in every snapshot: a Type 1 current value, a Type 2 effective dated value, and a Type 3 previous value.To recap the status and country changes mentioned in this example, a snapshot of the source system over time is presented here:Figure: Source system showing changes for customer XIn a business scenario where the customer status needed Type 2 and the country was presented as Type 1, 2, and 3, the resulting table would look like this (the HASH column is now calculated as a function of STATUS and COUNTRY):Figure: Type 1, 2, and 3 columns combine in a Type 6 SCDType 7: Complete as-at flexibilityBusiness users across all cultures and industries have a penchant for changing their minds. The Type 7 approach gives database modelers a way to deliver the needed historical attribute no matter the criteria or temporal reference point requested.A Type 7 dimension (unimaginatively named as the number that follows 6) includes a natural key and a surrogate key in a Type 2 table structure and embeds both in the fact table.A method for generating surrogate keysAn efficient—and data vault-inspired—way to generate a surrogate key for Type 2 records is to use an MD5 hash on the compound primary key (in this example, CUSTOMER_ID and FROM_DATE):SELECT MD5(customer_id || from_date) AS customer_skeyIn a Type 7 configuration, a surrogate key is added to an otherwise Type 2 structure and is embedded in the fact (the latest SKEY as of the creation of each fact record). Based on the example scenario from the Type 6 section, the tables would look like this:Figure: A Type 7 SCD offers complete analytical flexibilityA Type 7 SCD allows business users to select the appropriate customer attributes based on the following criteria:The most recent or current information (that is, TO_DATE = '9999-12-31')The primary effective date on the fact record (that is, LOAD_DATE)When the user changes their mind, any date associated with the fact record (that is, ORDER_ DATE or SHIPMENT_DATE)Here is how those queries might look:--get current SELECT < fact and attribute fields >    FROM order o    INNER JOIN customer c USING(customer_id)    WHERE c.to_date = '9999-12-31' --get dimension values as at the primary effective date on the fact record SELECT < fact and attribute fields >    FROM order o    INNER JOIN customer c USING(customer_skey) --get dimension values as-at any date on the fact record --example will use SHIPMENT_DATE SELECT < fact and attribute fields >    FROM order o    INNER JOIN customer c USING(customer_skey)    AND o.shipment_date BETWEEN c.from_date AND c.to_dateNow that you have a general understanding of the different SCD types, let’s recap before detailing the Snowflake recipes used to construct them.Overview of SCD typesThe following screenshot summarizes the seven SCD types covered in the previous section, including their maintenance strategy and usage. While eight (including Type 0) SCDs may seem like a lot, most database designs rarely go beyond Type 3, as the first four SCD types strike an acceptable balance of performance, maintainability, and historical reporting needs:Figure: A comparison of SCD typesNow, let’s see how to build SCDs with maximal efficiency using Snowflake-specific features.ConclusionSlowly Changing Dimensions are not a one-size-fits-all solution. Some attributes should never change (Type 0), others can be safely overwritten (Type 1), and many require full historical tracking (Type 2). As business complexity grows, hybrid approaches such as Types 4, 5, 6, and 7 offer increasing levels of analytical flexibility. They help organizations answer not only what is true now, but also what was true at the time of each transaction.Choosing the right SCD type is ultimately a business decision supported by sound modeling principles. The goal remains consistent: preserve the integrity of historical analysis while keeping data structures scalable and performant.For a deeper dive into implementing SCDs in Snowflake, including practical SQL recipes, hashing strategies, dynamic approaches, and performance considerations, you can learn more in the book Data Modeling with Snowflake, Second Edition by Serge Gershkovich. Modeling guides are often steeped in theory. This book’s innovative approach combines practical modeling concepts with Snowflake best practices and unique features - allowing you to create efficient designs that leverage the power of the Data Cloud.  Author BioSerge Gershkovich is a seasoned data architect with decades of experience designing and maintaining enterprise-scale data warehouse platforms and reporting solutions. He is a leading subject matter expert, speaker, content creator, and Snowflake Data Superhero. Serge earned a bachelor of science degree in information systems from the State University of New York (SUNY) Stony Brook. Throughout his career, Serge has worked in model-driven development from SAP BW/HANA to dashboard design to cost-effective cloud analytics with Snowflake. He currently serves as product success lead at SqlDBM, an online database modeling tool.