DEV Community: Gary Menzel

NodeJS and "crypto" for tokens

Gary Menzel — Wed, 13 Mar 2024 00:45:48 +0000

If you want to have secure tokens in your action emails that can contain state information then consider using nodejs crypto functions - specifically json-crypto (which is based on the crypto library).

Here are the reasons why:

URL safe (so you can use them immediately in your email links)
"nonce" based - meaning that each invocation of the encryption function produces a completely different encrypted string (so it is harder to crack)
easy to use with your own TOKEN secret (the thing that you protect on your backend that allows the magic to happen)

I wont go into a tutorial because the github repo for json-crypto is easy to follow.

The only thing I will point out is that you don't want to create your TOKEN key/secret each time - you should create that once and store it securely for your application to use it. This is often in environment variables but you could also use a secrets vault of some kind.

The other thing to consider is what you put in your payload - the JSON data that you encrypt. I'd recommend at least a timestamp of some kind (probably just the numeric date from new Date()). With a timestamp you can manage an expiry of the token as well as provide timeline reporting (like how long did it take to get a response). You also want some context regarding what is in the decrypted token. This could be anything like a type or an email or both - or just some other pieces of context that allow the token to be actioned for the specific purpose you want it for (e.g. a subscription confirmation). The payload can be any valid stringified JSON.

Personally, to keep my token smaller, I like to use an array rather than an object. The array then has a standard sequence of information like a type, the timestamp, a version, then other context information applicable to the type based on the version. But you do you - just make sure you follow a standard that you set.

That's about it... Yes - no code on this one again. I don't want to tackle the JS vs TS debate.

Thoughts about "keys" on React lists

Gary Menzel — Wed, 06 Mar 2024 02:53:27 +0000

It's been a while... a LONG while....

This is a really short post about the key property on React components that are lists (i.e. arrays)...

I really like to get rid of all the React warnings about unique keys on lists. You really want everything to have a unique key when it is part of a list so that things update reliably.

But when you get the warnings sometimes it can be difficult to work out which component in which list is the offender.

What I have found useful is to search anywhere you are using iterators (like map or reduce) and make sure you are composing a unique key on any component the iterator might return.

The other place to look is for any .push calls that might be creating the array with a component as the thing you are pushing and make sure they have unique keys.

Generally, I compose the key from part of the data and an index from the iterator. If that is not unique enough, then I might also add a prefix or suffix to the key as well.

I like my keys to have a reasonably consistent format to them and separate sections of the key with a dash (hyphen).

Doing this should ensure you have consistent key generation and keep the keys all unique.

Transformer - not a robot in disguise

Gary Menzel — Sun, 25 Oct 2020 01:37:54 +0000

My job keeps me very busy and I don't get a chance to write as much about what I am doing (compared to actually doing it). So this post is an interlude from the other series I started on pluggable APIs.

The company I work for does a lot of work with data and prepares all sorts of tables and charts. An internal project we are looking at as a need to be able to replicate these charts in a more "live" dashboard style of presentation.

Inspiration

I work a lot with MongoDB and have been intrigued with how the JSON query language they have developed provides a lot of power without being being to actual procedural code. Sometimes, you need that kind of power and flexibility after you have left the database behind and are in plain JavaScript land. So I started wondering about how this could be done.

I did look at JS modules that mimic the MongoDB approach but I wanted something that might be a little more "consumable" by developers with different language skills.

But, I am probably getting ahead of myself and we should talk about what a data pipeline is first.

Collection Pipelines

Martin Fowler describes Collection Pipelines as follows:

Collection pipelines are a programming pattern where you organize some computation as a sequence of operations which compose by taking a collection as output of one operation and feeding it into the next.

So it is a bit like this....

collection => function => output => function => ......

One of the ways we can do this in JavaScript is with a Promise. Promises can have an initial state and can pass the output of one operation into the next via the .then chaining function.

Promise.resolve(someData)
  .then(result => {
    // do something here
    const newResult = // details omitted
    return newResult
  })
  .then(previousResult => {
    return // something else
  })

NOTE: The above example is pseudocode and Promises can also come in the async/wait flavour. The importance of the particular choice for the example will become apparent soon.

This mechanism is great, but it means we have to know when we write the code what each of the operations are.

If we look at Martin Fowler's description, one thing that stands out is the word sequence. The main mechanism in JavaScript for a sequence is an array. What if we could use an array to give us the sequence we need but also leverage the power of the Promise/then pattern?

Combining Promises and Reduce

As it just so happens, someone has already thought about this and over on the MDN site there is an article that includes the following code:

[func1, func2, func3].reduce((p, f) => p.then(f), Promise.resolve())
.then(result3 => { /* use result3 */ });

You will have to scroll down to the Composition section to find it.

We can make a nice sequence function to abstract this:

const sequence = (operations, collection) => {
  return operations.reduce((p, f) => {
    return p.then(f)
  }, Promise.resolve(collection))
}

