Forem: Chris Ellis

Moving a Team from React to Svelte

Chris Ellis — Sat, 05 Nov 2022 09:46:14 +0000

Hey, I'm Chris.

I'm the Director of Engineering at XtendOps, but that's boring. I'll introduce myself later.

I want to talk about Developer Experience. We all have a feel for what that means and it's easy to talk about if you're a developer. The old saying goes, do things to make your developers' lives easier and you'll have better software.

We take for granted that good Developer Experience leads to better software. The weird thing is I recently found myself stumbling to describe exactly how to the Leadership at my company.

How does Developer Experience translate to better software? What does the business experience? Is Business Experience a thing? What does this have to do with Svelte and React?

Hey, I'm Chris.

I'm a translator at XtendOps. I translate the Business' needs to the Developers and the Developers' needs to the Business. (I wasn't sure about the apostrophes)

Let's start with a story. I just came from a 2 week trip to Las Vegas and Mexico. We had a conference in Vegas which was a bit of a coming out party for our company. We help run support for companies like HelloFresh and J. Crew, and we are scaling rapidly.

After drumming up new business, we went to our offices in Mexico for Leadership meetings. Sounds boring but I got to use a big glass window overlooking the Pacific Ocean as a whiteboard. We were planning out our next 6 months with the CEO and VPs. Post Covid, you tend to forget what developing in an office with other people is like.

The conversation turned to why we chose to operate in Svelte back in October and that's when I brought up Developer Experience. They looked at me blankly.

I looked back at them blankly.

I mean come on, you want your developers to have a good experience right? Am I right?

The Revelation

The business doesn't care about Developer Experience. Not in isolation and not for the sake of the developers.

The business does care about outcomes and at the end of the day outcomes are Business Experience. Its through this lense I want to look at moving from React to Svelte.

Hey, I'm Chris

I care deeply about Developer Experience (DX) and Business Experience (BX), and that's why we chose Svelte.

Conciseness

One of the huge joys of using Svelte is the conciseness of its API. IMHO it provides just enough of an interface to get the job done without bloating your mental landscape of the application with unnecessary abstraction.

Your code is your understanding of the problem you're exploring. So it's only when you have your code in your head that you really understand the problem.

Paul Graham: Y Combinator, Holding a Program in One's Head

We put a lot of emphasis on that mental landscape because I have found the more quickly you can digest a complicated frontend view, the quicker you can modify it.

That feeling you get when you keep reading a component over and over again is an indicator that you have poor abstractions. One thing is not leading to another which means it takes you more cycles to really understand the problem.

The closeness of Svelte to the browser APIs and its readibility are the DX for why we chose Svelte, but how does this translate to BX.

Our experience is that it yields faster delivery time with fewer rewrites because of the language. Clarity here is key and appropriate abstractions have reduced our development Lead Times by about 30-40%

On our first sprint with Svelte, I had chalked it up as a Learning Week. It wasn't going to be about releasing production code that week. (We set aside a whole week of Svelte onboarding giving the team the official Svelte tutorial, example production code, and 2-3 Youtube series.)

The PRs started coming in after a day and a half. My direct manager and I were completely blown away at the speed with which my team picked it up. I think this speaks to the readibility of Svelte and conciseness.

This revelation completely altered the development Lead Times we were prepared for and we haven't looked back since.

Why tiny matters?

One of the oft spoken about features of Svelte is its tiny bundle size. It's spoken about in very general terms, without quantifying the impact on individuals. It really does matter for our users.

As an outsourcing company, we hire in the hundreds which means we have thousands of applicants. In addition, our applicants are primarily in Mexico and the Philippines so they are often operating our applications on mobile devices on slower internet compared to the US or Europe.

I've given all of this context to say that our candidates jobs depend on being able to apply anywhere in the world.

You may be wondering why this matters for a simple job application form. I'd be wondering the same thing.

