The advent of Multicore OCaml is indeed an exciting development for our community. It stands to usher in a new era of parallel and concurrent processing, on par with, or possibly surpassing, what Erlang/Elixir offers. In particular, OCaml’s use of Ahead of Time (AOT) compilation, combined with runtime advancements such as the annotation of variables for stack allocation and the utilization of more efficient memory representations, opens up intriguing avenues for performance optimization.
Given these promising enhancements, the prospect of utilizing OCaml for web programming grows ever more enticing. On top of having convenient compile time checks, OCaml could power a highly performant server runtime, capable of handling millions of concurrent requests per second. This naturally brings to mind the potential for a robust library that enables real-time server-side rendering, wherein seamless and effortless communication between the client and server is facilitated. The Elixir’s LiveView library serves as an illuminating example of this concept.
The traditional request-response model of client-server architecture, while proven and widely used, does indeed present challenges and limitations, particularly for complex web applications. Here are some of the issues:
Complex State Management: State management on the client-side can quickly become complex, especially for large-scale applications. Frontend frameworks often require additional libraries to handle state management, increasing the overall complexity and learning curve.
Performance: Every time a client makes a request, the server has to process it, and send back a response. This round-trip, especially for large amounts of data, can result in latency. Caching and other optimization techniques are often necessary but add to the complexity and can still fall short of providing a seamless user experience.
Resource Intensive: Traditional client-side applications can be resource-intensive on the client’s machine. This can negatively affect performance on lower-end devices and result in a poor user experience.
Sync Issues: Keeping the client and server state in sync can be challenging. Any mismatch between client and server states can lead to inconsistent application behavior and hard-to-debug issues.
Increased Network Traffic: Since the client frequently communicates with the server to update its view, this increases the network traffic, which can be particularly problematic for users with slow internet connections.
By contrast, real-time server-side rendering like the one Phoenix LiveView provides, while not a one-size-fits-all solution, offers several substantial advantages that can alleviate or even eliminate these issues:
Simplified State Management: Because state is managed server-side, you avoid many of the complexities associated with client-side state management. The state is held in one place, on the server, reducing the chance of state mismatch.
Efficiency: With server-side rendering, the server can do most of the heavy lifting, and the client is only responsible for displaying the HTML and minimal user interactions, making the application less resource-intensive for the client.
Reduced Network Payloads: Server-side rendering frameworks typically only send the changes (diffs) to the HTML over the network rather than re-rendering entire pages or components. This approach can significantly reduce the amount of data sent over the network, improving performance.
Real-Time Updates: Because the server keeps a persistent connection to the client, it can push updates to the client in real-time. This ability is especially valuable for applications that require real-time interactivity.
Consistency and Reliability: Since the majority of the codebase resides on the server, this approach allows for more control and consistency, reduces the likelihood of client-side errors, and enhances application reliability.
Given these advantages, and drawing from my own experience with Elixir LiveView, I believe that the adoption of a real-time, server-side rendering approach can have considerable benefits for many types of web applications.
More specifically, an OCaml framework akin to LiveView could employ the following strategies to facilitate scalable and efficient communication between the server and its clients:
- WebSockets: These offer bi-directional, full-duplex communication channels over a single TCP connection, facilitating real-time updates between the client and server.
- Channels: Channels could be used to manage client connections to topics, broadcast messages to all clients expressing interest, and deal with incoming messages.
- PubSub: Leveraging OCaml’s built-in publish-subscribe system would allow for broadcasting messages to a vast number of clients.
With these strategies in place, clients of this proposed library could continuously update their views in response to changes. Diffs, outlining updates for the client view, could be transmitted via WebSockets.
I recognize that there is an existing platform, Eliom, which approximates the vision I am proposing. However, it appears development has slowed and it’s not achieving significant traction. Moreover, as far as I understand, it does not capitalize on Multicore OCaml’s benefits. It might be worthwhile to explore the implementation of a server-side rendering library that takes full advantage of Multicore OCaml’s capabilities.
I would be interested in hearing if anyone else in the community is currently working on, or considering such a project.