DEV Community: Claranet

From Static Pages to Interactive Spaces: Embedding Now4Real Chat

Gianluca La Manna — Tue, 23 Sep 2025 10:37:02 +0000

Today I want to show a cool thing. Have you never thought to chat instantly inside a specific web page with other people who share the same interest?

Now4Real is an excellent solution for that.

We at Claranet Italy have made this integration with a web management software: Logica by Sinapsi SB.

Now I show how we did it and how simple it is to integrate this tool into every web page.

First of all, we have to create an account on https://now4real.com/, and then we will have to access the dashboard like this:

As you can see in the bottom right corner, we have the chat icon, and this keeps track of the people, in that specific moment, who are showing the same page as you.

Inside it, we can chat with other people and share knowledge about the page, or share the same interests or something like that.

Let's move to the practice.

From the dashboard, we have to add a new site.

Important: Here we have to use a public domain.

Now, inside index.html of our application, we have to add this line of code:

<meta name="now4real-site-verification" content="XXXXX"/>

where XXXXX is a key provided by now4Real when you add the new site.

Commit and publish this modification to link the site with now4real.

Then we can manage the JWT authentication, because we want to use a logged-in user inside of Logica. So, if I log on to Logica with the Angelo user, I want to use the chat with the same user.

To do this, go to the menu dashboard under the Authentication menu item and generate a shared secret

As you can see, you have a lot of configuration on the side of the menu. We will show something later.

Now we need a JWT signed with the algorithm HS256, and use it inside the now4real object, like this:

window.now4real = window.now4real || {};

now4real.config = {
target: "api+widget",
scope: "page",
custom_auth: {
    enabled: true,
    jwt,
},
page_context: getPageContextFromHash()
};

Here are some considerations:

target is api+widget by now4real documentation to istantiate the service
scope, we want to use this to enable different chats per page.
custom_auth to use the authentication inside the chat
page_contextto use the discriminant per page, for example an id.

To remove the chat from some pages, currently we can remove the widget from the DOM like this:

const removeNow4RealFromDom = () => {
    document.getElementById('NOW4REAL')?.remove();
    const SCRIPT_REGEX = /.*now4real\.(min\.)?js/;
    document.querySelectorAll('script').forEach((script) => {
    const src = script.getAttribute('src');

    if (src && SCRIPT_REGEX.test(src)) {
        script.remove();
        console.log(`Removed Now4Real script: ${src}`);
    }

    });

    isInitialized = false;
    delete window.now4real;
};

Maybe we will have a new api from Now4real to manage this specific case.

Cool things
From the dashboard, we are able to manage the styles and position of our chat component

And you can publish instantly the modifications.

Or manage the messages

with message duration, or block specific words or offensive language

Thanks for reading. See you next time 👋🏻

Mobile development best practices

Francesco Mariani — Tue, 09 Sep 2025 07:03:37 +0000

Introduction

Today, mobile applications are at the forefront of user engagement, brand presence, and business growth. With the spread of multiple platforms, it’s essential to develop robust, scalable, and user-friendly mobile apps. This requires more than just coding skills, and it demands a solid grasp of best practices and deep platform knowledge to ensure long-term success and maintainability.

This article explores essential best practices in mobile development for building UIs aligned with iOS and Android platform guidelines, preserving usability, and managing upgrades to safeguard backward compatibility.

Next, we examine the critical roles of automated testing and CI/CD.

Finally, we’ll look at strategies for efficient data handling

Usability

When developing a project for iOS and Android, it is essential to adhere to the usability guidelines specific to each platform to ensure a consistent, intuitive, and accessible user experience.

You can refer to the official guidelines provided by Apple and Android

Now, we look at some of the usability rules, first with iOS and then Android:

IOS

Depth, clarity, and deference (subtle and unobtrusive interface design).

The app uses subtle shadows, blurs, and transitions to show hierarchy between components.

Top navigation bar with cantered titles

Centering titles in the top navigation bar reinforces platform consistency, offers immediate screen context, and contributes to a balanced, intuitive layout that aligns with iOS user expectations.

Bottom tab bar for primary sections

A bottom tab bar is essential for organizing an app’s main sections. It gives users immediate, consistent access to the app’s core areas, improving discoverability and reducing navigation steps. This aligns with iOS design principles by prioritizing simplicity and directness for frequent tasks.

Back gesture: swipe from left to right.

The swipe-from-left-edge back gesture makes navigation more fluid and natural, letting users move backward with a quick, intuitive swipe. It reduces reliance on tap targets, speeds up interaction, and aligns with iOS’s focus on gesture-driven, edge-to-edge experiences.

Minimalism: Apple promotes a clean and restrained design.

Apple consistently advocates for minimalistic design principles, emphasizing clarity, focus, and simplicity. Their interfaces use generous white space, subtle color palettes, and intuitive layouts that prioritize essential content, reducing cognitive load. This approach not only enhances aesthetics but also improves usability by guiding users naturally through tasks without unnecessary distractions.

Native components: UISwitch, UITableView, UICollectionView, etc.

Apple’s native UI components, such as UISwitch, UITableView, and UICollectionView, are fundamental building blocks of iOS applications. These standardized elements provide consistent behavior, accessibility, and visual style across apps. With the use of native controls, developers ensure seamless integration with system conventions, improve performance, and deliver a familiar experience that aligns with Apple’s Human Interface Guidelines.

Dark Mode: supporting is highly recommended

Dark Mode has become a standard expectation in modern mobile applications as it provides users with an alternative appearance that reduces eye strain and saves battery life on OLED screens. With system-driven dark appearances, developers ensure consistent theming, seamless transitions between light and dark modes, and adherence to user preferences. Supporting Dark Mode not only enhances accessibility and comfort but also aligns with platform guidelines, improving the overall quality and professionalism of the app.

Android

Material You: dynamic theming based on the user’s system theme and preferences.

Material You is a personalized design system that adapts its appearance based on the user's preferences and current system theme. It dynamically changes color schemes, typography, and other user interface elements to create a cohesive and customizable experience that feels unique to each user. This approach enhances the aesthetic appeal of an app and boosts usability and accessibility, making interactions more intuitive based on user's habitual patterns and preferences.

Floating Action Button (FAB) for primary actions.

The Floating Action Button (FAB) is a hallmark of Material Design, designed to promote a primary action within an app, such as composing a new message, adding a new contact, or creating a new document. Its distinguished circular shape and elevated position over the interface command user attention, making it easily accessible while not interfering with other UI elements. FAB supports a better user experience by providing a consistent and recognizable action button.

Navigation Drawer or Bottom Navigation for main navigation structures.

Navigation drawers and bottom navigation bars are critical components in structuring and accessing major areas of an app efficiently. The navigation drawer slides out from the side and is ideal for accessing a wide range of options without cluttering the primary interface. In contrast, bottom navigation bars provide visible at-a-glance views for top-level destinations. Both elements facilitate seamless navigation across the app's different sections, enhancing usability with clear, reachable pathways.

Physical or gesture-based back button: pressing the back button with a modal or overlay open should dismiss the modal, not navigate back to the previous screen.

Proper utilization of the back button ensures an intuitive navigation. Whether it's a physical button or a gesture-based control, pressing the back button should first close any active modals or overlays. This makes sure that the user doesn't unintentionally exit the current context or lose unsaved changes, thus maintaining a logical progression through app content and preventing potential frustration from unexpected navigation actions.

Standard Material components: Button, Card, Chip, Snackbar, etc.

Standard Material components such as Buttons, Cards, Chips, and Snackbars play key roles in creating a consistent and functional user interface. Each component serves distinct purposes: Buttons are for actions; Cards for grouping related information in a flexible container; Chips for compact elements representing input, attribute, or action; and Snackbars for brief messages about app processes. These components are designed for versatility and scalability across different platforms and provide a unified design language and interaction consistency.

Meaningful animations: transitions, elevation effects, and interaction feedback.

Meaningful animations enhance user experience by providing visual cues that depict relationships, hierarchy, and functionality. Smooth transitions guide users between app states with clear movement that respects context, improving cognitive recognition of app structure. Elevation effects create depth and focus attention, while interaction feedback animations reassure users of their actions, such as button presses or toggling settings, establishing a satisfying interaction that confirms user inputs have been recognized and processed.

There are also common best practices shared by iOS and Android that are useful in the daily use:

Design & test: use tools like Figma, Sketch, Adobe XD, and conduct testing with real users.
Respect platform differences: avoid forcing the behaviour of one platform onto the other.
Continuous update: stay aligned with the evolving Apple/Google guidelines and plan for continuous delivery, potentially leveraging a release pipeline.

WCAG Compliance Check

To verify whether an app is compliant with the WCAG, you can refer to the following specifically tailored for mobile accessibility:

https://www.w3.org/WAI/standards-guidelines/mobile/

After reviewing the WCAG guidelines, you need to check if your app complies with them. In the next chapter, we’ll look at some testing tools to help you do that.

Accessibility test tools

Both Android and iOS offer various frameworks for unit, UI, and integration testing, but finding the right tools to test accessibility can be more challenging.

Let’s describe some of them:

IOS

Xcode Accessibility Inspector: Xcode tool for display, query, and test accessibility information for the elements in your app’s view hierarchy.
VoiceOver: Built-in screen reader for Apple devices that enables users to interact with their devices using spoken and tactile feedback instead of visual cues.
ContrastKit: Is a Swift library design to facilitate colour contrast handling within iOS, IPadOS, macOS and tvOS applications.
Colour Contrast Calculator: Xcode’s tool to compute contrast between any two colours and use those colours for images used between normal and high-contrast mode. To open it, you can go to: ‘Open Developer tools > Accessibility Inspector > Window > Show Contrast Calculator.

Android

Accessibility Scanner (Google): You can download it from the Play store. The scanner records the current screen and provides you tips to improve accessibility of your app based on the following elements: labels, touch target size, clickable elements, text and image contrast.
TalkBack: this is a screen reader for Android devices, developed by Google, that provides spoken and braille feedback to help users with visual impairments interact with their devices.
Layout Inspector (included in Android Studio): this Android studio tools lets you debug the app layout by showing a view hierarchy where you can inspect the properties of each view.
Android Accessibility Test Framework (ATF) with Espresso: it works with Espresso, a popular testing framework, and automatically looks for common accessibility issues like missing labels or low contrast during UI tests.

Data management and synchronization

After discussing the UI, let’s look at how to handle the data in the following possible scenarios.

Handling small amounts of data

In this case the structure is primarily key value based, Android’s SharedPreferences and iOS’s UserDefaults are typically used.

To synchronize this information online -to enable the user to access the same app data across multiple devices or after reinstalling the app- we can find various online services, such as:

Firebase Remote Config: ideal for feature flags and configuration settings.
iCloud Key-Value Store: iOS-only, perfect for user settings, preferences, and app state, with a 1MB maximum limit.
Firebase Realtime Database or Firestore: enables real-time automatic synchronization, commonly used for shared data across devices, configurations, app state, and user preferences.

We can summarize using the following table:

Level	Tool	Scope
Local	SharedPreferences / UserDefaults	Cache and offline access
Synchronization	Firestore / REST API	Backup and synchronization between devices
Sensitive data	Keychain / Secure Storage	Token, password
Dynamic configurations	Firebase Remote Config / ICloud Key-Value	Feature toggle, A/B testing

Management and synchronization of large amounts of data

In this case, you will most likely manage a Room database for Android, Core Data for iOS, SQLite for Flutter, and WatermelonDB for React Native.

Stack	Local DB	Recommended Sync
Android	Room / SQLite	WorkManager + Retrofit / Firestore SDK
iOS	CoreData	CloudKit / API REST
Flutter	sqflite	Cloud Firestore / REST
React Native	WatermelonDB	Custom sync / Firebase

Below are some best practices for database management:

Change tracking: use fields such as lastModified, syncStatus, version.
Migration: create a migration for every app version upgrade and write automated tests to validate the migration.
Conflict management: use strategies like "Last Write Wins," logical merge, or centralized control.
Flexibility: keep the data model independent from the database (DTO ↔ Entity).
Network: detect network status before attempting sync; provide offline fallback.
Security: authentication (JWT, OAuth2), mandatory HTTPS, secure token management.
Intelligent sync: trigger sync on events (e.g., login, data changes), timers, or network conditions.
Backup & Restore: offer manual/automatic backups to cloud services or exportable files.

