MD Clarity

mdclarity

“Modular” is more than a blockchain buzzword—it’s a fundamental principle that could define the future of web3. The approach, which breaks down blockchain functions into distinct, interconnected layers, is gaining traction across the sector for its ability to enhance scalability, security, and flexibility. From data management to network verification, modular architectures are reshaping how we think about decentralization. This shift isn't just a technical consideration—it has far-reaching implications for transforming users into active network stakeholders, enabling new forms of data monetization, and reshaping the overall trajectory of web3. What’s Modularity in Blockchain Let’s start at the start. Modularity matters in blockchain because, in years gone by, the technology was monolithic. This meant a single chain attempted to handle all functions like execution, settlement, storage and consensus. While initially effective, this design soon encountered scaling challenges, leading to increased costs, reduced flexibility, and high operational overhead. As someone who’s been working in confidential computation and blockchain for a number of years, I can attest to the significant advantages of modular designs that separate functions into standalone yet interoperable layers. For starters, they enhance scalability by allowing each layer to optimize for its specific function. Security is improved through specialized protocols for each component, easily meeting and beating privacy standards set forth by Europe’s GDPR or California’s CPA. Flexibility, meanwhile, increases as developers can update or replace individual modules without overhauling the entire system. Perhaps more importantly, modularity offers cost-effectiveness and choice. By distributing tasks across specialized layers, resource requirements for each component fall. Users and developers can therefore select the modules that best suit their needs, creating a more customizable ecosystem. All of this matters because it helps solve blockchain’s scalability “trilemma”—the challenge of simultaneously achieving decentralization, security, and scalability. By breaking down blockchain functions into modular components, we're seeing innovative solutions that push the boundaries of what's possible in web3. Paving the Way for Scalable and Flexible Infrastructure In my mind, modularity is the key enabler for a new wave of projects and developments in this space. Take Celestia. As a data availability layer for modular blockchains, it's revolutionizing how Ethereum rollups and Layer 2 solutions operate. By providing a dedicated platform for publishing and verifying transaction data, Celestia is addressing one of the key bottlenecks in blockchain scalability. Its use of data availability sampling allows for lightweight verification, making the system more accessible and efficient. Similarly, EigenDA is leveraging Ethereum's existing infrastructure to create a robust data availability solution. By utilizing restaking, EigenLayer creates a more cost-effective and secure environment for rollups to post their transaction data. This approach not only enhances scalability but also maintains the security guarantees of the Ethereum mainnet. CARV, meanwhile, applies modularity to data management in gaming and AI with distinct layers for identity, storage, computation, execution, and verification. Its identity layer, for example, implements the ERC-7231 standard, unifying web2 and web3 identities for a seamless user experience. This modular approach enhances data handling and privacy but also enables flexible monetization, allowing users to selectively share and potentially profit from their gaming data with advertisers while maintaining control. These projects demonstrate how modularity is enabling innovative solutions to longstanding challenges in blockchain. By breaking down complex systems into interoperable components, they're not just improving scalability and flexibility, but also laying the groundwork for a new data infrastructure in web3. Putting Users At The Forefront Of Web3 Beyond the tech, however, it’s exciting to see modularity reshaping the very essence of user participation in blockchain. How? By elevating users from mere participants to essential stakeholders in a network’s integrity and operation. This transformation was powerfully demonstrated late last year when XAI, a Layer 3 gaming solution on Arbitrum, sold tens of thousands of nodes through a public sale. By operating nodes, users can participate in governance while also having the opportunity to earn rewards. The community and sentinel node operators, in this case, qualify to collectively earn 50% of the project's XAI tokens. It's a win-win scenario that aligns user incentives with the network’s goals, fostering a more engaged and committed community. This node success – echoed by other projects like Aethir and CARV – demonstrates how modularity can offer technical enhancements and also create new avenues for user participation and value creation. This model of user involvement is redefining how we think about blockchain networks, moving beyond the traditional roles of validators and users to create a more collaborative ecosystem. This is yet again why modularity matters. It brings us one step closer to a truly decentralized, efficient, and user-empowered digital world—the very promise that blockchain technology set out to fulfill. As developers, users, and businesses continue to explore and leverage modular blockchain designs, we can expect to see even more innovative solutions that push the boundaries of what’s possible in web3. Watch this space. “Modular” is more than a blockchain buzzword—it’s a fundamental principle that could define the future of web3. The approach, which breaks down blockchain functions into distinct, interconnected layers, is gaining traction across the sector for its ability to enhance scalability, security, and flexibility. From data management to network verification, modular architectures are reshaping how we think about decentralization. This shift isn't just a technical consideration—it has far-reaching implications for transforming users into active network stakeholders, enabling new forms of data monetization, and reshaping the overall trajectory of web3. What’s Modularity in Blockchain Let’s start at the start. Modularity matters in blockchain because, in years gone by, the technology was monolithic. This meant a single chain attempted to handle all functions like execution, settlement, storage and consensus. While initially effective, this design soon encountered scaling challenges, leading to increased costs, reduced flexibility, and high operational overhead. As someone who’s been working in confidential computation and blockchain for a number of years, I can attest to the significant advantages of modular designs that separate functions into standalone yet interoperable layers. For starters, they enhance scalability by allowing each layer to optimize for its specific function. Security is improved through specialized protocols for each component, easily meeting and beating privacy standards set forth by Europe’s GDPR or California’s CPA. Flexibility, meanwhile, increases as developers can update or replace individual modules without overhauling the entire system. Perhaps more importantly, modularity offers cost-effectiveness and choice. By distributing tasks across specialized layers, resource requirements for each component fall. Users and developers can therefore select the modules that best suit their needs, creating a more customizable ecosystem. All of this matters because it helps solve blockchain’s scalability “trilemma”—the challenge of simultaneously achieving decentralization, security, and scalability. By breaking down blockchain functions into modular components, we're seeing innovative solutions that push the boundaries of what's possible in web3. Paving the Way for Scalable and Flexible Infrastructure In my mind, modularity is the key enabler for a new wave of projects and developments in this space. Take Celestia. As a data availability layer for modular blockchains, it's revolutionizing how Ethereum rollups and Layer 2 solutions operate. By providing a dedicated platform for publishing and verifying transaction data, Celestia is addressing one of the key bottlenecks in blockchain scalability. Its use of data availability sampling allows for lightweight verification, making the system more accessible and efficient. Similarly, EigenDA is leveraging Ethereum's existing infrastructure to create a robust data availability solution. By utilizing restaking, EigenLayer creates a more cost-effective and secure environment for rollups to post their transaction data. This approach not only enhances scalability but also maintains the security guarantees of the Ethereum mainnet. CARV, meanwhile, applies modularity to data management in gaming and AI with distinct layers for identity, storage, computation, execution, and verification. Its identity layer, for example, implements the ERC-7231 standard, unifying web2 and web3 identities for a seamless user experience. This modular approach enhances data handling and privacy but also enables flexible monetization, allowing users to selectively share and potentially profit from their gaming data with advertisers while maintaining control. These projects demonstrate how modularity is enabling innovative solutions to longstanding challenges in blockchain. By breaking down complex systems into interoperable components, they're not just improving scalability and flexibility, but also laying the groundwork for a new data infrastructure in web3. Putting Users At The Forefront Of Web3 Beyond the tech, however, it’s exciting to see modularity reshaping the very essence of user participation in blockchain. How? By elevating users from mere participants to essential stakeholders in a network’s integrity and operation. This transformation was powerfully demonstrated late last year when XAI, a Layer 3 gaming solution on Arbitrum, sold tens of thousands of nodes through a public sale . sold tens of thousands of nodes through a public sale sold tens of thousands of nodes through a public sale By operating nodes, users can participate in governance while also having the opportunity to earn rewards. The community and sentinel node operators, in this case, qualify to collectively earn 50% of the project's XAI tokens. It's a win-win scenario that aligns user incentives with the network’s goals, fostering a more engaged and committed community. This node success – echoed by other projects like Aethir and CARV – demonstrates how modularity can offer technical enhancements and also create new avenues for user participation and value creation. This model of user involvement is redefining how we think about blockchain networks, moving beyond the traditional roles of validators and users to create a more collaborative ecosystem. This is yet again why modularity matters. It brings us one step closer to a truly decentralized, efficient, and user-empowered digital world—the very promise that blockchain technology set out to fulfill. As developers, users, and businesses continue to explore and leverage modular blockchain designs, we can expect to see even more innovative solutions that push the boundaries of what’s possible in web3. Watch this space.

