We Keep Coding

How to join two API in Angular 2

I want to simulate a micro blogging application to learn Angular 2.
I am using the following json placeholder links:
users
post
As you can see, the post api has userId, (and not username). If I have to display the user name while listing all post, would I require another API with both post and user name, or can it be done using two different calls to the above APIs?
This is the way I will be listing the post :-
<li *ngFor="let post of posts">
<div>{{post.userId}}</div>
<div>{{post.id}}</div>
<div>{{post.title}}</div>
<div>{{post.body}}</div>
</li>
As you can see, here based on the api call, I am getting userId...Instead of that I want it to display user's name

The way to do this in angular is using services. You don't directly call to an API from within your component. You need to create a "service" to deal with APIs, then inject your service in your component and consume them in there.
In your particular scenario, you will have two services, a "UserService" and a "PostService". Each of those services have a proper "get" method that calls to an API. Then in your component, you inject both those services and call their respective methods separately.
Regarding your specific update on the question, imagine you have a "posts" array and a "users" array after you have received your result from the API. Now, pay attention to the following logic:
for (let i=0; i<posts.length; i++)
{
posts[i].username = users.filter(u => u.id === posts[i].userId)[0].username
}
What we did here is iterating through all "posts" and adding a "username" attribute to each of them by cross referencing them to the users array. Just make sure you use the right syntax and case sensitivity as I have not tested this line and just included the logic in it

Both the options are viable..
You can create another API that responds with the required data. The new API can cal the controller functions of the previous API endpoints and return the data in the required format.
note: this is possible if you are working with your own server.
you can also chain the API calls if you want to work with the existing APIs.. Call the user api and then when you get the user details, in the subscribe handler, make another request to the posts API.
note the only problem i can see with this approach is the number of requests.. as there will be a posts request for each user.
In the End the decision is yours. you'll have to see the pros and cons.. If the server code is also yours, ill suggest the first approach..

How can I keep both users tables "synchronized" using BackAnd?

I'm good with registering users, login, etc.
Now I'm getting into modifying users with:
this.backand.object.update('users', user.userId, user)
but I can see that only my table gets modified, while I'll also need to modify the "Registered Users" table existing in "Security & Auth > Registered Users".
I understand I might need to create a custom action...maybe "Before Update"? ...but I can't find documentation on how to modify that specific table (via API or via BackAnd actions).
Thank you.

thanks for using Backand! We don't offer any methods via the SDK to update the registered users. You can use the HTTP object to send a call to the back-end's REST API directly, hitting the same URL that the SDK requests when creating a new user, but this isn't officially documented. In general, we try to limit direct modifications of the registered users table, as there are some security concerns regarding how frequently the data is accessed and modified, but you can access the users object directly via the /users URL. There is an article in our documentation at http://docs.backand.com/en/latest/apidocs/security/index.html#link-your-app-39-s-users-with-backand-39-s-registered-users that covers an automated process for making these kinds of changes - you should be able to adapt some of the server side code in that example to work with your use case.
One alternative that would work now would be to have any change in basic information (username, password, firstname, lastname) result in a new user being created, and you could then use a custom action to perform the migration to the new user, but that is unnecessarily complex. I will add a ticket for our developers to look at adding this registered user management functionality in the future.

RESTful API - handling updates that depend on other updates

I'm trying to design a RESTful API to serve data to a front-end JS app, and in future a native mobile app once I get round to writing it.
I'm fairly new to front-end dev, so API designs are also fairly new to me. I'm writing a table tennis league app to start my learning, and one of the endpoints doesn't seem to quite fit with any example I've read of recommended API structures.
I have two entities, leagues and players. A league has a collection of players, and when a result is entered the players switch "position" in the league if the winner was below the loser before the match was entered.
A standard REST API might have endpoints as follows to update the details of a specific player within the league:
(POST/PATCH) - /api/v1/leagues/{league-id}/players/{player-id}
e.g. /api/v1/leagues/1/players/12
This is fine, but in my case, when a result is entered into the web app, 2 different players need their "position" value updating via the API. Ideally, I would have this set as a unique field in the database, so only 1 player can be at each position within the league at any given time. However, if that were the case, using an API endpoint as above, my front-end app would need to calculate the new positions of the players based on the entered result, update player 1, and then if successful update player 2 (rolling back on failure). Following this structure, the position field cannot be made unique, as following the update of player 1, they both have the same position value until player 2 is updated.
The only other solution that I can think of is to have some other appropriately named endpoint that takes a "result" object, does the logic of working out the players new position on the server side, updates accordingly, and returns some data for the UI to re-bind and update to.
So my question is this: which of the 2 methods outlined above would you choose, and why?
If you choose the latter, what data would you return from the API call for the UI to bind to? A full league of player data? Or just the two players that have been updated?
Thanks

