The current webapp designs use a layered model, like all things in computer science. Each layer has it's primary concerns, the database layer is concerned with persistance, the client layer with presentation, the middle layer with everything else. The problem with this design is that abstractions leak, and constraints of each layer are visible in other layers.
My belief is that the correct way to engineer a webapp is to acknowledge the constraints of each part. The disks can deal with about 100 seeks per second per spindle, give or take. The channel between the web browser and the web app is high latency. And the most important is that any webapp design that requires disk seeks on either queries or updates is inherently DOSable.
This leads me towards a asynchronously updating network design, wherein browsers notify the webapp of changes, the webapp responds with changes it has seen, and the webapp streams updated state to disk. Think of a spider with it's eight legs spread on different strands, listening to it's web. The trick is going to be generating consistent code across the various nodes, the html, the javascript, the concurrent server code, the reporting code.
I think you're right. The future is in functional programming. Everything separated into jobs/tasks. Asynchronicity is easily achievable, also, simplicity of multi-threading. They can't be totally self contained, but their interactions with the outside world can be marshalled and controlled. Even persistence becomes just another job to complete, all in good time. Extending that to web apps should be almost natural, as the interface is at it's most simplistic, is inherintly request/response.
ReplyDeleteHell, while I'm here, why can't my bread and butter, event oriented coding be marshalled down to jobs? :) Nothing happens without an event right?
@notagod So many thoughts, and it's going to take a weekend to get them pushed into some reasonable shape.
ReplyDelete