Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
A Database in a Browser
So, what does it mean to integrate a database in a browser? Well, let’s first look at what it means to not use a database in the client browser (see Figure 1).
)
Figure 1 Traditional web "experience"
In Figure 1, a client machine hosts a browser that is served HTML pages. The browser renders the HTML pages, and any requirement for client data storage must use rather ugly and often dangerous mechanisms that involve the client machine’s hard disk.
Figure 2 illustrates the database-centric model I’ll be using. The only change from Figure 1 is the modest addition of a Derby database. But you’ll soon see what a difference this change makes!
)
Figure 2 A database-centric browser "experience"
In Figure 2, the browser can use data from Derby to populate fields in the rendered pages. If you think about the setup in Figure 2, there is potential for offloading a lot of server-side processing and then moving it onto the clients. At least initially, the latter is clearly a likely solution for intranets only. This might even be a good way of soaking up some of the masses of unused computing capacity on powerful desktop machines.
There are other benefits in that the amount of data traditionally transferred by the web server to clients could be reduced. Why is this so? Well, much web page data is static in nature (headers, footers, style rules, attributes, and so on), so a lot of this unchanging data could be located in local client-side databases.
Servers would then merely have to serve dynamic page data. Clients would then merge these two data streams into the end user web experience.
Let’s have a look at an example of using a Derby database in a browser-based application.