I have been looking today at several solutions to transfer data between the Client and the Server.
I am building an application that allows me to do several things:
- Simple Page — Everything happens on one single page. No page loading.
- CRUD — Get, add, edit and remove records in a database
- Secure — Build in several layers of security, including strong restrictions on data-access and a proper implementation of Server side authorization models to functionality and data.
- Update my skills — I have been doing a lot of Adobe Flex in the past years. C# has been limited to Server side and Client side applications. It is time to update my skills with HTML 5.
Frameworks: first impressions
I have been looking at:
- Breeze — Allows you to access the database directly via a C# layer. In the C# demo, requests from Breeze.js are by default immediately passed through to the database layer and executed. My first impressions:
- CRUD – leaky by default — Create, Read, Update and Delete can all be done via generic actions on a generic class granting access to the entire database. Overrides to check the data are done in that class. You can limit this by overriding the Context class that takes care of the Breeze to C# conversion and only allowing certain type of objects to be processed.
- Client side Queries – leaky by default — Breeze allows you to create and execute Client side queries. Meaning that if and when you know the database, you can fire your own queries against the C# back-end and see what comes back. Cute for prototypes, but a big NO for web-based applications. It is unclear at first sight how you can block this.
- Data overhead — I checked the data sent from the Breeze client. And each object contains
- Class references — To the object in C# that represents the data
- References to the table — In which the data is stored
- Upshot — I did not look at Upshot yet as it seem to be on hold/no longer supported by the creator. Upshot was used in a 2012 Microsoft demo of Single Page Applications with MVC4.
- JayData — JayData seems to take a similar approach as Breeze: connect immediately to the database using an svc definition found on the Server and referred to from the client. Like Breeze, you can define and execute clietn-side database queries.
- CRUD – leaky by default — In the examples I do not see the need to code in C#. It seems that we are talking directly to the database. Again awesome for prototyping and useless when you want more. The examples online do not link to pages like: “if you want to do it properly, go here”.
- Client side Queries – leaky by default — JayData allows for client side queries to the database. Meh.
CRUD and access levels
Here is the model I like to see:
- Client — Request concrete action from Server using abstract calls
- Server: check client — Is this client / user allowed to this action? If so, to what degree?
- Server: perform action — If allowed, perform action
- Server: return result — Return the result.
Client side: JSON, events and Data Binding
Client side I like to:
- Bind data to events — Changes in the data will lead to events.
- Bind input-elements to data — Changes in an input-element, like a text-box, a check-box, a drop down list, will automatically:
- Data — Update the data object.
- View — Update the view. Highlights, new/changed content, removals, additions.
- Load and save the data — I want to have an easy way to load and save the data.
Knockout and jQuery
Knockout and jQuery can do most of this job.
- jQuery — Is a framework for AJAX type of sites. It simplifies calls to objects in your HTML and offers functions to GET and POST data from and to the Server.
Keeping the client simple: reducing responsibilities
While Breeze and JayData seem to offer a solution to access and modify data on the Server, I hate what they allow to be done Client-side.
- Only abstract calls — Client side should NEVER reveal where or how data is stored Server side, nor in which tables you can find them.
- Only/always via Business Layer — Client side calls should ALWAYS go through a business layer. To allow direct calls to the database without offering me a clear alternate and secure “this is how you SHOULD do it” in your examples is stupid.
What is nice to have:
- Filtering data client side — To be able to query and filter data client side is smart. It reduces calls to the Server when you allow the clienjt to do basic things with the existing dataset. Its use and usefulness is also limited. If my dataset is huge, I will query that set each time I need a different view.
- Sorting data client side — Adding new elements, but also changing the sort-order in lists should be simple.
My priorities are:
- To build an industry standard solution — No space for potential leaks. All data sources abstracted, separated and obscured.
- To build a responsive UI — When data within an object updates somewhere in the app, it updates everywhere. Page-reloads are to be avoided in all occasions.
- To reduce data-overhead — Only what is required is sent. No overhead should be there related to things the Server should know. We solve that by calling specific methods in the API. Breeze is too much.
- Knockout — To do client side data binding. It is not the only framework and has some performance issues when your Single Page HTML definition has many, many objects (it traverses the HTML DOM to resolve the inline tags), but for now it suffices
- JSON via jQuery — I decided to focus on JSON first. Get this right and the exact future implementation is just detail.
- Server side queries — For now I assume the datasets Client side never represent the datasets Server side. So changes in any filter will lead to new queries.