Skip to main content

· 5 min read

The Big Picture

auth0 provides a solution to help you implement authorization (your users' level of access) and authentication (your users' identity) in the applications you build. You know how some website's navigate you to an authentication page that allows you to sign up and log in with your own email, or use Google? auth0 provides a smooth developer experience for implementing that type of functionality on your own application.

Note: if you're confused about authentication vs. authorization, auth0's docs feature a great analogy for remembering the difference. Authentication, or proof of identity, is like showing your badge to a security guard. Authorization, on the other hand, gives access to some resources but not others based on authorization level, like an elevator key sensor that gives you access to some floors but not others.

What kind of applications can you build with it? Well, auth0 provides solutions for several different types of apps.

Regular Web Apps

screenshot of page displaying a grid of regular web app options including Apache, ASP.NET, Django, and Express

Before the new wave of JavaScript apps that ran in the browser came along, most developers relied on apps that ran on the server. This is still the best way to implement many applications, especially those that require frequently refreshed data. auth0 has a generous amount of getting started resources for these types of apps, including tutorials for those apps that might combine server-side rendering with static site generation, like their Next.js tutorial.

Single Page Apps

screenshot of page displaying a grid of SPA web app options including Angular, React, JS, and Vue

auth0 also has support for SPAs (Single-Page Apps). SPAs use JavaScript in the browser to update content in a single page using APIs like fetch. This can improve performance, especially for websites like e-commerce pages and blogs, because the data doesn't have to be fetched from the server every single time a page is requested by a user. You can find tutorials for Angular, React, JS, and Vue apps on the auth0 website.

Native Apps

screenshot of page displaying a grid of regular web app options including Android, Cordova, Flutter, Device Auth Flow, and Angular

When an app runs natively, that means it is designed to run on a specific platform, rather than being platform-agnostic. For example, an iOS app is designed to run on an iOS operating system, and not an Android operating system. With auth0, you can get started and learn how to implement auth0 in native apps on multiple platforms, including iOS, Windows, and Flutter.

https://auth0.com/docs/quickstart/native

Backends and APIs

screenshot of page displaying a grid of regular web app options including ASP, Django, Laravel, and Go

You can implement auth0 to secure routes on many types of backends and APIs. This way, users who are not authenticated may not access private routes.

Which flow should I use?

auth0 offers different flows, or chains of steps in implementing security.

Client Credentials Flow

Now that you've been introduced to auth0 and the types of apps it integrates with, you might be wondering about different scenarios for using auth0.

For example, sometimes the person that needs authorization is not a person at all -- it's a machine! If you're not familiar with this type of scenario, think of CLIS (Command Line Interfaces), and similar services.

auth0 has designed a flow implementation for this called the Client Credentials Flow. A client credentials flow flow is appropriate when the client happens to be requesting access to requested resources which are also under its control, so when the flow is implemented, the client only uses the client credentials to request access.

Authorization Code Flow

auth0's Authorization Code Flow is a ten-step flow appropriate for server-side apps with end users who can provide login details and consent. Inside this flow, the Authorization Code is exchanged for a token. It can't be used for browser-side code because the Client Secret is sent in the flow, and that would be visible in the browser. It's also super safe since the token is passed directly to the Client.

Resource Owner Password Flow

This flow is not highly recommended, but it works in cases when the application can be trusted with the credentials. This is because this flow allows the credentials to be stored on the backend.

You can read more about it in auth0's resource.

Authorization Code Flow with Proof Key for Code Exchange (PKCE)

This flow is designed for SPAs and for mobile apps. Since these apps cannot store a Client Secret because it would then be exposed through either the browser or decompilation, auth0 recommends this alternative PKCE approach. The PKCE flow accepts a value from the calling app called a Code Challenge. It is a transform value of a secret called a Code Verifier, and without this original value an attacker would not be able to exchange it for a valid token.

Conclusion

I hope this post has given you a good big picture of how auth0 works! It's good to start with the type of application (Machine to machine? Mobile? SPA? Traditional?) and then identify the type of flow you need before you implement. If you have any more questions about implementation details, you can always head over to the auth0 docs. Of course, I'll be writing more blog posts on this topic in tutorial-style. 😉

