I have my server in nodejs and client in angularjs, mongodb(mongoose) as database. I want my client to be able to make a search query with all the normal consitions put in like fixing few fields to certain values, search string contained in few of the fields etc
query can be
(value of field A can be 'x' or 'y') and
(value of field B can range between dates P and Q) and
(string s contained in fields C or D or E) few more
is there any npm plugin or standardisation I can follow to enrich my server side API and also directly put the expression while querying with out doing a map reduce with multiple queries(with lots of code).
Yes, there are a few. I only know of those that work with Mongoose so if you're using another driver you may need to modify them a bit.
With each of these you'll need to determine which to filter locally and which to let the server handle it. Where you filter should depend largely on how much data you have. Personally, it made more sense to abandon local filtering for my largest sets and simply rely on MongoDB to handle the workload.
angoose
Connecting Mongoose and Angular and More
The original motive for Angoose project is to do away with the dual
model declarations(server and client side) if we are building a rich
model based SPA application using modern Javascript framework such as
Angular and node.js. With both front end and backend using Javascript,
Angoose allows the server side models and services to be used in the
client side as if they reside in the client side.
Angoose depends on following frameworks and assumes you have basic
familarities with them:
mongoose
express
angular (optional, for non-angular app, jQuery is required)
Mongoose Api Query
Mongoose plugin that takes a set of URL params and constructs a query for use in a search API. Also, worst project name ever.
If you use Mongoose to help serve results for API calls, you might be
used to handling calls like:
/monsters?color=purple&eats_humans=true
mongoose-api-query handles
some of that busywork for you. Pass in a vanilla object (e.g.
req.query) and query conditions will be cast to their appropriate
types according to your Mongoose schema. For example, if you have a
boolean defined in your schema, we'll convert the eats_humans=true to
a boolean for searching.
It also adds a ton of additional search operators, like less than,
greater than, not equal, near (for geosearch), in, and all. You can
find a full list below.
When searching strings, by default it does a partial, case-insensitive
match. (Which is not the default in MongoDB.)
Angular Bridge
Link models easily via a REST interface between Mongoose/Node-Express/Angular.js
Create, read, update, delete MongoDB collections via AngularJS.
It uses :
Mongoose for accessing to Mongodb
Express for the routing
AngularJS (with the $resource method)
Related
I am pretty new to NoSQL and would like to fully understand the concept of namespace and how it compares to SQL schema.
I have seen plenty of useful analogies between tables, row, ... and their NoSQL counterparts.
Could you please help me understand the namespaces ?
In particular, I would like to know how I could leverage them to segregate the data of my dozen of customers ? I want to prevent accidental information leak between two of then, while still using a single database.
It really depends of the database engine you are using, it is hard to give a generic answer.
Ideally, if you really want to segregate the data, you can use multiple databases (in Redis, Redis Enterprise, MongoDB). In this case you are sure that data are separated. But you say you want to use a single DB. (why?)
If you want to stick with a single database you have various options, once again depending of the database engine you are using.
If you are using Redis:
you can use specific namespace based on key pattern, for example app:cust-001:orders, and you control the access to the data based on the key name/pattern. In Redis 6.0, the notion of ACL (Access Control List) has been added allowing you to limit the operations/access to the data based on a key pattern, for the connected user. This will allow you to have a good control of the data and who can see/manipulate them
If you are using MongoDB:
you can use multiple collections (tables), for example, prefixing the collection name with a context.
or you can use a composite key, where one of the fields will be your context
In both cases, for Redis and MongoDB, you are kind of creating using business logic the concept of "database".
If you provide more details/examples, the community can probably give you a more detailed answer.
My service is built using Node + Loopback + Mongo.
I would like to drop the db at the startup if and only if at least one of the following two asserts is true:
any model schema has changed (note that I cannot use isActual() because that's usable only with relational DBs)
new data has been added/removed from the default data-set definition files (data folder)
I'm currently versioning the db using a custom logic comparing version table and a version unique var but I wonder if there is an easy way to check the two asserts above.
Any idea? Ty
I have to implement an architecture where, unfortunately, we are using SharePoint 2013 as, effectively, our principle database. (Not my choice, in case you hadn't picked that up). I have an Asp.Net MVC facade application on the server, handling composition of data from SP and a couple of other data sources, and then a JavaScript SPA as client. An additional wrinkle is that the client needs to be able to work offline, so I need to use IndexedDB to store the data for offline access.
This seems a perfect use-case for breeze.js. My basic architecture is to define a strongly typed model in the MVC facade that will wrap the untyped data I get from SP (in the form object["property"] - using the SP Client Side Object Model). Breeze will handle synchronization between this model and the client, and I will use the export/import functionality to cache data in IndexedDB as required.
So far so good. But... the SOA examples on the breeze site are still under development (and to me, this is fundamentally an SOA architecture, with each SP List a service to be composed). The closest thing I can find is the NoDB sample but this hard-codes metadata on the client. I'd like to establish relationships and validation in the MVC model, and then pass these through to the client, so validation can run off the same declaration in both places.
Is this possible? If so - how? If not does anyone have a workaround or a better idea? I'm already resigned to defining the model in two separate places (the facade and, implicitly, the structure of the SP lists). I would dearly like to avoid implementing it a third time in the client. I'm open to having breeze.js talk directly to the SP REST endpoints, but my understanding from https://stackoverflow.com/a/15364503/1014822 is that the implementation is flawed and does not expose the required metadata.
Resolution: Based on the accepted answer below, I came to the following solution:
1) Generate a service reference from the SP ListData.svc endpoint - thus creating an edmx and proxy classes.
2) Extend ContextProvider in my Repository and override BuildJsonMetadata like so:
protected override string BuildJsonMetadata()
{
XDocument xDoc = XDocument.Load(HttpContext.Current.Server.MapPath("PATH_TO_EDMX"));
String xString = xDoc.ToString();
xString = xString.Replace("DATA_SERVICE_NAMESPACE", "APP_NAMESPACE");
xDoc = XDocument.Parse(xString);
var jsonText = CsdlToJson(xDoc);
return jsonText;
}
3) Modify breeze.js very slightly, editing line 12383:
var schema = metadata.schema || metadata["edmx:Edmx"]["edmx:DataServices"].schema;
(I could presumably also have fixed this in the ContextProvider by choosing a descendant rather than the root node for my xDoc)
4) - Optionally use #Christoff's very useful T4TS.tt template script to generate a d.ts from the service proxy classes so I can have type safety on the data that breeze loads.
So far so good with this setup - I can perform basic CRUD with metadata, backed by SP as a data source.
As of v 1.2.7, We have documented Breeze's metadata schema, and json objects that adhere to this schema that are returned from your webservice will now be honored by Breeze.
--- previous post below
We are in the process of documenting how to expose arbitrary server side metadata over the next week or so, followed soon thereafter by some examples of how to consume an arbitrary web service. There are a few small code changes involved as well.
For the time being, until these docs are complete, the best workaround is to create your metadata on the client and use a jsonResultsAdapter to shape the results of your service call into "entities". The metadata you create on the client will be exactly the same as the metadata that you will eventually be creating on the server and sending down to the client.
Hope this helps.
is there any "ready to you" solution how to export mongoose models to client side app? If I imagine perfect world, mongoose models would let me define which properties and methods of entity is needed on client side and generates needed classes for client so I can easily use them with BreezeJS for example.
Any idea? Or is it road to hell combine it together? :))
Update - As of v 1.2.7 - we have provided two facilities that will help accomplish tasks like this.
The Breeze metadata format has been documented and any json object that adheres to this format and is returned from the breeze metadata call will be used to configure breeze's client side metadata.
The JsonResultsAdapter may be used to reshape or assist with interpreting the result of any web service call so that any results returned by the call can become Breeze entities.
--- Previous post
Please stay tuned, we will be releasing a new version of breeze in the next few days with support for pluggable json adapters that will allow the consumption of any web service. And since breeze metadata can already be defined for an arbitrary model, you should be able to consume your mongoose models pretty easily. Of course, the devil IS in the details.
My colleagues and I are building a web app with a relatively complex back end. Without giving away the product idea, we have several hundred form schemas paired with their return functions which are called when the form is submitted. The schemas are JSON objects which dynamically create a form on the client side. When the data in the form is submitted the linked functions may do a variety of different things with that data.
Currently these form schemas and linked functions are hosted in a private repo on GitHub. Is this the best way to go or could they be persisted in a database such as mongodb?
I understand mongodb will have no trouble storing the form schemas but what about the functions and the functions dependencies?
Store it into the database (as a string) and give it to the client when he requests it (will turn into a function). If you want to use that code on the backend (node), you'd eval it or make a function new Function(functionString) and do your validating on the server side as well.
/edit
Or put each schema in a file and request it server/client side when you need it. Making a DB round for something like this is expensive.