The algolia documentation explains two ways to index relations and suggests that option 2 is preferable. All the algolia examples I have seen (including the frontpage movie demo) use option 1.
My question is that, when using option 2 you would receive opbjects of different shapes when doing a query. Is the frontend simply supposed to handle this? Are there any best practices for handling this?
https://www.algolia.com/doc/guides/indexing/formatting-your-data#indexing-relations
Related
I'm designing a REST API where the /widgets endpoint can be filtered to only show widgets with a certain number of connections. This seems like a natural design:
/widgets?connections=4
I also want to allow filtering for widgets using lesser than and greater than, however. These URL designs seem wrong as they don't follow the classic query string pattern or appear misleading:
/widgets?connections>2
/widgets?connections=>2
What is the normal way of designing this kind of filter? I also need to be able to combine filters, e.g. "more than two connections and exactly one screen".
I've read this related question: REST URL design for greater than, less than operations, but it is not the same as it relates to pagination and ID, and does not contain a neat answer for combined filters.
REST does not give you an exact solution, it just says that your should use standards to build an uniform interface if there are available standards. If not, then it is up to you, anyways it must be documented for the client developers.
Here what you are doing is developing a complete query language for the URI. It would be good to check what exactly you need, because if there is a query language standard, then supporting it completely is just too much work. Afaik. Odata has something you need and there are other conventions, for example RQL is a very old one. With a little search there are other ones too: w x y z. I guess there are many others too. I would choose one of these and implement only what I need from it or look for an existing implementation.
When designing a REST API, following guidance such as 10 Best Practices for Better RESTful API, there seem to be all sorts of ways to provide a query syntax, pagination, selecting fields to return, etc.
For example, some ways to do pagination:
/orders?max=20&start=100
/orders?per_page=20&page=5
Some ways to provide a query interface:
/orders?q=value>20
/orders?q={'value': 'gt 20'}
Are there any standards for how to design an API that offers these features? If not, standards in development or best practice guidelines would be useful.
When researching this for the Watson Discovery and Assistant APIs, we weren't able to find any widely adopted conventions for filtering or paging, although there are many different conventions.
Some considerations for which convention you use:
Do you need compound clauses in your query? If you want to be able to express a > 10 || b < 10, then you need a string syntax or structured JSON structure to represent the more complicated queries, which will likely be a usability challenge for your users, and so is preferable to avoid if you don't really need the flexibility. In general, the simpler you can keep the requirements, the easier the API will be to learn and use, while potentially at the expense of flexibility. For example, if it turns out that the created date is the only field that users actually care about doing inequality filtering on, you could have explicit begin_date and end_date filter parameters instead of allowing inequality comparisons on all fields.
For pagination, do you have frequently changing data? If so, paging by offset may give you unstable results. For example, paging through logs that are actively being created, sorted by most recent, would cause you to see duplicate items. To avoid this, the server can return a token that represents the next page. This token can either be a lookup value or directly encode the information necessary to identify the values of the next item in the potentially changing list. Microsoft's API guidelines contain examples of both token and offset based paging, and are one of many sets of conventions to follow: https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md#98-pagination
Hi I'm new to mongoDB and Mongoid and am little bit confused on when to use embedded documents and how deep to embedd.
So a fictional example:
Library collection has_many :books, which embeds_many :pages, which embeds_many :sections
Since I cannot work with say a Section directly I have to go trough books.pages.sections, right?
This would result in this route, libraries/:id/books/:id/pages/:id/sections/:id
Which seems a little bit crazy, best practice would be to only nest one level deep, right?
One way would be to have the route pages/:id/sections/:id and then stick the bookid in the request?
Would it be harder to query on say, sections? For example if I need to find all the books where sections has tag x?
However if I don't embedd all the way I would have an extra query?
Can someone shed some light? Thanks.
First of I believe that no one can give you the right answer about how deeply you should embed documents. It is highly dependent on your concrete project requirements. In general you should answer some questions to choose appropriate schema design:
Will users concurrently update same object in collection? (or what would my boss say if clients lost their updates)
Do I need support atomic operations?
Do I need to independently show nested collections or are they queried with the parent?
Do I need to sort embedded objects?
Do I need to query on embedded objects?
If you will answer 1,2-true; 3 I need show them independently (different page); 4,5 - true then i am sure that embedding will be some kind of pain in your ass.
Extra queries should not be a problem I guess.
I'm starting off with a small Rails3:MongoDB:Mongoid project and came along some questions that's nature is more architectural.
When to use nested resources, and how deep to nest?
I'm not a friend of nested routes at all, but they become handy if not stacked deeper than 2 resources and document oriented databases like MongoDB seem to be a perfect target for nesting at all since documents itself are nested.
So my first question was: Should I use nested routes in case of a references_many <=> referenced_in association?
I tried, and since ActiveRecord's "build" is not existant, the whole controller stuff brake down to something that looked much nicer without nesting at all and doing all the stuff manually.
Am I wrong? Should I nest the routes of such associations too?
After that I came to my first embedded documents, and argued myself: Hey, this begs for nesting the routes. Some iterations later I ended up with 4 instead of 2 documents, every embedded in one of the others. So nesting the routes led to URL's I did'nt really like.
So the question to the already MongoDB-experienced user is: should I nest? And if yes, under what circumstanced and how deep?
Greets
J.
I had a similar set of questions. Ryan Bates created an excellent Railscast about Mongoid after you made this post. There is a section covering associations and when to use the embedded_* idiom versus the references_* idiom. It has examples of both. Hopefully you've had a chance to check out the Railscast. If not, here is the link to the associated ASCIIcast:
http://asciicasts.com/episodes/238-mongoid
Everything I've read about nesting resources with respect to Mongoid, or ActiveRecord states a best practice of nesting no more than one level deep.
http://weblog.jamisbuck.org/2007/2/5/nesting-resources
i have a decent understanding of configuring drupal and using modules for basic stuff, but just getting into module development and overriding functions and stuff due to my very basic understanding of php and mysql.
i have a custom content type ('books') and a 3 cck field for genres (primary, secondary, tertiary). i'd like a user to be able to filter a view of all books with one exposed multi-selectable 'genre' filter. that's where i'm stuck-- i understand how to have three exposed filters for the 3 genre 'weights' (primary, secondary, tertiary)--i want one filter that would allow users to select any or all of those weights.
is a custom search form my only option? was there a better way to set things up? would i have been better off using one cck field for 'genres' with multiple entries? i ruled this out because i thought it would be harder to determine the genre 'weight' (primary, secondary, tertiary).
thanks a million.
Think about what the meaning of genres to a book is. Taxonomy is just what you use for this kind of thing. There are several pros using the taxonomy rather than using CCK fields.
Taxonomy is meta data, CCK fields are not. This mean that the way the html is generated for taxonomy terms, it will help SE to understand that these genres are important and it will give you a free SEO
You can setup how genres should be selected in far more detail than a CCK field. Again since taxonomy is made for exactly this kind of thing. You can setup how users are presentated with the genre selection in various ways. You can predefine genres or let users enter their own as they like. You can make child-parent relation ships and more
It's easier and more lightweight to use taxonomy than CCK fields.
If there only is 1 or 2 genre inputted you wont have to have empty CCK fields.
probably more that I can't think of right now
Using taxonomy you can pretty easily make a search with views, where you make it possible for users to select genres using a multiple select list. You can decide if you require all terms or only one of them. Simply put you should really use taxonomy, it should solve all of your problems, if not, you should still use it and try to solve the problems you could get using taxonomy instead of CCK fields.
Jergason has a good point saying that taxonomy would probably be a good fit for your fields. However this wouldn't solve your problem of weighted genres.
A possible (though hacky) solution would be to have a fourth field which combined the values of the other three which is only set when a node is saved. This field could then be used for searching.
The non hacky solution is to write your own views filter but this is very advanced.
There may be a way to do this with views out of the box it is flexible, hopefully someone else knows of an easier non hacky solution.