Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
The community reviewed whether to reopen this question 7 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I have a REST api served by NodeJS to an AngularJS fronts.
I work with users :
GET /api/users #Returns all users
POST /api/users #Create new user
GET /api/users/:id #Return a user
PUT /api/users/:id #Edit a user
DELTE /api/users/:id #Delete a user
This is a user :
{
login : "admin"
email : "admin#admin.com"
pass : "hashedpassword"
...
}
My user can belong to groups
GET /api/users/:id/groups #Return the groups of a user
They can also have constraints or can inherits constraints form their groups
GET /api/users/:id/constraints #Return the constraints of a user
GET /api/groups/:id/constraints #Return the constraints of a group
The problem :
I'm making an admin page, displaying All the users, their groups, their constraints.
Should I :
Make many requests in a for loop in the javascript (Angular) front ?
Something like :
$http.get(/api/users).then(function(result) {
result.data.forEach(function(user) {
$http.get('/api/users/'+user.data.id+'/groups).then(function(groups) {
groups.forEach(function(group) {
$http.get('/api/groups/'+group.data.id+'/constraints)
})
})
})
})
Create a path /api/users/withConstraintsAndGroups
That would return a big list of all the users with their groups and their constraints.
I find solution 1 to be very nice, maintenable, easy, and generic but I'm affraid of very bad performance
I find solution 2 to be ugly, hard to maintain, hard to code, not generic but with good performance
Which solution should I choose?
Your question basically boils down to:
Which is better, one big HTTP request, or many small ones?
One thing to keep in mind is the expected network latency (ping time) between your clients and your server. In a high-latency situation with otherwise good bandwidth, many small requests will perform significantly worse than one large one.
Also, having one big request gives you better efficiency for compressing the response, and avoids the overhead of the extra HTTP requests and response headers.
Having said all that, I would still advise you to start with option 1, solely because you stated it is very easy for you to code. And then see if it meets your requirements. If not, then try option 2.
And as a final note, I generally prefer one big request to many small requests because that makes it easy to define each request as a transaction which is either completely applied or rolled back. That way my clients do not run into a state where some of their many small requests succeeded while others failed and they now have an inconsistent local copy of the data my API supplied.
Come on, how much would it cost in performance, based on the thesis that the result will be almost the same, multiple requests vs one massive request. We're in 2016 and unless you're dealing with poor internet connections, you should do it by making multiple requests.
You're developing your app for 99% of the population of the globe or for the 1% part which uses Opera ( for the turbo feature )?
Also, if we are talking about designing a REST api, being consistent is probably the main idea of such kind of API. In your case, if you write the second method you'll have to write something similar into the rest of your code to keep consistency of all controllers, which can't be done.
Also, an API is an API and should not be modified when a front end application is being built on that API. Think at the situation when you have 10 apps that are requesting your API, but you're in the same situation you presented, but you need a different response for each. You're going to add new methods to the API ? That's a bad practice
Routing in a REST api should be done accordingly to the logical resources you have ( objects that can be manipulated with HTTP verbs ) :
Examples:
* when you have a relation between entities
/users/3/accounts // should return a list of accounts from user 3
/users/3/accounts/2 // should return account 2 from user 3
* custom actions on your logical resources
/users/3/approve
/accounts/2/disable
Also a good API should be able to offer partial requests ( for example adding some querystrings parameters to an usual request : users/3?fields=Name,FirstName ), versioning, documentation ( apiDocs.js is very userful in this case ), same request type ( json ), pagination, token auth and compression ( I've never done the last one :) )
I recommend modifying your endpoint for serving user resources to accept (through a query parameter) what associated resources should be included as a part of the respose:
/api/users?includes=groups&includes=constraints
This is a very flexible solution and if your requirement expands in future, you can easily support more associated resources.
If you concerned about how to structure the response, I recommend taking a look at JSON:API.
An advantage of using JSON:API is that if multiple users share same groups/constraints then you will not have to fetch multiple representations of the same entity.
You're asking
which is better...
and that's not acceptable according to SO rules, so I will assume your question lies around what is REST supposed to do in certain cases.
REST is based on resources, which, in their own, are like objects with their own data and "accessors/getters".
When you're asking for /api/users/:id/groups, you're telling that you want to access, from the users resource/table, a specific user with an id and, from that user, the list of groups he/she belongs to (or owns, or whatever interpretation you want). In any case, the query is very specific for this groups resource (which, in REST terms, is unique, because every resource is universally directionable through its URL) and should not "collision" or be misinterpreted with another resource. If more than one object could be targeted with the URL (for example, if you call just /api/groups), then your resource is an array.
Taking that in consideration, I would consider (and recommend) always returning the biggest selection that matches the use case that you specify. For example, if I would create that API, I would probably do:
/users list of all users
/users/:id a specific user
/users/:id/groups groups to which the specific user has joined
/users/groups list of all groups that has at least one user
/users/groups/:id description of a particular group from /users/groups (detail)
etc...
Every user case should be completely defined by the URL. If not, then your REST specification is probably (and I'm almost sure) wrong.
==========
So, answering your question, considering that description, I would say your answer is: it depends what you need to do.
If you want to show every single constraint in the main page (possible, but not too elegant/crap UI), then yes, the first approach is fine (hope your end users don't kill you).
If you want to only ask for resources on demand (for example, when popping up info on mouse hover or after going to a specific section in the admin site), then your solution is something like the second one (yes, that's a big one... only if you really need that resource, you should use it).
Have you considered the path /api/users/:id/constraints on demand?
BTW, withConstraintsAndGroups is not a REST resource. REST resources are nouns (constraints or groups, but not both). Not verbs or adjectives.
I doesnt seem to me that for the admin page performance is too much of an issue. The only difference between the pretty much is, that in #1 you have 3 api calls, with #2 only one. The data should be the same, the data should be reasonable, not extremely huge. So if #1 is easier to code and maintain you should go with that. You should not have any performance issues.
I am creating a list and each item contains 3 properties: Caption, link, and image name. The list will be a "Trending now" list, where a related picture about the article is shown, a caption to the article, and a link to that article. Would it be best to store this information in an array or a database? With an array I could update the list, by adding 3 new properties, and removing the last 3. With a database, I could make a form where I submit the 3 properties and it'll update on its own without me touching the code. Would it be better to make this system in a Javascript array, or database? Wouldn't it be better to make it into an array for faster speeds? The list will have 10 items, each item has 3 properties.
For a list of 10 items, you can definitively go with a simple Array. If you need to store a bigger amount of data, than try localStorage.
Whichever solution you use, keep in mind that it will always be processed and stored in the browser.
Razor - your question touches many principles of programming. Being a beginner myself, I remember having had exactly those questions not too long ago.
That is why I answer in that 'beginner's' spirit:
if this were to be a web application then your 'trending now list' might be written as a ul list with li items in a section in an index.html in html code with css.style to style the list and your page.
Then you might use javascript, jQuery, d3.js etc. or other languages such as php to access and do something with data from those html elements.
pseudo-code example to get a value from an element:
var collectedValue = $("#your_element_id).value;
To get values into an array you would loop over your item.values pseudo-code:
for (all item.value collectable){
my_array.push(item.values);
}
Next you would have to decide how to store and retrieve values and or arrays.
This can be done client side, more or less meaning: it stays with the browser you are working in. Or server side, meaning more or less your browser interacts with a server on an 'other' computer to save and retrieve data.
Speed is an issue when you have huge data sets, otherwise it is not really an issue; certainly not for a short list. In my thinking speed is a question for commercial applications.
In case you use a database, then you have to learn the database language and manage the database, access to it, and so on. It is not overly complex in mysql and php ( that is how I started ) but you would have to learn it.
In html/css/javascript solutions others have pointed out 'JSON', which is often used for purposes such as yours.
'localStorage' is very straight forward, but has its limitations. Both these are easily understandable.
To start, I myself worked through simple database examples about mysql/php
Then I improved my html/css experience. Then I started gaining experience with javascript.
Best would be if you would enable yourself to answer your questions yourself:
learn principles of html/css to present your trending now list
learn principles of javascript to manipulate your elements
Set up a server on your computer to learn how to interact with server side ( with MAMP or such packages)
learn principles of mysql/php
learn about storage options client or server side
It is fun, takes a while, and your preferences and programming solutions will depend on your abilities in the various languages.
I hope this answer is not perceived as being too simplistic or condescending; your question seemed to imply that such 'beginner's talk' might be helpful to you.
I'm developing a site in which the user can create his set of questions and asnwers. I'll have some datas, for example:
Question1: "What's your name?";
Right answer: "Emiliano";
Wrong answers: ["Luke", "Mathew"]
Question2: "What's your favourite color?";
Right answer: "Green";
Wrong answers: ["Blue", "Black"]รน
...and so on.
and I want to give to some users the chance to create their own test.
My solution has to be focus on the performance (in my last quiz-site I had 10k users online at the same time).
How can I do?
I've thought I can generate static html pages from my data (this is how we've done since now, but since now our quizzes were generate by us and not by users, so we generated like 2 quizzes per day and in these two times we were able to use some expensive-performance tool like php).
I've read I can use node.js to generate my pages server-side, but there's some way to generate them client-side? I don't want to use my server as long as I can.
I need to generate page like
www.mysite.com/user-name/1.html
www.mysite.com/user-name/2.html
www.mysite.com/user-name/3.html
www.mysite.com/user-name/result.html
In which 1.html contain Question1 data and so on.
Also, let me know if I can do this in another "simple" way.
Thank you and sorry If I've written some meaningless things (in case, let me know what mistake I've made), first week on Javascript (and coding).
Not fishing for code because I want to build/maintain this myself. I have a need to ask a question. Based on the question's answer, I want to ask more questions and eventually submit the responses in an email.
Are you male or female? (user clicks male)
Are both of your parents living? (user clicks yes)
with a large set of questions, but only certain ones get asked based on your choices. Ex: if you click male, you won't be asked if you have ever been pregnant. (and no I'm not taking people who have had sex changes into the equation).
Ideally, I'd like to build it out so that it's fairly easy to change the questions and their relation to the other questions. Would this be easier in javascript or with a database?
"It depends."
What does it depend on? Glad you asked.
You can do this purely in javascript by dynamically building the DOM up to match the user's choices as they navigate through the choices available per question so long as the page does not refresh or relocate.
If it does refresh or relocate, for modern browsers you can use localstorage which will temporarily hold some data. You could also store it in a temporary Session variable on your server.
However, you cannot (to my knowledge) send an email purely from client side javascript. There must be a server that you eventually post all of your choices to in order to fire off the email.
This is where the database comes in. If you wish to save these choices and emails, then you are going to need a database. If you do not care to save the choices, then a database will have no use.
Not sure if i am asking this correctly, but here it goes.
If you have a group with 150 people on, and not all contribute, they are unlikely to be aware of anything new without looking on the side bar for a number, if any, of new posts. Is there a way to push a notification if a poll is placed and prompt them to visit. Or is there a way to post on their time-line. I cannot seem to find the documentation on what permissions for a group provide once accepted into that group ?
Thanks
I'm not sure I completely understand the question but it sounds like you want to force a notification when posting something to a group via the API? that's not possible - users set their own notification options for groups