Why Modularity Matters: Unlocking the Future of Data Infrastructure in Web3

Experienced professionals whose eyes glaze over with expertise may justifiably be dissatisfied, believing that containerization has been discussed many times before. They even would say, "Read the documentation." And in a sense, they would be right. However, new specialists don't know about the times when Ubuntu disks were given away for free and have no experience in compiling operating systems from scratch. So, this statement becomes utopian. Every new technology starts with enthusiasts who fully immerse themselves in its intricacies. For example, early amateur radio operators knew almost everything about radio communications. They could build a receiver with their own hands and catch signals on a homemade antenna. Early GNU/Linux users knew the operating system's inner workings. Many even knew how to patch and recompile modem drivers to set up a network connection. The current generation of users is generally not engaged with such basics, as they are starting to engage with the technology at a lower entry threshold. These processes are happening not only among end users but also among engineers. On the one hand, deep specialization is normal. On the other hand, specialists risk turning into priests who know the magic rituals but cannot fix something at a low level when it breaks. This phenomenon is also seen in the context of containerization. Recently, more DevOps engineers know how to use Docker and Podman. They can create a Dockerfile. However, they feel insecure when asked about namespaces in Linux or confused by a question about how containerization differs from deployment via RPM packages. My name is Tanya, and I am the Senior DevOps Engineer at Plerdy. Today, I would like to discuss the containerization topic from a slightly different angle and shed light on the following aspects: Basic principles on which modern containerization is based The differences between containerization and virtualization What Linux namespaces is Get your cup of coffee ready, and let's get started on this fascinating journey into the world of containerization. Abstraction Levels in Containerization Let’s start with the basics. Hardware-Level The backbone of modern infrastructure is hardware. It is often said that "there is nothing but an interface to the hardware in someone else's data center." But hardware can range from Chinese components with their peculiarities to branded servers from HP or even homemade clusters assembled on Raspberry Pi with individual controllers. Ideally, developers want their code to run everywhere with minimal changes and without worrying about what hardware is being used - SSD, HDD, or even a refurbished floppy disk just for fun. They also don't want to worry about accessing files, RAM areas, and other low-level details. Kernel Level The operating system is used to achieve this abstraction between hardware and software. It provides the necessary system calls that allow interaction with hardware resources. These system calls are often low-level, reliable, and simple. For example, "read 10 bytes, open file, read 10 bytes." In theory, you can develop applications using almost only system calls. Let's say you need to create a Windows application without using high-level libraries. You can directly write the window image to the video card buffer, display it on the screen, and respond to keystrokes. Then, through system calls, you can track mouse coordinates and locate screen clicks to properly handle events like "user pressed button_1". This is possible but not usually used for graphical applications. In this case, reusing existing code is limited and requires highly skilled developers. I mean up to and including writing direct machine code for the processor. Library Level A more common and convenient approach is to use off-the-shelf libraries that wrap system calls in higher-level abstractions and provide convenient interfaces to the computer mouse, network resources, and sound devices. One example is PulseAudio, which facilitates access to audio files and devices. User-Space Level The next level of abstraction is user space. A program running at this level has no direct knowledge of the hardware, operating system, or other low-level details. It is usually just a set of high-level instructions that rely on dependencies in the form of libraries from the previous level. The operating system creates a separate isolated process for our program. It allows the application to not worry about available resources and other technical details. The program runs inside this process under the notion that it is executed in an isolated environment where it owns all the resources. In reality, the operating system manages resources and ensures that RAM is allocated, monitors CPU time allocation, and manages task execution priorities. It can "suspend" one application to perform calculations for another, all according to quotas and priorities. This greatly facilitates development and ensures reliable system operation. How, ultimately, can a program without direct knowledge of the operating system and low-level details interact with all these components and infrastructure? This is accomplished by using dynamically pluggable libraries. These libraries are a set of standard instructions that are set aside in a separate abstraction to simplify interaction and provide programming convenience. Let's look at working in the console and understand how it functions. First, we must put the file command on the ls binary and ensure it was dynamically linked to the libraries. It will not work without them because it relies on their presence in the OS. Next, using ldd, we must determine which libraries the program uses when working. It is important that we connect not just any libraries but quite specific versions of them. In some minor releases, they may fix bugs, optimize something, and fix vulnerabilities. But major changes may add new features and break old ones. In the case of popular libraries, developers try to support all old API calls for as long as possible. Still, they must be removed if they interfere with implementing new architectural solutions. Usually, they warn about this in advance with long and persistent messages that this particular call is deprecated. As usual, often nobody does anything until the last moment if the business doesn't want to pay for it right now. No One Likes Maintenance Maintaining software is hard. Businesses are extremely reluctant to part with money to solve problems that haven't come yet. In addition, there are difficulties in the interaction between the developer and the end user who will run the application. For example, a developer sits on ancient Ubuntu and still can't update. Or, in the olden days, he dragged a library into the application's base somewhere, which was buried under several layers of code and abstractions. So, he takes an artifact of his application or source code and gives it to DevOps. The engineer rolls that application out into the environment, and everything crashes. It cusses that it can't feel legs, it can't feel arms, that library over there was not brought in, and this one is of an unknown version. The calls are wrong. DevOps engineer returns to the developer and says, “It doesn't work. You need to figure out how to run it”. But he may get a response like, "I don't know anything, I have the same leg, and it doesn't hurt; everything works; I checked". And that's where the dilemma comes in - what's the best way to reproduce the environment that the application needs to fully work? Let's assume I will take a bunch of libraries and somehow run them in a test environment. But how do I give the binary to the customer? Should I write a huge instruction on how to set up the environment with the necessary libraries, drag everything in a huge archive, and install it with a set of scripts? Or find a simpler solution? Distributions Maintenance Supporting different operating system distributions is an important task with pros and cons, depending on your situation and company resources. Here are a few important aspects. Pros of supporting multiple distributions: Accessibility to a wider audience. Supporting different distributions makes your application accessible to more users, as different organizations and individuals may prefer different distributions. End-user friendly. Users can install the application with minimal effort using package management tools such as or . yum apt-get Compatibility. Supporting different distributions helps to ensure compatibility with different operating system versions and libraries. Cons of supporting multiple distributions: Complexity and cost. Supporting multiple distributions requires additional effort and resources to test and ensure compatibility. It can be expensive and time-consuming. Development constraints. The need to support older versions of libraries and environments can limit the ability to introduce new features and optimize code. Dependency on distribution maintainers. You may need to work with distribution maintainers to ensure your application is properly integrated and supported. This may require additional effort. Some companies choose to support only a few popular distributions to simplify the development process and reduce costs. In contrast, others strive to provide broad availability and user-friendliness, even at additional cost. Containerization or Virtualization Most companies don't have the resources to support many distributions. You can limit yourself to a small number of distributions. But problems will start when the distribution becomes oldstable, and a small team will have to update all dependencies when upgrading to a new OS version. In this case, the traditional solution is to pack everything into a docker image and send it to the customer. What exactly he will run it on is not so important. Thanks to the abstraction layer, our image will contain everything we need in a portable form. If the DevOps is good, the image will be minimalistic and contain only the essentials. Suddenly, it turns out that the application needs to work with hardware tokens, hard disk controllers, and cash registers. We need full-fledged drivers and can't stuff our kernel into a container. And the OS won't let us do it. In this case, only full virtualization will help, where the host-OS hypervisor will allow us to run any kernel with the drivers we need. This is often a better solution. But now, we will consider a situation when we don't need overhead in the form of many running kernels of a full-fledged OS to run small applications. In the case of a container, we send system calls to the kernel on which all containers are running. Then, we drag the libraries together with the binary inside the docker image. This allows us to tell the process: "Don't go there for libraries, but here. They are in the container." The process knows nothing about the file system or the computer as a whole. The process gets everything from the kernel. When we say, "Give us a list of files in the directory", we send a request to the kernel. The kernel responds to this system call with a list of directory files. We send a request to the kernel, "Please give us a list of network interfaces." The kernel responds with a list of network interfaces. "Kernel, please open a TCP connection for us." The kernel returns a pointer to this connection. That is, the process is basically helpless without the kernel, even though it has brought with it all the libraries necessary for the application. Namespace The Linux kernel natively supports . This mechanism does not require any additional packages to be installed. They are provided right at the kernel level. It allows us to respond to each application's system calls differently. namespaces As this mechanism has evolved, new features have been added to virtualize certain functions. Namespace Kernel version Year Mount 2.4.19 2002 UTS 2.6.19 2006 PID 2.6.24 2008 Network 2.6.29 2009 IPC 2.6.30 2009 User 3.8 2013 Time 5.6 2020 With the advent of this technology, it is now possible, for example, to give different sets of available networks when querying the kernel from applications that run in different namespaces. The table above shows all currently available namespaces. The time namespace is a relatively recent addition, which allows different processes to see different system time or time zones. Let's look at some of them a little closer. Network namespaces provide a means of isolating network resources. They allow processes running in different namespaces to have their own network devices, routing tables, and firewall rules. If an application runs in a separate net namespace, we provide complete isolation of the network from the rest of the system, allowing communication only through dedicated interfaces. On the other hand, mount namespaces provide the application with its own representation of the file system. We can create a specific structure in a container and tell the process, "This is the root of the file system. Use this as the base." In this way, we give the application access only to specific files and directories, thus providing file system isolation within the container. The PID namespace creates isolated namespaces for processes, the User namespace allows us to have our own unique copy of user and group identifiers, and the IPC namespace provides control over inter-process communication. There is also the UTS namespace, which allows us to set our own hostname for each isolated environment. These types of namespaces provide complete isolation and control over resources and processes within the container. Conclusion The current major trend today is to strive for maximum modularity. This approach makes it possible to build customized environments from a set of libraries and ensure they work almost everywhere. This greatly accelerates the introduction of new solutions to the market, provides portability and fault tolerance, and simplifies load balancing. It also will bring other benefits associated with the transition from the "Pets" model (unique, hand-customized services and servers) to the "Cattle" model (homogeneous entities raised and destroyed by the hundreds). However, it is important to remember that Docker is a convenient shell over the standard kernel mechanisms. These mechanisms are used not only in the context of Docker but also in conjunction with many other technologies.