Our clients prize top placements on spoken English and comprehension. With the scale we're operating at, we need to evaluate our candidates before the first interview so we we have custom assessments in the application process.

How does this affect BX then? We need tiny bundles to run on less powerful devices and ensure the greatest number of applicants.

We moved to Svelte a year ago and haven't looked back.

I spoke about this and more at the Svelte Society London Meetup back in August.

Please let me know if you found this helpful.

Headless Ghost and NextJS

Chris Ellis — Tue, 30 Mar 2021 16:03:12 +0000

This post was originally posted at chrisellis.dev

I've taken chrisellis.dev headless. When I started my website, I chose Ghost because of its amazing publishing experience. It's pretty great.

Unfortunately, I found the theme development experience a little bit clunky. Especially when you compare it to something like Gatsby or NextJS.

So I decided to try out Headless Ghost. Let's see how you can do this.

How to do this

Create your NextJS App
Prepare your Ghost Server
Import use the Content API JavaScript Client to import posts
Host it on a Serverless Platform

Create your Next App

The first step is to create your NextJS app. You can find more detailed instructions for doing this at NextJS, but the just of it is to do the following:

# Create your site
yarn create next-app yourdomain.com
cd yourdomain.com

# Start your server
yarn dev

That's it.

Prepare your Ghost Server

This step is a bit more involved. Login to your Ghost site backend.

We need to get a Content API Key to be able to pull content from our Ghost Site.

Click Integrations at the bottom of your Ghost Backend
Then Add custom integration at the bottom of your Integrations page
Enter a decent name
Make note of your Content API Key

The Content API JavaScript Client

Ok, let's start getting fancy and adding a dependency. First, we need to import the Content API.

yarn add @tryghost/content-api

This API is used for fetching content. You can use the Admin API to do more complex things like reading, writing, and editing.

I've chosen to extract this out to a /lib folder for reusability. Create a file /lib/posts.js. We also need to create a .env.local file at the root of your project which NextJS will use for development.

// lib/posts.js
import GhostContentAPI from "@tryghost/content-api";

// Create API instance with site credentials
const api = new GhostContentAPI({
  url: process.env.BLOG_URL,
  key: process.env.API_KEY,
  version: "v3",
});

// .env.local
BLOG_URL="https://yourdomain.com"
API_KEY="f77b5e81e07899d45850bbf248"

Great, now our app will connect to our Ghost Instance.

To start off with, let's fetch all of the posts so we can list the posts on the index page.

// lib/posts.js
export async function getPosts() {
  let posts = await api.posts
    .browse({
      limit: "all"
    })
    .catch((err) => {
      console.error(err);
    });

  return posts;
}

Now in pages/index.js, we need to import our getPosts() and call it in a getStaticProps. In NextJS, getStaticProps is used to prerender the page at buildtime. Blog posts are a perfect use case for this as they don't change names and slugs very often.

// pages/index.js
// top o' the file
...
import { getPosts } from "../lib/posts";

export const getStaticProps = async () => {
  const posts = await getPosts();

  if (!posts) {
    return {
      notFound: true,
    };
  }
  return {
    props: {
      posts,
    },
  };
};

