Since 1994, we have pioneered processes and procedures that change the way high-quality repair services are done

iResQ

In this article, we’ll be going over Clean Architecture with MediatR. Starting with Clean Architecture, this is a design philosophy that promotes separation of concerns and scalability, which is highly relevant in modern application development. By dividing software into layers with distinct responsibilities, you can create systems that are easier to maintain, test, and evolve. The core idea centers around the ‘Domain’ and ‘Application’ layers remaining independent of frameworks, databases, and user interfaces, leading to more resilient and flexible software architectures. C# MediatR is a .NET library , which helps reduce dependencies by allowing objects to communicate indirectly through handlers and requests. MediatR facilitates the decoupling of software components, streamlining the implementation of C# Clean Architecture by managing interactions between different parts of an application in an elegant and maintainable manner. implementing the ‘Mediator’ pattern Understanding how to leverage MediatR within C# Clean Architecture can significantly enhance your code’s organization and efficiency. It promotes a clean separation of concerns and a well-structured pipeline for your requests. Together, they empower you to write code that is easier to understand, refactor, and test, ultimately delivering a higher-quality product. Or so that’s what we’re hoping for! Grasping C# Clean Architecture with MediatR: Foundations and Benefits Clean Architecture, as conceived by Robert C. Martin, lays down a blueprint for structuring software applications as a series of concentric layers, each with clear roles and dependencies. At its heart, it focuses on the creation of systems that are modular, maintainable, and seamlessly testable. Its foundational principle advises that dependencies should only point inwards, meaning that inner layers such as Domain Models and Business Rules remain unaffected by changes in outer layers like UI or Infrastructure. The application of Clean Architecture elevates the standard of your coding endeavors. You achieve separation of concerns, where changes in database access or user interface details ripple minimally through the system. Code quality also gets a significant boost – your business logic becomes the foundation, unaffected by external frameworks and libraries. Exploring The Layers of Clean Architecture in C# When implementing C# Clean Architecture with MediatR, you will encounter these layers: : Includes entities, enums, exceptions, interfaces, types, and logic specific to the domain itself. Domain Layer : Houses application logic and defines interfaces that are implemented by the outer layers. It orchestrates the flow of data to and from the domain entities, and leverages MediatR for commanding and querying. Application Layer : Provides implementations for interfaces defined in the application layer, such as data access code typically involving Entity Framework or Dapper. Infrastructure Layer : The UI layer, which could be anything from a web API to a desktop application. This is where MediatR handles come into play for mediating between user actions and application logic. Presentation Layer : Aspects that span multiple layers such as logging, caching, and error handling. Cross-Cutting Concerns Adopting Clean Architecture encourages improvement and adaptability in your software projects. While it’s not the only such architecture that does so, it aims to make it easier! Introducing MediatR in C# Clean Architecture MediatR is a lightweight .NET library that serves as a messaging tool, allowing objects to communicate with each other without direct references, thus following the . It acts as a central point for handling requests and commands, and dispatching them to their corresponding handlers. In C# Clean Architecture, MediatR streamlines the process of decoupling layers by serving as a connection between the UI (or any entry point into the application) and the Application Layer where the business logic resides. mediator pattern You can find a video of using MediatR here: https://www.youtube.com/watch?v=Uj7JTMSH8fQ&embedable=true Incorporating MediatR into C# Clean Architecture involves adhering to the principle that the Application Layer should not be concerned with the direct invocation of services or data persistence details. MediatR facilitates this by allowing you to construct clear and focused command/query handlers that are only responsible for single actions. Setting up the MediatR Package in Your Project Initiating MediatR in a C# project is straightforward. Here’s how to get it rolling: : To begin using MediatR, you’ll first need to install its package via NuGet into your Application Layer. Run the following command in the Package Manager Console: Install NuGet Packages Install-Package MediatR : Next, you will add the MediatR service to your application’s dependency injection container. If you’re using ASP.NET Core, this is typically done in the file, within the method: Add MediatR Service Startup.cs ConfigureServices // Assuming your handlers are in the same assembly as your Startup class.
services.AddMediatR(typeof(Startup)); : The configuration process links your requests to their handlers. MediatR automatically identifies request-handler pairs by scanning the assembly, alleviating you from any manual mapping. Configure the Mediator An Example With MediatR Let’s illustrate with a code snippet featuring a and its handler inside the Application Layer: CreateUserCommand public class CreateUserCommand : IRequest<bool>
{
    public string Username { get; set; }
    // Additional properties here
}

public class CreateUserCommandHandler : IRequestHandler<CreateUserCommand, bool>
{
    public Task<bool> Handle(
        CreateUserCommand request,
        CancellationToken cancellationToken)
    {
        // Handle the logic to create a user here
        return Task.FromResult(true);
    }
} By executing these steps, you’ve laid the groundwork for enhanced command and query handling in your applications, all while maintaining the separation of concerns promoted by Clean Architecture. Implementing Commands and Queries with MediatR Incorporating the Command Query Responsibility Segregation (CQRS) means separating the operations for reading data (queries) from the operations for modifying data (commands). This approach aligns perfectly with MediatR’s ability to distinctly separate requests that change the state of a system from those that simply retrieve data. When applied within C# Clean Architecture with MediatR, CQRS helps maintain a clean separation and high coherence of the various components involved. pattern into your application’s architecture Commands in MediatR represent operations that change the state of the application, such as adding or updating data. They often encapsulate all data required to perform the action and return void or a result indicating a command result. In contrast, queries fetch data from the application, typically returning a read-only response without causing any side effects. A Command and Query Implementation Example Here’s an example of command and query handlers with MediatR in C#: // Command
public class UpdateOrderCommand : IRequest<bool>
{
    public int OrderId { get; set; }
    public bool IsShipped { get; set; }
}

public class UpdateOrderCommandHandler : IRequestHandler<UpdateOrderCommand, bool>
{
    public Task<bool> Handle(
        UpdateOrderCommand request,
        CancellationToken cancellationToken)
    {
        // Logic to update the order shipping status
    }
}

// Query
public class GetOrderByIdQuery : IRequest<OrderDto>
{
    public int OrderId { get; set; }
}

public class GetOrderByIdQueryHandler : IRequestHandler<GetOrderByIdQuery, OrderDto>
{
    public Task<OrderDto> Handle(
        GetOrderByIdQuery request,
        CancellationToken cancellationToken)
    {
        // Logic to retrieve the order by ID
    }
} Enhancing Code Readability and Maintenance Leveraging command and query the readability and maintenance of your codebase. It does so by encapsulating business logic within clearly defined boundaries that lead to a more organized and intuitive code structure. This eases the cognitive load on developers who are navigating and updating the application. patterns with MediatR can improve Consider adhering to the following tips for maximum clarity: : Always name commands and queries after the actions they perform; for example, or . This immediately communicates their purpose. Consistent Naming CreateProductCommand GetUserByIdQuery : Command and query classes should be lean and specialized, containing only properties relevant to the particular action. Focused Classes : Ensure command handlers execute precisely one action, modifying state, and that query handlers focus exclusively on fetching data. Logic Segregation These guidelines help ensure that the purpose and responsibility of each class are apparent, streamlining future development work and reducing the risk of introducing unwanted side effects when making changes. C# Clean Architecture with MediatR: Best Practices Integrating MediatR into Clean Architecture in C# can help streamline communication between layers in your application. However, there are some best practices to ensure your implementation is effective, maintainable, and scalable. Otherwise, you run into common pitfalls that can lead to tightly coupled code, poor performance, and difficulty in identifying and resolving errors — The exact opposite of what we want here! When it comes to error handling, keep your logic consistent across command and query handlers. Use exceptions sparingly (I prefer a custom result type), and consider implementing global exception handling that can catch and process unhandled exceptions. This helps to centralize your error management logic and keeps your handlers clean and focused where otherwise you have similar-but-potentially-different logic scattered everywhere. For unit testing, every command and query handler should be covered by tests to ensure they perform the expected operations correctly — Or at least be written in a way where you CAN test them. Mocking dependencies and using in-memory databases (or check out Testcontainers!) can help simulate different scenarios. When writing tests, I find it valuable to follow the Arrange-Act-Assert pattern, where you first set up the test environment (Arrange), execute the command or query (Act), and then verify the results (Assert). This structured approach leads to more readable and maintainable test cases, and it’s popular amongst many programmers. Optimizing Performance and Scalability In larger applications, where performance and scalability become paramount, there are additional considerations to keep in mind when implementing C# Clean Architecture with MediatR. One consideration is the use of pipeline behaviors. These can intercept requests and offer a place to implement cross-cutting concerns, such as logging, validation, or performance tracing, without cluttering the handlers themselves. Caching is another crucial element to address. By caching frequently accessed data, you can reduce database calls and improve response times. However, it’s crucial to ensure your caching strategy does not introduce outdated data or complex cache invalidation logic. To keep your MediatR implementation performant and scalable, here are some useful guidelines: : Keep your handlers as simple as possible. Complex logic in handlers can be difficult to maintain and test. Simple Handlers : Make use of asynchronous processing to handle requests without blocking threads, allowing for higher throughput. Asynchronous Processing : Implement performance optimizations thoughtfully. Over-optimization can sometimes lead to unnecessary complexity, so always profile and identify bottlenecks before optimizing. Avoid Premature Optimizations : Leverage dependency injection to manage handler dependencies. This makes your application easier to scale and maintain. Dependency Injection By following these best practices for C# Clean Architecture with MediatR, you ensure that your application not only benefits from a well-organized structure but is also prepared to grow and adapt to future demands efficiently. Wrapping Up C# Clean Architecture with MediatR C# Clean Architecture with MediatR can help us build some awesome applications — but it’s important we understand what we’re working with. We saw that Clean Architecture is a software , maintainable, and testable design. Its key principles include separation of concerns, the dependency inversion principle, and the use of defined software layers to organize the codebase. design philosophy that emphasizes modular We also covered MediatR, which is a mediator pattern implementation in .NET that allows in-process messaging between objects. In Clean Architecture, MediatR helps decouple layers by allowing indirect communication between parts of the application. It ties very nicely into the architecture’s emphasis on separation of concerns. I hope that you have an opportunity to try implementing MediatR in your application! Let me know how it goes! Also published . here