Containerization In 2023: Strive for Maximum Modularity via the Cattle Model

Aspect-Oriented Programming (AOP) is a programming paradigm that aims to increase modularity by allowing the separation of cross-cutting concerns. In simple terms, it helps you keep your code clean, modular, and easy to maintain. We can leverage AOP to debug Spring Boot applications more effectively and seamlessly. In this post, we will explore how to use AOP to debug a Spring Boot application effectively. https://youtu.be/6kxpkcEqssw?embedable=true AOP Concepts Before diving into debugging with AOP, it is essential to understand the core concepts. AOP lets us write code that executes before or after a method. It includes the following common terms: An aspect represents the cross-cutting concerns or the functionality that needs to be applied throughout the application. Aspect: A join point is a specific point in the execution flow of the application, where an aspect can be applied. Join Point: The action taken by an aspect at a specific join point is called advice. There are different types of advice, such as before, after, around, and after throwing. Advice: A pointcut is a set of join points where an aspect should be applied. Pointcut: I will skip the discussion on weaving since there’s a lot of nuance related to that and I want to focus on the debugging aspects. I don't want to make this into an AOP tutorial. However, there’s one general aspect of AOP I want to discuss. While AOP offers significant benefits in terms of modularity, maintainability, and debugging capabilities, it's important to be aware of the potential performance implications. Using AOP can introduce some overhead, primarily due to the creation and execution of proxy objects, which intercept method calls and apply the specified advices. The impact on performance can vary depending on the number of aspects, the complexity of pointcut expressions, and the type of advice used. For example, around advice is typically more expensive in terms of performance compared to before and after advice. To minimize the performance impact of AOP, consider the following best practices: Apply AOP to the critical parts of your application where it provides the most value. Avoid using aspects for trivial or infrequent operations. Be selective: Ensure that your pointcut expressions are as precise as possible. This can help minimize the number of unnecessary interceptions and reduce the overhead. Optimize pointcut expressions: Choose the appropriate type of advice for your use case. For example, use before or after advice instead of around advice when possible. Limit advice execution: If some aspects are only required for debugging or development purposes, use conditional aspects that can be enabled or disabled based on a configuration property. This ensures that the performance impact is limited to specific environments or scenarios. Use conditional aspects: Regularly monitor and measure the performance of your application to ensure that the overhead introduced by AOP is within acceptable limits. Use profiling tools to identify potential bottlenecks and optimize your AOP implementation accordingly. Monitor and measure: Logging Aspect Let's create a simple aspect to log the execution time of methods in our Spring Boot application. This can help identify performance bottlenecks. We can create a new class called 'LoggingAspect' and annotate it with and to indicate that it's an aspect and a Spring-managed bean. We implement a pointcut expression to target the methods you want to measure. For example, you can target all public methods in a specific package. We then implement an around advice to measure the execution time and log the results. @Aspect @Component Here's an example of a : LoggingAspect @Aspect
@Component
public class LoggingAspect {
  private static final Logger logger = LoggerFactory.getLogger(LoggingAspect.class);

  @Pointcut("execution(public * com.example.myapp..*.*(..))")
  public void publicMethods() {}

  @Around("publicMethods()")
  public Object logExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
    long startTime = System.currentTimeMillis();

    Object result = joinPoint.proceed();

    long elapsedTime = System.currentTimeMillis() - startTime;
    logger.debug("Method [{}] executed in {} ms", joinPoint.getSignature(), elapsedTime);
    return result;
  }
} Pointcut methods are empty because their sole purpose is to define a pointcut expression, which determines the join points (i.e., specific points in the execution of a program) where the aspect should be applied. The method body itself does not contain any logic, as the behavior of the aspect is defined in the advice methods (e.g., , , , etc.). @Before @After @Around The pointcut method serves as a reusable reference to a specific pointcut expression, making it easier to maintain and update if needed. By referring to a pointcut method in your advice methods, you can apply the same pointcut expression to multiple pieces of advice without duplicating the expression. We will see that in action below. After implementing the , we can run our application and observe the logs. We should now see the execution time for each targeted method as a poor man's profiler. Just like a regular profiler, this tool has many disadvantages and impacts the observed application. However, we can extract valuable data if we tune this correctly. LoggingAspect Logging All Methods One of the common problems we face in big projects is flaky tests and failures. These are especially hard to understand as we might not have enough logging data. Adding logs to the entire application is impractical in most cases and we’d only want such logs for specific CI executions. We wouldn’t want to over-log in production or even maintain such logging code. However, knowing the parameters that every method received and its return value can lead us to understand a failure after the fact. The following code shows such a logger that can print out every entry/exit and the arguments or return values: @Aspect
@Component
public class LoggingAspect {
    private static final Logger logger = LoggerFactory.getLogger(LoggingAspect.class);

    @Pointcut("execution(public * com.example.myapp..*.*(..))")
    public void publicMethods() {}

    @Around("publicMethods()")
    public Object logMethodEntryAndExit(ProceedingJoinPoint joinPoint) throws Throwable {
        // Log method entry and arguments
        Object[] args = joinPoint.getArgs();

        logger.debug("Entering method [{}] with arguments: {}", joinPoint.getSignature(), Arrays.toString(args));

        // Execute the target method and capture the return value
        Object result = joinPoint.proceed();

        // Log method exit and return value
        logger.debug("Exiting method [{}] with result: {}", joinPoint.getSignature(), result);

        // Return the result
        return result;
    }
} The Tip of the Iceberg Logging to keep track of performance or method entry/exit is powerful but basic. We can go much deeper than that. We can create an aspect to log incoming HTTP requests and responses. This aspect intercepts the methods with the annotation, which is typically used for handling HTTP requests in Spring Boot applications: @RequestMapping @Aspect
@Component
public class RequestResponseLoggingAspect {
    private static final Logger logger = LoggerFactory.getLogger(RequestResponseLoggingAspect.class);

    @Pointcut("@annotation(org.springframework.web.bind.annotation.RequestMapping)")
    public void requestMappingMethods() {}

