I’ve been meaning to learn how to use jscodeshift for a while. Today we’re going to use jscodeshift to convert some old React 15
ref="container"code to some new React 16
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.
subscribe via RSS