· 4 min read

Dan Ott, Nick Taylor, Ben Holmes and I got together recently on a Twitter space to talk about JavaScript frameworks. It was a well-rounded conversation summarizing how to choose a framework, and the pros and cons of some of the more popular options. Below is a summary of what we shared.

My Summary of Our Conversation

What are some considerations to keep in mind when you’re choosing a JS framework?

It depends!

It’s important to keep in mind the end goal, apart from technology. If you have a client with a deadline, you’re going to need to use the solution at hand instead of spending lots of time exploring new solutions.

You have to provide reasons for the business value of your choices. If you’re working on a personal side project, however, you have more time to learn things for the sake of learning.

The other thing to keep in mind is what kind of website you’re building.

Content-heavy sites work best with a static site generator, whereas something like Spotify with a lot of client-side code might require a different type of framework.

It’s also important to keep in mind the goals of the project over time. Some people just pick the frameworks with the biggest applications to stay ‘safe’, while it might be smarter to start with the smallest functionality and build from there, to keep your website more performant.

This might look like, say, choosing Astro over a monolithic solution. It can also look like using an SSG like 11ty or Astro if you’re considering where you’re running JS as part of your considerations – they run on the client side. Or, you can start with Remix, which generates at runtime but is set up to do caching incredibly well.

Note: it’s not a community expectation that a frontend engineer knows the ins and outs of every single framework out there– for example, in an interview, it should be ‘good enough’ just to articulate the advantages and disadvantages of a few.

Note 2: The number of frameworks can become overwhelming if you’re new. Stick to learning one at a time, have patience, and eventually you’ll get a feel for where things have landed at your moment in time.

Why are we seeing JS frameworks encroach on more and more of the stack?

First of all, JS bundles are large and static and not easy to handle at scale.

Secondly, developers are beginning to request building routes partly statically, and partly dynamically, rather than building all routes statically. By moving JS to the server, you can stop shipping it and pass it to the client from the server instead.

For example, if you worked at a newspaper, perhaps you don’t want to statically deploy every single article from the last several decades every time you deploy routes. Caching the pages makes sense.

What is island architecture?

Island architecture allows the developer to ship less JS by volume. It’s as if static content were like oceans and content that requires shipping JS were islands.

For example, say you had a page with a banner and a carousel. You can load the banner statically, and ‘turn on’ animation and shipping JS for that carousel component only.

In Astro, nothing is turned on by default. That way, you only pay the cost of shipping the components that really need to ship JS.

One thing to note: since the advent of new technologies besides webpack (which is still powerful in its own right), it’s become a lot easier to create these new frameworks, which contributes to the recent burgeoning of them.

On hype: it’s fun, but also, some of the above questions about the purpose of your project are more important than just using the latest framework.

Another trend: edge computing

In edge computing, JS is shipping closer (literally, on a closer server) to the user, so that it becomes faster and more performant. With Netlify, it’s cheaper monetarily to use edge computing than not!

Framework vs libraries vs metaframeworks

Classically, a framework is fairly opinionated, while a library is a less opinionated set of features. A metaframework would be a framework built in some way off a framework. With respect to Vue, Astro is a metaframework, while with respect to React, Astro is a framework.

Resources:

Netlify Page Props in Next.js Resource

Anthony Campolo on Partial Hydration

Jason Format Application Holotypes Resource

Jason Format Islands Architecture Resource

Patterns Islands Architecture Resource

Island boy song

Astro.js

· One min read

This is my digital garden! I've organized the content by tags:

seeds - These are notes and half-baked thoughts.

sprouts - These are blog and talk drafts, or more rambling trains of thought that still have structure.

trees - These are fully fledged blog posts, or even essays!

There are other tags, too of course, but those will have to do with topics and less to do with the content's position in my garden.

Hope you enjoy clicking around. 🌱

· One min read

As far as I can tell, there's a paucity of resources outside of academia for helping people understand compilers. It gets worse when you consider the resources available that are aimed at JavaScript/TypeScript developers specifically. That's why I'd like to write a course called "Compilers For JS Developers".

Here's a tentative outline:

Section 1: What is a Compiler?

