One of the significant advancements in ZK 10 is Stateless Components. Instead of learning how to use the feature, today, we will talk to the key person behind the scenes and look at how he came up with the ideas and what challenges he had during this journey.
We are happy that we could interview the core developer behind this new feature – Jumper Chen, Director of Products and Technology at the ZK Team.
📢Tell us more about the Stateless Components. What was the starting point in the development of Stateless Components?
Because of this, reducing the ZK server-side memory footprint while allowing users to continue to manipulate ZK components by using Java API at the server has become our top priority.
📢Did you have this idea right from the beginning? Or did you also evaluate other ideas?
Jumper: Reducing the footprint on the server side means keeping less information on the server side; therefore, it naturally arrived in doing stateless components.
A stateless component, as suggested by the name, means it doesn’t hold a state on the server side. But how is that different? Take the HTTP protocol as an example. The HTTP protocol is also implemented in a “stateless” manner. Each HTTP request is independent at the time when the server receives it. It does not depend on another request, and there’s no order. This “independence” ensures that each request can be handled by any server or service in any order, without needing additional information. This is also essential for making “stateless” possible. We believe this can also be done in terms of web applications with proper design.
Initially, I focused on finding a feasible way to manage ZK components using Java API to achieve statelessness. I discovered that leveraging immutable instances could be a good way to retain the ZK component instances immutably at the server.
Once the server side was ready, we needed a tool to update ZK components at the client, and this is where we came up with the new UiAgent and Updater API.
Having the stateless ready also brings a positive side-effect: enabling modern use-cases and supporting current infrastructure needs such as micro-services and cloud-native support.
📢How long did you spend doing the POC?
Jumper: Doing POC didn’t take me a lot of time. However, over the past 10+ years, we’ve added many rich components to our library, so getting the complete Java API set ready is very time-consuming.
📢What are some of your difficulties in the development process?
📢What are the most common scenarios one would want to use the stateless components?
Jumper: Using stateless components will be most efficient when you have many boilerplate contents or static contents that don’t need to be updated often.
📢Why did you go with the Immutable Builder API pattern?
Jumper: We noticed that the Java new Time API uses the immutable builder API pattern, and we found it a good match with what we needed.
📢How to get started using the stateless components?
Jumper: You will be composing your UI using the stateless components (I-components) and associated APIs in Java. Then, you can use ActionHandler for event handling. For detailed steps, please refer to this small talk.
📢Can this be applied to an existing project? Or mix it with an existing project?
Jumper: Yes, it can be done as an independent page of a project, or an independent section of a page. We will be releasing articles to talk about how this can be done.
📢Do you recommend users use stateless components?
Jumper: Yes, definitely, if you wish to save server-side memory. By design, we assume most of the legacy ZK pages (except for MVVM) can utilize the stateless component API.
One important thing to note is that using stateless components doesn’t necessarily mean you are having a stateless application. Your application may still need to hold the states, such as user name and login status.
📢What are some of the concerns?
Jumper: Since it comes with a new set of Java API, it works differently from the current way. You may need to spend some time familiarizing yourself with the new API to control ZK components.
📢Considering the current client-side hype, do you also plan to provide a pure-client solution?
Jumper: We started from server-centric, and if you look at our community, I believe there is still a group of users that recognizes the value of server-side solutions where you don’t have to take care of the client side and any communication in between. We hope we can still preserve this value for our customers.
📢Thank you for giving us the insight! Before we end this interview, can you share your motivation with us? You have worked for over 15 years in Potix. What keeps you going?
Jumper: I believe working smart is much more important than working hard. I like to challenge myself and see if I can solve a problem in the most efficient way with limited time and resources. This drives me to learn proactively and brings me confidence and motivation.
We hope you find this interview interesting. If you have not checked out this new stateless feature, please try it out and give us your feedback! Learn more about the Feedback Event.