DEV Community: Andrew Stacy

Implement the New AWS CloudScape Design System into NextJS

Andrew Stacy — Fri, 29 Jul 2022 02:18:36 +0000

Something exciting has happened recently. AWS has released the design system that they now use for the AWS Console as open-source! The name for the design system in CloudScape and it is as beautiful as it is functional.

Find CloudScape here: https://cloudscape.design/

You can integrate it with NextJS but you may run into some some problems, so I wrote a blog post about it:

https://www.andrewstacy.com/blog/using-cloudscape-with-nextjs/

I hope it helps! Enjoy CloudScape!

What You Should Know About Logging with Micro-Frontends In 2022

Andrew Stacy — Thu, 07 Jul 2022 02:02:56 +0000

There is a new trend in building enterprise scale applications that is extending the concept of micro-services all the way through to the frontend of applications. We call this concept Micro-Frontends.

However, when we divide our applications into multiple, smaller applications, challenges arise in regards to how we control our logging in both the development environment and in production.

First, we'll take a look at a basic micro-frontend architected application and then dive into some logging concepts that are applied in standard back-end environments. After that we will take a look at how we can use the Adze logging library to solve this problem for the frontend.

To read the rest, go here: https://andrewstacy.com/blog/logging-with-micro-frontends/

How to make your JS/TS app logging better

Andrew Stacy — Mon, 27 Jun 2022 01:33:04 +0000

I recently released a blog post about implementing Adze into your web application to vastly improve your logging experience. Check it out!

https://www.andrewstacy.com/blog/better-javascript-logging-with-adze/

I made an Async Service Container for Node/Browser

Andrew Stacy — Fri, 01 Oct 2021 15:34:05 +0000

Hey friends,

Over the years I have implemented service container architecture in many large-scale front-end apps and it has vastly improved their performance and maintainability. I've finally got around to turning it into an open-source library called "Be Our Guest." The name is inspired by the Disney song from Beauty and the Beast and the lyric "put our service to the test."

So, what is it "Be Our Guest?"

It is an ASYNC service container that enables your node or browser applications to implement an Inversion of Control architecture for it's modules and dependencies. You may be thinking, "why do I need this?"

As an example to illustrate it's value, let's say we have a module that handles auth within our application. After you construct and register the module it requires a boot step to send some requests to the backend system to retrieve auth tokens that our other API modules will require. This action is an asynchronous action and we do not want to block initialization of our other modules while this module makes its request. We also need to inject this module into other modules that depend on the auth token. Those modules must await the initialization of our token module before they can be used. As you can see, providing async support for these types of initialization are crucial.

Why not use X other service container library?

There are quite a few other service container libraries out there, but most of them require decorator support for your applications which is not an official JS api and will make adoption into an existing application more difficult (as you will have to do some refactoring). The primary reason they do this is to enable automatic dependency injection. While auto-DI is a nice feature, it's not a hard requirement for an IoC service container to be useful.

Also, Be Our Guest is completely async. This enables you to more easily register and boot dependencies that require async operations. It also allows the service container to register and boot all of your services without them blocking each other in the process, further increasing your app's performance.

Check it out!

Please take a look at "Be Our Guest" and give us a star at https://github.com/AJStacy/be-our-guest .

The `any` type in 2021

Andrew Stacy — Tue, 24 Aug 2021 17:06:18 +0000

Better JS Logging for Micro-Frontends, Browser, Node

Andrew Stacy — Fri, 13 Aug 2021 15:22:24 +0000

Official documentation can be found here:
https://adzejs.com

Hey everyone, I recently released version 1.1 of Adze, a library that solves a lot of the pain points of handling logs in multiple environments and logging with modular systems like micro-frontends.

As you may already be aware there are a number of other good JS libraries out there to assist with logging. The focus of Adze is to provide a convenient and clean API, provide first-class TypeScript support, and to empower you to take command of your logs rather than pigeon-hole you into a specific way of handling them.

Here is a list of the features that Adze provides:

First-class TypeScript support
Multi-environment support for the Browser and Node
Wraps and extends the entire standard API
A fluent, chainable API
Log Listeners for capturing log data
Log annotation namespaces, labels, and other meta data
Attractive styling (EMOJI'S INCLUDED and consistent across major browsers)
Everything is configurable
Enables completely custom log levels
A global log store for recalling logs and overriding configuration (supports micro-frontends and modules)
Support for Mapped Diagnostic Context
Convenient unit testing environment controls
Advanced Log Filtering
and much more...

Beyond the new features that Adze provides you, it also wraps the entire console web standard.

Example:

// ----- setup.js ----- //
import { adze, createShed } from 'adze';

// Adze can be used without any configuration.
adze().log('Hello World!');

// But you'll likely want to set it up like this...

/* A shed is a global log store used for listeners and caching 
   as well as configuration overrides. */
const shed = createShed();

/* Let's create a log listener to transport our log data
   to a destination. We'll listen to all log levels. */
shed.addListener('*', (data, render) => {
  /* If a log does not render then we will ignore transporting 
     it. */
  if (render) {
    // Do transport logic here.
  }
});

// Let's create an Adze configuration (or import it from an env file).
const cfg = {
  logLevel: 1,
};

// Now we'll create a new factory using seal
export const log = adze(cfg).label('foo').count.seal();

// ----- elsewhere.js ----- //
import { log } from '~/setup.js';

// And now we can create new logs using our new factory
log().error('An error occurred! Oh no!');
log().error('Another error occurred! Quick! Help!');
log().log("I won't display because my log level is too high.");