Explain what compilers are on a high level. Include lexical analysis, syntax analysis, and code generation.

Section 2: Let's Play With the AST Explorer

Create exercises in JS, HTML, and CSS for developers to complete.

Section 3: Compilers In The Wild

Break down what happens when you run a TS compiling command -- doesn't need to be compiled to be executable since browsers have a JS parser. TypeScript, however, as a superset of JS, needs to be compiled to JS!

Resources:

· 4 min read

Writing A Clear Code Example

If you're a developer advocate, you've probably written a code example or two. The purpose of writing a code example is completely different from the purpose of writing production code. "It's messy, but it works," doesn't fly. It has to work and teach other developers. At the same time, you might not show the extension of an app to the fullest degree, for modularity's sake. In my time at a small startup, I've lost count of the number of code examples I've created. I've made some mistakes and learned a few things along the way. Here are some lessons that I can share with you.

Keep the Visual Impact In Mind

Keep it clean-looking. Running prettier before pushing is important, but that's not the only thing to consider here. Say I were writing a sample to show how to retrieve information from a certain API. How can I improve the readability of this codeblock?

fetch('https://api.sample.com/v3/endpoint',
method: 'POST',
headers: {
Accept: 'application/json',
'Content-Type': 'application/json',
Authorization: 'KEY'
},
body: JSON.stringify({ body: 'data' }),)
.then((response) => response.json())
.then((response) => console.log(response))
.catch((err) => console.error(err))

Well, I could pull out headers and options, make them variables, and pass them into the fetch call.

const headers = {
headers: {
Accept: 'application/json',
'Content-Type': 'application/json',
Authorization: 'KEY',
},
}

const options = {
method: 'POST',
headers: headers,
body: JSON.stringify({ body: 'data' }),
}

fetch(
'https://api.sample.com/v3/endpoint',
options
.then((response) => response.json())
.then((response) => console.log(response))
.catch((err) => console.error(err))
)

As you can see, that makes it a lot easier to see what options you need to pass to the API endpoint to receive a response.

Comment Wisely

Let's say I was working on the same block of code. Even though this is a code sample, it shouldn't be necessary to comment on a lot of lines.

// these are the headers to be sent in the request
const headers = {
headers: {
// default is application/json
Accept: 'application/json',
//content-type is application/json
'Content-Type': 'application/json',
// send authorization from your account here
Authorization: 'KEY',
},
}

The comments are starting to make this hard to read and I haven't even gotten to the options variable yet.

If you know your audience well enough, you might know that they're familiar with sending headers to an API. I'm a fan of short documentation links in templates, just in case:

// https://www.linktoapidocumentation.com
const headers = {
headers: {
Accept: 'application/json',
'Content-Type': 'application/json',
Authorization: 'KEY',
},
}

Otherwise, I try to keep comments out of the template, unless I'm doing something that interrupts a well-known coding paradigm.

Know The Limits Of Your Sample

It's important to keep your sample clear by illustrating one concept at a time (unless, say, it's a sample for a livestream and you want to show multiple aspects of your product, then-- time to go all out!).

This modularity is something that I have seen clearly illustrated in Next.js sample code. In Next.js's form example, you can see on line 34 that the information on a form is displayed in an alert.

Now, an alert box is often considered bad form (haha) in production. However, the authors of this code sample have wisely used it as a way to keep the modularity of their sample repository intact. Sure, they could have gone on and shown how to use useRouter() and query params to pass this information on to a new page, but they decided to focus on showing how to use forms in Next.js, so they ended the functionality on this page with an alert box.

In Conclusion

What have we learned? Well, the style of your code sample is determined by your scope and audience. Whether or not you need to comment to explain your code depends on your audience's understanding of the general concepts you're illustrating an instance of. Also, how much functionality you highlight depends on whether you're writing an example for documentation or a codebase to walk through a livestream. No matter what though, keep your code neatly formatted and organized. The need for clarity never changes. 😉

· 3 min read

Using Visual Thinking to Teach

How would you teach someone to draw a house? What would you say? I might write something like this.

"Draw a horizontal line. Draw two lines of the same length, starting from the ends of the original line, and perpendicular to the original line. Connect the two lines with another straight line. Now you have a square. From the top corner of your square, draw a line at roughly 45 degrees to the top line of the square..."