Using MediatR with Clean Architecture in C# to Build for Flexibility

Grinding your way from level 41-50 is a pain but seeing players on your friend list at level 50, you wonder when will you ever be on "PoGo mile-50 club". As a data scientist, your reflex action is to google (or maybe bing) pokemon go level requirements 40-50 Or if you prefer to ask / , you would have typed: bard chatgpt What are the level requirements for pokemon go from level 40-50? We used to talk normally until we regress into communicating with computers by dropping "stopwords" and SEO our keystrokes. And now you want us to go back to typing in full sentences so that computers can try to learn human language?! Maybe those AI models should start understanding: Cut-away: (╯°□°)╯︵◓ 🪜 how? Okay, back to proper plotting... This GameRadar guide is a good start but it's just not "data-friendly", lets convert the information into a JSON. https://www.gamesradar.com/pokemon-go-level-tasks-requirements-41-50/ level_guide = {
    41: {
        'xp': 6_000_000,
        'rewards': {
            'ultra_balls': 20,
            'max_potions': 20,
            'max_revives': 20,
            'razz_berries': 20,
            'incubator': 1,
            'xl_candy': 1
        },
        'tasks': ['Power up a Legendary Pokemon 20 times',
            'Win 30 raids',
            'Catch 200 Pokemon in a single day',
            'Earn 5 gold medals'
        ]
    },

    42: {
        'xp': 7_000_000,
        'rewards': {
            'ultra_balls': 20,
            'max_potions': 20,
            'max_revives': 20,
            'nanab_berries': 20,
            'incubator': 1,
            'premium_pass': 1,
            'xl_candy': 1
        },
        'tasks': ['Evolve Eevee into each of its unique evolutions',
            'Use items to evolve Pokemon 15 times',
            'Make 3 Excellent Throws',
            'Use 200 berries to help catch Pokemon'
        ]
    }, ...,

    50: {
        'xp': 30_000_000,
        'rewards': {
            'ultra_balls': 50,
            'max_potions': 50,
            'max_revives': 20,
            'super_incubator': 5,
            'xl_candy': 2,
            'elite_charged_tm': 1,
            'incense': 5,
            'lucky_egg': 5,
            'lure': 5
        },
        'tasks': ['Make 999 Excellent throws',
             'Catch a Legendary Pokemon in your next five Legendary Pokemon encounters',
             'Defeat a Team Go Rocket Leader three times using only Pokemon with 2,500 CP or less',
             'Reach Rank 10 in the Go Battle League'
        ]
    },

} from pprint import pprint

pprint(level_guide[42]) {'rewards': {'incubator': 1,
             'max_potions': 20,
             'max_revives': 20,
             'nanab_berries': 20,
             'premium_pass': 1,
             'ultra_balls': 20,
             'xl_candy': 1},
 'tasks': ['Evolve Eevee into each of its unique evolutions',
           'Use items to evolve Pokemon 15 times',
           'Make 3 Excellent Throws',
           'Use 200 berries to help catch Pokemon'],
 'xp': 7000000} Lets see how much more effort do I need to get to the next level import pandas as pd
import matplotlib as mpl
import matplotlib.pyplot as plt
import seaborn as sns


sns.set_theme(style="darkgrid")
plt.ticklabel_format(style='plain')

xp_needed = {k:level_guide[k]['xp'] for k in level_guide}
df_xp = pd.DataFrame(xp_needed.items(), columns=['Level', 'XP'])

ax = sns.lineplot(data=df_xp, x="Level", y="XP")
ax.yaxis.set_major_formatter(mpl.ticker.StrMethodFormatter('{x:,.0f}'))

ax.set_xlim(40, 51)

plt.show() What?! It's exponential increase in the no. of XP needed?!! Oh PoGo, your game designers and devs seriously knows how to keep players "sticky" to the app and buy those ever-inflationary Pokecoins! So much sacrifice to gratify my childhood nostalgia for cute little monsters on a candy-bar phone. For my grinding effort, what juicy binary rewards will I get? pprint(level_guide[42]['rewards']) {'incubator': 1,
 'max_potions': 20,
 'max_revives': 20,
 'nanab_berries': 20,
 'premium_pass': 1,
 'ultra_balls': 20,
 'xl_candy': 1} Even reading the list of rewards is painful to know exactly how many pots, balls and revives I'll get after leveling up... Lets try to put them into pictures. First collect the list of image urls and automate some downloading. import shutil
import requests

import imageio.v2 as imageio
import numpy as np
import PIL
from PIL import Image
from IPython.display import Image as JupyterImage


def download_image(img_url, save_to, thumbnail_size=(25,25)):
    response = requests.get(img_url, stream = True)
    response.raw.decode_content = True
    with open(save_to,'wb') as fout:
        shutil.copyfileobj(response.raw, fout)
    
    # Create thumbnail
    if thumbnail_size:
        image = Image.open(save_to)  
        image.thumbnail(thumbnail_size)
        image.save(save_to.rpartition('.')[0] + '.thumbnail.png')
    

img_urls = {'golden_razz_berries': "https://www.serebii.net/brilliantdiamondshiningpearl/berries/16.png",
 'max_potions': 'https://static.wikia.nocookie.net/pokemon/images/a/a2/Dream_Max_Potion_Sprite.png',
 'max_revives': 'https://static.wikia.nocookie.net/pokemon/images/4/45/Dream_Max_Revive_Sprite.png',
 'nanab_berries': 'https://static.wikia.nocookie.net/pokemon/images/f/f6/NanabBerry-GO.png',
 'razz_berries': "https://static.wikia.nocookie.net/pokemon/images/3/32/Dream_Razz_Berry_Sprite.png",
 'silver_pinap_berries': 'https://pokemongohub.net/wp-content/uploads/2018/08/Item_0707.png',
 'pinap_berries': 'https://pokemongohub.net/wp-content/uploads/2018/03/Item_0705.png',
 'ultra_balls': 'https://static.wikia.nocookie.net/pokemon/images/f/f1/UltraBallArt.png'}


for i, url in img_urls.items():
    download_image(url, f'{i}.png') Ah, I can use a scatter plot and to present the rewards. add_artist From https://stackoverflow.com/questions/22566284/matplotlib-how-to-plot-images-instead-of-points def fetch_num_items(level_guide_l, x):
    for r in level_guide_l['rewards']:
        if r.endswith(x):
            return level_guide_l['rewards'][r]
    return 0

ball_pots_revs = [{'levels': l, 
  'potions': fetch_num_items(level_guide[l], '_potions'),
  'revives': fetch_num_items(level_guide[l], '_revives'),
  'balls': fetch_num_items(level_guide[l], '_balls'),
  'berries': fetch_num_items(level_guide[l], '_berries'),
  'balls_img': next(r for r in level_guide[l]['rewards'] 
                      if r.endswith('_balls')) + '.thumbnail.png',
  'potions_img': next(r for r in level_guide[l]['rewards'] 
                      if r.endswith('_potions')) + '.thumbnail.png',
  'revives_img': next(r for r in level_guide[l]['rewards'] 
                      if r.endswith('_revives')) + '.thumbnail.png',
 }  for l in level_guide
]

df_bpr = pd.DataFrame.from_dict(ball_pots_revs)
df_bpr And the plot… import matplotlib.pyplot as plt
from matplotlib.offsetbox import OffsetImage, AnnotationBbox

def getImage(path, zoom=1):
    return OffsetImage(plt.imread(path), zoom=zoom)

# Substitute with `df_bpr['potions_img']` or `df_bpr['revives_img']`
paths = df_bpr['balls_img']
    
