Unblock your team boost your time to production preview

Devops, Infra, etc.

Homelabs are all about experimenting, learning, and building IT infrastructure



Miscellaneous

Beating Premium, One Trick at a Time

Why pay for premium when you can get creative? We explore hacks, tricks, and workarounds to maximize APIs without breaking the bank.



API's & integrations

Writing the Same Code Twice is a Crime

Design patterns are like cheat codes for coding. Why reinvent the wheel when you can just copy and paste the best practices?



Design Patterns

Top categories

Divider

Keep your server's IP as hidden as your best-kept secret, while still showing off your service to the world.


Hide Your Server's IP While Exposing Your Service

![](/images/ioc.webp)
# Compiled IoC for Java 🛠️

We’re going to explore **Dagger** as a **compiled** IoC for Java, as opposed to other IoCs like Spring Boot that inject dependencies at runtime.

## What is IoC? 🤔

The term **Inversion of Control (IoC)** arises because, in a traditional design, the application code controls the execution flow by creating and managing dependencies directly. With IoC, this control is "inverted" and delegated to a framework or container, such as Spring. This means that the responsibility for instantiating objects and managing their dependencies is transferred from the application code to the container.

- **Without IoC**: You (the developer) are responsible for creating objects and managing the dependencies between them. For example, if class A needs an instance of class B, you create and pass the instance of B to A directly in your code.

- **With IoC**: Instead of manually creating and passing dependencies, you register your classes with an IoC container. The container is then responsible for instantiating class A, creating the instance of class B that A needs, and passing it to A automatically.

## Advantages of Dagger 🚀
### Dagger offers several advantages over other IoC frameworks, particularly those that perform dependency injection at runtime:

- No Reflection: Unlike some other frameworks, Dagger does not use reflection to perform dependency injection. This eliminates the performance overhead associated with reflection and makes the application more efficient. Instead, Dagger generates code at compile time to handle dependency injection.
- Faster Runtime Performance: Because dependency injection is resolved at compile time rather than runtime, Dagger applications typically have faster startup times and reduced runtime overhead. This leads to more predictable and faster execution of your application.
- Improved Type Safety: Dagger provides compile-time checks for dependency injection, which helps catch errors early in the development process. This means fewer runtime errors and a more robust codebase.
- Simplified Code: By handling the boilerplate code associated with dependency management, Dagger simplifies your application code and reduces the need for manual dependency handling.
- Better Integration with IDEs: Since Dagger generates code at compile time, IDEs can provide better code completion, refactoring support, and error checking.

## Installation 📦

To get started with Dagger, you need to include the Dagger dependency in your project:

```xml
  
<dependency>  
    <groupId>com.google.dagger</groupId>  
    <artifactId>dagger</artifactId>  
    <version>${dagger.version}</version>  
    <scope>compile</scope>  
</dependency>
```
You also need to add the appropriate annotation processor to generate classes at compile time:

```xml
<build>  
    <plugins>  
        <plugin>  
            <groupId>org.apache.maven.plugins</groupId>  
            <artifactId>maven-compiler-plugin</artifactId>  
            <version>3.8.1</version>  
            <configuration>  
                <source>${maven.compiler.source}</source>  
                <target>${maven.compiler.target}</target>  
                <annotationProcessorPaths combine.children="append">  
                    <path>  
                        <groupId>com.google.dagger</groupId>  
                        <artifactId>dagger-compiler</artifactId>  
                        <version>${dagger.version}</version>  
                    </path>  
                </annotationProcessorPaths>  
            </configuration>  
        </plugin>  
    </plugins>  
</build>

```

## Usage 🧩
1.  Define a Module class that contains all of your beans:
    
    ```java
        @Module  
        public class DaggerModule {
    
            @Provides  
            synchronized Client provideClient() {  
            return new ClientImpl();  
            }  
        
            @Provides  
            Repository provideRepository() {  
            return new RepositoryImpl();  
            }
          
            @Provides  
            DummyUseCase provideDummyUseCase(Client client, Repository repository) {  
            return new DummyUseCase(client, repository);  
            }  
        }
    ```
   2. Define a Component class that will contain your instantiated classes. This is similar to your Spring context:
    
    ```java
        @Component(modules = DaggerModule.class)  
        public interface DaggerComponent {  
            DummyUseCase getDummyUseCase();  
        }
    ``` 

## Testing and Demonstration 📈
To verify that Dagger generates the necessary classes at compile time, follow these steps:

1. **Compile Your Project:**
Run the Maven build command to compile your project:

```bash
mvn clean install
```
This command will compile your project and trigger the annotation processor to generate the necessary Dagger classes.

2. **Check Generated Classes:**
After a successful build, you can find the generated classes in the target/generated-sources/annotations directory of your project. Look for files like DaggerComponent.java which are generated by Dagger.


#### [View on GitHub](https://github.com/bylidev/byli-lab/releases/tag/DAGGER)

Compiled IoC for JAVA

## The Most Powerful JMstack WIKI Made with Angular is Serverless and API-less! 💪

![](/images/caffee.gif)

## 🔥 **What is Serverless?** 🚀

Serverless is a cloud computing model where you don't manage servers. Instead, you pay only for specific functions that
execute in response to events.

### **Advantages of Serverless:**

