DEV Community: Franck Mercado

Functional MCP AI System Diagram

Franck Mercado — Mon, 15 Dec 2025 18:05:20 +0000

Mermaid Graph image

Mermaid Graph code

graph TD

    %% Node Definitions
    U[User]
    MT(MCP Tools / Host Application)
    MS(MCP Server / Capability Provider)
    LLM(Large Language Models)
    RAG(Retrieval-Augmented Generation)
    NLP(Natural Language Processing)
    GenAI[Generative AI]
    ET[External Tools & Resources]
    TD["Training Data (Corpus)"]
    VDB[Vector Database]

    %% 1. User Application Subgraph (The Host)
    subgraph User Interface ["(Host)"]
        U -- submits query/intent to --> MT
        MT -- renders final response to --> U
    end

    %% 2. Core AI & Orchestration Subgraph
    subgraph AI Processing & Orchestration
        LLM -- uses foundational capability of --> NLP
        LLM -- is a specific instance of --> GenAI
        RAG -- provides augmented context/prompt to --> LLM
    end

    %% 3. Capabilities and Context Subgraph (The Server's Role)
    subgraph External Capabilities ["(Data Resources)"]
        MS -- provides access to --> ET
        RAG -- executes retrieval query on --> VDB
        VDB -- stores vectorized embeddings for --> RAG
        TD -- pre-trains base model --> LLM
        ET -- includes external knowledge via --> TD
    end

    %% 4. Cross-Subgraph Functional Flow
    MT -- sends protocol request via Client to --> MS
    MS -- coordinates and invokes --> LLM
    MS -- implements retrieval logic via --> RAG

    LLM -- generates final output and returns to --> MS
    MS -- returns protocol response/result to --> MT

Suggest any improvements.

User Stories evaluation acronyms in agile software development teams

Franck Mercado — Fri, 17 Mar 2023 21:16:20 +0000

When working in an agile-ish software development team you will come to the part where, as a team, you will need to prioritize and decide how to split the user stories for your current Sprint. For these purpose there are widely accepted steps to take, that act as a checklist that will add up in quality and will favor clarity and visibility for the whole company; product, engineering, business teams.

These criteria for evaluating User Stories is summed up into two acronyms, INVEST and SMART.

Additionally the following suggestions can be considered as guidelines to split user stories :

Functional size: Amount of work required to complete the story. This can be measured in terms of the number of features or tasks that need to be completed.
Business value: Value that it provides to the end user or customer. This can be measured in terms of the benefit that the user will receive from the completed story.
Risk: Likelihood that the story will not be completed as planned. This can be measured in terms of the uncertainty or complexity of the work involved.
Dependencies: Tasks or features that must be completed before the story can be started. These dependencies can be internal to the team or external to the team.
Time constraints: Deadlines or due dates that must be met in order to complete the story. These constraints can be imposed by the team or by external factors such as customer deadlines.

API Middleware use cases

Franck Mercado — Sun, 22 Jan 2023 02:26:42 +0000

What is API Middleware?

Is a component that participates in the processing of an HTTP Request and the consequent generation of a Response. It acts as a mediator between the client or consumer and the software application service. There are multiple types of middlewares depending on which app they connect to. We will focus on API Middleware.

A middleware

can access your HTTP request and its related information like headers, method, body, parameters, etc
sends (or not) the request to the backend application for further processing through the request handler
return a valid HTTP response to the client or consumer.
performs actions before or/and after execution of the request handler, since is part of the processing pipeline, allowing flexible compute capabilities.

API Middleware use cases

Request/response manipulation (e.g. add headers, modify the body, etc)
Session
Cross-Origin Resource Sharing (CORS)
Firewall
Authentication
Authorization
Validation
Sanitize
Caching
Logging and monitoring
Error handling and exception management
Content negotiation (e.g. handling different formats for the same resource)
Rate limiting and Throttling
Honeypot
Security (e.g. CSRF protection, Same-Site Cookie)
Internationalization and localization
API Versioning

Software Architecture Patterns for common problems

Franck Mercado — Tue, 20 Sep 2022 01:37:36 +0000

Data management

Database per Service
Shared database
CQRS
Domain event
Event sourcing

Transactional messaging

Transactional outbox

Security

Access Token (JWT)
Oauth
Session

Observability

Log aggregation
Application metrics
Audit logging
Health check API

Software Architecture and Software Design

Franck Mercado — Wed, 27 Jul 2022 16:03:35 +0000

Based on both key definitions, software architecture and software design, we can lay down an organization of software principles, methodologies and patterns currently applied in modern software development and technology innovations.

Software Architecture

It's a high level blueprint for a system.
It defines the structural elements like subsystems, roles, relationships and responsibilities meaning it lays down the architecture style, patterns that will guide the software design.
Software architecture directly deals with arranging this elements like servers, databases, APIs, clients or users of the software application, etc in order to fulfill business requirements.

Software Design

Implies decisions at a lower level of detail as it provides an implementation plans for the laid out architecture.
Software designers will decide on the specifications, contracts used in these subsystems that later software engineers will implement.

Organization of software principles, methodologies and patterns

Index of software concepts:

Software architecture style
Software architecture patterns
Software design methodologies
Software design patterns
Programming paradigms
Clean code principles

1. Software Architecture Style

Based on Structure (separation of concerns)

Layered architecture (N-tier):Common for separation of concerns (e.g. presentation, business logic, data layers).
Hexagonal architecture (Ports & Adapters): Focused in decoupling core logic from external systems.

Based on distribution of the application

Monolith architecture
Microservices architecture
- Microservices patterns

Events

Focuses on asynchronous communication through events.

Event Driven architecture

Cloud

Involves event triggered functions (AWS Lambda) rather than traditional server management.

Serverless architecture

API Design

REST over HTTP

2. Software Architecture Patterns

Based on data management

Database per service (microservices)
Shared database (monoliths)

Event driven systems

CQRS: Common Query Responsibility Segregation, Separating read and write operations.
Domain event
Event sourcing: Store state changes as sequence of events.

Based on transactional messaging

Ensures reliable message delivery in distributed systems.

Transactional outbox

Based on security

Access tokens (Authentication)
Oauth (Authorization)
Session

Based on observability

Essential for monitoring and troubleshooting in distributed systems.

Log aggregation
Application metrics
Exception tracking
Health check API

3. Software Design Methodologies

Domain Driven Design (DDD): Focuses on modeling the domain and aligning software design with business needs.
Behavior Driven Development (BDD): emphasizes collaboration between developers, testers and business stakeholders.
Test Driven Development (TDD): involves writing tests for core domain logic before coding to ensure quality and maintainability.

4. Software Design Patterns

Creational Patterns
Structural Patterns
Behavioral Patterns

Expand on software design patterns

5. Programming Paradigms

Object Oriented Programming (OOP)
- Composition over inheritance
- SOLID
  - Single-responsiblity Principle
  - Open-closed Principle
  - Liskov Substitution Principle
  - Interface Segregation Principle
  - Dependency Inversion Principle
Functional Programming: emphasizes immutability and pure functions.

6. Basic principles

Clean Code
DRY: Don't repeat yourself
KISS: Keep it stupid simple
YAGNI: You aren't going to need it

Take into account that all these architectural principles, methodologies and patterns are no substitute for making your own decisions. You need to balance them according to business requirements of your software application.

Magic in an Application Framework

Franck Mercado — Sat, 23 Jul 2022 16:54:00 +0000

What is called magic in software development?

Well maybe you are already familiar with the following gif image below.

When I first was introduced to this meme I totally understood what they meant with magic in programming or what at the time I could identify as magic code.

To understand what magic is let's look at some examples.

The first example is from Rails framework. Looks like there's not much going on in this code, right?

Taken from the same Ruby on Rails official website:

... note that the Post class inherits from ActiveRecord::Base. Active Record supplies a great deal of functionality to your Rails models for free, including basic database CRUD (Create, Read, Update, Destroy) operations, data validation, as well as sophisticated search support and the ability to relate multiple models to one another. Another important part of this file is attr_accessible. It specifies a whitelist of attributes that are allowed to be updated in bulk

Now, let's see this second example. It comes from Laravel framework.

In that small piece of code the application's route will automatically resolve the Service class and inject it into your route's handler. But how? Well, internally it is grabbing it from the framework's service container and thanks to dependency injection it is doing some configurations and injecting an instance of that class. Laravel does this also in controllers, event listeners, middlewares, queued jobs, etc.

As you can see there's quite some functionality hidden and available for us in those two code examples. They hide some configuration as well as conventions inherit by their respective application frameworks.

Magic is great as it offers all this functionality with a few lines of code. And at the same time magic is bad when used indiscriminately.

Why? Well, remember that as part of our software engineer responsibilities we need to do short and long term planning. First keep in mind that other developers might be working in the same codebase and they will need to be aware of these conventions and read documentation beforehand in order to understand what the code does or what it offers internally.

Also consider that your application might be migrated away from its original infrastructure depending on business or technology needs and being tied to a particular application framework makes it harder for decoupling.

Well this is the part where you need to decide how much magic is good in your software application and also how good or bad is to be tied to the chosen application framework and depend on it.

Remember that if your application framework blocks you from integrating your app with other services or makes it hard to decouple your modules to migrate them to microservices for other teams to work on it, or just slows you down in order to optimize the performance, security of your apps then I recommend you to plan ahead and spend a bit of time thinking about these implementation decisions and if using them won't slow you down later.

Your future self will thank you for it!

Software and IT Infrastructure

Franck Mercado — Fri, 22 Jul 2022 21:38:28 +0000

From IT perspective, Infrastructure refers to all components, libraries, tools, etc that are connected to an actual physical infrastructure (hardware) or external service (software), through specific programs, drivers or other libraries which will enable such connection in order to operate or manage services or environments.

With that in mind, infrastructure is considered to be our storage systems of preference such as Databases or Cache, also Logging systems or Message brokers that are supporting our software applications, even external services to your application like Email messaging, external logging services or external reporting tools are considered infrastructure.

It is crucial to realize that also your favorite application framework is also part or considered to be infrastructure.

Software engineers that take architectural design principles into account when developing their systems, tend to guarantee, among others, these software characteristics:

Flexibility
Extensibility
Reliability
Maintainability
Reusability
Testability

And these features are very important for systems to last a long time and to require less resources to keep them up to date with latest technologies and keep them solid (secure, testable) and open for integrability and/or portability against new business requirements.

In order to achieve this objectives we need solid Software Architecture and Design principles, be conscious of when to apply Software Architecture Design Patterns available, as well as Software Architecture Patterns for Common Problems and proven industry techniques that help us keep our Software Domain decoupled from Infrastructure, solid and extensible allowing as to fulfill above mentioned software characteristics.

Software Design Patterns

Franck Mercado — Fri, 22 Jul 2022 21:20:00 +0000

Creational Patterns

Factory Pattern
Builder Pattern
Prototype Pattern
Singleton Pattern
Abstract Factory Pattern

Structural Patterns

Adapter Pattern
Bridge Pattern
Composite Pattern
Decorator Pattern
Facade Pattern
Flyweight Pattern
Proxy Pattern

Behavioral Patterns

Chain of Responsibility Pattern
Command Pattern
Iterator Pattern
Mediator Pattern
Observer Pattern
State Pattern
Strategy Pattern
Template Method Pattern
Visitor Pattern

Hello I'm Franck!

Franck Mercado — Tue, 12 Oct 2021 21:17:56 +0000

I live in Cusco.

I love coding and software architecture.

Find me on Twitter as @franckmercado

Happy to be in Dev! :)