x = df_bpr['levels'] 
y = df_bpr['balls'] # Substitute with `df_bpr['potions']` or `df_bpr['revives']`

fig, ax = plt.subplots()
ax.scatter(x, y) 

for x0, y0, path in zip(x, y,paths):
    ab = AnnotationBbox(getImage(path), (x0, y0), frameon=False)
    ax.add_artist(ab) Yeah that's nice, now do potions. And revives! What?! I get only 20 max revives for every level I wonder how the game devs decide how many reward items to give for the levels. Maybe they did what my teacher used to grade our papers, hold the student essays, walk to the staircase, throw them down the stairs, the nearest get As, the furthest gets Fs. The game devs must have done the same to the reward items and all the max revives plushies drops the bottom of the stairs. Come to think of it, why ain't Pokemon Company churning out plushies for Pokemon items? I would love to mix a bunch of different berries plushie and put them in the fridge whenever we run out of fruits before I go to the store to replenish them. I guess I could generate them with “un- ” on for now… stable diffusion huggingface Reading the plots individual is tedious... Can't you put all the items together? paths = list(df_bpr['revives_img']) + list(df_bpr['potions_img']) + list(df_bpr['balls_img'])
    
x = list(df_bpr['levels']) + list(df_bpr['levels']) + list(df_bpr['levels'])
y = list(df_bpr['revives']) + list(df_bpr['potions']) + list(df_bpr['balls'])

fig, ax = plt.subplots()
ax.scatter(x, y) 

