When building a monolith, it’s common to not think much about which service accesses which tables, especially when dealing with complex business logic that needs to conditionally update data based on values of existing data, or if complex data aggregation is needed. To make matters worse, in many projects, not a lot of thought is given to how the database is structured, and it might not actually align well with the business domain (especially if DDD techniques are not followed).

Here's something that might be a bit controversial: I believe that for most software projects, the performance of the language (C#, Golang) doesn't matter that much. The reason I am writing this article is that I've seen an almost cultlike obsession with various languages and tech stacks, to the point where teams are pushing for a complete rewrite of the application. I believe this is not warranted for most projects.

First, when creating a new application, should you start off with a microservice architecture? Well, the prevailing wisdom is no, because there is significant cost associated with maintaining, deploying, hosting., multiple microservices.Let's also look at some microservice tenets: 1. Microservices need to own their own data, which means you need a database for each. 2. Instead of synchronous communication, you usually use message based communication to ensure decoupling.

Gamification is the process of applying game-like elements and mechanics to non-game contexts to enhance user engagement, motivation, and overall experience. It involves incorporating game design elements such as points, badges, leaderboards, challenges, and rewards into non-game activities, such as marketing campaigns, educational programs, workplace training, and even daily tasks. The goal of gamification is to tap into the natural human desire for challenge, competition, and social interaction that we experience when playing games.

The estimation proces and estimation related time pressure are probably some of the most contentious aspects of software development - it is usual for project managers to try to push down initial estimations made by developers, either because of pressure placed on themselves by varios stakeholders or because they know that tasks tend to take up the whole allotted time (because of developer procrastination), or both. To make matters worse, a whopping 70% of projects are considered failures based on initial targets. Even if the teams use agile methodologies, a large number of the sprints will fail to meet their story point target.

CQRS has been popular for quite a few years (more than a decade old at this point), and while it's no longer in the hype phase of adoption, it still gets brought up quite a bit during architectural discussions for new projects (usually in conjunction with microservices). A few years after the pattern became popular, there was mounting criticism against it, mainly because of the complexity it introduces - with critics citing it as a typical example of over-engineering / premature optimization.

Closures are probably one of the most unintuitive features for newcomers to Javascript, especially if they come from languages such as Java or C#. The notion of a function within another function itself isn't hard to understand, the significant hurdle in understanding comes with preserving the lexical environment around these functions once the parent function has finished executing. There are also quite a few articles that use misleading terminology -- for example, context versus execution context, lexical environment versus scope, etc. We'll aim to clarify the terms.

Since a single database server can support a considerable load, it's worth starting off by saying that needing to scale out your database server means your business is doing several things right, so this is a good problem to have. While getting a machine with more processor cores, memory and disk space can alleviate your problems in the short term, at some point needing to distribute your database across multiple machines becomes unavoidable.

When implementing simple React applications, Redux might cause significant overhead, and just using component state might be enough. There are however differences between class components and function components related to how hooks work, which we'll look at next. With classes, component state is accessible via this.state, and updating it (and triggering component rerendering) is done via this.setState. In functional components, we use the useState hook and instead of merging the object we're passing in, the state is replaced.

In the previous example, we went over a global store app pattern that emulates Redux. The main advantage of this approach is familiarity, meaning that developers can structure their projects using a similar folder/code structure. There is, however, an alternative approach popularized by Svelte, which is less verbose. While this is a familiar approach, many developers feel that the single-store architectural approach leads to bad software patterns.

While the rumors about Redux's demise are most likely mostly exaggerated, that there is no doubt we can achieve a lot of the functionality it provides with hooks. Also, as a rule of thumb, we should avoid using as many external libraries as possible because chances are they could become deprecated in the future. While using the useReducer hook is relatively straightforward, React doesn't provide a prescription on how to structure a relatively large application.

React's development history is widely documented and was developed for internal use at Facebook, as it is the case with a lot of librarie, and for quite some time it was ES5 only - ES6 support of course followed, but the team quite quickly realized that if a component doesn't need to maintain an internal state, there's no need for it to be a class, and one of the major additions of v14.0 were stateless functional components. Not long after, the container / presentational pattern appeared, where the state changes would be handled in a wrapping class component, and the inner child component would handle the presentation part.

Before getting into library-specific details, it's worth starting with a definition of what constitutes reactivity. A typical example would be an Excel spreadsheet: if a cell aggregates data from other cells, that cell instantly changes if we change a value in any of the aggregated cells. In reactive programming, if a variable A depends on B and C, a change in either B or C would also trigger a change in A. While there seems to be an ongoing debate whether React is truly reactive, there's no doubt that the UI reacts to changes in the data model, even if parts of the model itself don't react to other parts being changed, so from now on, we'll consider this definition of reactivity.