Forem: Sami Ekblad

What makes Vaadin components special?

Sami Ekblad — Fri, 29 Aug 2025 09:06:00 +0000

Vaadin has always been a bit different.

Yes, it's a Java framework. Yes, it’s great for building modern web UIs. But if you’ve ever used Vaadin seriously, you’ve probably noticed something that sets it apart: its component architecture.

Whether you're using a ready-made component from the official library, building your own from scratch, or integrating a 3rd-party NPM package, all Vaadin components follow a consistent maintainable structure that bridges the server and the client and can evolve along with your application.

Not just widgets

There are lots of UI libraries out there. React has its components. Lit has web components. Bootstrap has... buttons.

Vaadin? It’s not just about visuals. It is not uncommon that Vaadin application and components are developed and maintained for many years. That is by design and is part of the Vaadin ideology.

With Vaadin the UI components can live entirely on the server, fully on the client, or anywhere in between. That flexibility is the superpower.

To better understand what and how, let’s go through the main types of components Vaadin has and and you can also build with Vaadin.

Server-only components

This is the most "Vaadin-native" approach. You’re writing pure Java. No HTML templates. No JavaScript. Just composing UI dynamically from existing Vaadin components (like TextField, Button, Grid, etc.) and building higher-level features—think “InvoiceEditor” rather than just “Form”.

Great for back-office UIs, internal tools, and anything where control and validation matter more than animations and visual finesse.

Pros:

Full user input validation on the server
No need to write or maintain any front-end code
Dynamic UI generation on the fly
Easy to hook into existing Java libraries and logic

Cons:

All interactions round-trip to the server
Not ideal for things like animations or drag-and-drop interactions

Want to create your own? Use this add-on project template

Client-server components

Here’s where things get exciting.

This type of component combines a custom client-side element (written in Lit, TypeScript, or plain Web Components) with a Vaadin Java API on the server. You get the best of both worlds: smooth UX and secure logic.

Want to build a date picker that works exactly how your users expect—right down to keyboard shortcuts and color transitions—but still ensure the selected date is validated against backend rules? This is your pattern.

Pros:

Full DOM access and rich interactions
Server-side Java validation and logic
Clean separation of concerns, with communication handled by the framework

Cons:

Requires knowledge of both client-side and server-side tech (TypeScript + Java)

Want to create your own? Use this add-on project template

Wrapping third-party custom elements

Sometimes, you don’t want to build it yourself. Fair enough.

In 2025, the web is full of amazing custom elements you can install with npm and drop into your app. Vaadin makes it easy to wrap these into reusable components—with a little TypeScript glue—and expose them to your Java UI.

Pros:

Rapidly integrate NPM-based components into your Java app
Minimal boilerplate to get started
Great for visual enhancements or non-critical UX features

Cons:

Server-side validation is still your responsibility
Some components may not blend perfectly with the Vaadin design system

Want to create your own? Use this add-on project template

Choosing the right model

Which one should I use? Each type of Vaadin component has its place. The idea is not to pick just one and stick with it—it’s to use the best tool for the job:

Server-only components for secure, logic-heavy forms and flows
Client-server components for interactive, UX-rich widgets
NPM-wrapped components for integrating modern web UIs quickly

The beauty of Vaadin is that these all coexist in the same app. You don’t need to compromise. You can treat your UI as a tree of components, each doing what it does best—on the server or the client. Your application integrates them on logical level: button is still fundamentally a button regardless of it's implementation.

The real magic behind Vaadin components isn't about whether they look nice or use Java or TypeScript. It’s the flexibility and maintainability. You can build UIs in Java, TypeScript, or both. You choose where the logic lives. You validate securely and integrate freely.

Most importantly, you don’t have to rewrite your app just to take advantage of something new. The component model is built for real-world apps that evolve over time.

Have you explored the different component types in your app? What kind of hybrid approach have you found most useful?

Third-Party Cookies Are Gone (Or Not). How Can I Still Embed Cross-Site Apps?

Sami Ekblad — Wed, 31 Jul 2024 14:32:00 +0000

In 2024, there has been significant discussion about third-party cookies becoming obsolete or user configurable. While these changes are beneficial for user privacy, they complicate the lives of web application developers who want their applications or widgets to be shared across different websites. The main question remains: can I still make embedded web applications? How can we ensure that those still work?

Here’s a brief guide on how to configure your web application to ensure it remains unaffected by upcoming changes.

Server-Side Configuration

Assuming your web application is already designed for website embedding, you only need to configure a few things on the server side to keep your application up and running.

1. Enable TLS for HTTPS

While maintaining secure data transmission has been a best practice for a long time, enabling TLS (or SSL) for HTTPS is now mandatory. The method for enabling SSL depends on where your application is hosted. For instance, Fly.io offers a force_https = true option to configure apps to use HTTPS only.

2. Configure Session Cookies

Embedded applications often rely on session cookies to function correctly. Properly configuring these cookies with the necessary attributes is critical.

SameSite=None: Means that the browser sends the cookie with both cross-site and same-site requests. The Secure attribute must also be set when setting this value.
Secure: Ensures that the cookies are only sent over HTTPS, protecting them from being intercepted in transit.
Partitioned: This attribute, part of the CHIPS (or Cookies Having Independent Partitioned State) proposal, ensures that cookies are partitioned based on the top-level site context, adding an extra layer of privacy by isolating cookies to the specific context. This is important since otherwise browsers will block the cookies in the future.

