DEV Community: Hassan Yosuf

LLaMA 3.3 AI Assistant to My Spring Boot WebSocket App

Hassan Yosuf — Mon, 11 May 2026 19:02:07 +0000

Real-time messaging apps are great engineering exercises, but adding a conversational AI that seamlessly interacts within the same chat room takes the complexity—and the fun—to the next level.

Recently, I integrated a LLaMA 3.3 model into my messaging backend, ChatUp. Here is a breakdown of what the application is, and how I architected the AI integration using Spring Boot, WebSockets, and the Groq API.

🔗 Live Demo: Try ChatUp here

💻 GitHub Repo: HassanYosuf/ChatUp

What is ChatUp?

Before adding AI, I built ChatUp as a robust, real-time messaging backend. The goal was to engineer a system capable of low-latency, bi-directional communication and real-time state synchronization.

Under the hood, it is powered by an event-driven architecture using Spring Boot and WebSocket/STOMP. The frontend is highly responsive, built entirely with HTML5, CSS3, and ES6+ JavaScript, utilizing SockJS for reliable WebSocket fallback and cross-browser compatibility. To ensure the application is easily deployable and scalable, the entire system is containerized with Docker and hosted on the Render cloud.

The Core Architecture of the AI Integration

To keep the application highly maintainable, ChatUp utilizes a modular MVC architecture. When it came time to introduce AI capabilities, my primary architectural constraint was strict: the AI integration could not disrupt or add latency to the core human-to-human message flow.

How It Works: Intercepting the Stream

Instead of building a separate "bot chat" interface, I wanted the assistant to live directly inside the existing multi-user chat rooms.

Here is the event flow:

The Trigger: The application monitors the WebSocket stream and intercepts any messages prefixed with @ai.
The Routing: Once detected, the message is decoupled from the standard chat flow and routed to a dedicated AI service layer.
The Brains: This service layer processes the message and handles the external call to the Groq API (running the LLaMA 3.3 model).
The Broadcast: Once the LLM generates a response, the Spring Boot service broadcasts the AI's reply in real time back to all subscribers in that specific chat room.

Frontend Handling

On the client side, I wanted to ensure the user experience remained intuitive. I added distinct UI rendering logic to the JavaScript. AI-generated messages are styled differently from standard user messages, making it immediately clear when the LLM is speaking to the room versus a human participant.

Swapping the Brain: Alternative APIs

One of the biggest advantages of decoupling the AI logic into a dedicated service layer is that you aren't locked into a single provider. While I used Groq for its incredibly low latency with LLaMA 3.3, this architecture makes it trivial to swap in other LLM APIs by simply changing the endpoint and payload structure in the service class.

If you are looking to build something similar, here are a few other APIs that fit perfectly into this pattern:

Anthropic Claude API: If your chat rooms require complex reasoning, coding assistance, or handling large contexts (like summarizing a long chat history), Claude is an excellent alternative. It is highly capable and relatively easy to integrate into a Spring Boot pipeline.
OpenAI API (GPT-4o-mini): The industry standard. It's incredibly reliable, well-documented, and the -mini model is fast and cost-effective for high-volume, real-time chat environments.
Local Models via Ollama: If data privacy is a strict constraint or you want to run the system entirely on-premise without API costs, you can point your Spring Boot service to a local Ollama instance running open-weights models. The latency will depend entirely on your hardware, but the integration pattern remains exactly the same.

Wrapping Up

Integrating an LLM via the Groq API into a live STOMP/WebSocket pipeline was a fantastic exercise in decoupling services. By isolating the AI routing into its own layer, the app successfully maintains high-performance real-time state sync for normal chats while offering powerful generative AI capabilities on demand.

If you are working with Spring Boot WebSockets or integrating LLMs into event-driven systems, feel free to check out the repo or drop a comment below!

MVC (Model-View-Controller)

Hassan Yosuf — Thu, 05 May 2022 16:30:08 +0000

Introduction:
The Model-View-Controller (MVC) is an architectural pattern that separates an application into three main logical components: the model, the view, and the controller. Each of these components is built to handle specific development aspects of an application. MVC is one of the most frequently used industry-standard web development frameworks to create scalable and extensible projects.

MVC Architecture:

Model:
The Model component corresponds to all the data-related logic that the user works with. This can represent either the data that is being transferred between the View and Controller components or any other business logic-related data. For example, a Customer object will retrieve the customer information from the database, manipulate it and update it data back to the database or use it to render data.

View:
The View component is used for all the UI logic of the application. For example, the Customer view will include all the UI components such as text boxes, dropdowns, etc. that the final user interacts with.

Controller:
Controllers act as an interface between Model and View components to process all the business logic and incoming requests, manipulate data using the Model component and interact with the Views to render the final output. For example, the Customer controller will handle all the interactions and inputs from the Customer View and update the database using the Customer Model. The same controller will be used to view the Customer data.

In Java Programming, the Model contains the simple Java classes, the View used to display the data and the Controller contains the servlets. Due to this separation, the user requests are processed as follows:

A client (browser) sends a request to the controller on the server-side, for a page.
The controller then calls the model. It gathers the requested data.
Then the controller transfers the data retrieved to the view layer.
Now the result is sent back to the browser (client) by the view.

Advantages of MVC Architecture:

Faster Development Process
Ability To Provide Multiple Views
The Modification Does Not Affect The Entire Model
MVC Model Returns The Data Without Formatting
SEO Friendly Development Platform
MVC has the feature of scalability that in turn helps the growth of the application.
The components are easy to maintain because there is less dependency.
A model can be reused by multiple views that provide the reusability of code.
The developers can work with the three layers (Model, View, and Controller) simultaneously.
Using MVC, each layer is maintained separately therefore we do not require to deal with massive code.
The extending and testing of applications is easier.

Disadvantages of MVC Architecture:

Complexity
Cost of Frequent Updates

MVC on the Web-based Applications
As a web developer, this pattern will probably be quite familiar even if you've never consciously used it before. Your data model is probably contained in some kind of database.Your app's controlling code is probably written in HTML/JavaScript, and your user interface is probably written using HTML/CSS/whatever else you like. This sounds very much like MVC, but MVC makes these components follow a more rigid pattern.
In the early days of the Web, MVC architecture was mostly implemented on the server-side, with the client requesting updates via forms or links, and receiving updated views back to display in the browser. However, these days, more of the logic is pushed to the client with the advent of client-side data stores, and XMLHttpRequest allowing partial page updates as required.
Web frameworks such as Spring MVC, AngularJS, and React.js all implement an MVC architecture.

MVC Flow Diagram:

Flow Steps
Step 1 − The client browser sends requests to the MVC Application.
Step 2 − Global receives this request and performs routing based on the URL
Step 3 − This routing operation calls the appropriate controller and executes it
Step 4 − The Controller processes the data using the Model and invokes the appropriate method
Step 5 − The processed Model is then passed to the View, which in turn renders the final output.

Conclusion

The MVC pattern has many advantages by separation of input logic, business logic and UI logic and on the other hand it also increases the development speed, easy to understand and test the bugs and error. It completely segregates the different layers of software architecture such as the Model Layer, View Layer, and Controller Layer.
It increases the readability of the code but on the other hand, it has some drawbacks such as framework navigation can be complex because it introduces new layers of abstraction and requires users to adapt to the decomposition criteria of MVC. and Knowledge on multiple technologies becomes the norm. Developers using MVC need to be skilled in multiple technologies.