Now we can write:

const collection = .....  // array or object
const finalResult = sequence([
  func1,
  func2,
  func3,
  ......
], collection)

BUT - this only gets us part of the way there.

Next (yes, running out of time again)

The next article in this series will wrap it all up with a way in which we can use something inspired by MongoDB... more like this:

const collection = // array of objects (or arrays for records)
const transformed = transformer([
  ["group", ["year", "state"]],
  ["mutate", {total: "`${row.men + row.women}`"}],
  ["rename", {total: 'Total'}]
], collection)

Stay tuned....

Pluggable API and React (Series) - Tooling

Gary Menzel — Mon, 28 Sep 2020 08:36:50 +0000

Following on from the introduction, this post will talk about some of the tooling that I have recently been using and why it help support a pluggable API.

snowpack

As many developers know, build (and dev) tools really help improve your productivity. Also, like many React developers, I had been using Create React App (cra) from the Facebook team. It abstracts away the tedious setup of webpack for helping to give you a "live" development environment as well as being able to bundle up your code for deployment.

However, I have recently cutover solely to Snowpack due to the speed in which it works and the non-lock-in to the supporting scripts which CRA requires you to "eject" from and then lose all the benefits. Snowpack also is not as aggressive in the way it bundles your files during development and the Hot Module Reload also works very well.

Unlike CRA, Snowpack has several templates to work with non-React frameworks.

If you don't already know about Snowpack, take a look here:
Snowpack. It has a few small issues but all can be overcome easily.

yarn workspaces

When developers are building modules for publication (on npm) the common go-to tool is lerna. However, when you just want to have some separation of server and client (or clients) yarn workspaces provides a nice way to have a mono-repo. You can always upgrade to lerna at a future point as they both can work together. So, for this series, we will stay with yarn workspaces and talk about some of the common usage commands with that.

react-hooks-global-state

In the global state management space, many have heard of Redux and MobX. These are very common but also have a fairly steep learning curve to master them. They are also often overkill (and overhead) when you have a smaller development team with good communication lines.

Fortunately, React Hooks have been around for a while now and there are some solid statement management solutions around.

For this series I am going to stick with react-hooks-global-state as the model is very simple to use and you CAN actually leverage your Redux knowledge of types, actions and reducers if you want. I am also looking at a different version of the pluggable API that uses zustand. One of the benefits of zustand over react-hooks-global-state is that zustand does not require an initial state to be created - allowing for more dynamic state at runtime.

These tools come from the similar developers. Both use React Hooks and both support the ability to interrogate and manipulate the state from outside of React. This becomes important when you want to separate your backend API calls from your front-end components.

Check out react-hooks-global-state and zustand just to become familiar with these packages. We may end up referring to both.

Next...

Next I will talk about the core parts of the pluggable API and we will start getting into some code. I am planning have a git repo that will have a branch for each stage but will see how that pans out along the way.

Pluggable API and React (Series) - Introduction

Gary Menzel — Sat, 19 Sep 2020 12:05:00 +0000

What is this series about?

In my development work over many years, I have built many APIs on both the front and backend of web-based systems. Obviously, REST is a popular communications API and many server platforms provide libraries to organise and manage various features or "service" but what about the front end?

This series is (probably) opinionated and is not specifically about React (although the inspiration for this framework comes from React). It is about building a framework that you can use to pass globalised and share all of your well-built functions for use within your React components.

It does use various React technologies (like hooks) where applicable but also adheres to the ideas of inversion of control and dependency injection - hence minimising imported modules and facilitating easier testing.

What will this series use?

The focus is on front-end technology but will also demonstrate using HTTP calls for backend access. It will also use React for the front-end technology and Snowpack as the development environment. For global state management, the series will use react-hooks-global-state rather than Redux or MobX - but you could probably apply similar ideas to those technologies or roll your own with React Context.

Why would I want an API in my front-end app?

If you are building a single-page-app (SPA) then it is likely that you have various components that share some type of global state. I have found that applying separation to read/write of global state really helps organise an application and an API can help do that. You can use React Hooks to read your data and an API to update your data (as well as provide side effects.

Yes, Redux and MobX can provide that type of separation but, out-of-the-box, hook-based global state usually does not. The reason for going with hook-based global state management is purely for consistency and minimal boilerplating. This approach may not be suitable for larger developer organisations but works very well for smaller dev-ops style IT groups.

What next?

This is just the introduction article. In future articles I plan to:

Go into more detail about the tooling selection - such as Snowpack and react-hooks-global-state
Work through the core of a pluggable API
Demonstrate how to add variables and functions in a plugin and how to access the global API from those plugins
Make suggestions about a component factory that allows each plugin to "extend" the API footprint
And other relevant things as we flesh out the pluggable API and various plugins

Please join me on this journey and provide your feedback.