In the end, your session cookie headers should look something like this:

Set-Cookie: PHPSESSID=abcde12345; path=/; HttpOnly; SameSite=Strict; Secure; Partitioned

Set-Cookie: JSESSIONID=abcde12345; Path=/; HttpOnly; SameSite=Strict; Secure; Partitioned

3. Add Basic CORS Headers

The W3C defines the CORS protocol, which allows you to specify which sites can embed your content. Adding the appropriate CORS headers to your HTTP responses ensures that your content can be securely embedded across different origins. Some required during the preflight (OPTIONS) request and others during the actual (GET, POST,...) request.

Sent During Preflight Requests:

Access-Control-Allow-Methods: Specifies the HTTP methods (e.g., GET, POST, PUT, DELETE) allowed when accessing the resource. This header is sent in response to a preflight request to inform the client of the methods supported by the server.
Access-Control-Allow-Headers: Lists the HTTP headers that can be used during the actual request. This is sent in the preflight response to let the client know which headers can be included in the actual request.
Access-Control-Max-Age: Indicates how long the results of the preflight request can be cached by the client. This allows the client to cache the preflight response for a specified duration.

Sent During Actual Requests:

Access-Control-Allow-Origin: Specifies the origin(s) allowed to access the resource. You need to use an explicit list of allowed domains instead of the wildcard (*). This header is sent in the actual response to indicate which origins have access to the resource.
Access-Control-Allow-Credentials: true tells browsers that the server allows cross-origin HTTP requests to include credentials. This is sent either in preflight or in the actual response to indicate whether credentials (such as cookies or HTTP authentication) are allowed to be included in the real request.

How you set these headers in HTTP responses depends on the framework and runtime environment you use, but the principles are the same.

Configuring the Hosting Page

Some HTTP headers need to be configured on the hosting page. Consider setting up the Cross-Origin-Embedder-Policy and the Cross-Origin-Resource-Policy. By default, these policies allow embedding and resource loading, but configuring them helps enhance the security of your application by restricting unauthorized access and embedding.

Demo Setup: Seeing is Believing

As you might know, my default full stack consists of Spring Boot and Vaadin, and that is what I use here too. You'll find my small demo live at: samie.github.io/vaadin-cors-sample. When using Chrome, test it with the third-party cookies disabled.

Conclusion

Yes, embedding cross-site applications will remain a valid approach in the future. By carefully configuring your server to handle cookies and headers correctly, you can maintain secure and functional cross-origin embedding even as third-party cookies evolve. This ensures your applications or widgets can continue to work across different websites without compromising on security or functionality.

Like always, source code at GitHub. See you there!

UX vs. KPIs? Lessons from Copenhagen's Bike Rentals.

Sami Ekblad — Wed, 03 Jul 2024 10:05:00 +0000

Story time. Recently we were visiting Copenhagen, the city known for the Little Mermaid and its vibrant biking culture. Eager to explore more of the city, we decided to rent bikes. The streets were lined with sleek, inviting rental bikes, and I picked the best-looking electric one. A QR code on the bike invited me to “Start here!”

Simple as 1-2-3

And that’s when the trouble began. The QR code led me to the company’s website, which advertised rental services to cities and communities. Not exactly user-friendly for someone just wanting a bike ride.

Well, I headed to the App Store to find the company’s app. Two apps appeared. Neither clearly indicated which one was for me. After some digging, I figured out which one to install. The other app was for cities to manage their bike fleets.

Upon launching the app, I was hit with a standard registration form: name, email, phone. This is where I hit a complete showstopper. The continue button was hidden underneath the virtual keyboard. Knowing many tricks iPhone didn’t help. Focusing on any of the fields popped up the keyboard and covered the continue button. We went for another bike rental.

What about KPIs?

I noticed plenty of unrented bikes from this company. In contrast, other bike rentals had almost all their bikes in use. I could imagine the frustration of their leadership team — high season, bikes sitting idle, new users almost nonexistent.

Maybe Android users just are more likely to rent a bike? Maybe the competitors have better bikes? Do we have the bikes in the right spots?

However, the lesson to learn here is clear: This isn’t a demographic issue or a need for expensive competitor research/analysis. It just a obvious UX problem. If the first touchpoint with your service is frustrating, users will abandon you quickly — they might not have a choice.

Prioritizing real-life field testing is the only way to spot and validate issues like this. Make the user experience your top priority, and the other KPIs will follow.

The saddest thing was that the next night they reorganized 10+ bikes, moved them to a better spot. And they all were there, unrented.

PS. I don’t want to mention any names or brands here, but if you happen to recognize yourself, I’m happy to provide further details and help. The bikes look awesome.

Happy Path: Web UI for Ollama using Java Only

Sami Ekblad — Tue, 21 May 2024 18:04:00 +0000

I found that getting a local LLM up and running is becoming easier and easier, so it's time to update the guides. In this article, I'm setting up Ollama and building a minimal web UI—all in Java.

A full-stack application with a Vaadin frontend and Spring Boot backend.
Real-time chatting capability using a local Ollama in a container.
Dynamic message streaming and display of Markdown for the UX you would expect.

We will need the following installed:

Java 21
Maven for building the app
Local Docker container environment for running Ollama

Install and Run Ollama Container

First, set up the Ollama Docker container:



docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

Next, we need to install some of the supported LLM models, with 'mistral' being the default. This will take a while to download:



docker exec ollama ollama pull mistral

Once done, you can check if the model is up and running by calling the REST API from the command line. For example:



curl http://localhost:11434/api/chat -d '{"model": "mistral", "messages": [{"role": "user", "content": "is black darker than white?"}], "stream":false}'

Creating the Web UI

Generate a new Spring Boot project using Spring Initializr. You can configure the dependencies you need, but for this, we only need:

Ollama - Spring AI APIs for the local LLM
Vaadin - for Java web UI

Here is direct link to the configuration.

This will create a ready-to-run project that you can import into your Java IDE.

Adding Extras

To use Vaadin add-ons, configure the dependencies in your pom.xml. We want to use the Viritin add-on for handy Markdown streaming.



<dependency>
    <groupId>in.virit</groupId>
    <artifactId>viritin</artifactId>
    <version>2.8.14</version>
</dependency>

Building the Web UI

We still need the UI. Create a MainView class to handle the chat UI and interaction with the local LLM. Injecting Spring beans into the Vaadin UI, this is all that is needed:



@Route("") // map view to the root
class MainView extends VerticalLayout {

    private final ArrayList<Message> chatHistory = new ArrayList<>();

    VerticalLayout messageList = new VerticalLayout();
    Scroller messageScroller = new Scroller(messageList);
    MessageInput messageInput = new MessageInput();

    MainView(StreamingChatClient chatClient) {
        add(messageScroller, messageInput);
        setSizeFull();
        setMargin(false);
        messageScroller.setSizeFull();
        messageInput.setWidthFull();

        // Add system message to help the AI to behave
        chatHistory.add(new SystemMessage("Only if the user asks you about Vaadin, reply in bro style. Always show a piece a code."));

        messageInput.addSubmitListener(ev -> {
            // Add use input as markdown message
            chatHistory.add(new UserMessage(ev.getValue()));
            messageList.add(new MarkdownMessage(ev.getValue(),"Me"));

            // Placeholder message for the upcoming AI reply
            MarkdownMessage reply = new MarkdownMessage("Assistant");
            messageList.add(reply);

            // Ask AI and stream back the reply to UI
            Prompt prompt = new Prompt(chatHistory);
            chatClient.stream(prompt)
                    .doOnComplete(() -> chatHistory.add(new AssistantMessage(reply.getMarkdown())))
                    .subscribe(cr -> reply.appendMarkdownAsync(cr.getResult().getOutput().getContent()));
            reply.scrollIntoView();
        });
    }
}