    @Around("requestMappingMethods()")
    public Object logRequestAndResponse(ProceedingJoinPoint joinPoint) throws Throwable {
        HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest();
        logger.debug("Request: {} {} - Parameters: {}", request.getMethod(), request.getRequestURI(), request.getParameterMap());
        Object result = joinPoint.proceed();
        if (result instanceof ResponseEntity) {
            ResponseEntity<?> responseEntity = (ResponseEntity<?>) result;
            logger.debug("Response: Status {} - Body: {}", responseEntity.getStatusCode(), responseEntity.getBody());
        }
        return result;
    }
} Another important aspect is bean creation and destruction. We can create an aspect to log these events. This aspect intercepts the methods annotated with and which doesn’t apply to all beans but would help us keep track of the applicable code in a large application: @PostConstruct @PreDestroy @Aspect
@Component
public class BeanLifecycleLoggingAspect {
    private static final Logger logger = LoggerFactory.getLogger(BeanLifecycleLoggingAspect.class);

    @Pointcut("@annotation(javax.annotation.PostConstruct)")
    public void postConstructMethods() {}

    @Pointcut("@annotation(javax.annotation.PreDestroy)")
    public void preDestroyMethods() {}

    @After("postConstructMethods()")
    public void logBeanInitialization(JoinPoint joinPoint) {
        logger.debug("Bean Initialized: {}", joinPoint.getTarget().getClass().getSimpleName());
    }

    @Before("preDestroyMethods()")
    public void logBeanDestruction(JoinPoint joinPoint) {
        logger.debug("Bean Destroyed: {}", joinPoint.getTarget().getClass().getSimpleName());
    }
} We can even log dependency injection events. This aspect intercepts the methods with the annotation. It doesn’t track constructor injection though but we can use it to track the instance type that gets injected into a bean: @Autowired @Aspect
@Component
public class DependencyInjectionLoggingAspect {
    private static final Logger logger = LoggerFactory.getLogger(DependencyInjectionLoggingAspect.class);
   @Pointcut("@annotation(org.springframework.beans.factory.annotation.Autowired)")
    public void autowiredMethods() {}

    @Before("autowiredMethods()")
    public void logDependencyInjection(JoinPoint joinPoint) {
        logger.debug("Autowired: {} - Target: {}", joinPoint.getSignature(), joinPoint.getTarget().getClass().getSimpleName());
    }
} Final Word AOP is a fantastic debugging tool. In this post, I skimmed a lot of big ideas and overused logging. When tracking performance a better approach would be to accumulate values and then log the statistics in the end, thus removing the overhead of the logger (which impacts the results). The one thing I recommend is turning this off by default. It’s important to run a CI cycle without AOP, the cost is too big and we can seriously impact the final result. We need to turn this on surgically when we need to understand something deep. In those situations, AOP tooling can make the difference when searching for that needle in the haystack. Also published . here

Spring Boot Debugging with Aspect-Oriented Programming (AOP) to Increase Modularity

One of the main reasons to design microservices is that they enforce . However, the cons of microservices are so huge that it’s like chopping off your right hand to learn to write with the left one; there are more manageable (and less painful!) ways to achieve the same result. strong module boundaries Even since the microservices craze started, some cooler heads have prevailed. In particular, , a developer on the Spring framework, has been a long-time proponent of the alternative. The idea is to keep a monolith but design it around modules. Oliver Drotbohm moduliths Many flocks to microservices because the application they work on resembles a spaghetti platter. If their application were better designed, the pull of microservices wouldn’t be so strong. Why modularity? Modularity is a way to reduce the impact of change on a codebase. It’s very similar to how one designs (big) ships. When water continuously leaks into a ship, the latter generally sinks because of the decreasing Archimedes thrust. To avoid a single leak sinking the ship, it’s designed around multiple watertight . If one leak happens, it’s contained in a single compartment. While it’s not ideal, it prevents the ship from sinking, allowing it to reroute to the nearest port where one can repair it. compartments Modularity works similarly: it puts boundaries around parts of the code. This way, the effect of a change is limited to the part and doesn’t spread beyond its boundaries. In Java, such parts are known as packages. The parallel with ships stops there because packages must work together to achieve the desired results. Packages cannot be “watertight”. The Java language provides visibility modifiers to work across package boundaries. Interestingly, the most famous one, , allows crossing packages entirely. public Designing boundaries that follow the principle of least privilege is a constant effort. Chances are that under the project’s pressure in the initial development or with time during maintenance, the effort will slip, and boundaries will decay. We need a more advanced way to enforce boundaries. Modules, modules everywhere In the long history of Java, “modules” have been a solution to enforce boundaries. The thing is, there are many definitions of what a module is, even today. , started in 2000, aimed to provide versioned components that could be safely deployed and undeployed at runtime. It kept the JAR deployment unit but added metadata in its manifest. OSGi was powerful, but developing an OSGi (the name for a module) was complex. Developers paid a higher development cost while the operation team enjoyed the deployment benefits. DevOps had yet to be born; it didn’t make OSGi as popular as it could have been. OSGI bundle In parallel, Java’s architects searched for their path to modularizing the JDK. The approach is much simpler compared to OSGI, as it avoids deployment and versioning concerns. Java modules, introduced in Java 9, limit themselves to the following data: a name, a public API, and dependencies to other modules. Java modules worked well for the JDK but much less for applications because of a chicken-and-egg problem. To be helpful to applications, developers must modularize libraries — not relying on auto-modules. But library developers would do it only if enough application developers would use it. , only half of 20 commons libraries were modularized. Last time I checked On the build side, I need to cite Maven modules. They allow splitting one’s code into multiple projects. There are other module systems on the JVM, but these three are the most well-known. A tentative approach to enforce boundaries As mentioned above, microservices provide the ultimate boundary during development and deployment. They are overkill in most cases. On the other side, there’s no denying that projects rot over time. Even the most beautifully crafted one, which values modularity, is bound to become a mess without constant care. We need rules to enforce boundaries, and they need to be treated like tests: when tests fail, one must fix them. Likewise, when one breaks a rule, one must fix it. is a tool to create and enforce rules. One configures the rules and verifies them as tests. Unfortunately, the configuration is time-consuming and must constantly be maintained to provide value. Here’s a snippet for a following the Hexagonal architecture principle: ArchUnit sample application HexagonalArchitecture.boundedContext("io.reflectoring.buckpal.account")
                     .withDomainLayer("domain")
                     .withAdaptersLayer("adapter")
                     .incoming("in.web")
                     .outgoing("out.persistence")
                     .and()
                         .withApplicationLayer("application")
                         .services("service")
                         .incomingPorts("port.in")
                         .outgoingPorts("port.out")
                     .and()
                         .withConfiguration("configuration")
                         .check(new ClassFileImporter()
                         .importPackages("io.reflectoring.buckpal..")); Note that the class is a custom-made DSL façade over the ArchUnit API. HexagonalArchitecture Overall, ArchUnit is better than nothing, but only marginally so. Its main benefit is automation via tests. It would significantly improve if the architectural rules could be automatically inferred. That’s the idea behind the Spring Modulith project. Spring Modulith Spring Modulith is the successor of Oliver Drotbohm’s (with a trailing S). It uses both ArchUnit and . At the time of this writing, it’s . Moduliths project jMolecules experimental Spring Modulith allows: Documenting the relationships between the packages of a project Restricting certain relationships Testing the restrictions during in tests It requires that one’s application uses the Spring Framework: it leverages the latter’s understanding of the former, obtained through DI assembly. By default, a Modulith module is a package located at the same level as the -annotated class. SpringBootApplication |_ ch.frankel.blog
    |_ DummyApplication       // 1
        |_ packagex           // 2
        |  |_ subpackagex     // 3
        |_ packagey           // 2
        |_ packagez           // 2
          |_ subpackagez      // 3 Application class Modulith module Not a module By default, a module can access the content of any other module but cannot access Spring Modulith offers to generate text-based diagrams based on PlantUML, with UML or (default) skins. The generation is easy as pie: C4 var modules = ApplicationModules.of(DummyApplication.class);
