[fetbaffe]

No, I don't want to share models between the client and the server. I want an API dependency between them, a code dependency is actually worse.

Why should the frontend change when the backend changes it´s abstractions? I want to change them independently, because they have different constraints and dependencies.

If you are implementering your database schema in the frontend, you´re doing it wrong.

An API is a view against a domain, which in turn is an abstraction above the database. However the client is not aware of the entire domain and shouldn´t be.

Only thing that is a good idea to share is the domain language and the API interface, but can be solved easily by other means than share code base.

And as soon you throw in another client with an other programming platform, all the benefits is lost anyway.

[bsaul]

I completely agree with the general point, however at the minimum this lets client and server share the same exchanged models ( what the server sends to the client is defined once, as well as the opposite).

There may be technologies like protobuf to define those structures in one place, but i can still imagine there are cases where it could be useful ( business rules and validation, etc).

[wtetzner]

Yeah, the most obvious benefit is being able to share validation logic across front-end and back-end. All validation is necessary on the back-end for security reasons, but it's convenient for users if it also happens on the front-end, because they don't have to send data to the server before finding out it's invalid.

[wittedhaddock]

Are you suggesting something like http://espresso.caffei.net/ ?