Update Management & Backward Compatibility

To ensure API stability across different app versions, it is essential to follow the following best practices:

API Versioning and Management

Use API versioning (e.g., /api/v1/): for each major release, it is recommended to maintain a dedicated API version.
Maintain backward compatibility: avoid breaking changes while previous app versions are still in use.
Gradually deprecate obsolete APIs that are no longer used.
Server-side feature flags: enable or disable features on the server side to prevent crashes in outdated app versions.
Check the client version in the API: send the app version in the request headers and tailor the response accordingly.

Environment management and testing

Separate environments for dev/staging/prod (including for APIs).
Mock APIs to test new features without affecting real data.
Automated and manual testing across multiple API and app versions.
Unit tests, UI tests (Espresso, XCTest), and integration tests.
Backward compatibility testing: test the new app against old APIs and vice versa, and handle exceptions accordingly.

Progressive rollout and rollback

A staged rollout deployment is useful and safe, it consists in releasing an app gradually to a small percentage of users first, then spreading it to more users in later phases. This approach helps to detect issues early, limits the impact of bugs, and ensures stability before the update becomes public.

Google Play → release to a percentage of users or test groups.
App Store → TestFlight or release to geographic groups or small batches.

Monitoring tools:

Firebase Crashlytics,
Sentry
Instabug
Datadog.

Fast rollback:

keep the previous version ready and the ability to disable features remotely.

Pipeline mobile best practice

Automation of the release process (CI/CD) is a key practice in modern mobile development. It enables automatic building, testing, and deployment of iOS and Android apps, reducing errors and accelerating release times.

Among the most common services we recommend there are:

GitHub Actions: integrated CI/CD within GitHub, highly flexible. Supports Android/iOS builds with YAML workflows.
Bitrise: mobile-specialized CI/CD platform, featuring a visual UI and support for Flutter, React Native, Kotlin, Swift.

Among the commonly used support tools for mobile release, we have:

Fastlane
Gradle
Xcodebuild

Conclusions

To wrap up, we have explored mobile best practices around UI design, data management, and the release pipeline. Together, these areas provide the foundation for developing applications that are solid, modular, and maintainable throughout their entire lifecycle.

Thanks for reading!

Build Your MCP Server in Just 5 Minutes using Vibe Coding with Kiro

Gianluca La Manna — Sat, 06 Sep 2025 13:06:41 +0000

Hey folks, today I want to show you how to create an MCP server with special assistants: Kiro and Sonnet Claude. ✨

But what is this new term? MCP. Is it a buzzword? I don't know, but recently it is has been very discussed recently.

So, let's dive into the MCP concept.

MCP: a new protocol by Anthropic

I'll start by showing right away the schema of the MCP Protocol:

Simple: with this protocol, we can connect our AI applications to the world.

We can imagine this protocol like a USB port to connect the LLM to other services, like Gmail, Notion, Obsidian, Drive or more simply a DB or API service, with a unique standard. This is the work done by Anthropic.

Now let's zoom in on this diagram 🔭

As you can see, the MCP is a layer that simplifies the communication between LLM and another service.

We define a real scenario.

In this last year, I've focused on my diet and gym results. So I want to know what I eat and the nutrients in food.

There are a ton of mobile applications to search for foods and get more info about them, but I'd like to search with more flexibility using natural language, for example, in a specific dataset when I'm using an AI client like Claude. The MCP protocol is the right way. We can ask, for example:
"I ate two eggs Bio Carrefour", and I'll expect a response with nutritional information.
Great, but how?

Let's move on to practice.

Use Vibe coding to create our MCP Server

As the literature says, we have to use the code vibe formula

$Vibe = (Project Soul + Your Intuition + Model's Character)$

If you are curious, read this book by David Gillette.

The first argument is What and Why of our project.

The second is our unique contribution as a human creators. It's our gut feeling, our creative spark, our accumulated experience.

The third is about understanding the specific AI model we are working with.

With this information, we can use Kiro's agent to address it to create our MCP Server.

Here is an example of text:

1) Project Soul — What & Why

Goal: build an MCP Server that communicates with the dataset and APIs of Open Food Facts. The server should receive requests from an MCP Client and fetch food-related information directly from the official API (ingredients, nutrition facts, allergens, categories, brands), never generating or hallucinating data.

Why: this enables AI systems to integrate verifiable, real-world food data in a reliable and traceable way.

Expected outcome: an MCP implementation with well-defined tools that can search, filter, and retrieve products, always returning source: "openfoodfacts:<endpoint>".



2) Your Intuition — Human Spark

Keep the architecture clean and modular: separate the MCP protocol layer from the connectors to Open Food Facts.

Define strict JSON Schemas for inputs and outputs of all tools so Claude Sonnet can safely orchestrate the calls.

Add support for language localisation (lang), since Open Food Facts is multilingual.

Implement lightweight caching to avoid redundant API requests.

Provide clear error messages, always including a hint field to guide the client in correcting invalid inputs.

Code style requirement:

Do not use class constructors.

Use const declarations and arrow functions for all functions, exports, and callbacks.

Prefer functional composition over OOP patterns.

Use Typescript for entire project.



3) Model’s Character — Who You Are

Model to use: Claude Sonnet.

Character traits:

excels at producing structured, logical, and safe outputs;

prefers explicit schemas and typed definitions;

skilled at summarising without losing precision;

acts as a connector to the API, not as a data source.

Constraint: every output must reference the Open Food Facts source (source).

We can use this prompt on Kiro, and then we will have our MCP Server that gets the information from Open Food Facts via API (in this case, not authenticated)

Client MCP

Now we need the client MCP to communicate with the Server.
We have to create a .kiro folder in our project and inside define a file called mcp.json with this content

{
  "mcpServers": {
    "calormeal": {
      "command": "node",
      "args": ["/Users/myUser/projects/new-calormeal/build/index.js"],
      "disabled": false,
      "autoApprove": ["search_products", "get_product", "search_by_nutrition", "search_by_category"]
    }
  }
}

That's all.

Let's try

Now we can ask our server something, like this

I ate 2 organic eggs from Carrefour. How much protein did I consume?

This is the result

As you can see, the response does not come from Claude's model, but our server is called, which in turn calls the Open Food Facts API and returns the information according to the structure we have defined.

The code

Let's see the code generated

We have an openfoodfacts.ts file that defines a direct interface with the openfoodfacts API.
We have for example, the searchProduct function.

export const searchProducts = async (input: SearchProductsInput): Promise<ProductListResponse | ErrorResponse> => {
  const cacheKey = `search:${JSON.stringify(input)}`;
  const cached = getCached<ProductListResponse>(cacheKey);
  if (cached) return cached;

  try {
    const params = new URLSearchParams({
      search_terms: input.query,
      page: input.page?.toString() || '1',
      page_size: input.page_size?.toString() || '20',
      sort_by: input.sort_by || 'popularity',
      json: '1'
    });

    const url = `https://${input.lang || 'world'}.openfoodfacts.org/cgi/search.pl?${params}`;
    const response = await fetch(url);

    if (!response.ok) {
      return createError(
        `API request failed with status ${response.status}`,
        'Check your network connection and try again with a simpler query'
      );
    }

    const data = await response.json() as any;

    const result: ProductListResponse = {
      products: (data.products || []).map(normalizeProduct),
      count: data.count || 0,
      page: input.page || 1,
      page_size: input.page_size || 20,
      source: 'openfoodfacts'
    };

    setCache(cacheKey, result);
    return result;

  } catch (error) {
    return createError(
      `Network error: ${error instanceof Error ? error.message : 'Unknown error'}`,
      'Verify your internet connection and ensure the query contains valid characters'
    );
  }
};

The server.ts defines an MCP server, and there are 4 registered tools:

search_products - General search by name/brand
get_product - Product details via barcode
search_by_nutrition - Filter by nutritional values
search_by_category - Search by food category

and then

ListToolsRequest - Returns a list of available tools
CallToolRequest - Runs the requested tool with input validation

Here we define the Server

import { Server } from '@modelcontextprotocol/sdk/server/index.js';

const server = new Server(
  {
    name: 'openfoodfacts-mcp-server',
    version: '1.0.0',
  },
  {
    capabilities: {
      tools: {},
    },
  }
);

and then we define the tools for each action like this:

const tools = [
  {
    name: 'search_products',
    description: 'Search for food products by name, brand, or keywords in Open Food Facts database',
    inputSchema: {
      type: 'object',
      properties: {
        query: {
          type: 'string',
          description: 'Search query (product name, brand, keywords)',
          minLength: 1
        },
        lang: {
          type: 'string',
          description: 'Language code (en, fr, es, de, etc.)',
          default: 'en'
        },
        page: {
          type: 'number',
          description: 'Page number for pagination',
          minimum: 1,
          default: 1
        },
        page_size: {
          type: 'number',
          description: 'Number of results per page',
          minimum: 1,
          maximum: 100,
          default: 20
        },
        sort_by: {
          type: 'string',
          enum: ['product_name', 'popularity', 'created_t'],
          description: 'Sort results by field',
          default: 'popularity'
        }
      },
      required: ['query']
    }
  },
/* [other tools] */

Here, the setRequestHandler associates a handler function with a specific request type:

Pattern matching – When a request matches the schema, the function is executed
Two registered handlers:

ListToolsRequestSchema → returns the list of available tools
CallToolRequestSchema → executes a specific tool

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;

  try {
    switch (name) {
      case 'search_products': {
        const input = SearchProductsInputSchema.parse(args);
        const result = await searchProducts(input);
        return {
          content: [
            {
              type: 'text',
              text: JSON.stringify(result, null, 2)
            }
          ]
        };
      }

...
 /* [other cases] */

and finally run the server

export const runServer = async (): Promise<void> => {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error('Open Food Facts MCP Server running on stdio');
};

Use Claude Desktop

Also, you can use the Claude desktop. Just configure this file claude_desktop_config.json

Then run the application, and under settings, you can find the MCP

and the ours functions

The result is

You can find all the code on my repo.

Remeber

You can find a lot of servers here (official and unofficial), but if you want to create one from zero to integrate your private service or for another reason, you can follow the previous steps for a good starter.

Thanks for the reading, and see you soon 👋🏻.

Modernizing a large multi-team application with Micro Frontends

Leonardo Montini — Fri, 27 Jun 2025 13:32:49 +0000

Here’s a quite common scenario: you have a web application, built years ago, with deeply intertwined modules and dependencies. To make things worse, there are layers of legacy code built on top of each other, and multiple teams are dealing with the same codebase daily.

Each team struggles to implement new features without stepping on each other’s toes, app-wide updates are a long and dangerous process and updating only a portion is just adding one more layer of tech debt and inconsistencies.

The result? Slower development cycles, frustrated developers, and a product that struggles to keep up with user expectations and the market in general.

One of our clients has been in a similar situation, here’s how we’re taking care of that with Micro Frontends.

Modernizing with Micro Frontends

The main React application has almost 10 years and is bundled with an old version of Webpack while the new micro frontends are React apps running on Vite.

The approach is to gradually extract smaller applications from the old system, using the long-time domain and project knowledge to properly know where to set the boundaries.

Each smaller project has a unique goal in the system and is assigned to a dedicated and autonomous team. This brings a lot of advantages as each team can independently develop, deploy, and maintain their own portion of the system.

Communication between the systems is mostly through custom events.

With that in place, micro frontends enable incremental upgrades, allowing the legacy codebase to coexist with the new technologies. The teams can replace old modules one by one rather than rewriting the entire application all at once.

Downsides you better not ignore

Before going all-in into your next huge refactor to adopt micro frontends, there are some downsides you must understand.

To begin with, to reduce complexity of your old legacy system you’re going to adopt an architecture that for sure fixes some of the flaws but also brings some more complexity in other areas of your application. To name a few, passing data between components of a single app might be trivial nowadays but sharing the state and communicating between micro frontends might not be that obvious. There’s plenty of solutions, but the team must get used to them.

Separating all the moving parts might seem a simplification but now you must handle each one of them independently, including deployment and versioning. It’s an aspect you might see as a benefit, but it undeniably adds complexity.

Consistency can also be a challenge if not handled properly, as autonomous teams can easily drift and lose sight of the bigger picture. A common outcome can be large differences in UI components giving an unpolished look at the final product.

DOs and DON’Ts

A few tips to guide your implementation to maximise the benefits and avoiding some common mistakes. Some of these are common sense, some we banged our heads on during the project.

DOs

1. Do define clear boundaries for each micro frontend
We all should have learned the lesson from microservices, using the wrong criteria to break down the monolith and set boundaries will inevitably do more harm than good. Make sure each micro frontend represents a distinct feature or domain.

2. Do ensure independent deployment
Micro frontends should be deployable independently. If you end up in the situation where you consistently can no longer deploy one sub-system by itself, you’re coupling too much and losing the benefits of having separate frontends.

3. Do use shared libraries
Leverage shared libraries for common functionality like design systems, authentication, or API clients to reduce duplication of logic and inconsistencies. Module federation easily allows setting up shared libraries, use it.
This should also help in making sure the user experience remains consistent through a centralized design system.

4. Do start small
Begin with a single feature or module to test the waters. Gradually expand the micro frontend architecture as you gain confidence and refine your processes.
If you’re transitioning from an old and large system this is even more relevant to avoid unexpected issues.

DON'Ts

1. Don’t overcomplicate your architecture
Once you unlock the power of splitting into separate apps you might enjoy it too much. You can’t look at micro frontends as if they were simple folders in your monolithic app. Splitting and organizing components into separate folders is as easy as (auto) updating the imports, doing the same over many micro frontends can be way more painful.
Avoid immediately splitting your application into too many micro frontends without a strong rationale.

2. Don’t ignore cross-team collaboration
While micro frontends promote autonomy, teams must still collaborate to ensure consistency and avoid duplication. Regular communication and alignment are essential. Some code and logic will be duplicated, that’s fine, just make sure it’s intentional and under control.

3. Don’t use different frameworks for the sake of it
Although micro frontends allow flexibility in technology choices, using entirely different frameworks (React for a module and Angular for another) can complicate integration and increase onboarding time for new developers.
Just because you can doesn’t mean you should.

4. Don’t forget testing
Each micro frontend must be thoroughly tested both independently and as part of the larger application. Skipping integration tests can result in unexpected issues when modules interact with each other.

5. Don’t forget about versioning
Proper version control is critical for shared libraries and APIs used across micro frontends. Ensure backward compatibility to avoid breaking changes that disrupt other modules. If you end up having breaking changes all the time, maybe moving over to micro frontend wasn’t the right choice (or you’re doing it wrong!)

6. Don’t skip documentation
Document the architecture, module boundaries, communication protocols, and deployment processes thoroughly. This ensures smooth onboarding for new developers and reduces confusion over time.

Conclusions

Micro frontends are indeed an interesting and valuable architecture bringing several benefits, as in our case it allowed us to gradually upgrade the system without the risks of a full rewrite by keeping the teams almost independent from each other.

However, it’s worth mentioning that it’s not always the best solution and it should be considered only if some conditions are met (application size, team(s) size, technical complexity, etc...). Smaller applications or teams may not benefit from the added overhead of managing multiple micro frontends, and simpler architectures might suffice for less complex systems.

This architecture doesn’t magically get rid of complexity, but it shifts it to other places trying to make it more manageable. If you and your team are not ready to manage that new kind of complexity, think again if this is really what you’re looking for.

As always, bad adoption of good practices can do more harm than good, do your research thoroughly and if you think you’ve got what it takes, then go for it and enjoy the flexibility of micro frontends!

Modern MVC with HTMX

Paolo Rabbito — Fri, 06 Jun 2025 15:05:35 +0000

“We need an admin panel that’s only accessible to administrators, not regular users.”
“I’d like a dashboard where I can track certain key metrics.”
“It would be great to have a web page where, as an admin, I can upload articles or manage users.”

If you’ve ever worked on an e-commerce platform, a CRM, or similar projects, chances are you’ve heard requests like these. Usually, they’re followed by something like: “It doesn’t have to be too complex—after all, regular users won’t see it.”

Issues with Traditional Approaches

To build our application, we could choose a tool like Angular or React. Alternatively, if we’re working with a backend framework such as Django or Symfony, we might opt for a template engine combined with some simple JavaScript.

However, both of these approaches have their drawbacks:

Using tools like Angular or React requires additional knowledge, more time to start up, introduces extra dependencies that need to be maintained and updated, and ultimately adds unnecessary complexity to the project.
Relying on HTML with a template engine and vanilla JavaScript is simpler in theory, but no one enjoys dealing with long stretches of JavaScript just to handle basic interactions that most libraries can take care of effortlessly nowadays.
And what if our frontend team is overloaded, and this task needs to be handled by someone who’s not comfortable with those technologies?

That’s where HTMX might be exactly what we need!

What's HTMX

From the documentation we can read that:

"htmx is a library that allows you to access modern browser features directly from HTML, rather than using javascript."

HTMX's tag-like attributes simplify interaction with the backend while keeping the logic in the HTML layer. This makes development more intuitive and reduces JavaScript complexity in many scenarios.

When applied to our use case, HTMX offers several advantages:

Since we only need to write HTML, our code is cleaner, more understandable, and easier to maintain.
The absence of JavaScript and related libraries makes it more accessible for backend developers, and reduces ongoing maintenance requirements.
Development is faster, as HTMX takes care of most of the necessary logic for us.

The Simplicity of HTMX

HTMX provides us with several useful tools for making AJAX calls, replacing parts of HTML with the received responses, triggering requests on certain events, and much more.

HTMX makes simplicity its greatest strength for several reasons:

It is so easy to integrate into your projects.
It doesn't come with heavy dependencies, doesn’t require TypeScript, nor does it rely on ES6. This makes it perfect for browser-based applications and even compatible with Internet Explorer 11.
Its lack of dependencies and the straightforward way HTMX’s code is designed make it ideal for the open-source world, encouraging user contributions and collaboration.

How to start an HTMX project

HTMX is a dependency-free, browser-oriented javascript library. To use it we can simply add a <script> tag to our document head and we are ready to go.

We can include HTMX via CDN:

<head>
  <meta charset="UTF-8">
  <title>Modern MVC with HTMX</title>

  <script 
   src="https://unpkg.com/htmx.org@2.0.4" integrity="sha384-HGfztofotfshcF7+8n44JQL2oJmowVChPTg48S+jvZoztPfvwD79OC/LTtG6dMp+" crossorigin="anonymous">
  </script>
</head>

Or we can download from here and include the file in our HTML:

<head>
  <meta charset="UTF-8">
  <title>Modern MVC with HTMX</title>

  <script src="/path/to/htmx.min.js"></script>
</head>

We can also install it in our application as an external dependency using our favorite package manager. This could be useful in case we want to extend a React application with HTMX.

Installing it:

npm install htmx.org@2.0.4

And add import in our javascript/typescript file.

import 'htmx.org';

In this article we will use it via CDN.

AJAX Requests

HTMX provides a range of attributes to handle HTTP requests directly in HTML, with each one serving a specific purpose.

hx-get

Can be used to send HTTP GET requests. It is typically employed to retrieve data from the server for display or interaction without requiring form submissions. When combined with hx-params, you can specify query parameters to dynamically modify the request.
For example:

<button hx-get="/api/data" hx-params="key=value">Fetch Data</button>

This sends a GET request to /api/data with the parameter key=value.

hx-post,hx-put and hx-patch

These attributes send HTTP POST/PUT/PATCH requests, commonly used to submit data to the server, such as form inputs or payloads. This is ideal for operations that create or update resources. For example:

<form hx-post="/api/save">
  <input type="text" name="username" />
  <button type="submit">Submit</button>
</form>

The above sends the form data to /api/save using a POST request but it can easily be changed with hx-put or hx-patch, depending on type of request we want to send.

hx-delete

Can be used to send HTTP DELETE requests, intended for removing a resource from the server. Simple and effective, it works as shown below:

<button hx-delete="/api/delete" hx-params="id=456">Delete Resource</button>

This sends a DELETE request to remove the resource identified by id=456.

Triggering Requests

It’s possible to trigger requests with different events using the hx-trigger attribute. By setting specific values for this attribute, you can control when a request is fired. Below are some examples of commonly used values for hx-trigger:

input

Fires the request on every keystroke, perfect for real-time updates (such as live search results).

<input type="text" hx-get="/search" hx-trigger="input" />

change

Fires the request only when the element loses focus or when its value changes (great for dropdowns or form fields).

<select hx-get="/api/filter" hx-trigger="change">
  <option value="all">All</option>
  <option value="active">Active</option>
  <option value="completed">Completed</option>
</select>

load

automatically once the element is initially loaded onto the page. This is useful for dynamic content loading or initializing parts of a webpage.

<div hx-get="/api/data" hx-trigger="load"></div>

delay

This value lets you delay the request by a specified amount of time after the triggering event. If another event of the same type occurs during the delay period, the countdown resets, ensuring only one request is sent after the delay. Could be useful in live search combined with other type of trigger.

<input type="text" hx-get="/search" hx-trigger="input delay:500ms" />

To check all the possible use case of triggers you can check the docs

Handle Response

HTMX provides attributes such as hx-target and hx-swap to control how and where a server’s response is applied to the DOM. These attributes give you precise control over your page's dynamic behavior without requiring JavaScript.

hx-swap

This attribute lets you define how the response content from the server is swapped into the target element (or the element that made the request). The default behavior is to replace the inner content of the targeted element using innerHTML.

<button hx-get="/api/message" hx-swap="innerHTML">Get Message</button>

outerHTMLreplaces the entire target element (including the tag itself) with the response.

<div hx-get="/api/card" hx-swap="outerHTML">Fetch Card</div>

To check every possible values read the docs

hx-target

This attribute allows you to specify which element in the DOM will be swapped with the server's response, rather than swapping the element that triggered the request.

<button hx-get="/api/message" hx-target="#output">Get Message</button>
<div id="output"></div>

The server's response replaces the content of the <div> with id="output" (using the default innerHTML swap behavior).

Practical Use Cases of HTMX

Many dashboards share common features, such as pagination, real-time data polling to update charts, form validation for adding new users or other entities, bulk file uploads, and table search functionality. HTMX simplifies the implementation of all these tasks—and much more—making development faster and more streamlined.

In this article, I’ll guide you through several practical examples to showcase HTMX's capabilities. However, I strongly recommend exploring the official documentation for a comprehensive overview of its features and use cases.

The examples presented here are built using HTMX, Tailwind CSS, and Twig (the template engine used by the Symfony framework). That said, these examples can be easily adapted to work with any backend language or template engine.

Form Validation

HTMX can be used to implement real-time form validation by sending data to the server to check its validity and dynamically displaying error messages or confirmations. For this, you can use attributes like hx-post, hx-trigger, hx-target, and hx-swap.

Controller:

#[Route('/validate-email', name: 'validate_email', methods: ['POST'])]
public function validateEmail(Request $request): Response
{
  $email = $request->request->get('email');

    // Mock validation logic (replace with your validation logic)
    $isValid = filter_var($email, FILTER_VALIDATE_EMAIL) !== false;

    // Return a user-friendly message formatted for display
    if ($isValid) {
        return new Response('<span class="text-sm text-green-600">Email is valid!</span>');
    }
    return new Response('<span class="text-sm text-red-600">Please enter a valid email address.</span>');
}

FormHTML

<form hx-post="/validate-email" hx-target="#email-validation-result" hx-swap="outerHTML">
  <label for="email" class="block text-sm font-medium text-gray-700">Email</label>
  <input
    type="email"
    name="email"
    id="email"
    class="border border-gray-300 px-3 py-2 rounded-md"
    hx-trigger="change delay:500ms"
  />
  <div id="email-validation-result" class="text-sm mt-2"></div>
  <button type="submit" class="bg-blue-500 text-white px-3 py-2 rounded hover:bg-blue-700">Submit</button>
</form>

Active Searching

To implement active searching we need to use hx-getto send get request, hx-params to add query params to our request, hx-target to point to our table that need to be populated with filtered result and hx-trigger to define when and how the get request should be sent.

Controller:

#[Route('/users_search', name: 'users_search', methods: ['GET'])]
public function search(
    #[MapQueryParameter] string $search,
    Request $request
): Response
{
    //return html file to frontend if is the first load
    if (!$request->headers->get('HX-Request')) {
        return $this->render('users/search_user.html');
    }

    //how to filter result depends on your system
    $users = $this->userService->filter($search);

    //return table rows with filtered data
    return $this->buildResponse($users);
}

Building response:

private function buildResponse($users): Response
{
    $html = '';
    foreach ($users as $user) {
        $html .=
        '<tr>
         <td class="px-6 py-4 whitespace-nowrap">
         <div class="text-sm text-blue-900">'.$user['id'] .'</div>
         </td>
         <td class="px-6 py-4 whitespace-nowrap">
         <div class="text-sm text-blue-900">'.$user['name'].'</div>
         </td>
         <td class="px-6 py-4 whitespace-nowrap">
         <div class="text-sm text-blue-900">'$user['last_name'].'</div>
         </td>
         </tr>';
    }
    return new Response($html);
}

search_user.html:

<!--....other html....-->

<input 
class="form-control border border-gray-300 rounded-md px-3 py-2 mb-4" 
type="search" 
name="search" placeholder="Begin Typing To Search Users..."
hx-get="/users_search"
hx-params="search"
hx-trigger="input changed delay:500ms, keyup[key=='Enter'], load"
hx-target="#search-results">

<!--....other html....-->

<tbody id="search-results">

</tbody>

Polling

To implement a polling system we need to use hx-getto send multiple get request, hx-swap to update the html with the response and hx-trigger to get data when we load the page and every "x" seconds.

Controller

#[Route('/polling/data', name: 'polling_data', methods: ['GET'])]
public function pollingData(Request $request): Response
{
    $companies = $this->companyService->getCompanyWithUpdate();

    //return update about growth for each company
    return $this->buildResponse($companies);
}

Build response:

private function buildResponse($companies): Response
{
    $html = '';
    foreach ($companies as $company) {
        $html .=
        '<tr > 
         <td class="px-6 py-4 whitespace-nowrap">  
         <div class="text-sm text-blue-900">'.$company['name'].'</div>
         </td>
         <td class="px-6 py-4 whitespace-nowrap">  
         <div class="text-sm text-blue-900">'.$company['growth'].'</div>
         </td>
         </tr>';
  }
    return new Response($html);
}

polling_table.html:

<!--...other html....-->
<tbody class="bg-white divide-y divide-blue-100" 
       hx-get="/polling/data" 
       hx-trigger="load, every 3s" 
       hx-swap="innerHTML">

</tbody>
<!--...other html....-->

Pagination

To implement pagination i'll show you a different approach using a template engine (Twig in this case).

In these example we have used hx-delete to send the delete request with the hx-confirm,hx-swapand hx-target inside the tbody element.

Other than delete we have used hx-get combined with hx-target and hx-swapto implement next and prev button.

Controller:

#[Route('/articles/page', name: 'app_articles_page', methods: ['GET'])]
public function page(Request $request): Response
{
    $articlesPage = $this->articlesService->getPage(
        (int)$request->query->get('page', 1),
        (int)$request->query->get('pageSize', 1),
    );

    return $this->render('articles/articles.html.twig', [
            'articles' => $articlesPage->items,
            'currentPage' => $articlesPage->currentPage,
            'totalPages' => $articlesPage->totalPages,
            'nextPage' => $articlesPage->nextPage,
            'previousPage' => $articlesPage->previousPage,
   ]);
}

Article's table:

<tbody hx-confirm="Are you sure?" 
       hx-target="closest tr" 
       hx-swap="outerHTML swap:1s">
{% for article in articles %}
<tr>
  <td class="px-6 py-4 whitespace-nowrap">
    <div class="text-sm text-blue-900">{{ article.id }}</div>
  </td>
  <td class="px-6 py-4 whitespace-nowrap">
    <div class="text-sm text-blue-900">{{ article.title }}</div>
  </td>
  <td class="px-6 py-4 whitespace-nowrap">
    <div class="text-sm text-blue-900">{{ article.price }}</div>
  </td>
  <td class="px-6 py-4 whitespace-nowrap">
    <button class="bg-red-500 hover:bg-red-700 text-white py-2 px-4     rounded" 
    hx-delete="/articles/{{ article.id }}">
      Cancel
    </button>
  </td>
</tr>
{% endfor %}
</tbody>

Article's button:

<div class="flex justify-center mt-6 space-x-2">
<button class="px-3 py-1 bg-blue-700 text-white rounded hover:bg-blue-800 disabled:opacity-50"
        hx-get="/articles/page?page={{ previousPage }}"
        hx-target="#articles-table-and-pagination"
        hx-swap="outerHTML"
{% if previousPage is null %}disabled{% endif %}>Prev</button>
<span class="px-3 py-1">
Pagina {{ currentPage }} di {{ totalPages }}
</span>

<button class="px-3 py-1 bg-blue-700 text-white rounded hover:bg-blue-800 disabled:opacity-50"
        hx-get="/articles/page?page={{ nextPage }}"
        hx-target="#articles-table-and-pagination"
        hx-swap="outerHTML"
{% if nextPage is null %}disabled{% endif %}>Next</button>
</div>

Conclusion

Implementing features like active searching, and many others, becomes remarkably simple with HTMX, requiring you to write almost exclusively HTML. This simplicity reduces development complexity while maintaining powerful functionality for dynamic, interactive web pages.

HTMX is an excellent choice for projects where advanced graphical functionality isn’t a priority, such as administration panels, dashboards, or other content-focused applications. By eliminating the need for extensive JavaScript frameworks, HTMX helps cut development costs and speeds up the delivery process, all while keeping your codebase easier to maintain.

Moreover, HTMX bridges the gap for backend-oriented developers, empowering them to create dynamic frontend features without requiring deep knowledge of modern JavaScript tooling. Its lightweight, dependency-free nature makes it not only cost-effective but also accessible to a wider range of programmers.

Whether you're building practical dashboards, simplifying server-client interactions, or just striving for cleaner code, HTMX provides the flexibility and efficiency to meet your goals. Combined with its compatibility across various template engines and backend languages, HTMX becomes a versatile and indispensable tool for modern web development.

If you'd like to dive deeper into practical examples, you can find the repository here.

Empower Your Development: Simulating AWS with LocalStack for Efficient Local Testing

Massimo Biagioli — Mon, 26 May 2025 12:38:42 +0000

Intro

In the development of cloud-based applications, the ability to replicate AWS services on local environments is invaluable, saving time and resources during the testing phase. LocalStack provides a comprehensive solution by emulating a wide range of AWS services locally, enabling developers to test their cloud applications without incurring the costs and complexities associated with connecting to actual AWS services. This robust tool supports services such as Lambda, S3, DynamoDB, and many more, offering a seamless integration with your existing AWS workflows. In this exploration, we will discuss how LocalStack can help developers and teams streamline their development process by providing a reliable and scalable local testing environment. Learn how to set up your LocalStack, integrate with your development pipeline, and leverage this powerful tool to enhance productivity, reduce development costs, and accelerate your go-to-market strategy. Embrace the power of local emulation with LocalStack and transform your cloud application development lifecycle.

Navigating the Complexity of Cloud Development

Cloud development presents a multifaceted challenge that significantly differs from traditional web development. Unlike monolithic web applications, which can often be built and tested in a single environment, cloud applications are inherently distributed, relying on a diverse array of services that interact with each other in complex ways. This architecture introduces additional layers of complexity, including service orchestration, network configurations, and data management across multiple cloud services. Moreover, the dynamic nature of the cloud environment necessitates considerations for scalability, latency, and security that are rarely required in conventional applications. Developers must navigate intricate dependencies and ensure that their applications remain resilient and performant under varying conditions. Understanding these complexities is crucial in adopting effective strategies and tools, such as LocalStack, that simplify local testing and streamline development workflows. Embracing these challenges is key to leveraging the full potential of cloud-native applications while mitigating risks associated with deployment and integration.

Use Case: Managing a New Booking in a Cloud-Based Booking System

Consider a cloud-based booking system where managing a new reservation is a key function. When a customer makes a new booking, the process involves several important steps supported by various AWS services. First, the booking details are saved in DynamoDB, which offers a scalable and easy-to-use NoSQL database for storing and accessing reservation information. At the same time, the system creates a confirmation PDF receipt to verify the booking, ensuring customers have a clear record of their reservation. This receipt is then stored in an S3 bucket, utilizing AWS's object storage capabilities for durability and easy access. By using these services, the platform ensures efficient data management and provides a smooth user experience. Implementing LocalStack allows developers to simulate this entire process locally, helping them test and improve each component —ultimately saving time and reducing costs while ensuring strong functionality before deployment.

A First Approach: Leveraging a Real AWS Environment

Testing in a real AWS environment can provide a valuable perspective on how cloud applications will perform in production. The primary advantage of this approach is:

Accurate Insights: Provides a true representation of service behavior, performance, and interactions within the full AWS ecosystem, allowing for the identification of potential integration issues.

However, relying solely on a real AWS environment for testing comes with notable drawbacks:

Cost: The expenses related to running resources in AWS can quickly accumulate, especially during extensive testing phases or with suboptimal resource management.
Complexity: Managing AWS environments can lead to longer setup and teardown times, making it challenging to iterate quickly on development and testing cycles.
Unpredictable Issues: External factors such as throttling limits, network latency, or availability concerns may arise in the shared environment, potentially distorting test results and making it difficult to consistently replicate scenarios.

Consequently, while using a real AWS environment has its merits, it is important to supplement this approach with localized testing solutions to enhance efficiency and control in the development process.

Introducing LocalStack: Empowering Local Development

LocalStack is an open-source tool that emulates Amazon Web Services (AWS) on your local machine, enabling developers to build, test, and deploy cloud applications without incurring the costs and complexities associated with actual cloud services. By providing a full-fledged local environment that mimics the behavior of AWS services, LocalStack supports a wide range of functionalities including Lambda, S3, DynamoDB, and many others.

The primary benefit of using LocalStack in the development lifecycle is the significant enhancement it brings to the feedback loop. Developers can quickly prototype and test new features in a controlled setting, leading to rapid iterations without the delays associated with deploying to the cloud. This accelerated feedback allows teams to identify and fix issues early in the development process, reducing the likelihood of regressions and enhancing the overall quality of releases.

Moreover, by integrating LocalStack into your development pipeline, you can simulate realistic scenarios that closely mirror production environments. This ensures that code changes are thoroughly tested before deployment, leading to more reliable applications and smoother rollouts. As a result, LocalStack not only streamlines development workflows but also fosters a culture of quality and accountability, allowing teams to deliver robust cloud-native applications with confidence.

You can easily run LocalStack using Docker, making it even more accessible for development teams. Here’s a simple example of a docker-compose.yml file to get you started:

services: 
  localstack: 
    container_name: "${LOCALSTACK_DOCKER_NAME:-localstack-main}" 
    image: localstack/localstack 
    ports: 
      - "127.0.0.1:4566:4566"            # LocalStack Gateway 
      - "127.0.0.1:4510-4559:4510-4559"  # external services port range 
    environment: 
      - DEBUG=${DEBUG:-1} 
      - LS_LOG=info 
      - LOCALSTACK_HOST=localstack 
      - HOSTNAME=localstack 
    volumes: 
      - "${LOCALSTACK_VOLUME_DIR:-./volume}:/var/lib/localstack" 
      - "/var/run/docker.sock:/var/run/docker.sock"

Structuring the Web Application: A Lambda-Based Architecture

Our web application follows a modern design pattern known as a "lambdalith," where we use AWS Lambda functions to create a scalable and cohesive application built with Python and FastAPI. This approach allows us to minimize the need for infrastructure management while maximizing scalability and responsiveness.

The application's architecture will include the following key components when deployed on AWS:

API Gateway: This acts as the entry point for incoming requests. API Gateway makes our FastAPI application accessible as RESTful endpoints, handling request routing, authentication, and response formatting. It ensures efficient and secure communication between clients and our backend functions.
Lambda Layer: To manage dependencies efficiently, we use Lambda Layers. This feature allows us to package shared libraries or code that can be used across multiple Lambda functions. By separating the core application logic from its dependencies, we can optimize deployment times and keep our functions lightweight.
Lambda Function: The core of our application is in the Lambda functions, which run the business logic defined using FastAPI. For this example, we use Mangum, a wrapper that transforms a FastAPI application into a Lambda-compatible function.

By structuring our web application in this way, we can take full advantage of serverless technologies while keeping our codebase maintainable and organized.

main.py

import os 

from fastapi import FastAPI 
from fastapi.middleware.cors import CORSMiddleware 
from mangum import Mangum 

from app.routers import health, booking 


app = FastAPI( 
   ... 

) 

app.include_router(health.router, prefix="/health", tags=["health"]) 
app.include_router(booking.router, prefix="/booking", tags=["booking"]) 


handler = Mangum(app)

Deciding What to Include in LocalStack: Focus on External Dependencies

When working with LocalStack, it's important to determine which components of your application to simulate locally. Since Mangum acts as a wrapper to transform a FastAPI application into a Lambda-compatible function, we can simplify our setup by focusing on external dependencies, such as S3 or DynamoDB, rather than trying to simulate the entire Lambda and API Gateway stack.

In this example, we chose the second approach. Here are three key advantages of this choice:

Simplified Development: By only simulating the essential AWS services that our application interacts with, we reduce complexity. This makes it easier for developers to focus on building and testing core functionality without getting sidetracked by configuring Lambda or API Gateway in a local environment.
Faster Feedback Loop: Concentrating on external dependencies allows for quicker testing and debugging. With LocalStack running only the necessary services, developers can rapidly iterate on their application, receiving immediate feedback and enhancing productivity. This streamlined approach accelerates development cycles.
Efficient Resource Usage: By limiting the number of resources that need to be simulated, we can run tests with a lighter environment. This makes it easier to manage local resources and keeps the testing setup straightforward, allowing developers to focus more on code quality and less on infrastructure concerns.

By focusing our LocalStack setup on external dependencies, we maintain an efficient local testing environment that supports development efforts while relying on Mangum to handle the conversion of our FastAPI application into a Lambda function.

Below is the Terraform code for creating the necessary S3 bucket and DynamoDB table:

s3.tf

resource "aws_s3_bucket" "booking_bucket" { 
  bucket = "booking" 
}

dynamodb.tf

resource "aws_dynamodb_table" "booking_table" { 
  name         = "booking" 
  billing_mode = "PAY_PER_REQUEST" 
  hash_key     = "customer_name" 
  range_key    = "check_in" 

  attribute { 
    name = "customer_name" 
    type = "S" 
  } 

  attribute { 
    name = "check_in" 
    type = "S" 
  } 
}

Use Case: Create Booking

When a customer creates a new booking, the application needs to seamlessly store the booking details and generate a confirmation receipt. To achieve this, we use the same library, Boto3, to interact with both S3 and DynamoDB when using LocalStack and when working with real AWS services. This creates a "transparent" development experience, as the code remains largely unchanged between local and production environments; developers simply need to adjust the connection parameters.

Here's a step-by-step breakdown of how the process works:

Storing Booking Details in DynamoDB: When a booking is created, the application saves the booking information—such as booking ID, customer details, and reservation dates—in a DynamoDB table. Using Boto3, the same code can connect to either LocalStack or the actual DynamoDB service in AWS by changing the endpoint URL.
Generating a Confirmation PDF
: After the booking details are saved, the system generates a PDF receipt confirming the booking. This receipt is then stored in an S3 bucket, again utilizing Boto3 to handle the upload.
Storing the Receipt in S3: The receipt is saved to an S3 bucket, providing customers with a downloadable file as proof of their booking. The code for interacting with S3 remains the same, requiring only a change in the connection parameters to switch between LocalStack and AWS.

create_booking.py

class CreateBookingUseCase: 
    def __init__( 
        self, 
        dynamodb_client: DynamoDBClientDependency, 
        s3_client: S3ClientDependency, 
    ): 
        self.dynamodb_client = dynamodb_client 
        self.s3_client = s3_client 

    async def execute(self, command: CreateBooking) -> Booking: 
        booking_id = uuid.uuid4() 

        booking = Booking( 
            **command.model_dump(), 
            booking_id=str(booking_id), 
        ) 

        pdf_path = generate_pdf(booking) 

        s3_key = f"{booking_id}.pdf" 

        self.s3_client.upload_file( 
            pdf_path, 
            settings.booking_bucket_name, 
            s3_key 
        ) 

        self.dynamodb_client.put_item( 
            TableName=settings.booking_table_name, 
            Item={ 
                'booking_id': {'S': str(booking_id)}, 
                'customer_name': {'S': booking.customer_name}, 
                'check_in': {'S': str(booking.check_in)}, 
                'check_out': {'S': str(booking.check_out)}, 
                'room_type': {'S': booking.room_type}, 
                'pdf_url': {'S': f"s3://{settings.booking_bucket_name}/{s3_key}"} 
            } 
        ) 

        return booking

libs/aws.py

start_local = os.environ.get("START_LOCAL", '0') 

LOCALSTACK_ENDPOINT_URL = 'http://localhost:4566' 
LOCALSTACK_AWS_REGION = 'us-east-1' 
LOCALSTACK_ACCESS_KEY_ID = 'test' 
LOCALSTACK_SECRET_ACCESS_KEY = 'test' 


def get_s3_client(): 
    if start_local == '1': 
        return boto3.client( 
            's3', 
            endpoint_url=os.getenv('LOCALSTACK_ENDPOINT', LOCALSTACK_ENDPOINT_URL), 
            region_name=os.getenv('AWS_REGION', LOCALSTACK_AWS_REGION), 
            aws_access_key_id=LOCALSTACK_ACCESS_KEY_ID, 
            aws_secret_access_key=LOCALSTACK_SECRET_ACCESS_KEY 
        ) 
    else: 
        return boto3.client('s3') 


def get_dynamodb_client(): 
    if start_local == '1': 
        return boto3.client( 
            'dynamodb', 
            endpoint_url=os.getenv('LOCALSTACK_ENDPOINT', LOCALSTACK_ENDPOINT_URL), 
            region_name=os.getenv('AWS_REGION', LOCALSTACK_AWS_REGION), 
            aws_access_key_id=LOCALSTACK_ACCESS_KEY_ID, 
            aws_secret_access_key=LOCALSTACK_SECRET_ACCESS_KEY 
        ) 
    else: 
        return boto3.client("dynamodb", region_name=settings.region) 


S3ClientDependency = Annotated[Any, Depends(get_s3_client)] 
DynamoDBClientDependency = Annotated[Any, Depends(get_dynamodb_client)]

Start the FastAPI local application with localstack

START_LOCAL=1 poetry run uvicorn app.main:app --reload

End-to-End Testing without Mocking AWS Services

With LocalStack, developers can perform true end-to-end testing without the need to mock AWS services. This allows teams to validate the entire workflow of their applications in a real-world environment before deployment. By simulating services like DynamoDB and S3, developers can verify that their code interacts correctly with these components, ensuring that functionalities such as creating bookings and storing receipts work as intended. This approach provides invaluable feedback, exposing potential issues early in the development process. Since the tests run against services that behave like their AWS counterparts, it increases confidence that the application will perform reliably in production. Overall, LocalStack helps maintain a high level of code quality by allowing thorough testing without the complexities and costs associated with using real AWS resources.

Verifying Operation Success with AWS CLI

Using the AWS Command Line Interface (CLI), developers can easily verify the success of operations performed on AWS services like DynamoDB and S3. With LocalStack running, the AWS CLI can be configured to point to the local endpoints, allowing for straightforward management and verification of resources.

For instance, to check the data within a DynamoDB table, you can run the following command:

aws --endpoint-url=http://localhost:4566 --profile localstack dynamodb scan --table-name booking

This will return a list of all items stored in the "booking" table, allowing you to confirm that your application is correctly saving booking details.

Similarly, to read the contents of an S3 bucket or download a file to your local machine, you can use:

aws --endpoint-url=http://localhost:4566 --profile localstack s3 ls s3://booking

or to download a specific file:

aws --endpoint-url=http://localhost:4566 --profile localstack cp s3://booking/$(key) ./downloads

These commands facilitate the verification of operations and help ensure that the application is functioning as expected, both locally with LocalStack and when deployed to the cloud. Leveraging the AWS CLI enhances the development workflow by providing direct access to data, making it easier to troubleshoot and validate application behavior.

As an alternative to configuring the AWS profile, developers can use awscli-local, a wrapper for the AWS CLI designed specifically for LocalStack. This tool simplifies the process by automatically setting the correct parameters and endpoints for local development.

Conclusion

Using LocalStack in your cloud application development streamlines testing and validation without relying on real AWS resources. By focusing on external dependencies and utilizing tools like Boto3 and the AWS CLI, developers can create a seamless environment that mirrors production. This approach enhances productivity, increases confidence in application reliability, and leads to higher-quality software before deployment in the cloud.

For a practical example of these concepts in action, you can explore the repository at this GitHub link.

Infusing Conversational AI in Your Business with Amazon Lex

Massimo Biagioli — Tue, 29 Apr 2025 06:20:27 +0000

Intro

In an era where instant and interactive customer service is the norm, Amazon Lex emerges as a transformative solution, enabling businesses to build sophisticated, AI-powered chatbots and voice assistants.

This technology leverages the same deep learning functionalities that power Amazon Alexa, making it possible to design conversational interfaces that genuinely understand the user's intent.

Amazon Lex automates interactions, offering a seamless, 24/7 customer engagement model that scales as your business grows.

This not only enhances user experience but also significantly reduces operational costs.

Business Needs

In today's fast-paced digital landscape, companies face a critical challenge: meeting customer demands for immediate support without straining their resources.

Long wait times and inadequate responses can lead to frustration and lost trust. There is a pressing need for solutions that enhance service efficiency while minimizing operational costs.

As customer expectations continue to rise, the inability to provide personalized interactions risks driving customers away.

Therefore, leveraging conversational AI like Amazon Lex becomes essential in effectively addressing these pain points.

Introducing Amazon Lex

Amazon Lex is a powerful service that enables businesses to build conversational interfaces using voice and text, effectively addressing the challenges of providing timely and accurate customer support.

By automating interactions, it significantly reduces response times and improves user satisfaction.

Key Features:

Natural Language Understanding (NLU): Amazon Lex uses advanced machine learning to understand user intents and context, improving the accuracy of interactions.
Multi-Channel Support: The service allows seamless integration with various platforms, including web applications, mobile apps, and messaging services, ensuring a consistent user experience.
Scalability: Lex is designed to easily scale with your business needs, efficiently handling increasing interaction volumes as your customer base grows.

Key Concepts in Amazon Lex

To effectively utilize Amazon Lex, it is essential to understand its key concepts:

Utterance: An utterance is what the user says or types to interact with the chatbot. It represents the user's input, which Lex will interpret to determine the desired action.
Intent: An intent is a mapping between what the user wants to accomplish and a specific action that the application should take. Each intent corresponds to a unique user goal, such as retrieving information or performing an action.
Slots: Slots are variables that capture specific pieces of information from the user's utterance needed to fulfill an intent. They act as placeholders that get filled in with data extracted from the user's input, such as dates or locations.

Consider the following examples of user utterances that correspond to an intent for retrieving warehouse movements:

Get all movements for warehouse {warehouse} on {date}
Give me all movements from warehouse {warehouse} on {date}

In these examples, {warehouse} and {date} are slots that will be populated with the specific warehouse name and date provided by the user, allowing the system to retrieve the relevant information.

A First, Simple Scenario

Imagine needing a chatbot integrated into an inventory management system. When a user interacts with the chatbot, it triggers Amazon Lex, which processes the user's request. Lex then invokes an AWS Lambda function that interprets the prompt and queries data stored in DynamoDB. After retrieving the necessary information, the Lambda function formats the response and sends it back to Lex. Finally, Lex delivers this information back to the user, ensuring a seamless and efficient interaction.

Let’s inspect the lambda

lambda_handler.py

from warehouse_service import get_movements_by_warehouse_and_date 


def lambda_handler(event, context): 
    slots = event['currentIntent']['slots'] 
    warehouse = slots['warehouse'] 
    date = slots['date'] 

    movements = get_movements_by_warehouse_and_date(warehouse, date) 
    if movements: 
        movement_list = ", ".join(m.__str__() for m in movements) 
        response_message = f"Sure, here is the list of movements: {movement_list}." 
    else: 
        response_message = "There are no recorded movements for the given warehouse and date." 

    return { 
        'dialogAction': { 
            'type': 'Close', 
            'fulfillmentState': 'Fulfilled', 
            'message': { 
                'contentType': 'PlainText', 
                'content': response_message 
            } 
        } 
    }

warehouse_service.py

import boto3 
from boto3.dynamodb.conditions import Key 
from botocore.exceptions import ClientError 

from warehouse_movement_item import WarehouseMovementItem 

TABLE_NAME = 'devrel-chatbot-dev-warehouse' 

def get_movements_by_warehouse_and_date(warehouse: str, operation_date: str) -> list[WarehouseMovementItem]: 
    dynamodb = boto3.resource('dynamodb') 
    table = dynamodb.Table(TABLE_NAME) 

    try: 
        response = table.query( 
            KeyConditionExpression=Key('pk').eq(warehouse) & 
                                   Key('sk').eq(operation_date) 
        ) 

        items = response.get('Items', []) 
        return [WarehouseMovementItem.from_dict(item) for item in items] 

    except ClientError as e: 
        print(f"Failed to retrieve items: {e.response['Error']['Message']}") 
        return []

This is the DynamoDB table’s data:

Setup the ChatBot with IaC with Terraform

Terraform is an open-source tool that enables Infrastructure as Code (IaC), allowing you to define and provision cloud resources through configuration files.

The entire infrastructure, including AWS Lambda and DynamoDB, has already been provisioned with Terraform.

Below are code snippets to set up a chatbot using Amazon Lex with Terraform.

resource "aws_lex_bot" "warehouse_bot" {
  name                        = "WarehouseBot"
  description                 = "Chatbot for warehouse movements queries"
  process_behavior            = "BUILD"
  idle_session_ttl_in_seconds = 300 # 5 minutes
  enable_model_improvements   = true
  locale                      = "en-US"
  child_directed              = false

  abort_statement {
    message {
      content      = "Sorry, I couldn't process your request. Please try again."
      content_type = "PlainText"
    }
  }

  clarification_prompt {
    max_attempts = 2
    message {
      content      = "I didn't understand you. Could you please rephrase your request?"
      content_type = "PlainText"
    }
  }

  intent {
    intent_name    = aws_lex_intent.warehouse_movements.name
    intent_version = aws_lex_intent.warehouse_movements.version
  }
}

resource "aws_lex_intent" "warehouse_movements" {
  name        = "GetWarehouseMovements"
  description = "Intent to get warehouse movements for a specific date"

  sample_utterances = [
    "Get all movements for warehouse {warehouse} on {date}",
    "Show me movements for warehouse {warehouse} on {date}",
    "List all warehouse {warehouse} movements for {date}",
    "Give me all movements from warehouse {warehouse} on {date}"
  ]

  fulfillment_activity {
    type = "CodeHook"
    code_hook {
      message_version = "1.0"
      uri             = aws_lambda_function.chatbot_lambda_function.arn
    }
  }

  slot {
    name           = "warehouse"
    description    = "The warehouse identifier"
    slot_constraint = "Required"
    slot_type      = "AMAZON.AlphaNumeric"
    value_elicitation_prompt {
      max_attempts = 2
      message {
        content      = "Which warehouse are you interested in?"
        content_type = "PlainText"
      }
    }
  }

  slot {
    name           = "date"
    description    = "The date of movements"
    slot_constraint = "Required"
    slot_type      = "AMAZON.AlphaNumeric"
    value_elicitation_prompt {
      max_attempts = 2
      message {
        content      = "For which date would you like to see movements?"
        content_type = "PlainText"
      }
    }
  }
}

resource "aws_lambda_permission" "lex_invoke_permission_generic" {
  statement_id  = "AllowExecutionFromLexGeneric"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.chatbot_lambda_function.function_name
  principal     = "lex.amazonaws.com"
}

Linking Lambda and the Chatbot

The connection between the AWS Lambda function and the chatbot in Amazon Lex is established through the “fulfillment_activity” section, utilizing a code hook. This code hook specifies that the Lambda function will be invoked to handle the logic required to fulfill the user's intent.

When a user interacts with the chatbot and their request is matched to a specific intent, the corresponding Lambda function is triggered, allowing it to process the necessary data and return a response back to Amazon Lex for the user.

This integration ensures dynamic and efficient handling of user interactions.

Let's See the Chatbot in Action

Using the AWS Management Console, it is possible to test the chatbot in real-time, allowing users to interact with it directly and observe its responses to different inputs.

A More Complex Scenario - Leveraging Generative AI with Bedrock

Now that the foundational components for building a chatbot have been established, it's possible to explore more advanced functionalities by integrating the Lambda function not only with DynamoDB but also with powerful services like Amazon Bedrock. Amazon Bedrock is a fully managed service that makes it easier for developers to build and scale generative AI applications using foundation models.

By leveraging Bedrock, businesses can enhance user interactions by utilizing advanced natural language processing capabilities, enabling more nuanced conversations with customers. This integration can significantly improve the chatbot's ability to understand complex queries and deliver more insightful responses.

From a business perspective, this translates to a superior customer experience, as users can engage in more meaningful dialogues and obtain relevant information quickly. Moreover, by providing a richer interaction model, companies can drive higher customer satisfaction and loyalty, ultimately leading to increased operational efficiency and effectiveness in meeting user needs.

Conclusion

In an increasingly competitive landscape, businesses face the critical challenge of meeting customer expectations for fast and effective support. By addressing these needs through innovative solutions, companies can enhance customer satisfaction and operational efficiency. Generative AI serves as a powerful tool in this regard, enabling more sophisticated interactions that go beyond basic queries.

Integrating a chatbot with advanced services, such as Amazon Bedrock, empowers businesses to create dynamic and meaningful conversations with users. These interactions not only provide immediate answers but also foster a deeper understanding of customer needs.

AWS stands out as a leader in offering a comprehensive suite of interconnected services that can be easily assembled to meet varying business demands. By leveraging AWS's powerful tools, organizations can build robust solutions that align with both user expectations and business objectives, ultimately driving growth and success in their respective markets.

For a practical example of these concepts in action, you can explore the repository at this GitHub link.

Prompt engineering and other fantastic creatures

Davide Donadio — Tue, 01 Apr 2025 13:00:55 +0000

Harnessing the Power of Prompt Engineering in AI Development

Prompt engineering serves as a crucial interface between human operators and Artificial Intelligence (AI), particularly in optimizing the utility of Large Language Models (LLMs). Here, we explore how various prompt engineering techniques enhance interactions with AI to achieve precise and practical outcomes, fundamentally advancing AI functionalities.

Understanding Foundation Models and LLMs

At the foundation of prompt engineering are the robust LLMs, trained on vast datasets to comprehend and replicate human-like text interaction. These models are adept at tasks that require little to no additional tuning, leveraging their capabilities through effectively designed prompts.

Practical Applications

In practical terms, LLMs have been instrumental across various fields, from easing content creation processes in digital marketing to enhancing decision-making in financial analysis. The flexibility of LLMs to adapt to different tasks makes them invaluable across sectors.

The Essence of Prompt Engineering: Dissecting the Components of a Prompt

Prompt engineering is crucial for optimizing interactions with AI models, ensuring they produce accurate and relevant responses. Each prompt consists of several key elements:

1. Instruction

This is the directive part of the prompt, clearly telling the AI the task to perform, such as “summarize the text.”

2. Data Input

It represents the content on which the AI acts, like a specific text or question, directly influencing the AI’s response.

3. Output Format

This specifies how the response should be structured, ensuring it meets certain criteria like a full sentence or a list.

4. Context

Providing relevant background or additional information can significantly enhance the effectiveness and relevance of the AI’s output.

Crafting the Perfect Prompt: For example, to analyze customer feedback sentiment:

Instruction: Report the sentiment of the feedback.
Data Input: The text of the feedback.
Output Format: Categorize as positive, negative, or neutral.
Context: Information about the related product/service.

By meticulously combining these components, prompt engineering transforms the capabilities of AI models to deliver more precise and practical outcomes.

Prompt engineering refines how these models receive and process inputs, thereby shaping their outputs. It ensures that the interactions are aligned with the specific needs of the task, which can dramatically affect the usability and accuracy of the AI's responses. Here's a deeper look at some of the pivotal prompt engineering techniques:

Zero-Shot Prompting

Zero-shot prompting is a technique where the model is directed to execute a task without the use of examples or demonstrations within the prompt itself. This approach relies purely on the model’s pre-trained understanding to carry out specific instructions.

In our exploration, we employed several zero-shot prompts, such as the following text classification example:

Prompt:

Classify the text into neutral, negative, or positive.
Text: I think the vacation is okay. Sentiment:

Output:

Neutral

Enhancements in zero-shot learning have been linked to instruction tuning, as demonstrated by research from Wei et al. (2022), which can be found here. Instruction tuning involves refining models through training on datasets that are explicitly described via instructions. Additionally, the method of Reinforcement Learning from Human Feedback (RLHF) explored here has been instrumental in scaling instruction tuning by aligning the model more closely with human preferences.

Few-Shot Prompting

Few-shot prompting is a technique that enhances model performance by providing specific examples within the prompt. These examples condition the model, helping it learn the context and improve its responses for subsequent queries.

Research by Touvron et al. (2023) indicates that the benefits of few-shot prompting emerged as models were scaled up significantly (Kaplan et al., 2020).

Here's an application of few-shot prompting demonstrated by Brown et al. (2020):

Prompt:

A "whatpu" is a small, furry animal native to Tanzania.
Use "whatpu" in a sentence.
Example: We were traveling in Africa and we saw these very cute whatpus.

To define a "farduddle" means to jump up and down really fast.
Use "farduddle" in a sentence.

Output:

When we won the game, we all started to farduddle in celebration.

This example shows that the model can effectively apply a new word in context with just a single example provided (1-shot). For more complex tasks, increasing the number of examples (3-shot, 5-shot, etc.) might be necessary.

According to Min et al. (2022), when using few-shot prompting, the choice of labels and the distribution of input text provided as examples are crucial—even if the labels aren't individually accurate. The format of the examples also significantly influences performance; surprisingly, using random labels is more effective than providing no labels. Optimal results are obtained when labels are randomly chosen from an accurate distribution rather than uniformly, which underscores the importance of how demonstrations are structured.

Chain-of-Thought Prompting

Introduced by Wei et al. (2022) in their research, chain-of-thought (CoT) prompting facilitates complex reasoning in AI models by guiding them through intermediate steps before arriving at a final response. This method can be further enhanced by combining it with few-shot prompting for tasks that demand intricate reasoning.

Prompt:

The odd numbers in this group add up to an even number: 4, 8, 9, 15, 12, 2, 1.
Adding all the odd numbers (9, 15, 1) totals 25.
The answer is False.

The odd numbers in this group add up to an even number: 17,  10, 19, 4, 8, 12, 24. 
Adding all the odd numbers (17, 19) totals 36. 
The answer is True.

The odd numbers in this group add up to an even number: 16,  11, 14, 4, 8, 13, 24. 
Adding all the odd numbers (11, 13) totals 24. 
The answer is True.

The odd numbers in this group add up to an even number: 17,  9, 10, 12, 13, 4, 2. 
Adding all the odd numbers (17, 9, 13) totals 39. 
The answer is False.

The odd numbers in this group add up to an even number: 15, 32, 5, 13, 82, 7, 1.

Output:

Adding all the odd numbers (15, 5, 13, 7, 1) totals 41. 
The answer is False.

This example clearly demonstrates the precision achieved with CoT prompting. Remarkably, we observed that even a single example can sufficiently guide the model to solve such arithmetic tasks correctly:

Prompt:

The odd numbers in this group add up to an even number: 4, 8, 9, 15, 12, 2, 1. Adding all the odd numbers (9, 15, 1) totals 25. The answer is False.
The odd numbers in this group add up to an even number: 15, 32, 5, 13, 82, 7, 1.

Output:

Adding all the odd numbers (15, 5, 13, 7, 1) totals 41. The answer is False.

Step-back Prompting

Step-Back Prompting is a method aimed at enhancing the problem-solving capabilities of LLMs by prompting them to abstract general principles before diving into detailed reasoning. This technique encourages models to focus on high-level concepts, thereby minimizing errors in the processing steps and improving the accuracy of their conclusions. Zheng et al. (2024) outline this approach in their work, highlighting its efficacy in reasoning-heavy tasks across fields like STEM, knowledge-based QA, and multi-hop reasoning. The method has shown notable improvements in models like PaLM-2L, GPT-4, and Llama2-70B, outperforming traditional techniques such as Chain-of-Thought Prompting.

How Step-Back Prompting Operates:

Abstraction: Initially, the model is prompted to consider the overarching principle or concept relevant to the query.
Reasoning: Leveraging this high-level abstraction, the model then addresses the specifics of the question.

Prompt:

Question: "What happens to the pressure of an ideal gas if the temperature is increased by a factor of 2 and the volume is increased by a factor of 8?"
Abstraction: The model determines the relevant principle: "Ideal Gas Law."

Output:

Answer: Applying this law, it calculates that the pressure decreases by a factor of 4.

ReAct Prompting

In 2022, Yao et al. introduced the ReAct framework, which enhances the functionality of Large Language Models (LLMs) by enabling them to generate reasoning traces and perform task-specific actions in a synchronized manner.

The capability to produce reasoning traces allows the model to develop, monitor, and revise action plans effectively, and even manage exceptions as they arise. The action component of ReAct facilitates the integration with external sources, such as knowledge bases or other environments, enabling the model to gather supplementary information.

ReAct significantly augments the capacity of LLMs to interact with external tools, securing more accurate and fact-based responses. The framework has demonstrated superior performance over various state-of-the-art methods in tasks involving language processing and decision-making. Moreover, the integration of ReAct with the chain-of-thought (CoT) prompting enriches the model's responses with both internal knowledge and externally acquired information, enhancing the interpretability and trustworthiness of LLMs.

ReAct is predicated on the interplay between 'acting' and 'reasoning', a combination pivotal for humans learning new tasks or making reasoned decisions. While CoT prompting has proven effective in enabling LLMs to trace logical reasoning in solving problems, it traditionally lacks the capability to interact with the external environment, which can lead to inaccuracies such as fact fabrication.

As a solution, ReAct amalgamates the concepts of reasoning and acting. It instructs LLMs to articulate verbal reasoning passages and enact specific actions relevant to the task at hand. This dual capability not only allows for dynamic and adaptable reasoning but also the integration of new information from external sources into the model’s framework, as depicted in the following example illustration of ReAct for a question-answering task.

The Impact and Future of Prompt Engineering

The advancement in prompt engineering techniques is not just enhancing the functionality of AI models but also expanding their potential applications. By improving how we structure inputs and interpret outputs, AI becomes a more powerful tool, capable of undertaking complex tasks with greater autonomy and accuracy.

As we continue to push the boundaries of what AI can achieve through sophisticated prompt engineering, the prospects for future technology—where humans and machines collaborate seamlessly—are immensely promising.

Frontend Rendering: How to Not Mess with SPAs, SSR & Friends

Leonardo Montini — Tue, 25 Mar 2025 08:02:04 +0000

The rendering strategy of a web application also defines its architecture and once you decide, it might not be trivial to transition away.

The question is: where is your content rendered? On the server or on the client?

Don’t be fooled though, the path to find the answer is way less technical than you might think!

Let's try to understand what’s hidden behind the buzzwords we see so often, SPA vs MPA and then CSR, SSR, SSG and everything else in between.

That’s funny how we like acronyms to make it easy to communicate but we use so many to the point sometimes it’s more confusing than ever.

The old problems

How did we end up with so many different techniques of just showing a web page to our users? We can try to understand that by looking at the past.

Let’s do a quick recap to understand the reasons behind each step.

The early, static, web

Ah the good old days where the web was just a collection of many static html pages, written once and published, then served as is.

Navigation is simply requesting a new page to the server and displaying it on the browser.

At first that was working fine, but updating the content meant having the developers to update the files and do a full deploy. Ok that was probably just swapping the old file with the new one but still updating something across the entire website meant doing that manually on each file, every time.

Rendering on the server

Static files were kind of a limitation, that’s why we made our web server smarter and instead of uploading pages with the full content we began creating templates. Those templates were then filled on the server by accessing the database and dynamically rendering HTML code. The final page with fresh data was then sent back to the browser.

That was such a great idea, but this moved a lot of extra pressure on servers that now had to do much more than just serving static files, we needed a solution.

Render on the Client

With the rise of AJAX we moved some load to the client that could at that time update just a portion of the page by requesting the raw data to the server and demanding the rendering duty to the browser.

We achieved interactivity without the need of reloading the entire page and distributed to the users some of the load previously on the server for everyone. Faster for the user and cheaper for the server.

If you push his approach of rendering everything on the client to its limits you no longer need to navigate between pages, you just need a single index.html and then navigation becomes simply replacing the content of the entire page with something else.

Such a great idea! However, search engine crawlers didn’t use to run javascript which meant pages rendered on the client were having a hard time being indexed, destroying their SEO. User interaction also wasn’t that great with slow connections or low-end devices, not powerful enough to take that duty we just got off the server, for example by showing empty pages as the content was loading.

Let’s render server side again

Modern frameworks like Next.js or Nuxt can do an initial render on the server so that SEO is happy and send a fully rendered page on the client so that the user immediately gets a fully formed page with data and all HTML components.

The javascript bundle is loaded separately (hydration) so that the page might be unresponsive at first but if done properly that shouldn’t even be noticeable by the user, as in fact the UI is entirely loaded.

Such a great idea! However going back to servers also brought back the old problems like excessive load and more complexity in deployments.

Caching might be a solution in some cases, in particular for those pages that might not update so often and that’s why we invented a completely new and unprecedented approach: letting the server reply with a static and fully rendered page!

What about rendering just once?

If a website doesn’t update its content so often like a blog or a marketing page, it might actually make sense to travel back in time where pages were just served as-is, and that’s what we call today SSG.

To be fair it’s slightly more advanced than 30 years ago as we now have introduced a build process that can smartly optimize and dynamically generate pages all at once, but the overall idea is exactly the same: to serve files as is. This also includes JavaScript code for interactivity if needed.

That’s a smart idea right? But we’re intentionally back at the point where in order to update some data you have to rebuild (and redeploy) your entire application.

Running in circles

History often repeats itself, and software development is no exception. However, one advantage we have is the ability to learn from past experiences and use that knowledge to make better decisions today. An example is the rise of meta metaframeworks, wrappers to the most famous client side frameworks enabling them with server side capabilities.

At the core, though, we’re still dealing with the same fundamental structure: computation that runs on the user’s device versus computation that runs somewhere else (a server, cloud function or someone else’s computer in general). All the modern solutions we have today are different ways of managing this split.

Even if we see a new JavaScript framework rise every other day, it’s all about combining and enhancing what we already have (and always had).

Informed Decisions Require Informed Developers

To make the right architectural choice, we must first understand the needs of our business and the requirements of our application. By knowing what we aim to achieve, we can smartly pick an approach with the right tradeoffs, the one which brings the benefits we need at the cost of some downsides we can ignore or are less impactful in our domain.

There’s no silver bullet or one size fits all, unfortunately.

It’s also tempting to follow what’s hyped and most talked around, if it’s the latest piece of tech it has to be the best, right? Well... that’s wrong.

As technical people we like to talk about tech, but we should never forget that the architecture of our application should be driven by the business needs.

It’s time to get more into detail for some approaches, what value they provide to the end user at what cost.

Single-Page Applications vs Multi Page Applications

Let’s briefly talk about this difference as it’s often confusing. SPAs are usually associated with CSR while MPAs are going together with SSR/SSG. While this is most often correct, it’s not actually a rule and some approaches might be mixed.

In general, the biggest strength of SPAs is that navigation is basically a lie, it’s not really navigating to another page (as MPAs were doing since day 1) but it’s replacing the entire content with the new one, providing a really fast transition that brings a smooth user experience. This is usually a requirement for those kinds of applications that are highly interactive such as SaaS products, dashboards or social media apps. Faster navigation and interactions make them look much better in a customer’s eyes.

Multi Page Applications still have their own use case that is taking care of content-heavy sites like an e-commerce, where it’s actually faster to delegate a big part of the work to the server and deliver to the client (and to search engine crawlers) a fully rendered page.

Where is your code rendered?

Regardless of if your application is all in one page or split into multiple pages, the other huge architectural decision you have to take is where is your code rendered. Client or Server? And... how often?

Client Side Rendering (CSR)

To get the most of CSR, this approach is usually combined with SPAs where the entire content of the page is replaced, without a real navigation.

The key aspect of CSR is that the initial page sent from the server is not the final result, it is usually a minimal set of HTML tags paired with some JavaScript code that is in charge of creating all the rest of the page directly in the browser.

After the initial page load, all other interactions with the server are only to request raw data, which will be then used by JavaScript to destroy and replace the needed HTML tags to render the updates.

However, there are also some challenges. The initial load time can be slow because the entire application logic, including JavaScript bundles, must be downloaded before rendering the content. This can be mitigated through a smart way of chunking your bundle, which means splitting the code of your application into smaller parts and only send to the browser the ones you need depending on what the user is doing.

The other downside is that this approach isn’t really SEO friendly.

Nowadays search engine crawlers can run JavaScript code, but that might not be enough. The first page they see will likely be blank and this might have a negative impact. Your your page also must be optimized enough to render the content even with the very limited resources a crawler might have.

You can still make it work with SEO, it’s just not as simple as with SSR.

Server-Side Rendering (SSR)

In contrast to CSR, Server-Side Rendering (SSR) generates all (or most of) the HTML content on the server for each user request before sending it to the browser. This means that the page is already rendered when it reaches the user, leading to faster initial load times and better SEO performance. Frameworks like Next.js or TanStack Start for React and Nuxt for Vue provide built-in support for SSR, making it easier for developers to implement.

Navigation usually (but not necessarily) happens through a real browser navigation where each page is an existing endpoint on the server delivering the page content.

SSR is particularly beneficial for content-heavy websites, e-commerce platforms, and applications that need to rank well on search engines. Since the content is delivered pre-rendered, search engine crawlers can index it more efficiently. Additionally, SSR improves the performance of applications on low-powered devices because the rendering is done server-side rather than relying on the client.

Despite these advantages, SSR has its downsides. Because the server has to generate a new page for every request, it can increase server load and reduce scalability compared to purely static solutions we’ll see in the next chapter. Additionally, while SSR ensures fast initial page loads, subsequent interactions may not feel as smooth as those in an SPA, since every new interaction may require a server request.

Static Site Generation (SSG)

Static Site Generation takes a different MPA approach by pre-building HTML files at build time rather than generating them dynamically for each request. This means that once the site is deployed, pages can be served instantly from a Content Delivery Network (CDN) without requiring further computation. Frameworks like Next.js, Gatsby, and Astro offer powerful tools for static site generation.

Navigation feels much like the good old days, each path means the server will provide the fully rendered page, as is.

For this reason, SSG is the optimal choice for websites where content does not change frequently, such as personal blogs, documentation sites, and marketing pages. Because the pages are already generated, they load almost instantly, providing an exceptional user experience and reducing server costs. Additionally, security risks are minimized since there is no need for active server-side processing.

However, the static nature of SSG can be a limitation for sites requiring frequent updates. Any change to the content requires rebuilding the entire site, which can be time-consuming for large-scale applications.

Incremental Static Regeneration

Incremental Static Regeneration is a hybrid approach between SSR and SSG, trying to take the best of both worlds by fixing SSG’s biggest flaw, updates.

ISR is performed by assigning to the pages some rules defining when they expire and need to be regenerated server side.

From a client perspective it will always receive fully rendered pages, but the server can decide when it’s time to update the page and start serving the new version, without the need of manual interaction or redeploying the entire website.

But what about the interactivity part of the page? Ah, there’s room for another entire article.

Choosing the Right Architecture

With all of that said, what we've seen is that web application architecture isn't a matter of right or wrong or following the trends, but of trade-offs... as everything else in the world.

In a nutshell: SPAs prioritize a fluid user experience, while MPAs focus on content delivery. SSR aims for SEO benefits, SSG emphasizes speed, and ISR attempts to bridge the gap.

Ultimately, the best architecture is the one that effectively meets your business and user needs and sets you up for long-term maintainability and success.

The best software architecture with the smaller effort

Luca Nicolini — Wed, 05 Mar 2025 16:26:08 +0000

For many years, code was written to create applications that got bigger and bigger, which we now call monolithic. Then we understood that this application was a big problem for businesses. Here are the main problems we have found with monolithic applications.

Reduced development speed: a large monolithic application makes development more complex and slower.
Scalability: scaling of individual components is not possible.
Reliability: failures in one module can affect the availability of the entire application.
Non-Agile development: Often more teams found a conflict in development code because they were working on the same code repository for different projects.
Lack of flexibility: a monolith is constrained by the technologies already used in the monolith itself.
Deployment: a minor change to a monolithic application requires a re-deployment of the entire monolith.

In recent years, many companies have migrated their monoliths to microservices architectures. Theoretically, I can assure you that it's the best choice, but in practice, there are different control indicators. Let's focus on the advantages of microservices over monoliths.

Improved scalability: because each service is a separate component, it is possible to scale a single function or service without having to scale the entire application.
Right tool for the right function: with microservices, it is possible to achieve greater independence from suppliers by choosing the right tool for each function. Each service can be written in its own programming language, can use its own structure and utilities, and can communicate with the other services in the application.
Increased resilience: with microservices, the entire application is decentralised and decoupled into services that act as separate entities. Unlike monolithic architecture, where a bug in the code affects more than one service or function, the impact of a bug in this architecture is minimal.
Faster deployment times: in monolithic architectures, changes require redeploying the entire application. A microservices architecture enables faster releases because each service is developed and deployed independently, reducing the risk and time associated with coordinating changes across an entire application.
Greater cost efficiency: activities are focused on specific services, reducing the overall cost of developing and maintaining the system. Teams work on specific functionalities, ensuring that resources are used efficiently without redundancy or excess.

Now let's talk about the drawbacks. When using microservice architecture there are two main disadvantages, in this article we'll focus on these ones and try to find a solution.

The first contraindication is the cost of the infrastructure, but we won't talk about this because it was discussed in a previous article that you can find here.

The second contradiction we're going to talk about in this article is the implementation effort. Building a microservices architecture is very expensive, both in terms of development and in terms of maintenance and monitoring. It's important not to underestimate the difficulty of the design, a bad design will become the most important problem.

There are companies that start a project with microservices and then come back because they understand that they are not ready for this architectural solution. Instead, there are companies that start migrating their monoliths to microservices and then stop because it's too expensive or too complicated.

The solution I want to recommend to you today is semi-monolithic architecture. I am talking about a hybrid architecture that uses monolithic and microservices in total harmony.

The image above shows a hybrid microservices and monolithic architecture.

I think that when you start a project you need to build a monolithic application. By monolithic I mean a large application that handles a significant part of the application domain. There may be more than one monolith in an organisation. The first thing you need to think about is dividing the application domain into a few parts and creating a monolithic application for each of them. You can think that a monolith needs to be only one, at actually we talk about monolith every time we have an application as managing a large part of the domain. So in a company there can be more monolithic application.

If you need a common part for multiple monoliths, you can create a microservice instead of a library, giving you a piece of code that can be written in a different language, updated and deployed independently of other applications.

Sometimes we need to create a microservice for a critical part that we can't scale horizontally. There are cases where we'll create a new microservice just because there's more functionality that's better implemented in a particular language.

In this type of architecture, it's very important that services communicate with them in asynchronous mode, using message queues such as SQS in AWS services. For communication from monoliths to microservices we can use http protocol for example.

Another important concept is that there will be no database sharing by applications. Each microservice will have its own database and will not access another microservice's database. This is fundamental when we use a modern ORM for database maintenance with migrations. Of course, the same is true for monoliths.

This solution allows us to create a hybrid architecture that uses microservices without abusing them. In this way, we can reduce infrastructure and development costs while taking advantage of the key benefits of microservices.

How to reduce the cost of microservices architecture

Luca Nicolini — Wed, 12 Feb 2025 11:55:47 +0000

Over the past few years, more and more companies have decided to go the microservices way. Some companies are now happy with their choice, but others have unfortunately encountered various problems. In this article, we look at the cost issue of a microservices architecture and try to provide a solution.

A big issue with microservices architecture is the cost of infrastructure. A microservice is a small application that runs inside a container. To create a microservices architecture, you need to manage tens or hundreds of containers. Obviously, this comes at a high cost in terms of the price of the machines running the containers, or cloud services if the containers are hosted in the cloud.

Now we're looking at AWS for cloud computing of our microservices. We need to know that in AWS we have two different ways of running containers, we can use EC2 machines or we can use Fargate.

With EC2, we have to pay a fixed price to AWS to run containers. A microservices architecture can consist of hundreds of microservices, and the cost of that can be very expensive.

With Fargate, the containers are serverless, so when we are not using them, they are off. We only pay for the containers while they are active.

In general, from a cost perspective, serverless resources make sense for low usage, while always-on resources make sense for high usage.

Within a microservices architecture, there are services that are called with high frequency and others that are called with low frequency, this makes you understand that some containers, unlike others, will be used very little and this represents a waste. A recent idea is to build a microservices architecture using serverless functions called Lambda, in this way microservices become a set of functions that only run when called. These functions are often called FaaS or Functions as a Service. This solution costs less than Fargate.

The image above shows an example of a serverless architecture implemented on AWS. This is a solution to save money by using a lambda serverless functions instead of microservices. This way we don't need containers and we write code without worrying about server. This is a modern solution that many companies are using today.

The first problem is that we need to create a Lambda for each function, so for large application domain we'll find a large number of Lambda function. Managing too many Lambda function may not be easy.

The second problem is in the resource consuming, for example using more Lambda on the same database the DBMS it can manage too connections. This applies to all resources used, not just the database.

The third problem is the start time for the Lambda startup when it is called in the off state. In fact, if we call a Lambda function in the off state, it'll perform a startup which will slow down the first execution. The lifecycle of a Lambda will last for a few minutes, then it'll be back in off and we'll find a new start time for the next execution.

The image above shows an example of microservices encapsulated within Lambda functions. It may look strange, but it is a powerful and versatile solution. So we can write microservices normally without thinking about concepts of serverless functions, we can deploy our microservices on Lambda functions, we can migrate our microservices to containers later.

My advice is to start with microservices within lambda function until they have low usage. When the microservice has high usage then we'll migrate to container, we can choose Fargate for high usage, EC2 for very high usage.

Now I'll show you how to implement this thing in Node.js using Fastify with TypeScript.

Let's start by creating a route as Fastify plugin.

import { FastifyPluginAsync } from 'fastify'

const routes: FastifyPluginAsync = async server => {
    server.get('/api/hello-world', async () => {
        return {
            hello: 'world'
        }
    })
}

export default routes

And then we create a simple Fastify application that uses the plugin above.

import fastify from 'fastify'

const port = 5100
const server = fastify()

server.register(import('./routes'))

server.listen({ port }, () => {
    console.log(`http://localhost:${port}/`)
})

This simple application can be seen as a first step towards creating a microservice. In this case, we are talking about a microservice running in a container, because we are implementing a web server listening on port 5100.

import fastify from 'fastify'
import awsLambdaFastify from '@fastify/aws-lambda'

const server = fastify()

server.register(import('./routes'))

export const lambda = awsLambdaFastify(server)

We've modified the code to create a Lambda function using '@fastify/aws-lambda'. This Lambda can then be deployed to AWS, for example using CloudFormation or Terraform to perform the deploy. As you can see, it's very easy going from container to Lambda and from Lambda to container.

In this repository we show an example of Terraform usage for Lambda deploy.

For container orchestration, we can use EKS or ECS. ECS is the first choice if you're in AWS, but EKS is important if you're a Kubernetes expert and you want to keep using it.

We've learned a way to write microservices, which run in a container or as lambda functions, and it's very easy to move from lambda to container or vice versa. So we've got a lot of control over the cost of our architecture, safely executed in the cloud.

The world of microservices is in continuous evolution, I think that encapsulating microservices to serverless functions is a good practice for services with low frequency of using. I also believe that using Semi-Monolithic Architecture could become important, but we will talk about this in the next episodes.

From a Brown Field to One in Bloom: Revitalizing AngularJS with React

Gianluca La Manna — Tue, 11 Feb 2025 16:34:49 +0000

If you have worked at least once on a brownfield project, you know how difficult and frustrating it can be.

You can use old approaches, but you're probably writing code without the Typescript superset. Furthermore, you are losing all the functionalities that a new framework has, which compromises the velocity and the devEx.

We can write the entire solution with another framework. Probably, this won't be a good idea, basically for two reasons:

Time 🕰️
Costs 💸

The good news is that you can write the new features with the latest framework while keeping the old features. If you have good craftsmanship, you will be able to use the strangler fig pattern by Martin Fowler, promoting a smooth and clean transition.

From brownfield to one in bloom 🌸, but how?

AngularJS issues

We take the example of AngularJS.

The most significant risk of staying on AngularJS is safety, given that Google doesn't provide new security patches.

Another big issue is the two-way-data-binding. Each change in UI is reflected in the model and vice versa.

Each state change synchronizes more variables, and the use of a digest cycle can slow the application.

The next example of how AngularJS makes you suffer is Dependency Injection 💉. In AngularJS, dependencies are injected by the name of an argument.

function MyController($scope, $state) { 
// … 
}

Here, the .toString() method is called, which extracts the argument names and then compares them with the already registered dependencies.
So, when you minify the code, it stops working.

Ultimately, we won't have TypeScript and all its advantages.

Perhaps we have enough points to think about writing with a new framework:

Safety
Two way data binding
DI
TS

Now, let's see how to integrate React into the AngularJS application.

Scaffolding React

The idea is to create a new folder in the AngularJS project's tree structure called app-new. This will be the entry point of our React application. Here, we can install the latest version of React. Preferably, we will install React with the Vite plugin.

Then, we will have a similar tree:

/
├── app
│   ├── assets
│   ├── modules
│   └── package.json
├── app-new
│   └── public
│       ├── src
│       └── package.json
├── assets
├── cypress
└── doc

As you can see, we have two package.json. One for app (AngularJS) and one for app-new (React)

Integration layer between two apps

We will create an Angular component that we will call into the routes.js file. Then, we will define a new route for this component.

 .state('react-home', {
        url: '/home',
        template: '<app-new-wrapper></app-new-wrapper>',
        data: { requiresAuth: true }
      })

Here, we can pass any props for this component.

Then, in the index.js Angular file, we should define a scope variable. This variable defines a base URL that will be used from React.

scope.NEW_APP_BASE_URL = 'http://localhost:3000';

The controller, instead, should be something like that:

(function () {
  const controller = function ($sce) {
    const ctrl = this;

    ctrl.$onInit = () => {
      ctrl.baseUrl = window.NEW_APP_BASE_URL;

      ctrl.url = $sce.trustAsResourceUrl(`${ctrl.baseUrl}/app-new/`);
    };
  };

  angular.module('libClient.common').component('appNewWrapper', {
    bindings: {
    },
    templateUrl: '/modules/common/component/appNewWrapper/appNewWrapper.html',
    controller: [
      '$sce',
      controller
    ]
  });
})();

and the view

<iframe name="iframe1" frameBorder="0" width="100%" height="100%" scrolling="no" src="{{$ctrl.url}}" allow="camera; microphone; display-capture; geolocation"></iframe>

Here's a little summary:

Generally, the iframe is not a good idea for several reasons. The basic idea is to use it only for the transition from Angular to React, then remove it. With iframe, if you have SEO on your website, you may be penalized by Google indexing and have a ranking problem, in addition to various security issues.

So, we will have 2 apps launched on different ports.

To call our React components inside the iframe, let's define them in our AppRouter with the correct url that will open the iframe.

const AppRouter = () => {
  return useRoutes([
    {
      path: '/home',
      element: <Home />
    },

    ...

Communication both frameworks

All right! Now we might ask ourselves a rather spontaneous question:

How can I communicate between a part of my app in angular and one in react or navigate through pages?

The answer? 🥁... : window.postMessage()

The window.postMessage() method safely enables cross-origin communication between a page and an iframe embedded within it

So, we create a function called goTo to navigate across the pages.

function goTo(destination: Destination, params?: NavigationParams): void {

    const {
        parent
    } = window

    parent.postMessage({
        type: 'navigation',
        state: destination,
        params: params ? params : null
    }, "*")
}

If we send a message from React to Angular, we use this

window.parent.postMessage(
        {
            type: 'UPDATE_ID',
            id: params.id.toString(),
        },
        '*'
    );

and then in the Angular controller

 window.addEventListener('message', (event) => {
  if (event.data?.type) {
    switch (event.data.type) {
      case 'UPDATE_ID':
        ctrl.id = event.data.id;
        break;
      }
    }
  });

Conclusion

With this approach, we can integrate React into AngularJS and revitalize it. A good next step would be to rewrite the old AngularJS controllers into React components. This way, we have a smooth transition from AngularJS to React. In the end, we can remove our app-new-wrapper and iframe and delete the old app folder. Then, we will have the whole project in the React framework ✨

See ya next time. 👋🏻