new Documenter(modules).writeModulesAsPlantUml(); To break the build if a module accesses a regular package, call the method in a test. verify() var modules = ApplicationModules.of(DummyApplication.class).verify(); A sample to play with I’ve created a to play with: it emulates the home page of an online shop. The home page is generated server-side with Thymeleaf and displays catalog items and a newsfeed. The latter is also accessible via an HTTP API for client-side calls (that I was too lazy to code). Items are displayed with a price, thus requiring a pricing service. sample app Each feature — page, catalog, newsfeed, and pricing — sits in a package, which is viewed as a Spring module. Spring Modulith’s documenting feature generates the following: Let’s check the design of the pricing feature: The current design has two issues: The is accessible outside of the module PricingRepository The leaks the JPA entity PricingService Pricing We shall fix the design by encapsulating types that shouldn’t be exposed. We move the and types into an subfolder of the module: Pricing PricingRepository internal pricing If we call the method, it throws and breaks the build because is not accessible from outside the module: verify() Pricing pricing Module 'home' depends on non-exposed type ch.frankel.blog.pricing.internal.Pricing within module 'pricing'! Let’s fix the violations with the following changes: Conclusion By toying with a sample application, I did like Spring Modulith. I can see two prominent use cases: documenting an existing application and keeping the design “clean”. The latter avoids the “rot” effect of applications over time. This way, we can keep the design as intended and avoid the spaghetti effect. The icing on the cake: it’s great when we need to chop one or more features to their deployment unit. It will be a very straightforward move, with no time wasted to untangle dependencies. Spring Modulith provides a huge benefit: . delay every impactful architectural decision until the last possible moment Thanks, for his review. Oliver Drotbohm You can find the source code on . GitHub Originally published at on November 13th, 2022 A Java Geek

Have We Reached the Age of Modularity Maturity?

Modularity is central to modern software engineering - or may be all type of engineering not just software. We’ll explore support for modularity in Java and .Net platforms, but before that let’s first try to find answers for what and why of modularity. What is a Module? Dictionary say a module is “one of a set of separate parts that, when combined, form a complete whole” So a module needs to have two main characteristics: Provide one or more related set of services via a standard interface — having standard interface would make a module reusable and replaceable Hide implementation details from the consumers of the services What is Modular thinking? Modular thinking would involve the following: 1. Break down the problem in small parts i.e. modules. Each part would satisfy the following: Each module is focused on one or more related services \ functions Services are exposed using a standard interface Each module can potentially be used in any place where the same services are required 2. Create the final solution by composing different modules together Almost everything around us is an example of modular thinking e.g. Automobiles, Personal Computer, Electronic Devices, etc. Most of today’s software solutions are built using tools and platforms that are built in modular approach e.g., Spring Framework and .Net Framework, two very popular frameworks in Java and .Net, are both modular in nature. Both have number of modules (libraries) and those modules can be used (or reused!) in solutions for different problems. But why Modularity? What do we gain from modular approach to the solution? I think the following three are the primary benefits: Same module can be used elsewhere, saving time and effort Reuse : A change in the system is reduced to small area (implementation is hidden from consumers) and that allows more complete testing in shorter time. Stability: Multiple modules can be developed by different teams in parallel and final solution built by composing those modules. Saving time to market. Parallel Execution: Logical & Physical Modules In software applications, logical grouping of functions and services is done to create a modular design. This would be an outcome of the application of Software Architecture principles on the problem domain e.g., the following modules may be identified for a Ticket Booking application, each focused on a specific area of the solution. However, that’s still a design of the software application. Working software (application binaries) can be in one of the two forms shown below: an executable file containing all the modules. Here, the modules may internally be organized separately in the source tree of the application, but physically they all are in one executable file produced by building the application. a. each module is a library and the application is using the libraries. Libraries are built and released separately from the main Application. b. Option (b) is the modular approach that we all are familiar with and use everyday. Option (b) gives all the benefits of modularity listed above. It is said that Unit of Release is the Unit of Reuse. There is no scope for reuse in Option (a). Required Platform Capabilities To support the modularity of option (b), a platform used to build the software application needs to have at least the following capabilities: Encapsulation at module level. This is to ensure consumer uses only standard public interface and the details are hidden. Consumers cannot build dependency on “details” so that details can change without breaking anything e.g., in a logging library, is public interface and is the class implementing logging to file. Users of logging library should not have access to so that can change without breaking any dependent application. Encapsulation: com.mylogger.api.Logger com.mylogger.service.impl.FileLogger FileLogger FileLogger Since each module would also depend on some other module, there needs to be a way for each module to declare its dependencies. Dependency Management: Once a module has declared its dependencies, the platform needs to discover those dependencies (modules i.e. libraries) at runtime, load them and make them available. Dependency Discovery: Versioning of modules is required to let each module evolve independently without breaking other modules depending on it. Versioning: Let’s compare Java and .Net on these parameters: * The package structure at runtime is used to locate .class files. JVM would look for exact same directory structure as the package name e.g. all types under “com.covidservice.api.service” should be found under “com/covidservice/api/service” on the Classpath JARs. So a package is not really treated as a dependency by JVM. JVM searches for .Class file when it has to create a new Class or Instance — this is different from how dependencies are managed in Java 9 and .Net. ** Java does not support versioning at JVM layer. The versions of JARs are maintained using naming convention i.e. including version in JAR filenames like spring-web-1.0.0-RELEASE.jar. If you have wrong version on Classpath or Modulepath, JVM would use that as long as the .Class file (Java 8) or Module (Java 9) are found. is an industry alliance for . OSGi was formed in late 1990s. There are many implementations of OSGi specifications like Apache Felix, Eclipise Equinox, etc.OSGi component system is used to build Eclipse IDE, JBoss, WebLogic, etc. Before module system was introduced in Java, OSGi came up with a dynamic module system. OSGi “a vendor-independent, standards-based approach to modularizing Java software applications and infrastructure” Summary Modular architecture is a necessity once complexity and scope grows beyond certain point. It is difficult to introduce modularity at a later stage so better to do it from the beginning. Modular design can be created by applying principles of Software Architecture, but platforms used to build the software need to support modular architecture. Java 9 and .Net are more capable than Java 8 — for reasons explained above — to enforce modularity. Previously published at https://dev.to/pathiknd/modularity-in-java-and-net-3dnj

Modularity Concept in Java and .Net

Modularity refers to a system’s ability to be broken down into components which can be separated and recombined. The best software development tools are often highly modular, and allow the reuse of “assemblies” or “modules”. This principle is at the core of development frameworks like Java, C# and Go. Modularity promotes innovation because new ideas become trivial to implement. When creating a new web app, the majority of the code running is really inside of externally-developed packages; whether they be database connections, page rendering engines, input validators etc. As such, it’s extremely easy for developers to spin up a prototype of a new website idea. Enter: Crypto However, if you were to go and look at the most prized crypto codebase of all, the repository, you’d notice that it’s extremely inflexible. Unmodular code is generally characterised by long files and classes, and individual implementations of classes often depend on other concrete implementations. For an example see Core’s . This isn’t just the case with Bitcoin Core. Most of the biggest node repositories — another example is - are absolutely not built with flexibility in mind. Bitcoin Core Bitcoin validation.cpp blockchain Go Ethereum Now it’s important to note that in the case of Bitcoin, modularity isn’t a priority. If you believe you’re building the “currency” of the future, why make it easier for others to build with your code? Bitcoin Core is highly integrated, but it has stood the test of time and it . This is not a criticism of Bitcoin Core’s codebase. singular works Experimenting with Blockchains With blockchain being cited as the answer to everything, many projects are starting to experiment with different node implementations. Especially in the case of sensitive data and private chains, or cases where external data is core to a chain’s operation, projects are finding that a smart contract based approach does not allow them enough flexibility. Unfortunately until recently this has meant that in order to innovate, developers are pulling apart integrated nodes like Bitcoin’s, or starting new nodes from scratch. Both of these avenues are painful, time-consuming, and error-prone (insecure). This space is really going to thrive when a blockchain network with a completely new set of features can be spun up *clicks fingers* . like that Stratis — A Modular Platform The most exciting thing about Stratis for me is we’re thinking about building blockchains radically differently. Different consensus algorithms, smart contract executors, wallets, and two-way peg implementations are all features in the one codebase. Currently you can run — all from the one codebase: A Bitcoin (PoW) node A Stratis (PoS) node A Cirrus (PoA + smart contract) node. Moreover, because of how flexible the node is, I’m confident we could build out full node integrations for Bitcoin Cash, Gold, Private, Doge, Litecoin, etc. in each. Down the road we could extend this to support even more chain types easily, after some foray into the account model and other features. days When building a new website in .NET Core, you can preload a template and adjust the components to your needs rapidly, punching out a new prototype web app in under a day. We hope that with Stratis developers will be able to do the same but for their own blockchain networks. IFullNode node = new FullNodeBuilder() .UseNodeSettings(nodeSettings)