for x0, y0, path in zip(x, y,paths):
    ab = AnnotationBbox(getImage(path), (x0, y0), frameon=False)
    ax.add_artist(ab) That looks better! Hmmm, something smells off... 待って! (Wait a minute!) Did the images slapped on each other when they are on the same point?! Q: Can't you try to just group them together if they fall on the same point?! A: I guess so, but do you really need some "beautiful" infographics just to know whether it's worth it for you to grind up to level 50? Lets try to combine some images and group them together From https://stackoverflow.com/questions/30227466/combine-several-images-horizontally-with-python def combine_images(image_filenames, output_filename, pilmode='RGBA', how='v'):
    imgs    = [Image.fromarray(imageio.imread(i, pilmode=pilmode))
               for i in image_filenames]
    max_shape = sorted( [(np.sum(i.size), i.size) for i in imgs])[-1][-1]
    # Vertical
    if how[0].lower()=='v':
        imgs_comb = np.vstack([i.resize(max_shape) for i in imgs])
    # Horizontal
    elif how[0].lower()=='h':
        imgs_comb = np.hstack([i.resize(max_shape) for i in imgs])
    # Square
    elif how[0].lower()=='s':
        if len(image_filenames) % 2 != 0: # If odd, add a blank image.
            Image.new('RGBA', max_shape).save('blank.png')
            image_filenames += ['blank.png']
        combine_images(image_filenames[:len(image_filenames)//2], 'part1.png', how='h')
        combine_images(image_filenames[len(image_filenames)//2:], 'part2.png', how='h')
        imgs = [Image.fromarray(imageio.imread('part1.png', pilmode=pilmode)),
                Image.fromarray(imageio.imread('part2.png', pilmode=pilmode))]
        scale = len(image_filenames[:len(image_filenames)//2])
        max_shape =(max_shape[0]*scale, max_shape[1]*1)
        imgs_comb = np.vstack([i.resize(max_shape) for i in imgs])
    imgs_comb = Image.fromarray(imgs_comb)
    imgs_comb.save(output_filename) Using the function combine_images list_im = ['max_revives.thumbnail.png', 'max_potions.thumbnail.png', 
           'ultra_balls.thumbnail.png', 'golden_razz_berries.thumbnail.png']
combine_images(list_im, output_filename='rewards-s.png', how='square')
display(JupyterImage(filename='rewards-s.png')) Cool! Now do the plots again. We'll have to group the images together by (x,y) points instead of keeping them in a nice table. def fetch_num_items(level_guide_l, x):
    for r in level_guide_l['rewards']:
        if r.endswith(x):
            return level_guide_l['rewards'][r]
    return 0

ball_pots_revs_ber = [{'levels': l, 
  'potions': fetch_num_items(level_guide[l], '_potions'),
  'revives': fetch_num_items(level_guide[l], '_revives'),
  'balls': fetch_num_items(level_guide[l], '_balls'),
  'berries': fetch_num_items(level_guide[l], '_berries'),
 }  for l in level_guide
]

df_bprb = pd.DataFrame.from_dict(ball_pots_revs_ber) from collections import defaultdict

data_points = defaultdict(list)
    
for idx, row in df_bprb.iterrows():
    x = row['levels']

    for i in row.index:
        if i != 'levels':
            y = row[i]
            if y == 0:
                continue
            data_points[(x,y)].append(
                next(r for r in level_guide[x]['rewards'] if r.endswith(i)) + '.thumbnail.png'
            )

print(data_points) [out]: defaultdict(list,
            {(41, 20): ['max_potions.thumbnail.png',
              'max_revives.thumbnail.png',
              'ultra_balls.thumbnail.png',
              'razz_berries.thumbnail.png'],
             (42, 20): ['max_potions.thumbnail.png',
              'max_revives.thumbnail.png',
              'ultra_balls.thumbnail.png',
              'nanab_berries.thumbnail.png'],
             ...,
             (50, 50): ['max_potions.thumbnail.png',
              'ultra_balls.thumbnail.png'],
             (50, 20): ['max_revives.thumbnail.png']}) Now, we have the images we want to combine for every scatter point data_points_imgs = {}
for k, v in data_points.items():
    fname = f"{'-'.join(map(str, k))}.png"
    if len(v) in [1,2]:
        combine_images(v, output_filename=fname, how='horizontal')
    else:
        combine_images(v, output_filename=fname, how='square')
    data_points_imgs[k] = fname Go, go, go. Plot it! import matplotlib as mpl
import matplotlib.pyplot as plt
from matplotlib.offsetbox import OffsetImage, AnnotationBbox

import seaborn as sns

sns.set(rc={'figure.figsize':(11.7,8.27)})

x, y = zip(*data_points_imgs)

fig, ax = plt.subplots()
ax.scatter(x, y, s=0.01)
plt.xlabel('Level')
plt.ylabel('Rewards')
plt.xlim([40, 51])

ppp = data_points_imgs.values()

for x0, y0, path in zip(x, y,ppp):
    ab = AnnotationBbox(
        OffsetImage(plt.imread(path), zoom=1),
        (x0, y0), frameon=False)
    ax.add_artist(ab) Now, you see the exponential grind and rewards, whatcha gonna do? https://youtu.be/MpaHR-V_R-o?embedable=true Also published . here

Level Requirements for Pokemon Go From 40-50

GraphQL is a modern and flexible data query language that was developed by . It provides an efficient and powerful alternative to traditional REST APIs and has become increasingly popular in recent years. The Remix Framework is a new and innovative approach to building React applications that offers a number of unique features and benefits. Facebook In this blog post, we will explore the process of integrating GraphQL with the Remix Framework. We will cover how to set up the project, add a GraphQL API to the mix, and create Queries to fetch data. By the end of this article, you will have a clear understanding of how to use GraphQL in a Remix React application, and you will see why this is an excellent choice for building modern, scalable, and efficient React applications. Update 02-06-2023: I just that questions why you would want to use Remix and GraphQL together in the first place. It's worth a read! uploaded a new post What is GraphQL? GraphQL is a query language for APIs that was developed by Facebook in 2012. It provides a more efficient and flexible alternative to traditional REST APIs. In a REST API, each endpoint returns a fixed data set determined by the API design. This can lead to over, or under-fetching of data, as well as increased latency, as multiple round trips to the server may be required to retrieve all the necessary information. GraphQL solves these issues by allowing the client to specify precisely what data it needs and receiving only that data in a single request. This results in less data being transferred over the network, reduced latency, and a better developer experience, as the client can retrieve all the necessary data in a single request. Other benefits of using GraphQL include: : GraphQL uses a type system to define the structure of data that is returned from the server, making it easier to catch bugs early in the development process. Strong typing : GraphQL provides a powerful way for clients to explore and test the capabilities of the API. Interactivity : GraphQL has a large and growing community of developers, and there are many open-source tools and libraries available for building and working with GraphQL APIs. Strong community and tooling : GraphQL can be used to fetch data from multiple sources, including databases, microservices, and third-party APIs. Versatility Consequently, GraphQL's advantages make it the prime pick for building robust and efficient APIs that are fit for modern use. What is Remix? The Remix Framework is a new and innovative approach to building React applications. It provides a set of tools and libraries that make it easier to build and manage complex applications while also offering a number of unique features that set it apart from other React frameworks. Remix utilizes Server Side Rendering ( ), a powerful rendering paradigm that moves page content rendering to the back end, cutting down on page latency and client-side bottlenecks. This technology allows Remix to manage the application state more efficiently as well. SSR Loaders and Actions in Remix In the Remix Framework, "Loaders" and "Actions" are essential functions used to manage your application's state and behavior. A Loader function is designed to retrieve and store information from external sources like APIs. This function can be defined on your route for easy access when responding to GET requests in order to get the data you need for server-side rendering. In contrast, action functions are used to control the behavior of your application and can be employed to cause side effects like sending an API request or transitioning to another part of the application. Action functions designated on a route will reply mainly when "modifying" HTTP verbs such as "POST", "PATCH", or "DELETE" are invoked. Typically, these functions are utilized to modify the app's state or underlying data structure. Loaders and Actions work together to provide a straightforward and user-friendly approach to organizing the state and functionality of your application. Furthermore, these tools allow you to concentrate on developing the core business logic instead of wasting time managing data retrieval or worrying about state management complexities. Utilizing Loaders and Actions makes it easier than ever before to create sophisticated yet easily scalable applications! How Remix Routes are different from Single Page App Routes Remix Routes and Single Page App (SPA) routes are two different approaches to routing in React applications. In a traditional SPA, routes are managed on the client side and are typically defined using a library such as React Router. When a user navigates to a different part of the application, the client-side router updates the URL and re-renders the relevant components. This results in a seamless and fast experience for the user but can also result in more complex code, as the client-side routing logic needs to be managed and maintained. In contrast, Remix App Routes are managed on the server side and use a unique approach to routing that differs from traditional SPA routes. When a user navigates to a different part of the application, the server generates a new HTML page, and the browser navigates to the new URL. This results in a slightly slower navigation experience but provides a number of benefits, including better SEO, improved performance for first-time users, and better accessibility for users with slow or unreliable internet connections. Why does this matter for a Remix GraphQL application? In a traditional SPA, a React component that needs data from a GraphQL API endpoint would use something like the Apollo GraphQL client to retrieve data. The component would most likely define the "useQuery" hook to manage data retreival when the component is mounted and rendered on the client side. The following code is an example of a classic React app using the apollo client to fetch data from GraphQL. import React, { useEffect, useState } from 'react';
import { useQuery } from '@apollo/client';
import gql from 'graphql-tag';

const GET_USERS = gql`
  query {
    users {
      id
      name
      email
    }
  }
`;

const Users = () => {
  const { loading, error, data } = useQuery(GET_USERS);
  const [users, setUsers] = useState([]);

  useEffect(() => {
    if (data) {
      setUsers(data.users);
    }
  }, [data]);

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error!</p>;

  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>
          {user.name} ({user.email})
        </li>
      ))}
    </ul>
  );
};

export default Users; In contrast to a traditional React SPA, Remix applications require fetching data and page rendering to be delegated on the server side. Although loading data in the client is an option for this application, it's typical practice with Remix to leave these tasks up to the server by defining loaders and actions on the application app routes. As we seek to incorporate GraphQL into our remix app, this presents an intricate test. We must integrate GraphQL with the loader function or action function in our routes for successful SSR flow when making GraphQL requests. Setting up the Remix project We are utilizing the Blues Stack template from Remix as our jumping-off point. This gives us a head start with a plethora of boilerplate code, comprising an application for taking notes, plus a Prisma schema and REST-like endpoints. However, to tailor it to our needs, we will be modifying those REST-like endpoints into GraphQL requests and modifying how we extract data via loader and action functions. Let's create the project! Create the remix app Open up a terminal and type in the following command. Then answer the questions as detailed in the example below. ❯ npx create-remix@latest --template remix-run/blues-stack
? Where would you like to create your app? remix-graphql
? TypeScript or JavaScript? TypeScript
? Do you want me to run `npm install`? Yes Install dependencies In order for us to continue with our tutorial, we must install a few dependencies. Primarily, the Apollo Client and some tooling will be necessary - all of which can be accessed by running this single command from within your new project directory. ❯ npm install @apollo/client @graphql-tools/schema @graphql-tools/utils Adding Apollo Client to the Remix App Now we are going to start editing some code! Let's start with adding the GraphQL schema to our app. Define the schema and queries To start, create a directory labeled 'graphql' in the folder. Then add a file named , where all of your GraphQL queries and schema will be defined! app schema.server.ts The suffix acts as a hint to the Remix project, indicating that it should exclude this file during client-side code bundling, thus ensuring these files are solely operated on the server side of your application. .server.ts // ~/graphql/schema.server.ts
import { gql } from '@apollo/client';
import { makeExecutableSchema } from '@graphql-tools/schema';
import { resolvers } from './resolvers.server';

const typeDefs = gql`
  type Note {
    id: String
    title: String
    body: String
    createdAt: String
    updatedAt: String
    userId: String
  }

  type Query {
    notes(userId: String!): [Note]
  }
`;

export const schema = makeExecutableSchema({
  typeDefs,
  resolvers,
}); In order to gain access to a user's notes, we declared the GraphQL schema type and built the query that requires a . Note notes userId Define the resolvers Next, we must create an extra file in the "graphql" directory entitled . This is where our resolver functions will be established. resolvers.server.ts // ~/graphql/resolver.server.ts
import type { IResolvers } from '@graphql-tools/utils';
import { prisma } from '../db.server';

export const resolvers: IResolvers = {
  Query: {
    notes: async (_: any, { userId }: { userId: string }) => {
      return prisma.note.findMany({
        where: { userId },
        orderBy: { updatedAt: 'desc' },
      });
    },
  },
}; This is where the resolver function gets defined. It will be executed whenever we make a query call. If you take a look at the existing , you'll notice that this code looks quite similar to what's in the function. This isn't a mistake, as all we had to do was move it over here and delete any unnecessary code like the "select" parameter since everything should come back (GraphQL decides which fields need to be returned). notes notes ~models/note.server.ts getNoteListItems Create the Apollo Client Now, we arrive at the file that is responsible for assembling all of our components together and defining an Apollo Client instance with the Schema Link system from the Apollo Client package. client.server.ts // ~/graphql/client.server.ts
import { ApolloClient, InMemoryCache } from '@apollo/client';
import { SchemaLink } from '@apollo/client/link/schema';
import { schema } from './schema.server';

export const client = new ApolloClient({
  cache: new InMemoryCache(),
  ssrMode: true,
  link: new SchemaLink({ schema }),
}); Utilizing the client we created, our queries can now be successfully executed on the server side. Use the client to fetch data from the server-side API Next, let's modify an API call to incorporate the GraphQL queries we designed earlier. // ~/models/note.server.ts
...
export function getNoteListItems({ userId }: { userId: User["id"] }) {
  return client.query<{ data: { notes: { id: string; title: string }[] } }>({
    query: gql`
      query getNotes($userId: String!) {
        notes(userId: $userId) {
          id
          title
        }
      }
    `,
    variables: { userId },
  });
}
... Display the data Lastly, we will amend the route to effectively use the retrieved data. notes.tsx // ~/routes/notes.tsx
import type { LoaderArgs } from '@remix-run/node';
import { json } from '@remix-run/node';
import { Form, Link, NavLink, Outlet, useLoaderData } from '@remix-run/react';

import { getNoteListItems } from '~/models/note.server';
import { requireUserId } from '~/session.server';
import { useUser } from '~/utils';

export async function loader({ request }: LoaderArgs) {
  const userId = await requireUserId(request);
  const noteListItems = await getNoteListItems({ userId });
  return json({ noteListItems });
}

export default function NotesPage() {
  const data = useLoaderData<typeof loader>();
  const user = useUser();

  return (
    <div className="flex h-full min-h-screen flex-col">
      <header className="flex items-center justify-between bg-slate-800 p-4 text-white">
        <h1 className="text-3xl font-bold">
          <Link to=".">Notes</Link>
        </h1>
        <p>{user.email}</p>
        <Form action="/logout" method="post">
          <button
            type="submit"
            className="rounded bg-slate-600 py-2 px-4 text-blue-100 hover:bg-blue-500 active:bg-blue-600"
          >
            Logout
          </button>
        </Form>
      </header>

      <main className="flex h-full bg-white">
        <div className="h-full w-80 border-r bg-gray-50">
          <Link to="new" className="block p-4 text-xl text-blue-500">
            + New Note
          </Link>

          <hr />

          {data.noteListItems.data.notes.length === 0 ? (
            <p className="p-4">No notes yet</p>
          ) : (
            <ol>
              {data.noteListItems.data.notes.map((note) => (
                <li key={note.id}>
                  <NavLink
                    className={({ isActive }) =>
                      `block border-b p-4 text-xl ${isActive ? 'bg-white' : ''}`
                    }
                    to={note.id}
                  >
                    📝 {note.title}
                  </NavLink>
                </li>
              ))}
            </ol>
          )}
        </div>

        <div className="flex-1 p-6">
          <Outlet />
        </div>
      </main>
    </div>
  );
} There is no need to alter the notes page loader function at all! We only needed to make some slight modifications to the data accessor logic because of a minor change in the data's structure. Where to go from here That was just the beginning. We have now modified Remix to utilize GraphQL with a single GraphQL query. You may also expand on this by adding more queries for individual s and mutations to create or edit them as needed. Additionally, you can also experiment with logging in and out via GraphQL queries and mutations if desired! There is still plenty left that could be done, but this should serve as an excellent starting point. Note I would also suggest the following resources for additional GraphQL/Remix integration information. I found them very helpful. (useCSV) A quick field guide to using Remix with Apollo GraphQL (LogRocket) Creating a Remix app with GraphQL Also published here.

How to Use GraphQL with the Remix Framework

Previously I wrote , this story will cover other details of its use. about RTK Imagine we need to display the same kind of data but from different resources depending on the incoming parameter value. In this case, we will have the component with two hooks that handle requests and receive data. Basically, the representation of API looks like this: export const configApi = baseApi.injectEndpoints({
    endpoints: build => ({
        fetchConfigDetails: build.query<IConfig[], IBaseRequest>({
            query: arg => `/config-details`,
            transformResponse: (x: IResponse<IConfig[]>) => x.result,
            providesTags: ['ConfigDetails'],
        }),
        fetchConfigRunDetails: build.query<IConfig[], IRunRequest>({
            query: arg => `/${arg.id}/config-details`,
            transformResponse: (x: IResponse<IConfig[]>) => x.result,
            providesTags: ['ConfigRunDetails'],
        }),
    }),
    overrideExisting: true,
}); It has two endpoints and the main difference between them is the argument ‘id’, so actually the resources are different. So the cache will be also different, one for and one for . ConfigDetails ConfigRunDetails For the clarification on where hooks take their names, I will provide the next example: export const {
    useFetchConfigDetailsQuery,
    useFetchConfigRunDetailsQuery,
} = configApi; The hook name consists of the prefix ‘use’, the endpoint name , and the postfix of the request’s type (a function that is used to create the endpoint) ‘build.query’ → . fetchConfigDetails useFetchConfigDetailsQuery And these two hooks will be used in one component: const RowResultsDetails: React.FC<IProps> = () => {
    const { id } = useParams<IRouteParams>();

    const fetchDetails = useFetchConfigDetailsQuery(
        { },
        {
            skip: !!id,
            selectFromResult: ({ data, isFetching }) => ({
                isFetching: isFetching,
                data: selectConfigDetails(data),
            }),
        }
    );
    const fetchRunDetails = useFetchConfigRunDetailsQuery(
        { id },
        {
            skip: !id,
            selectFromResult: ({ data, isFetching }) => ({
                isFetching: isFetching,
                data: selectRunConfigDetails(data),
            }),
        }
    );

    const { data, isFetching } = id ? fetchRunDetails : fetchDetails;

    return (
        <div>
            <Section.Title>({data.length})</Section.Title>
            ...
        </div>
    );
} As you may know, hooks in React must have the same order and can’t be inside some ‘if else’ condition. In RTK because of such constraint, there is a special property ‘skip’ direct in the hook second parameter (options). With this option, you can tell RTK to execute or not execute the hook. Additionally, for render optimization, RTK provides the possibility to use reselect library to choose the data that you need in this particular component. In other words, and are selectors to memoize data from the cache. If the request will be invoked and selected data is not changed, nothing will happen in the component. selectConfigDetails selectRunConfigDetails The selector actually has no difference from the store selector except you don’t provide the state to it. const emptyArray = [];

export const selectConfigDetails = createSelector(
    [
        (data?: IConfig[]) => data
    ],
    (data) => data?.filter(c => c.isAvailable) ?? emptyArray
); An important point here is if you are using the same selector for both hooks it will cause redundant rerender. In other words ‘selector’ is unique and remembers the result. For the same selector, there will be two different values in the result. to not rerender the component frequently. As well if you prefer to use the hook to memoize data, in this scenario there needs to be two different usages. Be careful useMemo useMemo

More Features of the RTK Query

According to the , “ is a powerful data fetching and caching tool. It is designed to simplify common cases for loading data in a web application, .” Redux Toolkit RTK Query eliminating the need to hand-write data fetching & caching logic yourself With the help of RTK Query, you can significantly decrease the number of actions, reducers, and side effects. Right out of the box, there is the possibility to query every N seconds, auto cache, and send repeated requests in the case when cache became invalid. It’s definitely a cool library however it’s sadly not applicable to all of the use cases possible with an API. This is because it’s managing both the state and all mutations. For example, I once tried to use it to query some table data and change it -- in other words, basic CRUD operations. I was faced, however, with an issue when I wanted to add additional data to objects and update that data calling the API. without For example, if I want to handle a few basic requests via RTK Query and not include manage state, or to not write reducers logic, etc. For better code readability, I realized it’s possible to use the and created : API splitting approach baseApi export const baseApi = createApi({
    reducerPath: 'baseApi',
    tagTypes: ['Notifications'],
    baseQuery: fetchBaseQuery({ baseUrl: getBaseUrl() }),
    endpoints: () => ({}),
}); For the API, which I need to query, I then wrote : notificationsApi const notificationsApi = baseApi.injectEndpoints({
    endpoints: build => ({
        fetch: build.query<INotification[], INotificationBaseRequest>({
            query: buildUrl,
            transformResponse: (x: IResponse<INotification[]>) => x.result,
            providesTags: ['Notifications'],
        }),
        remove: build.mutation<void, IRemoveNotificationRequest>({
            query: arg => ({
                url: buildUrl(arg),
                method: 'DELETE',
            }),
            invalidatesTags: (_: any, id: any) => [{ type: 'Notifications', id }],
        }),
        removeAll: build.mutation<void, INotificationBaseRequest>({
            query: arg => ({
                url: buildUrl(arg),
                method: 'DELETE',
            }),
            invalidatesTags: ['Notifications'],
        }),
    }),
});

export const { useFetchQuery, useRemoveMutation, useRemoveAllMutation } = notificationsApi; Where is a simple function that combines URL arguments in one string, such as notification ID to buildUrl ‘baseUrl/notifications/{id}’. In the section I introduced three operations that I needed to use. endpoints The operation retrieves data by . fetch GET request The data looks like an array: [ { id: number; name: string; message: string; }, ... ] This array I can easily get in component via the hook. useFecthQuery const { data, isLoading } = useFetchQuery({ ...params }); Here, I don’t need to implement logic that actually describes the status of the HTTP request. isLoading It is already there in the hook. However, please be careful, the is for the first query only. isLoading For common cases is more appropriate. The hook will automatically request data (in case if there is no data or the cache is invalid). isFetching More about cache. The operation is used to send a DELETE request and remove one notification. remove The is there to remove only one entry from the array by id. invalidatesTags const [remove] = useRemoveMutation(); Use it without dispatch, just as it is. You can call on a button click or another user action. As well as the operation. remove removeAll const [removeAll, { isLoading: isDeleting }] = useRemoveAllMutation(); Also in such an operation, there is a possibility to use properties to understand the status of HTTP requests. The main difference between and is that in removeAll I remove the whole cache. remove removeAll That’s pretty much it, all data stored, actions automatically generated. No need to manage it manually… or so I thought. But I understood that I want to extend objects in the array, to have an additional property: . It can not be done easily - just changing the current state of cached objects. isCollapsed The RTK Query manages the state by itself and I can’t create another action to handle such behavior. However, I found two ways how to solve it! First of all, I could create my own state , where there will be additional data stored, of course, I need to or and add more actions. NotificationState createSlice createReducer Or I will not use RTK Query, and all will be done via where objects will be extended with the required fields. createSlice The general takeaway here is, if for some reason you need to extend objects, or in your API, objects come in different schemas and you want to store it all in one place, it is better to manage the state by yourself from the begining.

The RTK Query, API Splitting Approach, and the Nuances of "Making Life Simpler"

Dependency injection (DI) is a wonderful thing. Simply add your dependency as a parameter to the constructor (most commonly) of your class, register it with you DI container, and away you go - the DI container will manage the rest. Some of the key benefits of DI are: greater testability, greater maintainability, and greater reusability. : { { ( dbContent = MyDbContext())
        {
            dbContext.Orders.Add(order);
            dbContent.SaveChanges(); Ok();
        }
    } { ( dbContext = MyDbContext())
        { orders = dbContext.Orders.ToList(); JsonResult(orders);
        }
    }
} : { MyDbContext _dbContext; {
        _dbContext = dbContext;
    } {
        _dbContext.Orders.Add(order);
        _dbContent.SaveChanges(); Ok();
    } { orders = _dbContext.Orders.ToList(); JsonResult(orders);
    }
} // without DI public class OrderController Controller ActionResult ( ) public Post Order order using var new return ActionResult ( ) public Get using var new var return new // with DI public class OrderController Controller private readonly ( ) public OrderController MyDbContext dbContext ActionResult ( ) public Post Order order return ActionResult ( ) public Get var return new However, I recently came across a use case where DI can be a real pain - dependency injection in inherited classes. The Problem I have recently been working a lot with the package, using it's request/request handler pattern to issue commands in the system (inspired by ). Mediatr Jason Taylor's Clean Architecture solution I typically create a RequestHandler base class that contains common dependencies and functionality. Each concrete request handler can then inherit from this base class. < , > : < , > : < >
{ {
        DbContext = dbContext;
    } IApplicationDbContext DbContext { ; } ;
} MyRequestHandler : RequestHandler<MyRequest, MyResponse>
{ { } { }
} public abstract class RequestHandler TRequest TResponse IRequestHandler TRequest TResponse where TRequest IRequest TResponse ( ) public RequestHandler IApplicationDbContext dbContext protected get Task<TResponse> ( ) public abstract Handle TRequest request, CancellationToken cancellationToken public ( ) : ( ) public MyRequestHandler IApplicationDbContext dbContext base dbContext Task<MyResponse> ( ) public override Handle MyRequest request, CancellationToken cancellationToken // handler logic The problem comes when I want to add more dependencies to the base class. Now I have to go through to every single concrete request handler and update the constructor to take the new dependency as well. Fortunately, the code will not compile if I miss one, so there is no risk of a runtime error, but it is still incredibly tedious work to have to update every single request handler. Also, you can end up with very large constructors, which obscures the intention of the class. < , > : < , > : < >
{ {
        DbContext = dbContext;
        CurrentUser = currentUser;
    } IApplicationDbContext DbContext { ; } ICurrentUser CurrentUser { ; } ;
} MyRequestHandler : RequestHandler<MyRequest, MyResponse>
{ { } { }
} public abstract class RequestHandler TRequest TResponse IRequestHandler TRequest TResponse where TRequest IRequest TResponse ( ) public RequestHandler IApplicationDbContext dbContext, ICurrentUser currentUser protected get protected get Task<TResponse> ( ) public abstract Handle TRequest request, CancellationToken cancellationToken public ( ) : ( ) public MyRequestHandler IApplicationDbContext dbContext, ICurrentUser currentUser base dbContext, currentUser Task<MyResponse> ( ) public override Handle MyRequest request, CancellationToken cancellationToken // handler logic The Solution - Dependency Aggregates The solution to this problem is really quite simple. Rather than injecting the dependencies directly, create a new class that contains the dependencies (known as an aggregate) and inject that instead. {
    IApplicationDbContext DbContext { ; }
    ICurrentUser { ; }
} : { {
        DbContext = dbContext;
        CurrentUser = currentUser;
    } IApplicationDbContext DbContext { ; } ICurrentUser CurrentUser { ; }
} < , > : < , > : < >
{ {
        DbContext = aggregate.DbContext;
        CurrentUser = aggregate.CurrentUser;
    } IApplicationDbContext DbContext { ; } ICurrentUser CurrentUser { ; } ;
} MyRequestHandler : RequestHandler<MyRequest, MyResponse>
{ { } { }
} public interface IDependencyAggregate get get public class DependencyAggregate IDependencyAggregate ( ) public DependencyAggregate IApplicationDbContext dbContext, ICurrentUser currentUser public get public get public abstract class RequestHandler TRequest TResponse IRequestHandler TRequest TResponse where TRequest IRequest TResponse ( ) public RequestHandler IDependencyAggregate aggregate protected get protected get Task<TResponse> ( ) public abstract Handle TRequest request, CancellationToken cancellationToken public ( ) : ( ) public MyRequestHandler IDependencyAggregate aggregate base aggregate Task<MyResponse> ( ) public override Handle MyRequest request, CancellationToken cancellationToken // handler logic Now if I want to add a new dependency, the only places that I need to change the code are in the DependencyAggregate class and the RequestHandler base class (I don't need to make any changes to the inherited classes). Conclusion In this post I have described a simple method for managing dependency injection in inherited classes, by creating a dependency aggregate class to inject into the base class. This ensures that new dependencies can easily be introduced with having to make changes to every inherited class. I post mostly about full stack .NET and Vue web development. To make sure that you don't miss out on any posts, please follow this blog and . If you found this post helpful, please like it and share it. You can also find me on . subscribe to my newsletter Twitter Previously published at https://samwalpole.com/handling-dependency-injection-in-inherited-classes

How to Create a Dependency Aggregate Class to Manage DI: Clearly Exemplified

Software development is a complex task and as a developer you gain nothing from "reinventing the wheel". I'm a firm believer that you should make your life as easy as possible as a developer, by using tried and tested packages where possible; it will take so much headache out of your development experience. Below are a few of the packages that I use in most of my projects. I believe they make for an easier development experience and make my code much easier to maintain. I would recommend that you consider them for your own projects in the future. If I've missed a package that you think is super useful, please share in the comments section below. My top 4 Nuget packages are: Automapper Mediatr Swagger Fluent Validation Automapper Most software applications consist of different layers that each have their own concerns. For example, a common pattern is the . Since each layer has its own concerns and should be loosely coupled to the other layers, each layer normally has its own objects models too. 3-layered data access, logic, and presentation model For example, a user object in the logic layer may contain methods that define the behaviour of that model, whereas a user object in the presentation layer may only contain the properties necessary to be displayed in the UI. Therefore, each time data is passed up and down between layers, the objects of one layer must be converted to the objects of the next layer. For example, in an ASP.NET Core MVC application, you may typically see something like this in a controller action. : { IUserService _userService; {
        _userService = userService;
    } { domainUser = _userService.Get(id); presentationUser = PresentationUser
        {
            Id = domainUser.Id,
            FirstName = domainUser.FirstName,
            LastName = domainUser.LastName, }; JsonResult(presentationUser);
    }
} public class UserController Controller private readonly ( ) public UserController IUserService userService Task<IActionResult> ( ) public async GetUser id int var await var new // etc return new This process is known as mapping, and I'm sure you'll agree that it can get incredibly boring and tedious to write such code, not to mention it convoluting your code with trivial procedures. This is where comes to save the day (and your sanity). It is a convention-based object-object mapper written by and it really takes a lot of the pain out of mapping objects. It really takes minimal configuration in most cases and results in much cleaner code with all of the trivial mapping code removed: Automapper Jimmy Bogard : { IUserService _userService; IMapper _mapper; {
        _userService = userService;
        _mapper = mapper;
    } { domainUser = _userService.Get(id); presentationUser = _mapper.Map<PresentationUser>(domainUser); JsonResult(presentationUser);
    }
} public class UserController Controller private readonly private readonly ( ) public UserController IUserService userService, IMapper mapper Task<IActionResult> ( ) public async GetUser id int var await var return new To find out more, and . read the Automapper documentation find it in the NuGet Gallery Mediatr Mediatr is another package by and is an implementation of the . The mediator pattern is designed to reduced coupled between classes by having them interact through an intermediate mediator class. The result is easier-to-maintain code with fewer dependencies. Jimmy Bogard mediator software design pattern All interactions in Mediatr consist of a class containing the data that you want to send and a handler class for that data. There are two different types of interaction, a request and a notification. A request expects to have just one handler implementation and can expect a value to be returned from the request. : < >
{ UserId { ; ; }
} : < , >
{ IUserService _userService; {
        _userService = userService;
    } { _userService.Get(request.UserId);
    }
} : { IMediator _mediator; {
        _mediator = mediator;
    } { request = UserRequest { UserId = id }; user = _mediator.Send(request); JsonResult(user);
    }
} public class UserRequest IRequest DomainUser public int get set public class UserRequestHandler IRequestHandler UserRequest User private readonly ( ) public UserRequestHandler IUserService userService Task<User> ( ) public async Handle UserRequest request, CancellationToken ct return await public class UserController Controller private readonly ( ) public UserController IMediator mediator Task<IActionResult> ( ) public async GetUser id int var new var await return new A notification is similar to an event. It can be broadcast to multiple handlers, each of which can do their own logic based on the notification. Notifications do not return any value. : { UserId { ; ; }
} : < >
{ { }
} : < >
{ { }
} : { IMediator _mediator; {
        _mediator = mediator;
    } { request = UserRequest { UserId = id }; user = _mediator.Send(request); notification = UserRetrievedNotification { UserId = id }; _mediator.Publish(notification); JsonResult(user);
    }
} public class UserRetrievedNotification INotification public int get set public class UserRetrievedNotificationHandler1 INotificationHandler UserRetrievedNotification Task ( ) public async Handle UserRetrievedNotification notification, CancellationToken ct // do some logic public class UserRetrievedNotificationHandler2 INotificationHandler UserRetrievedNotification Task ( ) public async Handle UserRetrievedNotification notification, CancellationToken ct // do some more logic public class UserController Controller private readonly ( ) public UserController IMediator mediator Task<IActionResult> ( ) public async GetUser id int var new var await var new await return new Another really cool feature of Mediatr is that you can configure a pipeline to actions to run before and after a request/notification, so you could implement exception handling or logging automatically for every request. To find out more, and . read the Mediatr documentation find it in the NuGet Gallery Swagger Swagger is a must-have if you're creating APIs using ASP.NET Core. It automatically scans all of your controllers and actions to generate an , which makes it super easy to visualise and maintain all of your API endpoints. OpenAPI document Swagger is also really useful for testing as it allows you to send requests to each of your endpoints via the browser. There's not really much more to say than that, since it requires hardly any configuration and generates everything for you. For instructions on how to install it, I would recommend . To find out more, and . this Microsoft article read the Swagger documentation find it in the NuGet Gallery Fluent Validation When receiving any input from a user, it is important to make sure that the data that they have supplied is valid and complete. You can do this to some extent on the front end using (and you definitely should do this for a better user experience), but all input should be validated again on the backend since there are a number of ways that a user could bypass the client-side validation (whether maliciously or not). client-side form validation There are a number of ways that you could set up validation on the server, but ultimately it comes down to checking each property of the input class against a set of rules. The logic for these rules will need to be defined for each input class, and, similar to the object mapping example, can be rather boring, repetitive and trivial. : { IUserService _userService; {
        _userService = userService;
    } { (user ) ArgumentNullException(); ( .IsNullOrEmpty(user.FirstName)) ArgumentException(); (user.FirstName.Length > ) ArgumentException(); result = _userService.Create(user); JsonResult(result);
    }
} public class UserController Controller private readonly ( ) public UserController IUserService userService Task<IActionResult> ( ) public async CreateUser User user if is null throw new if string throw new if 50 throw new // etc var await return new Fluent Validation makes this whole process much more pleasant by using a to configure validation in a much less tedious way. The logic for many common types of validation is already defined, along with helpful error messages, although this can all by configured further if you wish. fluent interface pattern : < >
{ {
        RuleFor(u => u.FirstName).NotEmpty().MaximumLength( );
        RuleFor(u => u.LastName).NotEmpty().MaximumLength( ); }
} public class UserValidator AbstractValidator User ( ) public UserValidator 50 50 // etc To find out more, and . read the Fluent Validation documentation find it in the NuGet Gallery Conclusion These were my top 4 Nuget packages that I use in almost all of my projects. I find that they make for a much nicer development and maintenance experience, and I hope that you will find them useful too. If you know any other packages that you think should have been in this list, please let me know in the comments section below. I post mostly about full stack .NET and Vue web development. To make sure that you don't miss out on any posts, please follow this blog and . If you found this post helpful, please like it and share it. You can also . subscribe to my newsletter find me on Twitter Previously published at https://samwalpole.com/my-top-4-nuget-packages-for-aspnet-core

