This article is going to explore using winston and Elasticsearch to do “structured logging” in Node.js. The basic idea is that we want to write logs with some metadata attached to them, beyond just a timestamp, a level, and a message.
The traditional “twelve factors” approach to logging is just to write your logs to stdout, and let some extrenal process deal with logging. For example, you might use fluentd to read stdout on all your processes and write the results into Elasticsearch. This works well, and it works across different projects written in different languages. But, with a little extra work, we can write some extra information into those logs.
For example, for every request we could write the URL of the request to the log as
request.url, and then write the response time in milliseconds as
response.responseTime, and now it’s a simple mater to generate an Elasticsearch graph showing our average and max response time to HTTP requests, or even to write a query which finds the top ten slowest routes in our system. Or we could write a
userfield to the log on every request, so we can figure out which users in our system are most active.
I’m working on a reporting engine right now, and one of the requirements I have is to be able to export reports as PDF files, and send PDF reports via email. We also have a management page where you can see all the dashboards, and we’d like to render a PNG thumbnail of the dashboard to show here. Our back-end is all Node.js based, and you’re probably aware that Node is not known for it’s graphics prowess. All of our reports are currently being generated by a React app, written with Gatsby.js, so what we’d like to do is load up a report in a headless browser of some sort, and then either “print” that to PDF or take a PNG image. We’re going to look at doing exactly this using Playwright and Browserless.
Cross-site request forgery (CSRF) attacks are a type of attack where a website you don’t control tries to send commands to your website, using your customer’s cookies. Today we’re going to look at a few ways you can avoid CSRF attacks, mostly just by being careful about how you design your API.
Since GitHub Actions is in beta, to get any of these examples to work you’ll need to apply for the beta program.
A couple of months ago Typescript team revealed that they were formally adopting eslint as the linter for Typescript, and that they were actively working to improve compatibility between eslint and typescript. What you might not know is, you can use eslint with Typescript today! Read more to see how to set up eslint on your typescript project.
subscribe via RSS