I have multiple get functions returning a list. I want get all those get in one get. Is it good idea to do that? or implement get all individually and call them in get?
Related
I'm developing a node application which has an endpoint where it filters stories.
I accept multiples query params up to five. I don't know if this is too much query params but I need these params to filter in the data base.
Example:
http://localhost:3000/api/search?location=wherever&duration=123
I was wondering if there is any way better to do it like:
http://localhost:3000/api/search?filter=location:wherever,duration:123
or even I could send a stringify object from the url but it seems an ugly solution for me.
The second way I put here looks cleaner for me but I'm not sure how to handle the parameters.
In the first option I can pass req.query to my service and handle the object however in the other way handle the filter value would be harder.
What do you think? How do you manage this case to send a filter to your back?
Thanks in advance and my apologies if it was already answered, I didn't find a similar post.
What is the maximum query params url I should use?
There is no limit to the number of query parameters and it doesn't cause any problem to have lots of them.
I accept multiples query params up to five. I don't know if this is too much query params but I need these params to filter in the data base.
Five is low, not high - you're absolutely fine.
The practical limit to the total URL length is around 2000 characters so you just want to make sure your URLs stay comfortably below that and not worry about the count of separate query parameters.
I would only consider an alternative way to send the query if the total URL length was getting too long or could be too long. Aside from that, you can have as many query parameters as you want. It's not really something a human consumes directly, it's just something your code generates and parses so the quantity really doesn't matter.
That said, if you had 100 separate query parameters that would all be used at once, I'd wonder what you were doing and if there was a better way to accomplish it or express the query, but it wouldn't be a technical problem or limitation.
The structural alternatives are using POST instead of a GET and sending data as JSON or something like that. You can send as much data as you want that way, but a POST changes the usability of the URL since it's not something that can just be directly linked to or bookmarked or copied into a URL bar like a GET can.
I am using mongodb and what I am trying to do is query a collection, and receive well filtered and ordered and projected result. Sadly the logic I want to implement is complex and even if we assume that it is possible to use db.collection.aggregate it will result in long, complex, hard to read aggregate descriptor, which I believe in most cases is unwanted.
So I was thinking - Mongodb understands javascript, therefor most likely I can pass a javascript function during the query itself, expecting that my mongo server will make the query, run the provided function passing the query result to it, then return the final result to me. Something like:
db.collection.find(myQuery, serverCallback).toArray(function(err, db) { ... });
Sadly it seems this is impossible. Investigating further I reached stored javascript and understood that I can define that serverCallback on the server instead of passing it. Which is good, but seems messy and wrong to me. So basically this is the reason, why i decided to ask here if someone with better mongodb experience can argument this approach.
[My understandings]
I beleive that not every case of filtering, aggregating, etc. can be achieved with db.collection.aggregate, which is pretty normal. For all the cases that need special way of filtering the query result, we have two options - to define stored javascript that we execute on the query result on the mongo server, or to fetch the information from the server and do the processing/filtering/etc. in the client.
If we choose to define stored javascript, it is very likely that we will define some project specific logic into the mongo server. I think that the project specifics should always belong to the project code instead of the database. That way we can version them with git and easily access them if we want to change them.
If we choose to apply the aggregation logic after the query we loose the capability to choose who will make the calculations - the server or the client. Which may be an opinion that we want to have.
[My question]
What is the reasoning behind not allowing serverCallback to be provided during the query? I believe that there must be reasons that I do not understand here.
[Edits]
First I want to say that I have resolve my problem and as it was way too complex to explain it easily. I will prefer to stick to something easier to explain and understand. I believe this example of MongoDB stored javascript provides great example so lets use it. Basically what i tried to ask above was is there a way to pass this sum function during db.collection.find (and why there isn't any). Something like this:
function sum(queryResultAsArray) {
//Do whatever we want with queryResultAsArray
//For the example we filter result rows with x + y == 6;
return queryResultAsArray.filter(function(row) {
return row.x + row.y == 6
});
}
db.test.find({}, queryResultAsArray);
And this to be equal to the examples:
db.test.find({$where: "sum(this.x, this.y) == 6"});
For reasoning on why would one can prefer passing function rather than stored javascript see the original post.
I am wanting to share some logic between multiple functions which now seems to be partially achievable by using Function Filters within azure functions however in certain cases I don't want to continue execution of the function and be able to return a result back to the binding provider (same as returning a result from the function it's self).
Taking a look at the code the only way to short circuit the calling of the inner IFunctionInvoker within FunctionInvocationFilterInvoker is to throw an exception inside the custom invocation filter. The only problem with this approach is that the exception will bubble up to the host and cause a failure/retries etc.. somewhere else.
Also taking this approach doesn't allow me to set another return value back binding provider. I did see that we could wrap this in our own IFunctionInvoker but I was wondering if there was a better way to achieve this?
Code executing filters
Not possible yet, but this is something we'll definitely enable. We're tracking this capability in our repo here.
In couchDB, does reduce still get called if the map result is empty? if so, are both keys and value empty?
my use case (and hopefully there's a better way to do this):
I send a query to my cluster, and I require both the list of items and the count of items returned (which the map doesnt seem to provide… it only gives me the total count of the view, not the filtered viewresult). I then call reduce to get the count in a separate query.
Sometimes the ViewResult is empty, which makes reduce return null. I could look for this null, but I doubt this is the correct approach in couchdb world.
Edit: turns out the ORM I'm using does support a way to do it.
The reduce function isn't called when there are no rows.
The easiest way to achieve your goal is to just do the map, and back in your code retrieve the length of the rows array that is returned from CouchDB.
The reduce function being called on an empty map was actually a bug that I aided in fixing many months ago. I believe it was patched in 1.2. If you are up for using 1.1 then this bug may still exist and be useable.
In our domain-driven application, we use a type called ServiceResponse<> to send data between layers of our application - specifically, one is returned by every method in the domain. As of right now, it encapsulates the data (if any) which was returned from the method, or any errors that it may have generated.
My question, then, is this: is it an acceptable practice to add fields to this object that may be useful in other layers of the application? For example, is it good form to add a Status or StatusCode field to it that may be interpreted later by the service layer for use as an HTTP status code (with or without some mapping)?
It sounds like a fine place to me. The idea that every method returns a "response" of some sort smells a bit like trying to decouple too much, but there are some cases where such extreme decoupling is warranted.
In any case, the ServiceResponse could easily have a status, and if it needed one, that is where I would put it.