QLive: A new framework
DomainQL/Automaton has fulfilled its primary goal in running the emission control platform, but the ideas for a bright future for it with many projects have not come to fruition.
I will not be developing Automaton and DomainQL any further and I don't think that there will be any work on it at all beyond some maintenance.
The reasons for creating it and a lot of the details of it are still cool and promising, I think, and so I am working on a new framework that takes the ideas to the next level.
Reasons
The basic reasons for creating that kind of framework are the same:
- I still prefer Java on the server. I like the convenience of spinning up a quick server in node and there are certainly more serious projects in that space, but all in all, I want Java for performance and ease of integration into all kinds of enterprise environment. Whenever I even try to get away from Spring I end up missing its features.
- The concept of doing component work on the server is still interesting, but without Javascript, we need another concept. The idea of a declarative, symbolic way to express data needs still seems very attractive and GraphQL fits really well into that.
- Lastly, given the previous two, we can have the server know what the client is going to need and provide it in advance. What might seem more like a gimmick at first, maybe, has a lot of implications on both the operation of such a website and the development for it. Components and component tests really simplify. We can avoid all async behavior on load. This reduces the need for loading-state representation and error handling and saves a whole lot of async request latency. The initial data traveling together improves compression rates.
Good Ideas on a new level
Besides being built on newer web technology, the project is more streamlined and focused on its strength. The new design is cleaner, more correct in places and introduces new concepts to round out the central concepts.
At first I planning on just reusing key libraries for the new purpose, but in the end there were organizational difficulties that could not be resolved. Given me losing write access to the former projects, I opted to not only fork them but to do a clean break and incorporate the code into the new project and let all compatibility go. Now I can repair what I always wanted to repair, restructure things that weren't right the first time and really see where the ideas want to go.
Development Status
There's already a lot of functionality working but we're also still in an exploratory phase, trying out concepts that might not hold up in the end. The old framework was definitely production ready and the application running on it successfully passed an external security audit (of which the framework of course was only a small part). Seeing that we already started on a high level, but we're not quite there yet. If you're really adventurous and don't mind maybe redoing things, you can try it out now.