.UseBlockStore()

.UseMempool()

.AddRPC()

.AddSmartContracts()

.UseCLRExecutor()

.UseApi()

.Build(); Isn’t it beautiful? Our . Full Node repo is here In Conclusion Modularity == Innovation. I don’t think anyone is as far ahead as we are when it comes to a strong composable approach to building blockchain networks. To find out more follow us on Twitter: https://twitter.com/stratisplatform Or if you just want to wave: https://twitter.com/codingupastorm

The Importance of Modularity in a Blockchain Platform

This article outlines how to transition from singletons to dependency injection in a SwiftUI app with minimal effort. If you're here, you likely already know that you should avoid singletons with various of reasons like: Hidden Dependencies: Classes rely on singletons without explicit indicators, making it harder to track app dependencies and leading to unintended coupling.
Circular Dependencies: Singletons depending on each other can create cycles, leading to initialization deadlocks as instances wait for each other.
Testing Challenges: Using singletons complicates testing and SwiftUI previews since singletons can't easily be swapped for mocks. Lack of Flexibility: Singletons make it difficult to provide different implementations for different environments (e.g., live vs. mock versions for testing). And many others. Dependency Injection To overcome most issues we can use Dependency injection (DI). Using it, swapping in a new implementation becomes much easier, as components don’t rely on a single shared instance but on protocols that can be implemented in different ways. This promotes flexibility, easier testing, and adaptability as app requirements evolve. Constructor Injection Constructor injection is a straightforward technique for injecting dependencies by passing them through initializers. While effective, it often increases the size and complexity of initializers. A common challenge with constructor injection is passing dependencies through a deep UI hierarchy. If a dependency is only needed on a specific screen but must be passed down through multiple intermediary screens, this can quickly become cumbersome. One way to handle this is by using the Coordinator pattern, which centralizes navigation and manages dependencies more efficiently. Check out this article to learn how to make it. Why Not Use @EnvironmentObject? While @EnvironmentObject simplifies dependency sharing in SwiftUI, it has limitations: It only works with ObservableObject
It doesn’t allow using protocols for implementation switching.
It only works in SwiftUI views hierarchy
It only checks for service existence when accessed, increasing the risk of unintentional omissions in views. Dependency injection with property wrappers This is similar to the @EnvironmentObject solution where the dependency management happens inside of property wrappers, but without drawbacks. DependencyContainer This small library contains only a couple files, can be copied directly into your project or integrated via SPM. Please, make sure you put a star on it if you like it. Here is the link on GitHub. Let’s create an example of the service we need to pass as a dependency. As we are assuming that we are going to make a mock for testing, we need to implement our service as a protocol. Also we make it as ObservableObject, to review additional features of the framework. import Combine

protocol DataRepository: Actor, ObservableObject {
    
    func fetchData() async throws
}

actor DataRepositoryImp: DataRepository {
    
    func fetchData() async throws {
        // do real stuff
    }
}

actor DataRepositoryMock: DataRepository {
    
    func fetchData() async throws {
        // do mocked stuff
    }
} Defining a DI container Once integrated, you’ll set up a DI container to manage your services. Each service requires a unique key. You have no limitations in creating keys with the same service type. import DependencyContainer

extension DI {
    static let data = Key<any DataRepository>()
} Next let’s create a function for registering service in DI Container. extension DI.Container {
    
    static func setup() {
        register(DI.data, DataRepositoryImp())
    }
} Then, call this function at app startup. @main
struct ExampleApp: App {
    
    @MainActor final class AppState: ObservableObject {
        
        init() {
            DI.Container.setup()
        }
    }
    @StateObject var state = AppState()
    
    var body: some Scene {
        WindowGroup {
            MainView()
        }
    }
} Injecting Dependencies The actual injection is done with several property wrappers. The most common one is @DI.Static. You just need to pass a key we defined earlier. struct MainView: View {
    
    @DI.Static(DI.data) var data
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} The points we need to make attention to: No Need to Specify Type. As you may have noticed we don’t need to write a type here, because Swift gets the type from the key.
It’s very convenient in case you start with a concrete type for your service and later decide to use a protocol to enable mocking. You only need to update the type in the key definition. This change propagates automatically without requiring updates to any code referencing that service. Dependency Existence Checked on Initialization. The property wrapper checks that the service exists when initialized. This helps prevent accidental circular dependencies, where services might try to reference each other. The framework enforces a clear initialization order, encouraging thoughtful dependency management and avoiding deadlocks. Additional property wrappers: @DI.Observed Use this in SwiftUI views when your service is ObservableObject. Views will be updated when the service is changed. struct MainView: View {
    
    //updates the view when data is posting objectWillChange
    @DI.Observed(DI.data) var data
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} @DI.RePublished Should be used in ObservableObject. If your service is ObservableObject, the update will be republished further by the owner of the property wrapper. struct MainView: View {
    
    final class State: ObservableObject {
        
        // Republishes the data.objectWillChange to the State.objectWillChange
        // The view will be updated
        @DI.RePublished(DI.data) var data
    }
    
    @StateObject var state = State()
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} In addition, if you have nested services you can use a key path in property wrappers. In this case the observing logic uses the service referenced by a keypath. @DI.Static(DI.data, \.innerService) var innerService

@DI.Observed(DI.data, \.innerService) var innerService

@DI.RePublished(DI.data, \.innerService) var innerService Mocking To swap out implementations for testing or previews, you have two options: Initialize with mocked dependency
MainView(data: .init(value: DataRepositoryMock())) Replace service with mock in DI Container
DI.Container.register(DI.data, DataRepositoryMock())
    
MainView() Conclusion This guide provides a straightforward approach to adopting DI using a DependencyContainer framework and moving away from singletons, enhancing flexibility, modularity, and testability in your iOS apps. This article outlines how to transition from singletons to dependency injection in a SwiftUI app with minimal effort. singletons dependency injection minimal If you're here, you likely already know that you should avoid singletons with various of reasons like: reasons Hidden Dependencies: Classes rely on singletons without explicit indicators, making it harder to track app dependencies and leading to unintended coupling. Circular Dependencies: Singletons depending on each other can create cycles, leading to initialization deadlocks as instances wait for each other. Testing Challenges: Using singletons complicates testing and SwiftUI previews since singletons can't easily be swapped for mocks. Hidden Dependencies: Classes rely on singletons without explicit indicators, making it harder to track app dependencies and leading to unintended coupling. Hidden Dependencies: Circular Dependencies: Singletons depending on each other can create cycles, leading to initialization deadlocks as instances wait for each other. Circular Dependencies: Testing Challenges : Using singletons complicates testing and SwiftUI previews since singletons can't easily be swapped for mocks. Testing Challenges Lack of Flexibility : Singletons make it difficult to provide different implementations for different environments (e.g., live vs. mock versions for testing). Lack of Flexibility And many others. Dependency Injection Dependency Injection To overcome most issues we can use Dependency injection (DI). Using it, swapping in a new implementation becomes much easier, as components don’t rely on a single shared instance but on protocols that can be implemented in different ways. This promotes flexibility, easier testing, and adaptability as app requirements evolve. Dependency injection protocols Constructor Injection Constructor Injection Constructor injection is a straightforward technique for injecting dependencies by passing them through initializers . While effective, it often increases the size and complexity of initializers. initializers A common challenge with constructor injection is passing dependencies through a deep UI hierarchy . If a dependency is only needed on a specific screen but must be passed down through multiple intermediary screens, this can quickly become cumbersome. deep UI hierarchy One way to handle this is by using the Coordinator pattern, which centralizes navigation and manages dependencies more efficiently. Check out this article to learn how to make it. Coordinator this article this article this article Why Not Use @EnvironmentObject ? Why Not Use @EnvironmentObject ? While @EnvironmentObject simplifies dependency sharing in SwiftUI, it has limitations : @EnvironmentObject limitations It only works with ObservableObject It doesn’t allow using protocols for implementation switching. It only works in SwiftUI views hierarchy It only checks for service existence when accessed, increasing the risk of unintentional omissions in views. It only works with ObservableObject ObservableObject It doesn’t allow using protocols for implementation switching. protocols It only works in SwiftUI views hierarchy views It only checks for service existence when accessed, increasing the risk of unintentional omissions in views. existence Dependency injection with property wrappers Dependency injection with property wrappers This is similar to the @EnvironmentObject solution where the dependency management happens inside of property wrappers , but without drawbacks. @EnvironmentObject property wrappers DependencyContainer DependencyContainer This small library contains only a couple files , can be copied directly into your project or integrated via SPM . couple files SPM Please, make sure you put a star on it if you like it. star Here is the link on GitHub . link on GitHub link on GitHub link on GitHub link on GitHub Let’s create an example of the service we need to pass as a dependency. As we are assuming that we are going to make a mock for testing, we need to implement our service as a protocol. Also we make it as ObservableObject , to review additional features of the framework. ObservableObject import Combine