You can run the application either by running the main Application.java class from your IDE or from the command line using Maven: `mvn spring-boot:run'.

Now we can chat with the Ollama Mistral model locally at localhost:8080

Conclusion

This was another one of those step-by-step guides that I wrote mostly for myself when setting up a small demo application. The full app is in GitHub (note the branch), if you wish to use it as a starting point for your own demos.

If you find it useful, let me know in the comments. Thanks!

Running Java App using Google Cloud Run

Sami Ekblad — Wed, 21 Feb 2024 21:05:00 +0000

In our journey we've created a Net Promoter Score (NPS) widget and application that saves data to a Google Spreadsheet. This time, we take the app to the cloud.

Since we already used Google Sheets for storage, it felt natural to use Google Cloud Run for deployment. It offers a fully managed platform with enough of resources that allows applications to run in containers accessible via the web. Additionally, when using the Cloud Console, we do not need to install any local tools, streamlining the deployment process.

Clone, Build, Deploy

Deploying Java applications in the cloud has been a challenge. However, recent advancements have greatly simplified this process. Utilizing build packs or a Dockerfile, we can build and deploy Maven applications quickly.

Step 1: Navigate to shell.cloud.google.com to access Google Cloud's integrated shell environment. This is a full-featured IDE in your browser.

Step 2: Clone the NPS project from GitHub github.com/samie/nps. This repository contains a Vaadin add-on itself, but also the demo application project we want to deploy.

Step 3: If your project lacks a Dockerfile, you need to add one. You can use Java build packs, but a two-phase Dockerfile gives you a more definitive build. This first downloads all dependencies before creating your Vaadin application's production build.

Step 4: Build and deploy to Cloud Run. Select the correct Dockerfile, in this case, demo/Dockerfile, and initiate the build. Deployment build may take several minutes (typically 3 to 4 minutes).

Upon successful deployment, you will encounter an error related to Google Sheets access:

{ width=60% }

This was expected. We need the credentials to access the Google Sheet.

Configuring Secrets

Managing environment variables and secret files in cloud environments can be tricky. Google provides a "Secret Manager" tool where you can safely manage your application-specific secrets.

Step 1: Create a Secret
Create a new secret containing the service account credentials to access the Google Sheet at console.cloud.google.com/security/secret-manager. If you already created a key for the Service Account, you can paste the content of that file, or you can create a new key at console.cloud.google.com/iam-admin/serviceaccounts and choose tab "Keys" in the correct service account.

Step 2: Make Secrets Available
Make these secrets available to your deployed containers by creating a special "secrets" volume under the "Volumes" tab. Then, mount this volume to /local on the container through the "Containers" tab.

Step 3: Use secrets in the code
Adjust your application code (in this case, in NPSView.java) to check for the proper credentials file location at /local/<secret_name>.

With the secrets configured and your application adjusted, click "Deploy" to finalize the process. Your application should now be operational!

The NPS feedback view is running at nps-u342s5ewoq-uc.a.run.app/
And the embedded page sample at nps-u342s5ewoq-uc.a.run.app/example.html

Conclusion

I was captivated by the simplicity of cloud-only tooling. Building directly from GitHub in browser IDE without local installations was refreshingly straightforward. The most challenging part was ensuring secure access to sensitive files, and I was a bit disappointed with how little synergy GCP offered for my architecture. Nevertheless, once you navigate its terminology and enable all the needed services, Google Cloud Platform provides robust tools to build anything.

This marks the end of the series. It was initially a set of personal memos, from crafting a custom Vaadin widget, calling APIs, and integrating cloud services. But it grew into this guide, the path of deploying Java-only applications in the cloud. I hope you enjoyed the journey as much as I did.I thank you for joining this journey.

Happy coding, and let me know what you built!

Integrating a Vaadin Web Application into External Webpages

Sami Ekblad — Fri, 13 Oct 2023 10:39:41 +0000

Have you created a web application that would make more sense embedded into another web page?

In my previous blog, I created an NPS (Net Promoter Score) widget that stores data directly into Google Sheets, and in this blog, we look at what it takes to embed this single Vaadin-based view as a part of any other web page. After all, you want to collect user feedback like NPS in the right place and context.

Our primariry goal is to have the web application embedded into another web page. Furthermore, having it in a popup instead of directly on the page makes sense. The example.html is our host page with two examples: direct embedding and a JavaScript popup.

Export a web component...

First, we need to export the application to use from another page. In Vaadin, a utility called WebComponentExporter takes any Vaadin view and exports it as a single custom element. To export a custom element called nps-feedback we create the following class:



public class CustomElementExporter extends WebComponentExporter<NPSView> {
    public CustomElementExporter() {        
        super("nps-feedback");
        // ... [further configuration goes here] ...
    }
}

We can add attribute handling to allow NPS view configuration when using it as custom element. Like passing the header title:



addProperty("header", "Thank you for visiting us").onChange(NPSView::setHeader);

This adds a element property named header with a default value . Whenever the property changes, the setHeader method of NPSView will be called with the new value.

...and embed to a page.

Let's jump into our example host page and see how to embed the NPS feedback there.

The simplest way is to include the component just as-is:



<script type="module" src="./web-component/nps-feedback.js"</script>
<nps-feedback id="nps-web-component" product="page" header="Thanks for being here" question="How like you are to come back?"></nps-feedback>

This will import show the web component to the page. However, I wanted to have the NPS survey presented in a popup dynamically. So, let's check further.

Micro frontend in a dynamic popup

Micro frontends is an architectural style that extends the concepts of microservices to the frontend. It advocates splitting the frontend into smaller, more manageable pieces, each deployable independently.

For our use case of NPS feedback, including it non-intrusively as a popup that the user can open (or can be opened programmatically) on desired pages often makes much sense.

The popup functionality is in a separate JS file. Here, the npm.js module also imports the web component dynamically when needed. It exports the popup functionality in logical methods that we import in our host page:



<script type="module">
import {createNpsPopup, openNpsPopup, closeNpsPopup} from './nps.js';
createNpsPopup("myappfeedback", "Thank you for visiting the service");
</script>

To create a button on the host page to open the created popup, you can attach a click listener as follows.



document.querySelector("#openNpsBtn").addEventListener('click',openNpsPopup);

Conclusion

Embedding your NPS widget as a micro frontend within another webpage is a leap towards enhanced user engagement and modular code. Definitely the way to go with small apps like this.

If you wish to explore more, let the GitHub repository be your launchpad into an ecosystem where web applications no longer need to be monoliths.

Push data to Google Sheets from your Java app

Sami Ekblad — Thu, 29 Jun 2023 14:46:01 +0000

The previous article explained how to make a reusable NPS feedback component. After writing the article, I made a few tweaks to the component:

A square style for the buttons
Customizable texts

These are good additions to make the component usable in any application but to get further, we need something outside the UI: Store the NPS feedback data somewhere in the cloud.

Use the spreadsheet for NPS feedback

Isn't that obvious when you say that aloud? After all, people who collect this type of user feedback are also familiar with spreadsheets. Let's keep it simple for them.

For the scope of this NPS application, I used Google Sheets, which is more configuration than programming. The spreadsheet layout is simple enough: timestamp, anonymous user id, and the NPS score columns. I also added a "Feedback" column for future improvements.

Creating a Google Service Account

This is the configuration part you must do in Google Cloud. Service Accounts are the application-specific counterpart of user accounts. To create one to access Google Sheets:

Select or create a new project, and add a new Service Account without other roles or permissions.
Go to "Manage Keys", click "Add key", and create and download a new Service Account authentication JSON key. Store it somewhere safe outside the code repository.
Enable the Google Sheets API for the project.

Authorize the Service Account to access your sheet

Now that you have your Service Account set up, we can give it access to the document you created:
Copy the email of your Service Account. It is the one like 'app-name@project-name-123456.iam.gserviceaccount.com'
Grant editor permission to this account in your NPS Spreadsheet.

Libraries and code

We are back in IDE. One service account and the spreadsheet has been created. It's time to access them from your application code.

When building new functionality, I like to start by "writing the code I like". This helps me design the API I need for the use case. In this case, I started with the following in my ValueChangeListener:

String userId = "" + UI.getCurrent().hashCode(); // for testing only
int npsScore =  e.getValue(); // User fee
FeedbackSheet sheet = new FeedbackSheet();
sheet.append(userId, npsScore);

So, most of the implementation would go to the FeedbackSheet.java. Logically it does the following things:

Read the ServiceAccountCredentials from a JSON file
Creates a Sheets instance to run authorized actions for a specified sheet. An append method adds a new row to the first sheet.

This is the code part. To make this work, you need to add a couple of dependencies to pom.xml. They are the Google Java libraries for Google Sheets, OAauth2 and JSON parsing:

Update 2024-10-24: latest versions of the libraries.

<dependency>
    <groupId>com.google.api-client</groupId>
    <artifactId>google-api-client</artifactId>
    <version>2.7.0</version>
</dependency>
<dependency>
    <groupId>com.google.apis</groupId>
    <artifactId>google-api-services-sheets</artifactId>
    <version>v4-rev20241008-2.0.0</version>
</dependency>
<dependency>
    <groupId>com.google.oauth-client</groupId>
    <artifactId>google-oauth-client</artifactId>
    <version>1.36.0</version>
</dependency>
<dependency>
    <groupId>com.google.http-client</groupId>
    <artifactId>google-http-client-gson</artifactId>
    <version>1.45.0</version>
</dependency>

Findings and Conclusion

Using Google Sheets to store data is a manageable amount of Java code - once you find it. There are a few good articles like this one from Baeldung, but getting the code to match the configuration takes some work. Also, Google Cloud is a living thing; many other articles I found outdated in 2023.

The way I use it here has the benefit of the spreadsheet owner granting and revoking access to the documents to an app, but it does not offer any fancy impersonation possibilities which would need a OAUth consent dialog.

If you want to try locally, you'll find the sample code in GitHub and the sample feedback spreadsheet in Google Sheets.

Creating Custom Component for NPS Feedback

Sami Ekblad — Sun, 30 Apr 2023 12:38:39 +0000

(Update 2023-05-24: The component is available as add-on at vaadin.com/directory/component/nps.)

We had a project that needed to implement the famous Net Promoter Score or NPS feedback. Quite boring, TBH. Just one of those relatively trivial UIs that you need to have. ("Does this spark joy?" It would most definitely be a clear "No." ).

However, there is a good reason for collecting user feedback like this, and we wanted to have it. I immediately thought that something like this would make sense as a separate component (mainly to avoid doing it again), so I decided to do that.

Here is the process I went through to build a reusable version. This blog is again for Vaadin, but the principles and the "build reusable components" -thinking makes sense on any web or IU framework.

Create a new add-on project

The first step in reusability: We want to create a separate add-on project. I used the Vaadin default addon-template from GitHub and created a new repository under my account. This project is a good starting point as it provides the boilerplate for packaging and distribution.

Clone the project locally

Next, clone the repository project locally in Visual Studio Code. I'm using the Dev Containers to run the project separately from others. There is a ready-made Java container to which I add Maven as a build system.

Vaadin Tip: Upgrade to V24
At the time of writing, the template project was still on older Vaadin 23. So a minor update is needed to pom.xml to make it compatible with the latest Vaadin version.

Vaadin version to 24.0.5

Java version to 17

Jetty version to 11.0.15

The UI Code

Like I said in the beginning, the UI is pretty simple, and the code to create that it's not too much:

public NPS() {
    Span title = new Span("On a scale of 1 to 10, how likely would you recommend this to your friend or colleague?");
    HorizontalLayout buttons = new HorizontalLayout();
    buttons.add(new Text("Not likely"));
    for (int i = 1; i <= 10; i++) {
        Button button = new Button(String.valueOf(i), e -> {
            int score = Integer.parseInt(e.getSource().getText());
            Notification.show("Changed to "+score);
        });  
        buttons.add(button);
    }
    buttons.add(new Text("Very likely"));
    this.add(title, buttons);    
}

So the title and list of buttons in a horizontal layout. This is already usable as-is in your Vaadin application if you like to try it and use "copy-paste reusability".

Thinking about component reusability

When making reusable components, you want to consider a few things. The simplest way to document your component is to create a self-explanatory API.

Component UX. Do you need keyboard navigation? Mouse hover? Shortcuts? I suggest staying safe, combining existing components, and making your custom solutions sparingly.
Component configuration or DX. You want to be able to change the text and behaviour in various ways. The combinations can get tricky, so you want to have various scenarios well-tested.
UI integration. Is your component to be used alone (i.e., single-component app)? Will it be in a pop-up, or will it be part of that other UI? Data integration. Are your component emitting events? Does it support data binding? How much data to cache on the server, and how much can the browser handle?
Compatibility. What framework version are you using? What version do you expect your user to be using? How about the Java version? Remember, dependencies work much like Venn diagrams, so keep the list short.
Testing. How to automate tests. As said, the configuration of states might get tricky, so you want to be good here to make sure to find the edge cases.
Documentation. This part should be straightforward if you did good job with the API. Focus on describing the developer use cases and skip the "this method does X" style docs altogether.

It might take a round or two to get everything right, but best to start with a "real app" where you use it and write code that uses your component. Not aiming for full-blown TDD, this is what I made for testing:

final NPS nps = new NPS();
nps.setId("nps");  // This is for automated tests

// Button to start the feed process
add(new Button("Ask NPS", e -> {
    add(nps);
}));

// Get the score and remove component
nps.addValueChangeListener(e-> {
    Notification.show("Value changed from "+e.getOldValue()+" to "+e.getValue());
    add(new Paragraph("NPS: " +e.getOldValue()+" -> "+e.getValue()));
    remove(nps);
});

// Edit the the score
add(new Button("Edit score", e -> {
    nps.setValue((int)Math.ceil(Math.random()*10));
    add(nps);
}));

This is implemented in AddonView.java, also used for automated tests. It is not the real thing, but simulating scenarios we had in the actual application.

The basic business logic

Since the NPS component is clearly a "field component" with a single editable value, we can reuse the framework functionality here. Extending CustomField gives us most of the functions we need for value input and events. We only need to implement the following:

protected Integer generateModelValue() {
    return this.score;
}

protected void setPresentationValue(Integer score) {
    this.score = score;        
}

Our test case already revealed a problem with the read-only support. We want the value to be visible, yet the input is disabled. The requires two more methods to be implemented.

First, highlighting the selection. We use the "success color" to do that.

private void updateButtonSate() {
    this.buttons
        .getChildren()
        .filter(c -> c instanceof Button)
        .forEach(c -> {
            Button b = (Button)c;
            if (score != null && score.equals(Integer.parseInt(b.getText()))) {
                b.addClassName(LumoUtility.Background.SUCCESS_50);
                b.addClassName(LumoUtility.TextColor.SUCCESS_CONTRAST);
            } else {
                b.removeClassName(LumoUtility.Background.SUCCESS_50);
                b.removeClassName(LumoUtility.TextColor.SUCCESS_CONTRAST);
            };
        });
}

Then another one to disable the buttons when we are in read-only state.

public void setReadOnly(boolean readOnly) {
    super.setReadOnly(readOnly);
    this.buttons
        .getChildren()
        .filter(c -> c instanceof Button)
        .forEach(c -> ((Button)c).setEnabled(!readOnly));
}

Now we have the events, we got the component value bookkeeping.

Release, release

"Release early, release often", correct? This is all you need to create a simple application that collects NPS feedback from your users. As you see, it is only the web UI part, and you still need to store data and calculate the final score.

You may have your custom database, and we still need to package the component for distribution, but I'll show some simple options in the next blog post. In the meantime: checkout the component at github.com/samie/nps.

This reusability actually sparks joy, but now it is your turn: On a scale of 1 to 10, how likely would you recommend this NPS survey to your friend or colleague? Leave a comment below.

Happy Path: Adding speech recognition to Vaadin apps.

Sami Ekblad — Tue, 18 Apr 2023 14:15:32 +0000

The previous blog post added wake word detection for a Vaadin application using Picovoice. That is a robust in-browser approach to creating always-listening apps. You might want to use that for full speech recognition, but also the draft standard web speech API also provides a way to voice-enable applications.

There are a few ways you can integrate web APIs. This time we look at how to use web speech API for speech recognition in Vaadin by integrating a ready-made add-on from Vaadin Directory.

Choose an add-on from Vaadin Directory

Head to vaadin.com/directory and search for "speech". Pick an add-on, such as "Voice Recognition", and click the install button on the top-right to see the different ways of installing: get the necessary dependencies, download, or in this case: create a new project.

Create a Vaadin project with the add-on

Click on "Create Project" and it starts downloading a Zip file with the full Maven project setup. Extract the zip and import it into your IDE. In IntelliJ, use New --> Project from Existing Sources....

Implement Speech Recognition in Vaadin UI

After opening the Vaadin project in your IDE, locate the main View class. I edited the "HelloWorldView.java" which has some sample code in it. Head back to the add-on page and copy and paste the sample code from the add-on's documentation into the constructor of the view class. Just replace the previous sample code.

Run the Application class in debug and start the development server. Because we are adding a new add-on, this might take a while, but be patient.

Click the start button in the UI and grant permission to use the microphone. Try to say something and see how well it performs. On the first try, the browser will ask your permission to access the mic. Remember, at the time being, the speech recognition API is only available in Chrome and Safari.

Customize and add your own commands

Now you can implement your custom application-specific functions. For example, modifying the code in the event listener to show a Vaadin standard Notification:

final String command = "show notification";
voiceRecognition.addResultListener(listener -> {
    String text = listener.getSpeech();
    if (text.contains(command)) {
        Notification.show(
            text.substring(text.indexOf(command)
                          +command.length()));
     }
});

Conclusion

That was a simple way to create a voice commands for Vaadin web application. While still limited by browser support, speech recognition opens up exciting possibilities for enhancing user experience in web applications. Share your thoughts and experiences in the comments below, and stay tuned for more.

Happy path: Building a Chatbot in Vaadin with OpenAI

Sami Ekblad — Tue, 11 Apr 2023 14:12:54 +0000

Want to build better version of ChatGPT? Here is how to use OpenAI's Chat completions API to add a robot participant to your Vaadin chat app.

Create a new chat app project

Using the service at start.vaadin.com, create a new Vaadin application. There actually is a complete chat example template, but the "hello world" sample is enough for this.

Create a simple chat UI

Using MessageList and MessageInput from Vaadin, create a simple chat UI:

public class ChatView extends VerticalLayout {
    private MessageList chat;
    private MessageInput input;

    public ChatView() {
        chat = new MessageList();
        input = new MessageInput();
        add(chat, input);
    input.addSubmitListener(this::onSubmit);
    }
}

And to make everything align nicely:

this.setHorizontalComponentAlignment(Alignment.CENTER, 
        chat, input);
this.setPadding(true); // Leave some white space
this.setHeightFull(); // We maximize to window
chat.setSizeFull(); // Chat takes most of the space
input.setWidthFull(); // Full width only
chat.setMaxWidth("800px"); // Limit the width
input.setMaxWidth("800px");

Create OpenAI Java API to call

The next step is the interesting one. There is a Java API for OpenAI, but can ChatGPT create a simple REST API to call itself from Java? It took a few steps to get right, but yes, it can. Here is what I asked so you get the idea...

Write a simple Java class called "OpenAI" to call completions to chat API with one "send" method that takes the latest user input as a parameter and returns updated chat messages. Provide inner classes "ChatRequest" and "ChatResponse" and use Jackson ObjectMapper for communication.

[ ... ]

That code uses the basic completion API, not the chat completion API endpoint at api.openai.com/v1/chat/completions. Can you adjust the code?

[ ... ]

Change the return value of send to be a List of instances of inner class "ChatMessage" instead of an array of strings.

[ ... ]

Change the ChatResponse class to match the following JSON:

[ ... ]

Write a sendAsync method that calls the OpenAI.send method asynchronously.

[ ... ]

And so on. Eventually, with some manual tweaking, here we are. Just the way I wanted it. Spring Component, very readable code.

Make the Vaadin app chat with you

To call the OpenAI's chat endpoint synchronously is simple, add a submit listener to the MessageInput:

input.addSubmitListener(this::onSubmit);

and implement the method:

private void onSubmit(MessageInput.SubmitEvent submitEvent) {
    List<OpenAI.Message> messages =
            openAI.send(submitEvent.getValue());     
    chat.setItems(messages.stream()
            .map(this::convertMessage)
            .collect(Collectors.toList()));
}

That combined with straight-forward conversion from Message to MessageListItem:

private MessageListItem convertMessage(OpenAI.Message msg) {
    return new MessageListItem(msg.getContent(),
                            msg.getTime(),
                            formatName(msg.getRole()));
}

Chatting asynchronously

To make the chat behave more real-time, few steps are needed
Enable websockets by adding @Push in Application class and to
use OpenAI.sendAsync instead to return a CompletableFuture

Note: to update the UI in the asynchronous callback, wrapping it into a UI.access call.

@Push
public class Application implements AppShellConfigurator {
    // ...
}

private void onSubmit(MessageInput.SubmitEvent submitEvent) {
openAI.sendAsync(submitEvent.getValue())
    .whenComplete((messages, t) -> {
        // Lock the Vaadin UI for updates
        getUI().get().access(() -> {
            chat.setItems(messages.stream()
                        .map(this::convertMessage)
                        .collect(Collectors.toList()));
        });
    });

Conclusion

That was nice. Vaadin components provide a nice familiar look and feel, and you can easily customize them to your own needs. The complete source code is again available on GitHub for your (and AI's) inspiration: github.com/samie/vaadin-openai-chat

Just update the openai.apikey in the application.properties and you are good to try it yourself.

Continuing from here, you can guess where this is heading if you already saw my voice activation tips for Vaadin.

Always-Listening Voice Commands for Vaadin web applications

Sami Ekblad — Tue, 28 Mar 2023 19:31:49 +0000

This small tutorial takes 15 minutes from the start to a working demo. We use Picovoice Porcupine Wake Word Engine to enable a Vaadin-based Java web application.

(If you don't have that much time: clone the repo, create a accesskey and run it.)

Wake Word Detection is also known as Keyword Spotting, Hotword Detection, Always-Listening Voice Commands, Trigger Word Detection, and Voice Activation.

Setup the Project

The first step is to create a new Vaadin Java application project:

1. Download a new project from start.vaadin.com with an empty view.

2. Create new Java API for always-on keyword detection and import Picovoice libraries:

package com.example.application;

import com.vaadin.flow.component.UI;
import com.vaadin.flow.component.dependency.JsModule;
import com.vaadin.flow.component.dependency.NpmPackage;

@NpmPackage(value = "@picovoice/porcupine-web", version = "2.1.16")
@NpmPackage(value = "@picovoice/web-voice-processor", version = "4.0.5")
@JsModule("./porcupine-integration.js")
public class Porcupine { 

    boolean started = false;

    public Porcupine(String picovoiceAccesskey) {
        UI.getCurrent().getPage().executeJs("window.vaadinPorcupine.key=$0;"
                    , picovoiceAccesskey);
    }

    public void start() {
        this.started = true;
        UI.getCurrent().getPage().executeJs("window.vaadinPorcupine.start()");
    }

    public void stop() {
        this.started = false;
        UI.getCurrent().getPage().executeJs("window.vaadinPorcupine.stop()");
    }

    public boolean isStarted() {
        return this.started;
    }
}

This is the server API available for the rest of the Vaadin Java application.

3. Create porcupine-integration.js in project’s frontend folder.

import { WebVoiceProcessor } from "@picovoice/web-voice-processor";
import { PorcupineWorker, BuiltInKeyword } from "@picovoice/porcupine-web";
import modelParams from "./porcupine_params.js";

// a global 'vaadinPorcupine' integration instance is enough
window.vaadinPorcupine = window.vaadinPorcupine || {
    key: null,
    async start() {
        console.log('Starting wake word detection');
        window.vaadinPorcupine._worker = window.vaadinPorcupine._worker ||         
        await PorcupineWorker.create(
            window.vaadinPorcupine.key,
            [BuiltInKeyword.Computer],
            window.vaadinPorcupine.keywordDetectionCallback,
            {base64: modelParams }
        );
        await WebVoiceProcessor.subscribe(window.vaadinPorcupine._worker);
    },
    async stop() {
        console.log('Stopping wake word detection');
        await WebVoiceProcessor.unsubscribe(window.vaadinPorcupine._worker);
    },
    keywordDetectionCallback(detection) {
        console.log(`Detected keyword: ${detection.label}`);
        const e = new CustomEvent("voice-wakeword", 
                    { "detail": detection.label });
        document.body.dispatchEvent(e);
    }
}

This is the client side part of the API integrating the in-browser wake word detection library.

4. Download the Porcupine model (i.e. Deep Neural Network). From the project frontend folder, run the following to turn the binary .pv model into a base64 string model.

echo "const model_params='$( cat porcupine_params.pv | base64 )';\nexport default model_params;\n\n" > porcupine_params.js

5. Get your Picovoice AccessKey

Go to Picovoice Console's dashboard. Copy your AccessKey.

6. Add a test button to the EmptyView.java to turn the wake word detection on and off:

final Porcupine porcupine = new Porcupine(System.getenv("PICOVOICE_ACCESSKEY"));
add(new Button("Start/Stop wake word detection", e -> { 
    if (!porcupine.isStarted()) {porcupine.start(); }
    else { porcupine.stop();}
}));

Run the application using your own accessKey:

PICOVOICE_ACCESSKEY=your_accesskey_here ./mvnw

Source Code and more examples?

The source code for a fully-working Vaadin demo with Porcupine is available in my GitHub repository. I’ve added a custom event and handler example there and later I’ll show how to train and add your own custom wake word using Picovoice Porcupine… What should I do next?

What's the deal with Vaadin add-ons?

Sami Ekblad — Mon, 30 Jan 2023 12:03:16 +0000

Vaadin is a framework for creating web applications in Java. It grew in the era when Java was the most popular programming language out there. But its benefits and popularity go more profound than the Java language. That is best visible in the way you extend Vaadin.

There are many UI widget libraries out there. Vaadin also offers a consistent set of widgets optimized for "desktop-like" applications. The difference is how those widgets or components are made and behave. Vaadin provides three kinds of add-on templates. They are not the only options you have, but they reflect the different use cases and benefits of the framework. Let's have a look at each of them.

Server-only add-on

This is the most "Vaadin-native" way of extending Vaadin. In this, the component is entirely composed of existing Vaadin components or other add-ons. It is good for making bigger logical UI composites like CRUDs and "micro-UIs" for e.g., editing certain types of data. Think of "person editor" instead of just a "form".

This is close to how you would typically build and divide the whole application UI in Vaadin. The component state resizes fully on the server side, and the framework for you renders the client side.

Pros:

Fully validated user input
No need to use HTML, CSS, JavaScript, or TypeScript.
Easy UI integration to any Java-library

Cons:

Requires all data sent to the server
Not optimal for creating pure UX improvements like animations

Template: addon-template

Client-server add-on

This unlocks the full potential of the web and Vaadin in your applications. You are building your reusable components and custom elements that implement a particular user experience combined with desired server-side logic.

With this component architecture, you can build your client-side logic that is combined with server-side logic. The perfect approach both for creating new innovative UI widgets that securely validate user input, or just a simple yet cool presentation-only widgets. You can let the framework take care of all the communication and lifecycle things and focus on the UX.

Pros:

Full control of DOM combined secure server-side data validation
Utilize all browser APIs to build remarkable UX and styling
Validate the input on the server side to keep data consistent

Cons:

Needs knowledge of DOM, custom elements, JavaScript or TypeScript, and CSS.

Template: client-server-addon-template

Extension from 3rd party NPM package

Since Vaadin components on the client side are custom elements, you can use any other custom element with Vaadin. The framework gives you standard ways of interacting with the component using DOM events, attributes, and methods already; typically, that is all you need.

This opens the vast world of client-side integrations. Further combined with a small client-side JavaScript or TypeScript adapter, you can fine-tune the logic to build a Vaadin component with a less server-side state.

Pros:

Create Java API for any existing custom element from npmjs.com
Minimal Vaadin-specific code to write and maintain

Cons:

Client-side-only logic is not secure and needs also server-side validation
Integrating 3rd party elements might create inconsistent UX

Template: npm-addon-template

The right tools for the use case

The goal is to build highly reusable components that utilize both the server and the client where they are the best. This follows the abstraction philosophy behind Vaadin:

The server is the place of secure business logic and validations
Client-side is for building awesome UX and cool visual effects
Build logical reusable components and widgets

You, whether a web or Java expert, know the best approach. With the Vaadin add-on, you can decide and build and deliver your web components in a highly maintainable way that is best for both worlds: Ever evolving APIs and critical Java backends.

What are your experiences with reusability and architecture on the UI layer?