I think I see two problems
you haven't defined enough resources
you are confusing http with your domain model
Try something like this
PUT /api/v1/matches/{match-id}
{ winner : { id }, loser : { id }, ... }
Put to the API a message describing the outcome of the game (POST is acceptable, PUT is better for idempotency).
As a side effect of this message's arrival, incorporate the results into your domain model. It's your domain model that should include the rules that describe how the rankings of players change when a game is finished.
When somebody wants to see the rankings of the players...
GET /api/v1/leagues/{league-id}/standings
you send them to a resource that returns a representation of the current rankings in your model.
The spelling of the uri doesn't particularly matter; I prefer "standings" because I believe that's a real thing in your domain. But if you wanted to reflect the data structure of your resources without additional context, you might use a spelling like
GET /api/v1/leagues/{league-id}/players?orderBy=position
The data representation in the body of the request sent to you by the client isn't a serialization of an entity in your domain model, it's a serialization of a message addressed to your domain model.

The choice of where to calculate the positions within the league is really subjective - I would suggest doing it at the server, since it involves searching the database again (other players' scores).
Since you have multiple players and you may update 2 players at a time, it would be better to send the players' scores in the request body with their positions, and return the calculated full league information in the response for each request, because that would simplify your client code and ensure that you get the latest data.
This suggestion is based on the assumption that you do not have large number of players in a league (may be > 100). In that case, I would suggest approach 1 is better.
So your API URL can be..
(POST) /api/v1/leagues/{league-id}
And your request body, can be
"players":[
{"player-id":"101", "newScore":"10"},
{"player-id":"103","newScore":"20"}
]
Your response can be the full list of players in the resulting league.
"players":[
{"player-id":"101", "position":"1"},
{"player-id":"102", "position":"2"},
{"player-id":"103","position":"3"}
{"player-id":"104","position":"4"}
{"player-id":"105","position":"5"}
]

Adding couchdb persistence to a socketio json feed in node

I'm currently researching how to add persistence to a realtime twitter json feed in node.
I've got my stream setup, it's broadcasting to the client, but how do i go about storing this data in a json database such as couchdb, so i can access the stores json when the client first visits the page?
I can't seem to get my head around couchdb.
var array = {
"tweet_id": tweet.id,
"screen_name": tweet.user.screen_name,
"text" : tweet.text,
"profile_image_url" : tweet.user.profile_image_url
};
db.saveDoc('tweet', strencode(array), function(er, ok) {
if (er) throw new Error(JSON.stringify(er));
util.puts('Saved my first doc to the couch!');
});
db.allDocs(function(er, doc) {
if (er) throw new Error(JSON.stringify(er));
//client.send(JSON.stringify(doc));
console.log(JSON.stringify(doc));
util.puts('Fetched my new doc from couch:');
});
These are the two snippets i'm using to try and save / retrieve tweet data. The array is one individual tweet, and needs to be saved to couch each time a new tweet is received.
I don't understand the id part of saveDoc - when i make it unique, db.allDocs only lists ID's and not the content of each doc in the database - and when it's not unique, it fails after the first db entry.
Can someone kindly explain the correct way to save and retrieve this type of json data to couchdb?
I basically want to to load the entire database when the client first views the page. (The database will have less than 100 entries)
Cheers.

You need to insert the documents in the database. You can do this by inserting the JSON that comes from the twitter API or you can insert one status at a time (for loop)
You should create a view that exposes that information. If you saved the JSON directly from Twitter you are going to need to emit several times in your map function
There operations (ingestion and querying) are not the same thing, so you should really do them at the different times in your program.
You should consider running a bg process (maybe in something as simple as a setInterval) that updates your database. Or you can use something like clarinet (http://github.com/dscape/clarinet) to parse the Twitter streaming API directly.
I'm the author of nano, and here is one of the tests that does most of what you need:
https://github.com/dscape/nano/blob/master/tests/view/query.js
For the actual query semantics and for you learn a bit more of how CouchDB works I would suggest you read:
http://guide.couchdb.org/editions/1/en/index.html
I you find it useful I would suggest you buy the book :)

If you want to use a module to interact with CouchDB I would suggest cradle or nano.
You can also use the default http module you find in Node.js to make requests to CouchDB. The down-side is that the default http module tends to be a little verbose. There are alternatives that give you an better API to deal with http requests. The request is really popular.
To get data you need to make a GET request to a view you can find more information here. If you want to create a document you have to use PUT request to your database.

Ways to save Backbone.js model data?

I am more into front end development and have recently started exploring Backbone.js into my app. I want to persist the model data to the server.
Could you please explain me the various way to save the Model data (using json format). I am using Java on server side. Also I have mainly seen REST being used to save data. As i am more into front end dev, i am not aware of REST and other similar stuff.
It would be great if someone could please explain me the process with some simple example.

Basically Models have a property called attributes which are the various values a certain model may have. Backbone uses JSON objects as a simple way to populate these values using various methods that take JSON objects. Example:
Donuts = Backbone.Model.extend({
defaults: {
flavor: 'Boston Cream', // Some string
price: '0.50' // Dollars
}
});
To populate the model there are a few ways to do so. For example, you can set up your model instance by passing in a JSON OR use method called set() which takes a JSON object of attributes.
myDonut = new Donut({'flavor':'lemon', 'price':'0.75'});
mySecondHelping = new Donut();
mySecondHelping.set({'flavor':'plain', 'price':'0.25'});
console.log(myDonut.toJSON());
// {'flavor':'lemon', 'price':'0.75'}
console.log(mySecondHelping.toJSON());
// {'flavor':'plain', 'price':'0.25'}
So this brings us up to saving models and persisting them either to a server. There is a whole slew of details regarding "What is REST/RESTful?" And it is kind of difficult to explain all this in a short blurb here. Specifically with regard to REST and Backbone saving, the thing to wrap your head around is the semantics of HTTP requests and what you are doing with your data.
You're probably used to two kinds of HTTP requests. GET and POST. In a RESTful environment, these verbs have special meaning for specific uses that Backbone assumes. When you want to get a certain resource from the server, (e.g. donut model I saved last time, a blog entry, an computer specification) and that resource exists, you do a GET request. Conversely, when you want to create a new resource you use POST.
Before I got into Backbone, I've never even touched the following two HTTP request methods. PUT and DELETE. These two verbs also have specific meaning to Backbone. When you want to update a resource, (e.g. Change the flavor of lemon donut to limon donut, etc.) you use a PUT request. When you want to delete that model from the server all together, you use a DELETE request.
These basics are very important because with your RESTful app, you probably will have a URI designation that will do the appropriate task based on the kind of request verb you use. For example:
// The URI pattern
http://localhost:8888/donut/:id
// My URI call
http://localhost:8888/donut/17
If I make a GET to that URI, it would get donut model with an ID of 17. The :id depends on how you are saving it server side. This could just be the ID of your donut resource in your database table.
If I make a PUT to that URI with new data, I'd be updating it, saving over it. And if I DELETE to that URI, then it would purge it from my system.
With POST, since you haven't created a resource yet it won't have an established resource ID. Maybe the URI target I want to create resources is simply this:
http://localhost:8888/donut
No ID fragment in the URI. All of these URI designs are up to you and how you think about your resources. But with regard to RESTful design, my understanding is that you want to keep the verbs of your actions to your HTTP request and the resources as nouns which make URIs easy to read and human friendly.
Are you still with me? :-)
So let's get back to thinking about Backbone. Backbone is wonderful because it does a lot of work for you. To save our donut and secondHelping, we simply do this:
myDonut.save();
mySecondHelping.save();
Backbone is smart. If you just created a donut resource, it won't have an ID from the server. It has something called a cID which is what Backbone uses internally but since it doesn't have an official ID it knows that it should create a new resource and it sends a POST request. If you got your model from the server, it will probably have an ID if all was right. In this case, when you save() Backbone assumes you want to update the server and it will send a PUT. To get a specific resource, you'd use the Backbone method .fetch() and it sends a GET request. When you call .destroy() on a model it will send the DELETE.
In the previous examples, I never explicitly told Backbone where the URI is. Let's do that in the next example.
thirdHelping = Backbone.Model.extend({
url: 'donut'
});
thirdHelping.set({id:15}); // Set the id attribute of model to 15
thirdHelping.fetch(); // Backbone assumes this model exists on server as ID 15
Backbone will GET the thirdHelping at http://localhost:8888/donut/15 It will simply add /donut stem to your site root.
If you're STILL with me, good. I think. Unless you're confused. But we'll trudge on anyway. The second part of this is the SERVER side. We've talked about different verbs of HTTP and the semantic meanings behind those verbs. Meanings that you, Backbone, AND your server must share.
Your server needs to understand the difference between a GET, POST, PUT, and DELETE request. As you saw in the examples above, GET, PUT, and DELETE could all point to the same URI http://localhost:8888/donut/07 Unless your server can differentiate between these HTTP requests, it will be very confused as to what to do with that resource.
This is when you start thinking about your RESTful server end code. Some people like Ruby, some people like .net, I like PHP. Particularly I like SLIM PHP micro-framework. SLIM PHP is a micro-framework that has a very elegant and simple tool set for dealing with RESTful activities. You can define routes (URIs) like in the examples above and depending on whether the call is GET, POST, PUT, or DELETE it will execute the right code. There are other solutions similar to SLIM like Recess, Tonic. I believe bigger frameworks like Cake and CodeIgniter also do similar things although I like minimal. Did I say I like Slim? ;-)
This is what excerpt code on the server might look (i.e. specifically regarding the routes.)
$app->get('/donut/:id', function($id) use ($app) {
// get donut model with id of $id from database.
$donut = ...
// Looks something like this maybe:
// $donut = array('id'=>7, 'flavor'=>'chocolate', 'price'=>'1.00')
$response = $app->response();
$response['Content-Type'] = 'application/json';
$response->body(json_encode($donut));
});
Here it's important to note that Backbone expects a JSON object. Always have your server designate the content-type as 'application/json' and encode it in json format if you can. Then when Backbone receives the JSON object it knows how to populate the model that requested it.
With SLIM PHP, the routes operate pretty similarly to the above.
$app->post('/donut', function() use ($app) {
// Code to create new donut
// Returns a full donut resource with ID
});
$app->put('/donut/:id', function($id) use ($app) {
// Code to update donut with id, $id
$response = $app->response();
$response->status(200); // OK!
// But you can send back other status like 400 which can trigger an error callback.
});
$app->delete('/donut/:id', function($id) use ($app) {
// Code to delete donut with id, $id
// Bye bye resource
});
So you've almost made the full round trip! Go get a soda. I like Diet Mountain Dew. Get one for me too.
Once your server processes a request, does something with the database and resource, prepares a response (whether it be a simple http status number or full JSON resource), then the data comes back to Backbone for final processing.
With your save(), fetch(), etc. methods - you can add optional callbacks on success and error. Here is an example of how I set up this particular cake:
Cake = Backbone.Model.extend({
defaults: {
type: 'plain',
nuts: false
},
url: 'cake'
});
myCake = new Cake();
myCake.toJSON() // Shows us that it is a plain cake without nuts
myCake.save({type:'coconut', nuts:true}, {
wait:true,
success:function(model, response) {
console.log('Successfully saved!');
},
error: function(model, error) {
console.log(model.toJSON());
console.log('error.responseText');
}
});
// ASSUME my server is set up to respond with a status(403)
// ASSUME my server responds with string payload saying 'we don't like nuts'
There are a couple different things about this example that. You'll see that for my cake, instead of set() ing the attributes before save, I simply passed in the new attributes to my save call. Backbone is pretty ninja at taking JSON data all over the place and handling it like a champ. So I want to save my cake with coconuts and nuts. (Is that 2 nuts?) Anyway, I passed in two objects to my save. The attributes JSON object AND some options. The first, {wait:true} means don't update my client side model until the server side trip is successful. The success call back will occur when the server successfully returns a response. However, since this example results in an error (a status other than 200 will indicate to Backbone to use the error callback) we get a representation of the model without the changes. It should still be plain and without nuts. We also have access to the error object that the server sent back. We sent back a string but it could be JSON error object with more properties. This is located in the error.responseText attribute. Yeah, 'we don't like nuts.'
Congratulations. You've made your first pretty full round trip from setting up a model, saving it server side, and back. I hope that this answer epic gives you an IDEA of how this all comes together. There are of course, lots of details that I'm cruising past but the basic ideas of Backbone save, RESTful verbs, Server-side actions, Response are here. Keep going through the Backbone documentation (which is super easy to read compared to other docs) but just keep in mind that this takes time to wrap your head around. The more you keep at it the more fluent you'll be. I learn something new with Backbone every day and it gets really fun as you start making leaps and see your fluency in this framework growing. :-)
EDIT: Resources that may be useful:
Other Similar Answers on SO:
How to generate model IDs with Backbone
On REST:
http://rest.elkstein.org/
http://www.infoq.com/articles/rest-introduction
http://www.recessframework.org/page/towards-restful-php-5-basic-tips