StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
20141905
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-11-22T09:57:08.777
FavoriteCount
0
LastActivityDate
2013-11-22T09:57:08.777
LastEditDate
LastEditorUserId
0
OwnerUserId
1447045
ParentId
20092065
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
Well, I finally got it to work somehow. But frankly, I don't get it. It was definitely related to <code>localhost</code> not being the same as <code>127.0.0.1</code>. How did it ended that way, I don't have a clue... I'll share what I learned while doing this, as I found no real answer for debugging this staff out there on the web. Here is what I learned: <ul> <li>grunt has a <code>--verbose</code> option that may help you see what's going on</li> </ul> If grunt-connect-proxy is configured correctly you must see something like this at startup: <pre> Running "configureProxies" task Proxy created for: /api/v1 to localhost:8000 </pre> In my case, the grunt server was running on <code>127.0.0.1:9000</code>, the second server on <code>localhost:8000</code>. I proxied requests made on <code>api/v1</code> so <code>grunt server --verbose</code> would output something like this on every proxied request: <pre><code>Proxied request: /api/v1/test -> http://localhost:8000/api/v1/test { "host": "127.0.0.1:9000", "connection": "keep-alive", "accept": "...", "user-agent": "...", "accept-encoding": "...", "accept-language": "...", "cookie": "..." } </code></pre> <ul> <li>the whole point of using a proxy is to avoid any unnecessary CORS configuration on your second server</li> </ul> This is because once deployed your frontend and backend code will coexist on the same server (= the grunt server is only needed at dev time). I wanted to stress that point, because @Ulugbek answer may suggest that you need CORS to make grunt-connect-proxy work. <ul> <li>the ECONNREFUSED error happens when your second server is not responding</li> </ul> In my case, I discovered that <code>http://127.0.0.1:8000/api/v1/test</code> was not responding even if <code>http://localhost:8000/api/v1/test</code> was. So, I messed around with the /etc/hosts a bit and solved the problem by making sure both endpoints were responding accordingly. The same error may happen to you if the second server is not listening to the proxied endpoint.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POYeoman with grunt-connect-proxy returns a ECONNREFUSED error
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USDream4ge
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POYeoman with grunt-connect-proxy returns a ECONNREFUSED error
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.