protocol DataRepository: Actor, ObservableObject {
    
    func fetchData() async throws
}

actor DataRepositoryImp: DataRepository {
    
    func fetchData() async throws {
        // do real stuff
    }
}

actor DataRepositoryMock: DataRepository {
    
    func fetchData() async throws {
        // do mocked stuff
    }
} import Combine

protocol DataRepository: Actor, ObservableObject {
    
    func fetchData() async throws
}

actor DataRepositoryImp: DataRepository {
    
    func fetchData() async throws {
        // do real stuff
    }
}

actor DataRepositoryMock: DataRepository {
    
    func fetchData() async throws {
        // do mocked stuff
    }
} Defining a DI container Defining a DI container Once integrated, you’ll set up a DI container to manage your services. Each service requires a unique key. You have no limitations in creating keys with the same service type . DI container unique key. service type import DependencyContainer

extension DI {
    static let data = Key<any DataRepository>()
} import DependencyContainer

extension DI {
    static let data = Key<any DataRepository>()
} Next let’s create a function for registering service in DI Container. function extension DI.Container {
    
    static func setup() {
        register(DI.data, DataRepositoryImp())
    }
} extension DI.Container {
    
    static func setup() {
        register(DI.data, DataRepositoryImp())
    }
} Then, call this function at app startup . app startup @main
struct ExampleApp: App {
    
    @MainActor final class AppState: ObservableObject {
        
        init() {
            DI.Container.setup()
        }
    }
    @StateObject var state = AppState()
    
    var body: some Scene {
        WindowGroup {
            MainView()
        }
    }
} @main
struct ExampleApp: App {
    
    @MainActor final class AppState: ObservableObject {
        
        init() {
            DI.Container.setup()
        }
    }
    @StateObject var state = AppState()
    
    var body: some Scene {
        WindowGroup {
            MainView()
        }
    }
} Injecting Dependencies Injecting Dependencies The actual injection is done with several property wrappers. The most common one is @DI.Static . You just need to pass a key we defined earlier. injection common @DI.Static key struct MainView: View {
    
    @DI.Static(DI.data) var data
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} struct MainView: View {
    
    @DI.Static(DI.data) var data
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} The points we need to make attention to: attention No Need to Specify Type. As you may have noticed we don’t need to write a type here, because Swift gets the type from the key.
It’s very convenient in case you start with a concrete type for your service and later decide to use a protocol to enable mocking. You only need to update the type in the key definition. This change propagates automatically without requiring updates to any code referencing that service. No Need to Specify Type. As you may have noticed we don’t need to write a type here, because Swift gets the type from the key. It’s very convenient in case you start with a concrete type for your service and later decide to use a protocol to enable mocking. You only need to update the type in the key definition. This change propagates automatically without requiring updates to any code referencing that service. No Need to Specify Type. As you may have noticed we don’t need to write a type here, because Swift gets the type from the key. No Need to Specify Type. type It’s very convenient in case you start with a concrete type for your service and later decide to use a protocol to enable mocking. You only need to update the type in the key definition. This change propagates automatically without requiring updates to any code referencing that service. concrete type protocol Dependency Existence Checked on Initialization. The property wrapper checks that the service exists when initialized. This helps prevent accidental circular dependencies, where services might try to reference each other. The framework enforces a clear initialization order, encouraging thoughtful dependency management and avoiding deadlocks. Dependency Existence Checked on Initialization. The property wrapper checks that the service exists when initialized . This helps prevent accidental circular dependencies, where services might try to reference each other. The framework enforces a clear initialization order, encouraging thoughtful dependency management and avoiding deadlocks . Dependency Existence Checked on Initialization. initialized deadlocks Additional property wrappers: @DI.Observed Use this in SwiftUI views when your service is ObservableObject . Views will be updated when the service is changed. @DI.Observed ObservableObject struct MainView: View {
    
    //updates the view when data is posting objectWillChange
    @DI.Observed(DI.data) var data
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} struct MainView: View {
    
    //updates the view when data is posting objectWillChange
    @DI.Observed(DI.data) var data
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} @DI.RePublished Should be used in ObservableObject . If your service is ObservableObject , the update will be republished further by the owner of the property wrapper. @DI.RePublished ObservableObject ObservableObject struct MainView: View {
    
    final class State: ObservableObject {
        
        // Republishes the data.objectWillChange to the State.objectWillChange
        // The view will be updated
        @DI.RePublished(DI.data) var data
    }
    
    @StateObject var state = State()
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} struct MainView: View {
    
    final class State: ObservableObject {
        
        // Republishes the data.objectWillChange to the State.objectWillChange
        // The view will be updated
        @DI.RePublished(DI.data) var data
    }
    
    @StateObject var state = State()
    
    var body: some View {
        Color.clear.task {
            try? await data.fetchData()
        }
    }
} In addition, if you have nested services you can use a key path in property wrappers. In this case the observing logic uses the service referenced by a keypath. key path observing logic @DI.Static(DI.data, \.innerService) var innerService

@DI.Observed(DI.data, \.innerService) var innerService

@DI.RePublished(DI.data, \.innerService) var innerService @DI.Static(DI.data, \.innerService) var innerService

@DI.Observed(DI.data, \.innerService) var innerService

@DI.RePublished(DI.data, \.innerService) var innerService Mocking Mocking To swap out implementations for testing or previews, you have two options: Initialize with mocked dependency
MainView(data: .init(value: DataRepositoryMock())) Initialize with mocked dependency MainView(data: .init(value: DataRepositoryMock())) Initialize with mocked dependency MainView(data: .init(value: DataRepositoryMock())) MainView(data: .init(value: DataRepositoryMock())) Replace service with mock in DI Container
DI.Container.register(DI.data, DataRepositoryMock())
    
MainView() Replace service with mock in DI Container DI.Container.register(DI.data, DataRepositoryMock())
    
MainView() Replace service with mock in DI Container DI.Container.register(DI.data, DataRepositoryMock())
    
MainView() DI.Container.register(DI.data, DataRepositoryMock())
    
MainView() Conclusion Conclusion This guide provides a straightforward approach to adopting DI using a DependencyContainer framework and moving away from singletons, enhancing flexibility, modularity, and testability in your iOS apps. DependencyContainer DependencyContainer DependencyContainer DependencyContainer

How to Stop Making Singletons in Swift: A Dependency Injection Guide

Explanation of ERC-6900: Modular Smart Contract Accounts and Plugins

Introduction to Cargo and cargo.toml

