hapi 19, joi 17
this is when connecting for example nes or other well known modules
Based on this comment: https://github.com/hapijs/joi/issues/1601#issuecomment-431677851 what is an "inlined option" vs not?
Hi guys, I'm using Joi Validation which is awesome. I'm having a hard time trying to implement a validation-renaming action on a schema. Do you know how to implement this? hapijs/joi#2307
We're migrating our hapijs app from 16->17->18. There seems to have been some change to the structure of the response object. What I could access with
request.response.source now I need to access with request.response.source.payload. I'm having difficulty identifying when and where that change was introduced. Could someone provide some insight. Thank you.
I am working on upgrading an application to the latest express-validation which was using the old form of Joi. After the upgrade, none of the body objects are mutated as they were before. In particular, date objects are still strings which breaks things. We were just chaining the validation with a wrap function which takes in request, response and next. Do we need to upgrade our process to call the validation differently now?
route.post('/some_route', validate({
body: {
end_date: Joi.date().iso().allow(null).default(DateTime.local(2019, 11, 1)),
start_date: Joi.date().iso().allow(null).default(DateTime.local(2019, 11, 30)),
},
}), wrap(async (req, res) =>
// references to end_date and start_date within req.body were dates before. Now they are strings.
// this is after upgrading from express-validation 1.0.2 to 3.0.2 and joi 14.3.1 to @hapi/joi 17.1.1
// how to access the mutated body object now.
}));
Do we need to upgrade our workflow and call validation differently in order to get access to the values being coerced within @hapi/joi?
body: {
end_date: Joi.date().iso().allow(null).default(DateTime.local(2019, 11, 1)),
start_date: Joi.date().iso().allow(null).default(DateTime.local(2019, 11, 30)),
},
}), wrap(async (req, res) =>
// references to end_date and start_date within req.body were dates before. Now they are strings.
// this is after upgrading from express-validation 1.0.2 to 3.0.2 and joi 14.3.1 to @hapi/joi 17.1.1
// how to access the mutated body object now.
}));
Do we need to upgrade our workflow and call validation differently in order to get access to the values being coerced within @hapi/joi?
i got a post route that calls one function that upserts doc to mongo
i have a job that runs once a day that send up to 80 requests with about 1000 elems in an array in each request
is there a way I can queue the jobs on HAPI - or should i do it on the client side (send request one-by-one)
Speed is not important
As it now, i tend to get alot of socket time outs after the first few
i have a job that runs once a day that send up to 80 requests with about 1000 elems in an array in each request
is there a way I can queue the jobs on HAPI - or should i do it on the client side (send request one-by-one)
Speed is not important
As it now, i tend to get alot of socket time outs after the first few
I found my problem, in case somebody runs into the same issue this is how you solve it. You need to import it like this: import * as J from '@hapi/joi';
Or anyone has some documentation about Continuous Integration Pipelines in Jenkins using Lab + Code for the testing?
let refreshData = function () {
server.methods
.search(deepCopy(AllProjectsQuery.query), null, "USE_CACHE")
.then((data) => {
logger.log('info', 'refresh all projects data succeed')
})
.catch((err) => {
logger.log('error', 'refresh all projects data error: %s', JSON.stringify(err))
})
}
it says server.methods.search is not a function
Currently I am migrating from v16 to v18, all seems to be working except this part. Maybe someone could give me a hint what is wrong?
Any idea on how I can enable streaming HTTP respones in Hapi?
I tried hapijs/hapi#3599 but no success
I've also tried removing compression (in server flags pass compression false) and then streaming but it all still gets sent in a single chunk
For file downloads(CSV/TEXT)
Hi, I'd need to implement catchall OPTIONS -method handling for a HAPI v19 based development server. What would be the simplest and least disruptive way to implement this? I was thinking of implementing a HTTP 404 handler that would check if it was an OPTIONS request and basically just turn the response into HTTP 200. I'm new to HAPI, so advice and/or pointers would be welcome. Also, I'd prefer to avoid adding new modules if possible. Any thoughts?
Anyone able to help me on how to get HAPI to generate CORS headers?
access-control-allow-origin et al. are working ok, but how do I configure Access-Control-Allow-Methods? I'm currently generating *-methods header in my plugin, but just I'd prefer to use HAPI CORS config for this if possible.
can any of you point me to the right direction to make it work a simple web browser connect to @hapi/nes