export default function Home({ posts }) {
  console.log(posts);
...

If you've set everything up correctly, you should now have a list of all of your published posts in your console from your Ghost site. Switch over to your terminal and you will notice that the posts are logged there as well. This demonstrates that getStaticProps is run during the pre-render at build time.

Let's display these posts in a list so we can navigate to them. We've already destructured the posts in our Home component so all we have to do is use plain old React patterns to display. Remove everything but the heading inside of . I'll throw mine in an unordered list.

// pages/index.js
import Link from "next/link";
...
<main className={styles.main}>
  <h1 className={styles.title}>Posts</h1>
  <ul>
  {posts.map((post) => {
      return (
        <li key={post.slug}>
          <Link 
            href="/posts/[slug]" 
            as={`/posts/${post.slug}`}>
            <a>{post.title}</a>
          </Link>
        </li>
      );
    })}
  </ul>
</main>
...

Note we've also imported the Link component to take advantage of NextJS's routing. Onto the post pages.

You may have noticed the href and as in the Link component. As is a decorator on the Link and href is the actual link. Documentation

We need to create another async function to get a single post by its slug from our Ghost site. Head back over to lib/posts and add the following code.

// lib/posts.js
export async function getSinglePost(postSlug) {
  return await api.posts
    .read({
      slug: postSlug,
    })
    .catch((err) => {
      console.error(err);
    });
}

Remember, Next uses file-based routing so let's create a posts folder with a file called [slug].js in it. This is called a dynamic route in NextJS.

Next.js provides dynamic routes for pages that don’t have a fixed URL / slug. The name of the js file will be the variable, in this case the post slug, wrapped in square brackets – [slug].js.

Rendering a Single Post

// pages/posts/[slug].js

import { getSinglePost, getPosts } from "../../lib/posts";

export async function getStaticPaths() {
  const posts = await getPosts();

  const paths = posts.map((post) => ({
    params: { slug: post.slug },
  }));

  return { paths, fallback: false };
}

export async function getStaticProps(context) {
  const post = await getSinglePost(context.params.slug);

  if (!post) {
    return {
      notFound: true,
    };
  }

  return {
    props: { post },
  };
}

const PostPage = ({ post }) => {
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.html }} />
    </article>
  );
};

export default PostPage;

Walking you through it, we import our data fetching functions.

Next, we use getStaticPaths() to get the list of posts that match the given slug. Hint, should only be one.

Having matched the paths, we pass the matching paths into getStaticProps() via context so Next knows to render this post at build time.

Then we just render it like we would in any other React application. Simple, right? 😕

I've added some styling in the css. You can see the repo at https://github.com/csellis/headless-ghost-next.

It's all downhill from here.

Host it on a Serverless Platform

The easiest way to manage this is using Vercel's own hosting platform. Vercel owns NextJS so you get to take advantage of the tight integrations.

I like to use the Vercel CLI as I tend to throw up a lot of small projects. I'll let you follow their install instructions and we'll just go through uploading it to their domain.

Once you have the CLI setup and logged in, literally just type vercel and enter a bunch of times.

And you'll be greeted with an amazing deploy error. I'm so excited.

Following the link, you'll discover we're missing the environment variables we have in our .env.local file. Since we're going all CLI here, let's take advantage of the vercel env part of it.

➜  yourdomain.com git:(main) vercel env add
Vercel CLI 21.3.3
? Which type of Environment Variable do you want to add? Plaintext
? What’s the name of the variable? API_KEY
? What’s the value of API_KEY? f77b5e81e07899d45850bbf248
? Add API_KEY to which Environments (select multiple)? Production, Preview, Development
✅  Added Environment Variable API_KEY to Project yourdomain-com [592ms]
Adding API_KEY

Do the same for both BLOG_URL and API_KEY.

This time to redeploy we need to run vercel --prod. Et voilà !

Check it out https://yourdomain-com.vercel.app/

We've successfully uploaded our Headless Ghost site with NextJS to Vercel. Now you can test the site out before making a full switch to Headless Ghost.

Next steps

From here you have several options. What I chose to do was host this site on a subdomain while I was working on it over several weekends. You could still visit chrisellis.dev and get to Genuine GhostJS experience.

When I was happy with the Headless site, I swapped the subdomains around. Reach out to me if you'd like to read about that experience.

If you want to get more of these posts as soon as they come out, check out chrisellis.dev.

Code under pressure

Chris Ellis — Sun, 01 Nov 2020 10:05:06 +0000

Don't do it.

But the servers are literally on fire.

No, seriously. Don't do it.

But I have to.

You're going to regret it. Don't do it.

But the C levels are yelling. My job/reputation/company is on the line.

OK.

Yell back

