recently i checked vaadin 10 and first of all i want to thank all people who are participating on this project. gr8t work.
I want to ask you why vaadin is still serializing UI to user session? Why vaadin needs this backend
stateful counterpart to communicate with? Why its not done like in Errai with some sort of calling stateless service? I agree thats is easy to provide working application in descent time, but the most crutial part is always
scaling a nd its not fun to bring a infinispan cluster or hazelcast cluster up in order to replicated user sessions. its 2018 can we store everthing in browser? I can not grasp the reason why its still something in the session. Please correct me if i am wrong.
The stateful backend makes it possible to simplify things for the application developer, thus increasing productivity. Some things that can be simplified specifically to Errai include:
Synchronous communciation between UI logic and the backend (since both run in the same server-side JVM process).
A simpler and faster development toolchain.
Ability to use any Java library also for the UI logic.
Not necessary to deal with code splitting as the number of views in the application increases.
Reduced exposure to security issues like CORS or direct object references.
Many “best pracitces” that are being presented online and at conferences are based on the tehcnical solutions from companies such as Google, Facebook or Netflix. They support massive numbers of users, but they can also afford having huge engineering teams. For them, a 1% reduction in server resource consumption might be worth millions of dollars on a yearly basis.
Many of the applications that are being built with Vaadin only need to support hundreds or maybe thousands of concurrent users. A server with enough memory for a case like that still costs much less than hiring even a single additional developer to deal with a more complex application setup.
At the same time, we also have some ideas on how to reduce the amount of server-side state needed per active user or even fully eliminate it, while still not sacrificing the unique benefits that the state currently provides us. We have still not fully investigated the potential of those ideas since we’re currently focusing on finalizing Vaadin 10 with the same statefull approach that has already served our current users well for many years.
You can eliminate the state by using Vaadin Elements together with any stateless client-side application framework (or no framework at all) that supports Web Components. Creating an application in that way does of course mean that you are giving up the benefits of having state on the server. In some cases, it’s worthwhile and in other cases it’s not. There is no silver bullet.
With Vaadin 10, we let you choose the most suitable alternative for each application.
The focus of Vaadin 10 is to introduce Web Components for use either through client-side frameworks or in combination with Vaadin Flow for the same niche that has been enjoying our previous statefull versions.
We also have some ideas about how to reduce or fully eliminate the need for per-user state on the server while still using server-side Java for the UI logic. This will be the topic of further research once everyone isn’t fully occupied with finalizing Vaadin 10. If they turn out to work well in practice, those ideas might be the topic of a future Vaadin version.
I just want to say that the situation today is not like it was 5 or 10 years ago. Nower days to be competetive we cant afford just to show the client something like “sorry your session is not valid please refresh browser” or maintainance page. Such things like Continues delivery and Zero downtime are become not just realy valueable they are a
must . This means you need to hire someone who will setup cluster and do additional afford to maintain the cache cluster, be more
discipline to be backword compatible with released version just not to mess up the serialized objects, and yes development of you application is fast, but only because of
state you got additional maintainance costs and more headache and sometimes unpredictable deployments, i am not talking about gb of traffic. And this makes me wounder why you are sticking to the state, instead to eleminate it.
Rly you tring to convince me that state on backend is for good? If i choose to use vaadin components then i dont need vaadin as a framework. For a green field development i can do it yes. But the problem is existing projects, they was started like 5 years ago and constantly growing, demanding new features among which are zdd and ability to deploy several time per day in order to reduce batches.
i just hoped that in vaadin 10 something changes regarding state, but no i checked the source what i see in vaadin session is a hashmap of ui. and you just saying “we done it for 10 years we will keep doing it” its pitty to hear this because i like vaadin but the way you choosen seems not to be good
And you are saying that i can use different java libraries well thats not quit true. If i do session replication then all classes must be serializable and surpise not all of them rly are. For example guava event bus nice example, was using it for decoupling components but cant use it anymore just because its not serializable. There are huge amount of problems waiting for you when you starting to scale vaadin applications
If i choose to use vaadin components then i dont need vaadin as a framework. For a green field development i can do it yes. But the problem is existing projects, they was started like 5 years ago and constantly growing, demanding new features among which are zdd and ability to deploy several time per day in order to reduce batches.