LONDON, UK, November 4th, 2024/Chainwire/--WebZero has announced the full agenda for its conference sub0 reset, inviting developers, investors and innovators to join Polkadot founder Dr Gavin Wood, along with industry leaders from Parity and the Web3 Foundation, to work on building JAM, a new paradigm paving the way forward for writing and securing Web3 applications. The three day event from 9-11 November in Bangkok is dedicated to the most exciting innovation of the Polkadot ecosystem: advancing Gavin Wood’s visionary JAM chain project into the implementation stage and showcasing the most innovative projects built on Substrate. JAM takes Polkadot's current architecture to a new level of flexibility, in which Polkadot's cores can be used for any verification task, whether for smart contracts or sovereign blockchains, maximizing the potential of the cores. It seeks to offer a real solution to the scalability vs coherency dilemma in Web3. sub0 reset kicks off with a dedicated education day. Attendees can learn from industry greats such as Polkadot founder Robert Habermeier and Avail’s Anurag Arjun, and join barcamp deep-dives focused on Substrate. Day two is Modularity Day, with discussions from leading innovators at Avail, R0gue, Midnight and Parity Technologies. Day three is JAM & Scalability day, building out Polkadot’s founder Gavin Wood’s vision to transform the ecosystem into the world’s first global computer. The venue’s 24/7 hackerspace will give new teams the chance to co-work and compete for 10k USD in prizes. Fabian Gompf, CEO of the Web3 Foundation said: “sub0 reset is the best opportunity for global developer talent to come together and catch up on the cutting-edge innovation happening in the Substrate and Polkadot ecosystems. Ranging from network updates and milestones to parachains, solochains and a whole day covering Join Accumulate Machine, sub0 reset is an important step for driving forward progress on Polkadot.” Agenda highlights Saturday 9th Interoperability deep-dive from Anurag Arjun 12:00pm, main stage
Keynote from Robert Habermeier, 12:30pm, main stage Sunday 10th Workshop: Building on Polkadot - Shawn Tabrizi, Parity 14:00-15:00
Building bespoke Web3 gaming experiences, John Linden, Mythical Games 16:30-17:10 JAM Day - Monday 11th Demystifying Jam - Kian Paimani, Parity 11:00am
Keynote speech on JAM from Dr. Gavin Wood - 17:00-18:00pm
JAM Toaster: developers can test and optimise JAM implementations on a full-scale simulation of the network with 1,023 nodes at full capacity and 16,384 AMD CPUs. - All day The Venue Spectacular five-floor industrial venue
24/7 hackerspace with bounties and $10k prize
Rooftop oasis
Free catering and drinks from a private chef Practical details: Sub0 reset is taking place at 127 Na Ranong Rd, Khlong Toei, Bangkok from 9-11 November, 2024. A limited supply of free tickets for sub0 reset are available here. The event runs from 10 AM until late each day. Make sure to subscribe to the WebZero Luma for full scheduling opportunities. The hackerspace runs 24 hours a day, ensuring developers can build at all hours of the night with food and beverages provided free of charge. Media lounge and recording rooms are provided. The event will be streamed on the Polkadot Youtube channel. For any further media enquiries, please contact media@joinwebzero.com About WEBZERO WebZero is a developer experience builder that is establishing a hybrid between event production and developer relations, based on its own unique vision and methodology. About Polkadot Polkadot is the powerful, secure core of Web3, providing a shared foundation that unites some of the world’s most transformative apps and blockchains. Polkadot offers advanced modular architecture that allows devs to easily design and build their own specialized blockchain projects, pooled security that ensures the same high standard for secure block production across all connected chains and apps connected to it, and robust governance that ensures a transparent system where everyone has say in shaping the blockchain ecosystem for growth and sustainability. With Polkadot, users are not just participants, they're co-creators with the power to shape its future. Contact Manager of comms / PR Jonathan Duran Distractive media@joinwebzero.com This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here LONDON, UK, November 4th, 2024/Chainwire/--WebZero has announced the full agenda for its conference sub0 reset, inviting developers, investors and innovators to join Polkadot founder Dr Gavin Wood, along with industry leaders from Parity and the Web3 Foundation, to work on building JAM, a new paradigm paving the way forward for writing and securing Web3 applications. The three day event from 9-11 November in Bangkok is dedicated to the most exciting innovation of the Polkadot ecosystem: advancing Gavin Wood’s visionary JAM chain project into the implementation stage and showcasing the most innovative projects built on Substrate. JAM takes Polkadot's current architecture to a new level of flexibility, in which Polkadot's cores can be used for any verification task, whether for smart contracts or sovereign blockchains, maximizing the potential of the cores. It seeks to offer a real solution to the scalability vs coherency dilemma in Web3. sub0 reset kicks off with a dedicated education day. Attendees can learn from industry greats such as Polkadot founder Robert Habermeier and Avail’s Anurag Arjun, and join barcamp deep-dives focused on Substrate. Day two is Modularity Day, with discussions from leading innovators at Avail, R0gue, Midnight and Parity Technologies. Day three is JAM & Scalability day, building out Polkadot’s founder Gavin Wood’s vision to transform the ecosystem into the world’s first global computer. The venue’s 24/7 hackerspace will give new teams the chance to co-work and compete for 10k USD in prizes. Fabian Gompf, CEO of the Web3 Foundation said: “sub0 reset is the best opportunity for global developer talent to come together and catch up on the cutting-edge innovation happening in the Substrate and Polkadot ecosystems. Ranging from network updates and milestones to parachains, solochains and a whole day covering Join Accumulate Machine, sub0 reset is an important step for driving forward progress on Polkadot.” Fabian Gompf, CEO of the Web3 Foundation said: “sub0 reset is the best opportunity for global developer talent to come together and catch up on the cutting-edge innovation happening in the Substrate and Polkadot ecosystems. Ranging from network updates and milestones to parachains, solochains and a whole day covering Join Accumulate Machine, sub0 reset is an important step for driving forward progress on Polkadot.” Agenda highlights Saturday 9th Saturday 9th Interoperability deep-dive from Anurag Arjun 12:00pm, main stage Keynote from Robert Habermeier, 12:30pm, main stage Interoperability deep-dive from Anurag Arjun 12:00pm, main stage Keynote from Robert Habermeier, 12:30pm, main stage Sunday 10th Sunday 10th Workshop: Building on Polkadot - Shawn Tabrizi, Parity 14:00-15:00 Building bespoke Web3 gaming experiences, John Linden, Mythical Games 16:30-17:10 Workshop: Building on Polkadot - Shawn Tabrizi, Parity 14:00-15:00 Building bespoke Web3 gaming experiences, John Linden, Mythical Games 16:30-17:10 JAM Day - Monday 11th JAM Day - Monday 11th Demystifying Jam - Kian Paimani, Parity 11:00am Keynote speech on JAM from Dr. Gavin Wood - 17:00-18:00pm JAM Toaster: developers can test and optimise JAM implementations on a full-scale simulation of the network with 1,023 nodes at full capacity and 16,384 AMD CPUs. - All day Demystifying Jam - Kian Paimani, Parity 11:00am Keynote speech on JAM from Dr. Gavin Wood - 17:00-18:00pm JAM Toaster: developers can test and optimise JAM implementations on a full-scale simulation of the network with 1,023 nodes at full capacity and 16,384 AMD CPUs. - All day The Venue The Venue Spectacular five-floor industrial venue 24/7 hackerspace with bounties and $10k prize Rooftop oasis Free catering and drinks from a private chef Spectacular five-floor industrial venue 24/7 hackerspace with bounties and $10k prize Rooftop oasis Free catering and drinks from a private chef Practical details: Sub0 reset is taking place at 127 Na Ranong Rd, Khlong Toei, Bangkok from 9-11 November, 2024. A limited supply of free tickets for sub0 reset are available here . here here The event runs from 10 AM until late each day. Make sure to subscribe to the WebZero Luma for full scheduling opportunities. WebZero Luma WebZero Luma The hackerspace runs 24 hours a day, ensuring developers can build at all hours of the night with food and beverages provided free of charge. Media lounge and recording rooms are provided. The event will be streamed on the Polkadot Youtube channel . Polkadot Youtube channel Polkadot Youtube channel For any further media enquiries, please contact media@joinwebzero.com media@joinwebzero.com media@joinwebzero.com About WEBZERO WebZero is a developer experience builder that is establishing a hybrid between event production and developer relations, based on its own unique vision and methodology. WebZero WebZero About Polkadot Polkadot is the powerful, secure core of Web3, providing a shared foundation that unites some of the world’s most transformative apps and blockchains. Polkadot Polkadot Polkadot offers advanced modular architecture that allows devs to easily design and build their own specialized blockchain projects, pooled security that ensures the same high standard for secure block production across all connected chains and apps connected to it, and robust governance that ensures a transparent system where everyone has say in shaping the blockchain ecosystem for growth and sustainability. With Polkadot, users are not just participants, they're co-creators with the power to shape its future. Contact Manager of comms / PR Jonathan Duran Distractive media@joinwebzero.com This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here here here

Stories, News & Mentions about MDCLARITY

Mdclarity’s Stories on HackerNoon