The Top 4 Nuget Packages According to This Software Developer

We have created this blog post for business stakeholders managing the development of a software system or product, those looking to find ways to reduce cost and time to market. This post will be useful for those whose technical background is a bit outdated or isn’t sufficient to make that judgment call. We will look at how to approach architecture planning so that the product is scalable and the money is spent wisely. Also, we will show the example of how CQRS can help in the implementation of client applications and whether microservices is indeed the panacea. Why should business care about software architecture It is impossible to consider any software in isolation from the business context. Software products and systems are built to automate processes, improve customer experience, and assist the business to achieve KPIs. Software architecture is created with the business processes in mind, thus being a prerequisite for seamless product development, scaling, and optimization. Cost Good software architecture makes it cheaper to develop and maintain products due to the creation of reusable elements. Furthermore, it provides a sound basis for communication and straightforward decision making further down the line. Thus, it reduces negotiation times and boosts team effectiveness. In case architecting is ignored, making changes to the product in the later stages of the development process will be much more expensive. Risk mitigation The organization of the system, which business processes it takes part in and how it interacts with other systems and applications is determined by the architecture. Effective architecture identifies design risks and allows timely mitigation. Competitive advantage The effective architecture enables faster time to market. The ability to reduce time to market is vital in the environment of highly competitive markets. A business that is able to meet the needs and demands of the market ahead of others gains a competitive advantage. Adaptable business-model The highly competitive and dynamic environment also dictates that the business is adequately prepared when things change. The ability to transform the business model and introduce changes to the product is contingent on the well-thought-out architecture. The architecture roadmap should be aligned with the product roadmap and strategic plans for the business. Otherwise, strategic adaptability will be lost. Technical solutions Product architecture determines the technical solutions and standards. The choice of programming language, platform, framework, and tools determine the level of current and future cost. Technical solutions also affect the speed at which changes can be introduced to the product. This is critical in a situation when MVP isn’t coping with the influx of users. Two extremes Inevitably a question pertaining to architecture design arises — when should one start considering it, what style and patterns to use, and to what extent should the architecture be thought out? We have come across different points of view. On the one side of the spectrum, there is “minimum viable product does not imply an architecture since it is put together as quickly as possible”, on the other — “microservices should be used from the outset so that scalability and flexibility are at the very core of the product”. These are two extremes, each potentially being quite costly. Below we will look at how to find a middle way. Big Ball of Mud A big ball of mud — a type of system with chaotic architecture — is not uncommon. Such systems take shape over time due to a lack of architecture design and planning. It all starts with a request by a business stakeholder: “we just need to get the first users to sign up, we’ll figure out later what to do with retention and how to improve the product.” Iterative and incremental development is widely used. Generally, MVP is developed without thorough architecture design, and oftentimes even without paying much attention to nonfunctional requirements. This is followed by the series of iterations to incrementally add capabilities. Sometimes this results in technical debt and a system that can hardly function, which requires continuous fixing. We know of many cases when an architectural focus was lacking. Every time that would lead to repercussions costing hefty amounts to correct. For example, a product crashing while not being able to cope with the large user load. Consequently, this leads to the team working long hours trying to put out the fires; the number of churned customers grows. The business fails to take off. In other instances, the entire system may require re-coding. It takes more time and effort than all the preceding development work combined. Worst of all, the users have to learn how to use the system all over again, causing frustration and damaging loyalty on their part. As a result, jeopardizing future sales. Microservices isn’t the magic pill What is microservices There are different approaches to architectural design. Microservices — one of the possible styles of architecture. Microservices are opposed to a monolithic architecture, in which different components are combined into a single indivisible unit. Microservice architecture is created in small, independent, modular services. Each service is responsible for a specific task corresponding to a business capability. Services interact through the API (application program interface) — that is an intermediary that links all the elements together. Each API is programmed to fulfill a specific business goal. Using separate services allows you to use the most appropriate technical stack for each specific task. What to pay attention to Microservices is a rather popular approach to designing system architecture. Moreover, some clines insist on building architecture using microservices from the very outset, not knowing that this might be a very expensive approach. To reap the benefits, one should be able to design microservice in the right way. It isn’t enough to define a few independent modules and say that’s microservices. When designing a microservice architecture, several concerns need to be addressed. For a start, how to trace a sequence of calls to different services that resulted in a mistake? Or how to identify which service is a bottleneck in the work of the entire system? Some of these concerns can be addressed with various degrees of success either by ready-made infrastructure solutions (for example, Elastic for logging) or custom infrastructure services. Another thing to keep in mind is data integrity. Therefore, it is necessary to establish mechanisms for ensuring data integrity in advance. Unfortunately, this is often overlooked, which leads to unpleasant consequences in the form of data loss or desynchronization. Moreover, in the early stages of the design process, segregating the system into independent services is a hard task at hand. The structure of the subject field is vague at this point and the exact functionality isn’t clear. Consequently, inappropriate segregation of services will lead to issues and additional costs when implementing required scenarios of work of the system. In some cases, the system simply will not function adequately. Microservices may cost an arm and a leg Depending on the scale of a system, the costs of deploying infrastructure for several services in several configurations, performance, and scalability checks may cost quite a hefty amount. Smaller projects for sure will cost less but these are expenses that are not necessarily justifiable. More often than not, large investments in the architecture design at the early stages of product development are not justified. When working in a situation of uncertainty it’s hard to tell how many customers will get on board, whether the product will take off, or the business will close down. A well thought out architecture is the foundation of a successful product A competent decomposition and description of the business capability holds a central place in the designing of a microservices architecture. Inadequate decomposition of the system into loosely coupled services may hinder revisions and make it impossible to trace and verify all system behavior scenarios. This will lead to failures in snowballing. To avoid this, a high level of understanding of how the system will work on all the levels, who and how will be using it is required. Therefore, it is critical to start thinking of and put a vision of the architecture at the very early stages of product design. Example Say, we build an e-commerce website. Good user experience is shaped by many things. Not the least by accurate order assembly by the Order Picker at the warehouse, convenient online payment and delivery options available to the customer. For that, a thought out the user interface for warehouse staff is required, as well as integration with payment systems and warehouse logistics system. That is underpinned by a thorough understanding of at least the main business processes. Failure to capture business processes may result in omitting a big part of the requirements. In turn, this will result in an impractical system. Moreover, additional resources will be needed to refine the system. These are the expenses that otherwise could have been avoided. The lack of funds is not uncommon in such situations since the money has been spent on features that were not relevant at the time. Without a thorough understanding of how the system services interact with one another, we may start building the wrong functionality at the wrong time. An example of such functionality maybe a CRM system at a time when the customer does not require a unique functionality and a ready-made solution can be used. And only after having studied and understood the environment, can we justifiably decide on the choice of software architecture and decomposition of the system into loosely coupled services, etc. So, where to start? It is highly recommended to hold a one- or two-day workshop with a customer to not only define architectural solutions but also low-fidelity system design and main use scenarios. In the case of startups, an extremely important step is to fill out a so that all the stakeholders understand the viability of the business idea. One of the artifacts of the workshop would be a document describing non-functional requirements for the system. Business Model Canvas One of the outcomes of the workshop may be the decision to pull the plug on the project: it will help stakeholders see the shortcomings of the business idea without spending time and money on technical implementation. It may sound counterproductive, but even such an outcome can build a better understanding and trust between the client and the technical team. Is the game worth a candle? Absolutely! It costs as little as 2 intensive days of work the team. If this step is left out, the majority of the mistakes in product development will cost considerably more to correct. Over time, a business may change in response to external circumstances. For example, businesses all over the world are facing drastic changes right now. The world, as we know it, will never be the same again due to the pandemic of Covid-19. Businesses should always be ready to adapt and change their business models. As mentioned above, this flexibility is underpinned by an effective architecture and by means of tried and tested practices, such as the CQRS pattern. For instance, using CQRS at the logical level at the beginning of the design process will enable us to physically locate the services as the business and product scale. This, in turn, will enable the reuse of the functionality by splitting it into independent components. At the early stages, it is not that important to have services physically segregate. However, if you attempt to do that early on you may waste resources on monitoring and implementing distributed transactions and other dependencies that are not yet essential at the stage. CQRS at the logical level CQRS definition CQRS (Command-Query Responsibility Segregation) is a popular and widely used software architecture design pattern. It implies that all methods (i.e. certain sets of actions) in a program can be of two types: either requests that do not alter the state of the program or commands that alter the state of the program. In other words, queries can only read data, while commands update data. What we did In this , we had a task to develop a system for a client managing a fleet of sea vessels. The software was to help our client to optimize and manage the automation of business processes. The client was very specific about the strict timelines and restricted budget so we had to find a way to deliver the system fast and in a cost-efficient manner. We opted for the approach of implementing CQRS at the level of logical architecture. project By observing the basic principles of SOLID, namely Dependency Inversion and Dependency Injection, and correct Inversion of Control Containers, all the commands and queries become easily manageable elements which can be reassembled elsewhere in the system. The diagram depicts 3 parts of the system that can work similarly to the Model: Interaction of the Admin Office Desktop App with the Model Interaction of the Ship Desktop Mechanic App with the Model Interaction of the SyncService with the Model We noticed that the users, who use the Admin Office Desktop App in the office, more often read data from the vessels rather than make any data entries. And the users who are on board the vessels in the offline zone, on the contrary, more often submit data rather than read. Why does it matter? It matters because whilst the architecture, as it is at this stage, is the foundation for further scalability of the system, it certainly has a greater potential to make further development, scalability, and maintenance of the system cheaper and trouble-free. If need be, it would be significantly easier to single out query contexts and build services with the DB optimized to enable reads, as well as to single out command contexts into separate services. Examples of segregation The following are a few examples of the main # C classes that you can use in your projects. {
      IQueryHandler<TQuery, TResult> CreateQueryHandler<TQuery, TResult>();
 
      IAsyncQueryHandler<TQuery, TResult> CreateAsyncQueryHandler<TQuery,