Whew. That's already a mouthful, and we haven't even finished the roof yet.

Ed Emberly was an artist who taught children how to draw. If he were to teach a child to draw a house, he would draw something like this (this is my own drawing):

Three slides. The first shows a square. The second shows a triangle on top of the square. The third shows a rectangle added to represent a door. There are mini version of each shape under each step.

Without a single word, you understand how to draw a house in a moment or two.

This is power of visual thinking. It's important in all fields of teaching. In developer advocacy, it can be used to teach audiences with graphs and maps and videos (of course, audio must also be supplied). Visual thinking can also help developer advocates create the constraints they need to be creative. I think this is the less obvious point, so let's talk about it.

Using Visual Thinking to Plan Projects

Let's say I were a developer advocate who was planning a tutorial to introduce developers to a new SDK (Software Development Kit). Say that this SDK provides the developer with a type of hyperaccurate timestamp. To show the purpose of the SDK, I use it in the framework that I used to build this website, docusaurus.io. I'm also really excited about the docusaurus CLI (Command Line Interface), so I'll describe how to use that to view the pages in development. I'll draw a map of what I'm doing.

Three stacked blocks representing steps, only one with SDK mentioned

Hm. That's a lot of real estate devoted to docusaurus. Only one step is devoted to the SDK I'm writing a tutorial about. Maybe this plan could work for a livestream format, but for a tutorial, I'd better narrow my focus:

Two stacked blocks representing steps, one with SDK mentioned

There. I've planned my tutorial and given it a good focus, using visual thinking!

Where To Go From Here

I hope this has given you some good ideas about how to use visual thinking in your own approach to developer advocacy. It's helped me, in that it's given me some 'shortcuts' to project planning and also helped me communicate concepts more clearly to my audiences.

If you're interested in learning more about visual thinking, I highly recommend these resources:

Edward Tufte's Work

The Doodle Revolution, by Sunni Brown

Unflattening, by Nick Sousanis

· 3 min read

I started bootcamp when my daughter 2 months old. Yes, it was tough. But it also helped me understand what I wanted from a tech career. These two aspects of life -- tech and parenting -- don't have to be in tension. Here are some of the ways I've adapted to being present for other developers as a developer advocate, while being present for my daughter.

Boundaries

The biggest thing is having a hard line on what you will and will not accept from work.

These hard lines can revolve around:

  • How many hours/week you work.
  • How much you travel for work.
  • Whether there is parental leave.
  • How much pay you receive.
  • Whether you will work remote.

I actually found that this made it easier, not harder, to narrow down opportunities. If you eliminate some of them because they won't work with your lifestyle, you have a filter by which to figure out which jobs you're really interested in.

Attitude

The other big thing to remember is that parenting is not limiting. Yes, you won't make the same choices as you did before. But you will make choices based on a new aspect of your life that will enrich it.

And, it's ok to make choices based simply on what you want. There's a lot of pressure on parents to do the "right" thing, but the most important thing is to take care of yourself so you can be there for your kid.

'What aligns with my joy?' vs 'What do others think I should do?'

It will free up a lot of work/life tension if that's the first question you ask yourself -- what aligns with my joy?

There's a lot of pressure on developers and parents to behave in very particular ways. You don't have to participate in what doesn't suit you.

If your joy is found in a life pattern that's not attainable yet, you can make small daily changes to work towards your goal. If there's another tech subfield you want to work in, make a goal to talk to one person in that field per week. If you want to have a job that's more flexible and allows you to pick up your kid from school early, apply to one of those jobs a week.

We all know that a life that aligns with your inner peace is not necessarily easy. There's a lot of external turmoil in the world. It can be exhausting, scary, and downright overwhelming to be a parent, especially a new parent, in tech. But it's a lot easier when you pay attention to what you, as a whole person, delight in.

Caveat

There are a lot of systemic issues out there that make life difficult for caregivers. This post is not intended to say you can solve all those difficulties with an attitude adjustment. Laws and cultural expectations need changing. This post is solely intended to help with any internal friction you may be experiencing, since these thoughts have helped me.