- **Automatic Scalability**: Functions scale automatically based on demand.
- **Cost Efficiency**: You pay only for the execution time of your functions, not for idle servers.
- **Less Maintenance**: No need to worry about server infrastructure maintenance.

## 🌐 **What is API-less Architecture?** 🤔

API-less architecture focuses on building applications without directly interacting with APIs for every piece of
functionality. Instead, it may rely on static data or built-in functions and services. This can simplify development and
reduce dependencies on external systems.

### **Benefits of API-less Architecture:**

- **Simpler Development**: Fewer dependencies and reduced complexity.
- **Faster Execution**: Eliminates the need for API calls, which can speed up performance.
- **Reduced Costs**: Fewer external services may mean lower operational costs.

## 🎉 **How Do JAMstack and Serverless Relate?**

JAMstack and Serverless complement each other perfectly. While JAMstack focuses on a modern, fast frontend architecture,
Serverless handles backend logic seamlessly without the need for server management. Together, they provide a robust and
efficient solution for building web applications and sites.

## 🛠️ **How to Use Mnemosine Wiki**

### **1. Setting Up Your Environment**

Before you start, ensure you have Node.js and npm installed.

```bash
 git clone git@github.com:bylidev/mnemosine-wiki.git
```

Now you will see the following directory structure:

```bash
-- 
    |-- app
    |-- 
    |---- images
    |---- *.md
-- app
    |-- src
    |-- package.json
    |-- angular.json
    |-- ...
```
To this point, you have created a new Mnemosine Wiki  project with the default structure. 


### **3. Running Your Mnemosine Wiki  Project 🚀**

```bash
cd ./app
npm install
ng serve
```

### **4. Markdown needed metadata 📝**
When creating a new markdown file, you need to add the following metadata at the beginning of the file:

```markdown
---
title: "Mnemosine Wiki - The Most Powerful JAMstack  Made with Angular is Serverless and API-less!"
author: "Ignacio Lopez"
route: "abstract-factory"
thumb: "caffee.gif"
date: "2024-07-20"
tags:
  - markdown
---
```
- title: The title of the article. 📚
- author: The author of the article. ✍️
- route: The Angular route of the article. 🌐
- thumb: The thumbnail of the article (this image will be resized). 🖼️
- date: The date of the article (important for sorting). 📅
- tags: Tags of the article (important for generating tags and SEO metadata). 🏷️

### 5. backups  💾
You only need to backup the `` directory, as it contains all your content. The `app` directory is your Angular project, and you can always recreate it.

### 6. Deploying your Mnemosine Wiki  🚀
You can deploy your Mnemosine Wiki  to any static hosting provider, like gitlab pages, github pages, cloudflare pages. Just build your Angular app and deploy the `dist` directory.
Mnemosine Wiki , provides you a configured workflow for github pages.

Mnemosine Wiki - Deploy your wiki with markdowns without servers !

![conflict](/images/event.png)

## Common Use Cases for Event-Driven Architecture

- **Fire and Forget**
  - **Example:** Sending a notification email or SMS after a user registers on a website.
  
- **Reliable Delivery**
  - **Example:** Processing online payments where each transaction must be recorded accurately.
  
- **Handling Infinite Stream of Events**
  - **Example:** Monitoring sensor data in a smart home system, such as temperature, humidity, and motion data.
  
- **Anomaly Detection and Pattern Recognition**
  - **Example:** Fraud detection in financial transactions by identifying unusual patterns in user behavior.
  
- **Broadcasting**
  - **Example:** Live streaming sports events to multiple users, where all subscribers receive the same event data simultaneously.
  
- **Buffering**
  - **Example:** Managing log data from multiple applications before sending it to a central logging system.

## Pub/Sub Events
Events are delivered to each subscriber starting at the moment of subscription without any explicit order.

## Streaming Events
Events are stored in order and can be replayed historically.

## Delivery Semantics

### At-Most-Once
- Data loss is acceptable
- Least overhead / lowest latency
  - **Example:** Sending promotional emails where missing a few emails is not critical. The system sends each email only once without confirming delivery.

### At-Least-Once
- Data loss is unacceptable
- Data duplication is acceptable
- Increased latency
  - **Example:** Processing online orders where each order must be recorded at least once. The system ensures each order is logged, even if it means duplicating entries that can be filtered out later.

### Exactly-Once (Idempotency ID)
- Most difficult to achieve
- Highest latency
  - **Example:** Transferring funds between bank accounts where the transaction must occur exactly once to avoid errors. The system ensures each transaction is processed exactly once to prevent overcharging or double processing.



## Message Broker Technologies - Delivery Guarantees
### Apache Kafka
- Producer Delivery Semantics: At-Most-Once, At-Least-Once, Exactly-Once
- Consumer Receipt Semantics: At-Most-Once, At-Least-Once, Exactly-Once

*Note: Apache Kafka supports Exactly-Once Delivery Semantics when transferring and processing data between Kafka topics.*

### Amazon SQS
- Standard Queues: At-Least-Once Delivery
- Exactly-Once Processing: Applies only to publishing events into an SQS queue.

### Google Cloud Pub/Sub
- Exactly-Once Delivery

### Microsoft Azure
- Event Hubs Output: Exactly-Once Delivery
- Event Grid Message Delivery and Retry: At-Least-Once Delivery

Byli’s Dev Core