TResult>();
      ICommandHandler<TCommand> CreateCommandHandler<TCommand>();
 
      IAsyncCommandHandler<TCommand> CreateAsyncCommandHandler<TCommand>();
    } < >
    { Execute(TCommand command);
    } < , >
    {
        TResult Execute(TQuery query);
    } : { readonly IResolutionRoot _resolutionRoot; NinjectFactory(IResolutionRoot resolutionRoot)
        {
            _resolutionRoot = resolutionRoot;
        } IAsyncCommandHandler<TCommand> CreateAsyncCommandHandler<TCommand>()
        { _resolutionRoot.Get<IAsyncCommandHandler<TCommand>>();
        } IAsyncQueryHandler<TQuery, TResult> CreateAsyncQueryHandler<TQuery, TResult>()
        { _resolutionRoot.Get<IAsyncQueryHandler<TQuery, TResult>>();
        } ICommandHandler<TCommand> CreateCommandHandler<TCommand>()
        { _resolutionRoot.Get<ICommandHandler<TCommand>>();
        } IQueryHandler<TQuery, TResult> CreateQueryHandler<TQuery, TResult>()
        { _resolutionRoot.Get<IQueryHandler<TQuery, TResult>>();
        }
    } /// <summary> ///   Universal factory for creating queries. ///   To be implemented in Composition Root (web api project,  website main prototype, etc) /// </summary> public interface IHandlersFactory /// <summary> ///   Basic interface for the command /// </summary> public interface ICommandHandler TCommand void /// <summary> ///   Basic interface for the query /// </summary> public interface IQueryHandler TQuery TResult /// <summary> ///  Factory Ninject to create standardised commands and queries /// </summary> public class NinjectFactory IHandlersFactory private public public return public return public return public return Examples of Binding of queries with Ninject override Load()
        { Bind<IQueryHandler<GetCertificateByIdQuery, Certificate>>(). <GetCertificateByIdQueryHandler>();
            Bind<IQueryHandler<GetCertificatesQuery, <Certificate>>>(). <GetCertificatesQueryHandler>();
            Bind<IQueryHandler<GetCertificateByShipQuery, <Certificate>>>(). <GetCertificateByShipQueryHandler>();
…………. public void // queries To List To List To After the injection of IHandlerFactory into the class, you can use your commands and queries as follows. Query example:
Ship ship = mHandlersFactory.CreateQueryHandler<GetShipByIdQuery, Ship> . );

