I agree with a lot of your points, except where it comes to JSON encoding. In many of my apps I use an ORM, NHibernate to be specific. I've found that this makes a lot of operations on the server side much simpler as there is less code for me to write and debug.
The problem comes though when I'm ready to encode to JSON to send to the client. Your correct that it is just one additional line to encode to JSON, but NHibernate creates objects that have relationships to other objects, and serializing those relationships can be very tricky. I have not found a great way to do this and often end up writing simplified versions of the server side classes and code to map from a server side class to a client side class.
Now you could argue that my framework or language sucks, but I think this goes to the point of the article. I feel the code I am writing on the server side is pretty solid and I am happy with my productivity. But as soon as I introduce any complex behavior on the client side, I end up with a lot of duplication and the entire code base gets much harder to manage.
I feel your pain, but it's not a new problem.. I spent years building server side apps with Hibernate, and before there was JSON, there was XML, or transfer-objects, or even hibernate entities that were disconnected from the backend (and would throw arbitrary exceptions when calling across un-fetched relationships). There's always a need to sort out how to represent these models across tiers.. In general, I favor only serializing relationships to things that are completely dependent (ie: dependent children who's lifecycles are married to the parent).. I try to never serialize relationships to independent entities.. let those get fetched by id if the client needs them.
Comments
I agree with a lot of your points, except where it comes to JSON encoding. In many of my apps I use an ORM, NHibernate to be specific. I've found that this makes a lot of operations on the server side much simpler as there is less code for me to write and debug.
The problem comes though when I'm ready to encode to JSON to send to the client. Your correct that it is just one additional line to encode to JSON, but NHibernate creates objects that have relationships to other objects, and serializing those relationships can be very tricky. I have not found a great way to do this and often end up writing simplified versions of the server side classes and code to map from a server side class to a client side class.
Now you could argue that my framework or language sucks, but I think this goes to the point of the article. I feel the code I am writing on the server side is pretty solid and I am happy with my productivity. But as soon as I introduce any complex behavior on the client side, I end up with a lot of duplication and the entire code base gets much harder to manage.
I feel your pain, but it's not a new problem.. I spent years building server side apps with Hibernate, and before there was JSON, there was XML, or transfer-objects, or even hibernate entities that were disconnected from the backend (and would throw arbitrary exceptions when calling across un-fetched relationships). There's always a need to sort out how to represent these models across tiers.. In general, I favor only serializing relationships to things that are completely dependent (ie: dependent children who's lifecycles are married to the parent).. I try to never serialize relationships to independent entities.. let those get fetched by id if the client needs them.
I'm sorry to hear that, in most places it's just one line. Let's hope the Hibernate people fix this.