For the purposes of this post, we're going to assume you aren't under pressure from your own doing. You have done everything you could possibly do to avoid this circumstance.

Yell back. If you're client or company is yelling at you about this dumpster fire. Yell back, strategically. And keep it civil.

Yell strategically. They need to fully understand that coding in these situations is prone to error and is dangerous. This should buy you some sympathy, but you know.

If you have a good idea of what went wrong here, briefly say so. You aren't looking for an argument here, you are planting seeds for what you'll talk about in the retrospective. You will have a retrospective.

Keep it civil. Don't yell like an emotional 4 year old. Yell like an adult and calmly. Heightening the emotion of this situation won't make it any better and could make you less effective.

Dispassionately say what went wrong without assigning blame.

Through a series of unfortunate events, we've ended up down to the wire. I needed the guest list yesterday. Let's fix this if we can.

We’re Lost, But We’re Making Good Time

Hands off keyboard.

Don't build when you don't know what you're building. Talk to the stakeholders.

After you've established that this situation sucks, you need to make sure you're not lost. (That title/quote was Yogi Berra)

Talk to the stakeholders. Ideally you have a high fidelity talk with them. This at least means a phone call. Even better would be a video call. Even better would be a video call with a screen share.

Here's why. Text can be misunderstood. It can be misinterpreted. It can be completely omitted. There's not enough time for a back and forth now.

The video and audio help capture tones and expressions. So when they stress something, you catch it.

Know what you're building. This should be reducible to an ordered bulleted list. While talking to the stakeholder, have them rank the list.

OK, in this order we need to:

Change the speaker's image

Add the 25 guests

Remove the subtitle

Yes, but add the guests first

Cut Scope

Let's face it. You might not get all this done in time.

If you have a little bit of time left, how about start writing your own bucket list

Photo by Glenn Carstens-Peters / Unsplash

That's why we had the stakeholder rank the list.

Prepare them. Tell them you will do your best to get these done, but the last few items may not be completed.

I'm going to be heads down coding. I will ping you with each item I get done and I need you to verify promptly. Anything else before I get started?

Head's down

You probably have an idea of what works to make you most productive. Get all of that ready to start.

Take care of yourself. Are you hungry? Do you need the bathroom? Are you comfortable? These will pull at your attention and focus, take care of these.

Take a breath. Before you start, close your eyes, take a deep breath in, hold, and exhale. Repeat n number of times until your focus is 💯.

Pair if possible. If you aren't soloing this dungeon, have someone pair with you. Extreme Programming had it right with code quality and this is an extreme situation.

Code your face off. With each item ask, what's the quickest way I can do this that's acceptable. Don't introduce security flaws, but also don't test in triplicate.

Check for spelling. You're not done. Check your spelling and don't put curse words in your console. Just say them audibly to get them out of your psyche.

Ping the stakeholder. It's on them. They're your QA now. Move on to the next item. If they ping back, don't check it until you're done with what you're working on.

The Retrospective

Hopefully, this isn't your first rodeo. Hopefully, it's not your client or C-level's. Also, hopefully, you made it through.

Be available during the crucial time. If you made it through, the stakeholder will be pleased. If you didn't, you may be called to the front of the class.

Though it feels like it in the moment, these aren't often as crucial as they seem. Most of the time people have an idea of what they want, but their users have no preconceived notions.

We do want to avoid these circumstances in the future though. That's why it's vitally important to have a retrospective with the stakeholders.

Congratulate and commiserate. They're feeling pressure too. Empathy for them can go a long way for future projects. Keep it positive and avoid the blame game. Use objective language, look for points where you could have communicated what you needed sooner, talk about sign offs, and look to the future.

Training the stakeholder. If you've been working in software for a while, you're familiar with how long things take and what rabbit holes can come up. Your stakeholder isn't.

They need to recognize we're working with complex information and need time to develop it. There are millions of configurations that are wrong and a much smaller set that are right.