I have registered my web address (let's just call it https://mywebaddress/callbacks) with this external API and it will now send me JSON when it completes an action. I don't need to initiate anything outbound to it, I just need to receive the JSON and store it.
EDIT:
JSON data will be receive via POST
Paul's link sent me in the right direction. (http://www.meteorpedia.com/read/REST_API).
Then I found the section titled "WebApp.connectHandlers and connect".
I used the code found there, but in my instance there was an error in the code. I had to change the first line from var connect = Npm.require('connect'); to var connect = Meteor.require('connect');
Here is the code below.
// necessary to parse POST data
var connect = Meteor.require('connect');
// necessary for Collection use and other wrapped methods
var Fiber = Npm.require('fibers');
WebApp.connectHandlers
.use(connect.urlencoded()) // these two replace
.use(connect.json()) // the old bodyParser
.use('/getUserProfile', function(req, res, next) {
// necessary for Collection use and other wrapped methods
Fiber(function() {
var userId = req.body.userId;
var user = Meteor.users.findOne(userId);
res.writeHead(200, {'Content-Type': 'application/json'});
res.end(JSON.stringify(user.profile));
}).run();
});
}
Then to test that this was working I used http://www.hurl.it/. I changed the destination to POST and added a header of content-type - application/json. I then pasted in the body some JSON that I knew came from balanced. If you need a tool to see what is actually being posted to your server you can use http://requestb.in/.
Related
I need to forward a header from the browser to an external API I call from the server side.
The external API is called from getServerSideProps and API routes.
I was thinking about implementing some sort of a request context (using AsyncLocalStorage for example) that I can access from anywhere in the server side code.
That way I could create a middleware that will save the header to the context, and in the external API client I'll fetch it from the context and add it to the requests.
For example:
// context.ts
export const context = new AsyncLocalStorage<string>();
// middleware.ts
export function middleware(request: NextRequest) {
const store = request.headers[SOME_HEADER];
return context.run(store, () => NextResponse.next());
}
// client.ts
axios.post(EXTERNAL_API, DATA, {
headers: {
SOME_HEADER: context.getStore()
}
}).then(...)
Currently I simply send it as a parameter which is pretty tedious.
Is there a way of achieving it?
I tried adding async_hooks to my project but it got really messy when I tried to build the project.
Trying to figure out how to modify request headers for the graph client toolkit and have it apply when using the GET component. I don't necessarily want to override the entire graph client.
For reference, here's how you do it:
// Already likely on page, adding as reference
TeamsProvider.microsoftTeamsLib = microsoftTeams;
const provider = new TeamsProvider(config);
const options = {
authProvider: provider,
fetchOptions: { headers: {'ConsistencyLevel':'eventual'}}
};
const client = Client.initWithMiddleware(options);
provider.graph = new Graph(client)
// Now set provider with new graph
Providers.globalProvider = provider
I have gotten this to work without having to re-initialize the graph client by doing this:
Providers.globalProvider.graph.client.config.fetchOptions = { headers: {'ConsistencyLevel':'eventual'}}
You can also remove the request headers by setting fetchOptions to {}. This can be toggled at any time between requests, and can be set even after the globalProvider has been initialized without having to re-create the middleware chain.
I posted a comment in the issues section of the MGT repo here.
I have a custom service that must return data in CSV format.
I can't use a standard Express route, because I need Feathers' hooks on this endpoint.
I couldn't find an example of a Feathers service returning non-HTML, non-JSON data, and have found no way to specify a response content type.
Using res.set('Content-Type', 'text/csv') before returning from the service method didn't work; the final Content-Type header was reset to application/json, even though the method's return value was a regular string.
How can I properly set arbitrary response content types in Feathers' custom service methods?
You can customize the response format like this:
const feathers = require('feathers');
const rest = require('feathers-rest');
const app = feathers();
function restFormatter(req, res) {
res.format({
'text/plain': function() {
res.end(`The Message is: "${res.data.text}"`);
}
});
}
app.configure(rest(restFormatter));
The complete documentation can be found here.
Using your own service specific middleware to send the response should also work.
Currently, I use the built-in meteor http method (see http://docs.meteor.com/#http) for issuing http calls, on both my client and my server.
However, I'm experiencing two issues:
is it possible to cancel a request?
is it possible to have multiple query parameters which share the same key?
Are these just Meteor limitations, or are there ways to get both to work using Meteor?
I know I could you jquery on the clientside, and there must be a server-side solution which supports both as wel, but I'd prefer sticking with meteor code here.
"is it possible to cancel a request?"
HTTP.call() does not appear to return an object on which we could call something like a stop() method. Perhaps a solution would be to prevent execution of your callback based on a Session variable?
HTTP.call("GET", url, function(error, result) {
if (!Session.get("stopHTTP")) {
// Callback code here
}
});
Then when you reach a point where you want to cancel the request, do this:
Session.set("stopHTTP", true);
On the server, instead of Session perhaps you could use an environment variable?
Note that the HTTP.call() options object does accept a timeout key, so if you're just worried about the request never timing out, you can set this to whatever millisecond integer you want.
"is it possible to have multiple query parameters which share the same key?"
Yes, this appears to be possible. Here's a simple test I used:
Meteor code:
HTTP.call("GET", "http://localhost:1337", {
query: "id=foo&id=bar"
}, function(error, result) {
// ...
});
Separate Node.js server: (just the basic example on the Node.js homepage, with a console.log line to output the request URL with query string)
var http = require('http');
http.createServer(function(req, res) {
console.log(req.url); // Here I log the request URL, with the query string
res.writeHead(200, {
'Content-Type': 'text/plain'
});
res.end('Hello World\n');
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');
When the Meteor server is run, the Node.js server logged:
/?id=foo&id=bar
Of course, this is only for GET URL query parameters. If you need to do this for POST params, perhaps you could store the separate values as a serialized array string with EJSON.stringify?
I am building a registration form (passport-local as authentication, forms as form helper).
Because the registration only knows GET and POST I would like to do the whole handling in one function.
With other words I am searching after something like:
exports.register = function(req, res){
if (req.isPost) {
// do form handling
}
res.render('user/registration.html.swig', { form: form.toHTML() });
};
The answer was quite easy
exports.register = function(req, res) {
if (req.method == "POST") {
// do form handling
}
res.render('user/registration.html.swig', { form: form.toHTML() });
};
But I searched a long time for this approach in the express guide.
Finally the node documentation has such detailed information:
http://nodejs.org/api/http.html#http_http_request_options_callback
Now you can use a package in npm => "method-override", which provides a middle-ware layer that overrides the "req.method" property.
Basically your client can send a POST request with a modified "req.method", something like /registration/passportID?_method=PUT.
The
?_method=XXXXX
portion is for the middle-ware to identify that this is an undercover PUT request.
The flow is that the client sends a POST req with data to your server side, and the middle-ware translates the req and run the corresponding "app.put..." route.
I think this is a way of compromise. For more info: method-override