Command example:
mHandlersFactory.CreateCommandHandler<DeleteReportCommand> . ); () Execute( GetShipByIdQuery( ) new id () Execute( DeleteReportCommand( ) new report By all means, all architectural decisions must be based on and developed according to the requirements and situation. No need to design the architecture for the entire product or system outright. The following questions will guide you through the decision making process. Why is the structure of the software product like this? Why is this particular implementation being used here? How will a new implementation fit into the overall structure of the system? How will the non-functional requirements of the entire system be met? It is also very important to allocate the Bounded Context in the system. This practice helps to depict the customer’s business structure, find a common language with a client, and manage the regression in the product. But we’ll cover this in the next article. Benefits of CQRS The basic architecture of the application was built in compliance with various principles and design patterns: MVVM, SOLID, CQRS, etc. This allowed reusing functionality in separate client applications. With that, the implementation did not take much time and was cost-effective. By the time the development was to commence the team had already developed classes and the same level of understanding of the application architecture. In subsequent refinements, it fully paid off: about 40% of functionality could simply be flexibly reused. With this approach, the customer significantly reduced the cost of implementing functions by roughly 30–40%. In conclusion The Agile approach to development is mistakenly interpreted as “you don’t need to design anything in advance, just build, release and get the feedback. Should we need to improve the operational speed of the product or add new capabilities more rapidly, we’ll just throw microservices in. At every corner, they saw how effective and versatile microservices are.” uch a thoughtless approach, generally, results in a poor product and wasted cash. On the other hand, it is practically impossible to come up with a fully-fledged design right off the bat. A balanced approach is the best. S Firstly, having a vision for the product architecture provides a sound basis for current and future decisions. As a result, this will have a huge impact on the cost of the development as the product matures. Secondly, documenting the adopted architectural decisions will allow for the understanding of certain decisions further down the line. Thirdly, regular checks of the environment in which the product operates, allows to reduce the risks of failures and justifies the decisions regarding refinements or change. Thus, giving some thought to what a product’s architecture will look like and using competent practices when writing code provides a solid foundation for scaling a product in the future.

IRESQ

iresq.com

-- employees

Since n.d.

COMPANY RANKING

IRESQ

EVERGREEN INDEX #5685

Representing this company? Click here to claim and customize this page!

iResQ WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

IRESQ

iresq.com

-- employees

Since n.d.

COMPANY RANKING

IRESQ

EVERGREEN INDEX #5685

RELATED COMPANIESRANK

STORIES ABOUT IRESQ

Representing this company? Click here to claim and customize this page!

iResQ WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!