Isn't it dangerous to have query information in javascript using breezejs?

Question

Just starting to play with breeze.js because of the obvious gains in coding time, i.e. managing to access model data from the server direct within Javascript (I am a newbie here, so obviously bare with!).

In the past I have used the stock ajax calls to get/post data to the server, and I have used a few different client tools in the past to provide some help in querying local data, such as jLinq.

My question is this. Isn't it dangerous to have essentially full model query access in Javascript? I must be missing something because it looks like a really well thought through tool. In the past I have at least controlled what can be sent to the client via the backend query process, and again using something like jLinq etc I could filter the data etc. I can also understand the trade-off perhaps with gaining the direct query/none-duplicating local model problem, so just if anyone could provide some insight to this?

Thanks!

EDIT Obviously I am not the only one, however I am guessing there is a reasonable response - maybe limiting the data being requested using DTO methods or something? The other question posted is here

Neuroticism

Dangerous in what way? Does your model contain sensitive data that shouldn’t be exposed to the client? – Neve

Answer 1

It can be dangerous to expose the full business model. It can be dangerous to allow unrestrained querying of even that part of the model that you want to expose to the client. This is true whether you offer an easy-to-query API or one that is difficult to query.

That's why our teams are careful about how we construct our services.

You should only expose types that your client app needs. If you want to limit access to authorized instances of a type, you can write carefully prescribed non-queryable service methods. Breeze can call them just fine. You don't have to use the Breeze query facilities for every request. You'll still benefit from the caching, related-entity-navigation, change-tracking, validation, save-bundling, cache-querying, offline support.

Repeat: your service methods don't have to return IQueryable. Even when they do return IQueryable, you can easily write the service method to constrain the query results to just those entities the user is authorized to see.

Fortunately, you can blend the two approaches in the same service or in collaborating services.

Breeze gives you choices. It's up to you to exercise those choices wisely. Go out there and design your services to fit your requirements.

Gaddis

The more I explore breeze and obviously apply those comments above (which lets face are common sense of course - easy to "see" technical solutions as some sort of a cyclops view of the world!) the more I get a fuzzy warm feeling that finally the browser and server world are finally being brought together :) – Neuroticism

Answer 2

Breeze isn't meant to be your business logic in that sense. Keeping in mind the rule of thumb that if you do something in Javascript, anyone can do it, you ought to be restricting the visibility of your own service data as needed.

In other words, it's useful for you if you meant to make the data publicly visible anyway. But only expose the entities that you're happy exposing and allowing anyone to query; another way to look at it is that your API becomes a public API for your website (but not one you advertise and tell everyone to use).

I am personally not a fan of doing things this way as there is a dependency created on the schema of the backend implementation. If I want to make changes to my database tables, I now have to take my Javascript into consideration. I also lack in terms of integration and unit testing.

However, it can have its uses if you want to quickly build a website feature on non-sensitive data without having to build the service methods and various layers of implementation of it.

Adebayo

Hey good response, thank you. I guess I was thinking along the same path re: exposing only the data you really want to i.e. if your model had a bunch of properties including items that shouldn't be visible externally, then using a DTO to transfer only those elements you wish visible. I guess I just wanted to get some confirmation around that in case I had missed something, so thanks again for the response. – Neuroticism

You can certainly only expose what you want through DTO's in your Web API, then Breeze can only get to those. I think the topic of you DB changes really doesnt hold water though practically. If you add a field to a table, you have to update some code in your business models. You could choose not to update you DTO's and then the changes would not affect the JavaScript at all. So there are ways around that with separation patterns. – Scotty

I think it does hold water; DB changes aren't limited to just adding a column to a table. You can remove a column, move tables, split tables, change DB providers. If I have an API, I would like to keep the separation so that any schema change doesn't affect the client. It's only when my interface contract requires a change that I am happy to version the API and inform the client. This is the separation that a client-side query model makes difficult. – Adebayo

First, you need only worry about tables backing types you expose in the client model, not every table in the Db. The db provider is irrelevant, ORM or not. You expose a service, not the Db. Your ORM is supposed to provide additional abstraction for the Db changes you mention. In my experience it is rare to thoroughly tear up my model entities without expecting comparable changes in the UI. Business reasons are the typical driver of model change and these flow to UI. Meanwhile, the extra effort of "separation" adds complexity and cost that may never pay off. YAGNI? – Gaddis

Thanks to all here.. really good comments, very valuable. Look, I guess I am also learning lots of new stuff i.e. webapi and so on.. and in fairness I haven't had to think much about DTO's and the like.. having gone through a few examples from Scott Hanselman, and pluralsight cause like John Papa (thanks for the comment!), I am slowly getting a grasp of the why/how and not's! so the DTO approach certainly makes sense (in my case at least) which means I can expose only what I need to. Finally we are moving out of the browser dark/middle ages, at least to the Renaissance at least? – Neuroticism

course! not cause! although it's kinda funny as pluralsight has been a great cause! :) sorry, couldn't resist (although doesn't follow the YAGNI principle does it?) – Neuroticism

Answer 3

What about when you expose the Metadata? Isn't that considered dangerous. IMHO is not safe to expose metadata from the DbContext. I know you can construct metadata on the client, but the point is to do things as quickly as possible(if safe).

Absquatulate

What makes the metadata dangerous? Where does type information rank among all your security risks? Well it's best to minimize low risks too if you can do so at reasonable cost without compromising functionality. Fortunately, it's pretty easy w/r/t type info. You don't have to expose your entire business model,only types allowed on the client. Limiting to those types can be as simple as limiting the surface of the DbContext to support your client application model. And if the objects exist on the client, what does the metadata tell you that the object on the client does not? – Gaddis