Recently while browsing through one of our projects I found some atrocious piece of code I wrote a few months back. As ugly as it looks I think it can serve as a decent example of how much you can progress in a short time, even as a ‘copywriter-turned-not-really-a-dev’ like myself, and also how much you can do wrong in just one simple component.

While the code here serves as an example for the sake of the blogpost, it is an actual piece of my code from one of our websites. It's a simple component with four tiles with an image, some text and icons that illustrate the features of one of our applications. In case you're wondering why fixing it matters, I can tell you that if there's one thing that impacts SEO - it's poorly written code. It can worsen performance causing our website to work too slow and incur something Google calls Cumulative Layout Shift. It's basically a measurement of how much crawlers see your website's layout change as components or elements are loading in, which may happen if your code is bloated. Google considers that bad for user experience and can penalize your website's positioning for it. Aside from that obviously fixing bad code just for the sake of it is reason enough (especially if you don't want to get yelled at during code review). So here's the code for the component:

```ts
import { useTranslation } from 'next-i18next';
import { AutomationIcon, FastIcon, ProcessorIcon, AccurateIcon } from '@/assets';

export const FeaturesSection = () => {
    const { t } = useTranslation('landing');
    return (
        <FeatureSectionWrapper>
            <FeatureText>
                <h2 className="header" dangerouslySetInnerHTML={{ __html: t('features.header') }} />
                <div className="desc">{t('features.description')}</div>
                <ul>
                    <li>
                        <div>
                            <AccurateIcon />
                            {t('features.features.accurate')}
                        </div>
                        <p>{t('features.features.accurateText')}</p>
                    </li>
                    <li>
                        <div>
                            <FastIcon />
                            {t('features.features.fast')}
                        </div>
                        <p>{t('features.features.fastText')}</p>
                    </li>
                    <li>
                        <div>
                            <ProcessorIcon />
                            {t('features.features.ai')}
                        </div>
                        <p>{t('features.features.aiText')}</p>
                    </li>
                    <li>
                        <div>
                            <AutomationIcon />
                            {t('features.features.automated')}
                        </div>
                        <p>{t('features.features.automatedText')}</p>
                    </li>
                </ul>
            </FeatureText>
            <FeatureImg
                src="/images/results.png"
                alt="feature image"
            />
        </FeatureSectionWrapper>
    );
};
```

As you can see even though I had some basic understanding of html and the useTranslation hook, but I made a mess of it because I didn't do any mapping and just wrote out every segment of the component as a list item. The component is rather simple, it has two columns - one is an image and the other has a header, description and four smaller tiles with titles, descriptions and icons. First we need to properly map the translated text and for that we have to restructure the json file with the translations:

```json
"featuresSection": {
		"header": "lorem ipsum header",
		"description": "lorem ipsum desc",
		"features": {
			"fast": {
				"name": "Fast",
				"text": "lorem ipsum dolor",
				"icon": "FastIcon"
			},
			"accurate": {
				"name": "Accurate",
				"text": "lorem ipsum dolor",
				"icon": "AccurateIcon"
			},
			"ai": {
				"name": "AI powered",
				"text": "lorem ipsum dolor",
				"icon": "ProcessorIcon"
			},
			"automated": {
				"name": "Fully automated",
				"text": "lorem ipsum dolor",
				"icon": "AutomationIcon"
			}
		}
	},
```

Now that we have everything neatly organized in our json files it's time to map it using the i18next useTranslation hook. Lets use a const for the section of the landing json file we're using so that we can then access it via just curly braces like in the h2 and desc div here:

```ts
import { useTranslation } from 'next-i18next';

const { t } = useTranslation('landing');
const featSection = t('featuresSection');
<h2 className="header" dangerouslySetInnerHTML={{ __html: featSection.header }} />
<div className="desc">{featSection.description}</div>
```

Alternatively you can use the built-in i18next attribute `KeyPrefix`. I think this works the same way regardless (unless there's some key difference I’m unaware of) but I just like using the const as that way I can access every translation string by just calling the const name in curly braces `{featSection.whatever}` instead of doing `{t(‘whatever’)}` but that’s just personal preference and you can do it like this as well:

```ts
const { t } = useTranslation('landing', {keyPrefix: 'featuresSection'});
<h2 className="header" dangerouslySetInnerHTML={{ __html: t('header') }} />
<div className="desc">{t('description')}</div>
```

With that done let's change the html code for the list items. We can simplify it since all the list items are structured the same way:

```ts
<li key={key}>
  <div>
    <IconComponent />
    {name}
  </div>
  <p>{text}</p>
</li>
```

Now for the whole list we still need to map these elements, at first I went with this:

```ts
const iconComponents = {
        AutomationIcon,
        FastIcon,
        ProcessorIcon,
        AccurateIcon,
};
<ul>
    {Object.keys(featSection.features).map((key) => {
        const { icon, name, text } =
            featSection.features[key as keyof typeof featSection.features]; const
                IconComponent = iconComponents[icon as keyof typeof iconComponents];
        return (
            <li key="{key}">
                <div>
                    <IconComponent />
                    {name}
                </div>
                <p>{text}</p>
            </li>
        );
    })}
</ul>
```

While that worked it required an extra const and a somewhat hacky workaround for a TypeScript type error via `key as keyof typeof featSection.features`. We can definitely do better! In general there’s three methods of mapping objects: keys, values and entries (which contain both keys and values). As you can see at first I went with keys, but using values makes more sense since that way TypeScript can infer the type values and we can just use idx which will also let it identify the key values. That approach lets us get rid of the const and simplify the code again:

```ts
const iconComponents = {
        AutomationIcon,
        FastIcon,
        ProcessorIcon,
        AccurateIcon,
};
<ul>
    {Object.values(featSection.features).map(({ icon, name, text }, idx) => {
        const IconComponent = iconComponents[icon as keyof typeof iconComponents];
        return (
            <li key={idx}>
                <div>
                    <IconComponent />
                    {name}
                </div>
                <p>{text}</p>
            </li>
        );
    })}
</ul>
```

That's nice and simple but as you can see I'm still defining the icon types and values via an extra const and the hacky `as keyof typeof` workaround. To get rid of that we can use React's dynamic imports. Since the json file already defines what icon should be in each component we can use that to import the icons dynamically. So now instead of using `import { AutomationIcon, FastIcon, ProcessorIcon, AccurateIcon } from '@/assets';` we can use this:

```ts
import * as Icons from '@/assets';
<ul>
    {Object.values(featSection.features).map(({ icon, name, text }, idx) => {
        return (
            <li key={idx}>
                <div>
                    {Icons[icon as keyof typeof Icons]()}
                    {name}
                </div>
                <p>{text}</p>
            </li>
        );
    })}
</ul>
```

Now we can even use different icons for different language versions if we want to, by simply specifying their names in that language json file. Let's look at the whole component:

```ts
import { useTranslation } from 'next-i18next';
import * as Icons from '@/assets';

export const FeaturesSection = () => {
    const { t } = useTranslation('landing');
    return (
        <FeatureSectionWrapper>
            <FeatureText>
                <h2 className="header" dangerouslySetInnerHTML={{ __html: t('features.header') }} />
                <div className="desc">{t('features.description')}</div>
                <ul>
                    {Object.values(featSection.features).map(({ icon, name, text }, idx) => {
                        return (
                            <li key={idx}>
                                <div>
                                    {Icons[icon as keyof typeof Icons]()}
                                    {name}
                                </div>
                                <p>{text}</p>
                            </li>
                        );
                    })}
                </ul>
            </FeatureText>
            <FeatureImg
                src="/images/results.png"
                alt="feature image"
            />
        </FeatureSectionWrapper>
    );
};
```

That's a lot cleaner and less painful to look at, and it only took a couple simple changes. Obviously it's a reach to call this a refactor or really anything but a small fix, but going over earlier mistakes makes things easier to remember (at least for me). It's also a small step towards writing cleaner and simpler code which is a good thing to keep in mind. It's also the best route to take especially in regards to SEO where better safe than sorry is the only correct approach. You can be sure that it's a whole lot easier than figuring out which piece of code on your website is causing the dreaded layout shifts Google has flagged you for.

I18next translations inside maps & React dynamic import

So far so good, in part one we managed to do a very basic setup of a blog website sticking to just markdown and html (with a little bit of Nunjucks admittedly). If that's all you wanted from [Eleventy](https://www.11ty.dev/) then you're good to go and you'll find a lot of possible improvements and additions if needed. If you wanted to build a more complex website, well... this is where things get a bit tougher as modern websites use components and for Eleventy those are a bit of a touchy subject.

## Components

Components are used almost universally now so it's hard to imagine web dev without them. At first glance everything looks really promising - not only does Eleventy support components but since it will compile them to static html and CSS we're getting a true server-side component system! While that sounds great in theory, sadly things aren't as simple as that. To get to know why first let's look at the numerous methods of creating components in Eleventy:

* Liquid Render/Include
* Nunjucks Include & Macro
* Eleventy Render Plugin
* Eleventy Vue Plugin (soon to be archived)
* Eleventy Shortcodes
* WebC Plugin (new!)

### Templating

We've done a bit of that already with collections and this approach follows the same logic. Since we already have our blog posts now we need a bit of navigation, let's add a go-back button for users, letting them return to the index page after they're done reading a post. For that we need a button component in our `_includes` folder which will have typical button props like label and URL.

```html
<a href="/">Go back</a>
```

Now we need to include it in our layout template:

```ts
{% include "button.html" %}
```

That works, but it isn't really fair, is it? We simply imported a static piece of html. If we want a real button component it should have props and to do that with Eleventy we need to use Nunjucks and create a button.njk component with those props:

```ts
<a href="{{ url }}">{{ label }}</a>
```

with that we can go to our template and specify what that url and label for the included button will be:

```ts
{% set url = "/" %}
{% set label = "Go Back" %}
{% include "button.njk" %}
```

### No thanks

So we managed to create the simplest button component with props. The downside is that not only is this very similar to React and importing components - it's also more boilerplate compared to something like a simple import statement and `<Button href="/">Go Back</Button>`. Just to hammer this point home, this button was the simplest example. Let's imagine some standard website component which will have not only a button but also localized text, which will vary depending on which language the user selects and styling which will vary if a different theme is selected.

Liquid includes/render works basically the same - you can include a global reusable component like `button.liquid` in your `_includes` folder and render it in a template or page as `{% render 'button' %}`. It does have additional options but since we're looking for simplicity and this method has already soured us on that, I won't be going over them in more detail here.

Similarly there's also an option of using Nunjucks Macros for larger components like a pricing card:

```ts
{% macro pricingCard(title, description, price) %}
  <div class="pricing-card">
    <h2>{{ title }}</h2>
    <p>{{ description }}</p>
    <span class="price">{{ price }}</span>
  </div>
{% endmacro %}
```

```ts
{% import "pricingCard.njk" as pricingCard %}

{% block content %}
  <div class="container">
    {{ pricingCard.pricingCard('Basic Plan', 'Includes essential features', '$1.99/month') }}
  </div>
{% endblock %}
```

The issue with all these methods is they are doing something similar to React, but in a more complicated way. What about conditional props which in React are as simple as a single `?`, well for those you'll have to do even more javascript boilerplate and use if/else conditions. It's pretty apparent that neither of these approaches fits our simplicity requirement, so that's 0-2 for Eleventy and let’s proceed to the others.

### Custom Template Shortcodes

The Render Plugin I mentioned before is a little addon which gives you two shortcodes for quick and easy use, so let’s go over shortcodes in general. You might be wondering why there’s a plugin with just two shortcodes when Eleventy supports them out of the box. The answer is very simple - adding them is even more of a hassle and even more boilerplate code.

Going back to our button example, let’s say we want to get closer to React and use something like:

```ts
{% button url = "/", label = "Go Back" %}
```

That is doable, but for that we need to tell Eleventy what this button is and this is done via a function in the main eleventy config file. I don't think I need to go over this step by step because a quick look at the code will tell you everything you need to know:

```ts
const fs = require('fs');
const path = require('path');
const nunjucks = require('nunjucks');

module.exports = (eleventyConfig) => {
  eleventyConfig.addNunjucksShortcode('button', (props) => {
    const filePath = path.join(__dirname, '_includes/button.njk');
    if (!fs.existsSync(filePath)) {
      return 'missing file';
    }
    const content = fs.readFileSync(filePath).toString();
    return nunjucks.renderString(content, { component: props });
  });
};
```

Holy boilerplate, this just looks terrible and remember this is all for **just one basic button component**. I guess I get the idea, but I shudder to think how that config file would look for some of our websites. Now I have seen some example of getting around that using functions to loop over a directory with components, but that's just digging a deeper hole with even more js code. Even if you make that work it's just another makeshift solution which will then run into the fact that most websites use nested components as organisms, atoms, sections etc. which you'll have to do even more clunky workarounds to handle. Once again we were looking for simplicity - and we arrived at the opposite end of the spectrum - tedious boilerplate code shoved into a bloated config file. I mean just compare the atrocity above with a simple export like this:

```ts
const Button = ({ href, children }) => {
  return <Button href={href}>{children}</Button>;
};
export default Button;
```

## Vue woes

So with that we're down to 0-4, not great to put it mildly. Eleventy has also cooperated with Vue on a specific Eleventy Vue Plugin. This approach had its benefits as it used Vue components out of the box rendering them to plain html providing you with a very nice base. The issue here is that after a while Eleventy ran into the [same problem I mentioned in the first blogpost](https://graphqleditor.com/blog/eleventy/) - maintenance. Maintaining a plugin like this requires cooperation on all the connected things and long story short that has broken down and the Eleventy Vue plugin is on its way to being archived after VUE shut it down on their end.

## WebC to the rescue?

Now being completely honest I'm probably a bit too harsh on Eleventy as it did its job as a SSG wonderfully as I outlined in the first post. It's just a bummer that we got into this roadblock with components and looking at the various methods has put me off trying it for even a simple landing page. Just to make it perfectly clear I'm not comparing Eleventy with React because I want it to be React - far from it! We were looking for something that isn't React and thats why wrapping components in boilerplate js code to get them to work kinda like React is missing the point entirely.

But thankfully from what I've read there's a light in the tunnel in the shape of a new WebC Plugin. I have to say I am a bit skeptical after going through the sad tale of the Vue plugin, but from what I've seen this looks a lot more promising. Which is great because Eleventy really is promising and solves a lot of the basic problems. All that's missing is some less hacky way to do components and it can be truly great. So thanks for reading and see you in part three where we look at the new WebC plugin and if that solves our component issues.

Eleventy components woes

> *if you prefer to watch a vid demo instead of reading* [just click here](https://youtu.be/0Y4tk7BMEaA)

***

### Looking for a springboard

For a while now we have seen data from both analytics and community feedback that [GraphQL Editor](https://graphqleditor.com/) has a pretty steep learning curve and a lot of users have trouble getting their projects off the ground. We've tried pretty much everything to remedy that:

* youtube tutorials
* detailed documentation with gifs
* step-by-step guides
* pop-up onboardings
* interactive in-app tutorials

While that has had positive effects it still didn't satisfy a lot of users who wanted to get going right away without following tutorials or guides. While brainstorming someone floated the idea of creating an example project that would give users some basic view of what they can do. This made a lot of sense, but why stop at a generic project when we can use AI to tailor it to what the user needs?

### AI-generated Docs

We actually were already working on utilizing Chat-GPT for generating documentation. While that will be a sweet feature (as nobody likes writing documentation) it's a bit more complicated and we're still working on it. That said, we have decided that giving new users a jumping-off point was a priority and more importantly a lot easier to implement. So while ai-generated docs are coming soon, we do have two new AI features to show off!

### AI-generated schema

From now on, when starting a new [GraphQL Editor](https://graphqleditor.com/) project you will notice a new field with some sparkles. This is where you can enter your prompt and the AI will then generate a schema for your project based on what you have entered. It can be anything - a food delivery app or a twitter clone and the AI should give you a nice base schema to play around with.

Here's what I got after typing 'schema for a twitter-like app':

```gql
type User {
  id: ID!
  username: String!
  email: String!
  password: String!
  createdAt: DateTime!
  followers: [User!]!
  following: [User!]!
  tweets: [Tweet!]!
}

type Tweet {
  id: ID!
  content: String!
  createdAt: DateTime!
  author: User!
  likes: [User!]!
  retweets: [User!]!
  replies: [Tweet!]!
}

type Query {
  getUser(id: ID!): User
  getTweet(id: ID!): Tweet
  searchUsers(query: String!): [User!]!
  searchTweets(query: String!): [Tweet!]!
}

type Mutation {
  createUser(username: String!, email: String!, password: String!): User!
  deleteUser(id: ID!): User!
  createTweet(content: String!): Tweet!
  deleteTweet(id: ID!): Tweet!
  likeTweet(tweetId: ID!): Tweet!
  retweetTweet(tweetId: ID!): Tweet!
  replyTweet(tweetId: ID!, content: String!): Tweet!
}

scalar DateTime

schema {
  query: Query
  mutation: Mutation
}
```

### Ai-powered fake backend

Additionally you can now go to the API section and test out your queries and mutations against a fake backend with AI-generated field values! The AI will provide mock responses automatically based on the information it can gather - so if your query is something like `getUsers` with fields of usernames and email addresses the mock backend will return faked responses for those fields with random names and emails and the same for anything from `listMovies` to `getListofPizzaToppings` and the like. We had used the popular FakerJS database for this for years but that had its limitations and more importantly, required the user to choose and click the type of value they wanted faked for each field. While handy that was only a small step from writing them in yourself in an array. Now all that happens automatically without requiring the user to do anything!

Here's the result I got for the `searchUsers` query:

```json
{
  "searchUsers": [
    {
      "createdAt": "Wed, 27 Sep 2023 18:42:23 GMT",
      "email": "Santos_Murray@yahoo.com",
      "username": "Chanel.Cummings"
    },
    {
      "createdAt": "Thu, 28 Sep 2023 07:48:07 GMT",
      "email": "Howard_Romaguera30@yahoo.com",
      "username": "Lexie.Langosh"
    },
    {
      "createdAt": "Wed, 27 Sep 2023 22:31:15 GMT",
      "email": "Ulices.Brown@yahoo.com",
      "username": "Johnathon_Krajcik"
    },
    {
      "createdAt": "Wed, 27 Sep 2023 20:31:03 GMT",
      "email": "Bart_Emmerich97@hotmail.com",
      "username": "Scot20"
    },
    {
      "createdAt": "Thu, 28 Sep 2023 00:13:46 GMT",
      "email": "Jaylin_Marvin@gmail.com",
      "username": "Loren.Harris65"
    },
    {
      "createdAt": "Wed, 27 Sep 2023 23:01:56 GMT",
      "email": "Rylan3@gmail.com",
      "username": "Alysson.Heaney88"
    },
    {
      "createdAt": "Wed, 27 Sep 2023 16:35:04 GMT",
      "email": "Angelo81@yahoo.com",
      "username": "Katheryn.Bednar0"
    },
    {
      "createdAt": "Thu, 28 Sep 2023 05:54:44 GMT",
      "email": "Nichole_Schamberger@yahoo.com",
      "username": "Lottie.Fay63"
    }
  ]
}
```

### For fun or as POC

As you can see it's very easy to play around with. Our main hope is that with this users (especially new ones) will have a way easier time getting acquainted with the basic possibilities of the tool. Obviously that's just one use, it can also be pretty handy to show proof of concept for an app showing both the overall structure and possible query and mutation results. It also serves as a nice starting point as you can easily edit all the fields the AI has created for you - changing the schema to whatever fits your needs. The whole process is so simple it requires only a few clicks without writing or even knowing any code - so even non-coders can easily do it and show their idea for an application!

AI-generated GraphQL Schema and Fake backend

GraphQL is a query language for APIs that resolves the common REST problem of over- & under-fetching data. It does that by allowing users to request only the exact data they need by specifying that in a single customizable query. Additionally it also provides easy introspection which lets users explore what query and data is available from the API. On top of that GraphQL does not care about API versioning at all - since users can tailor their query to get exactly what they want the API version doesn't even matter.

## Before we start

We're going to be using two GraphQL tools for this simple tutorial app:

- **GraphQL Editor**: a feature rich platform for all things GraphQL - from schema design and documentation to code generation and deployment. Simply put it's everything you need to build a robust GraphQL API.

- **Stucco.js**: a GraphQL backend runtime that makes it easy to develop and deploy GraphQL APIs. It relies on the Golang Stucco library and handles communication between our resolvers and the outside world.

Before we go ahead we need to do a bit of a set up - first make sure you have:

- an account on [GraphQL Editor website](https://app.graphqleditor.com/)
- node.js installed [Node.js](https://nodejs.org/en/download)
- install graphql-editor-cli as global library [gecli](https://github.com/graphql-editor/graphql-editor-cli)

If you're done let's begin!

## First things first

Go on [graphqleditor.com](https://graphqleditor.com/) log in and create your first workspace. Workspaces are groups of projects shared among any number of team members who you can easily follow and collaborate with. For now you can skip adding members since we wont be needing any help with our simple tutorial app. Remember that you can add them later at any point, and collaborating is what [GraphQL Editor](https://graphqleditor.com/) is all about!

The next step is creating our project, so click `new project`, name it something like `Hello-world-app` (or whatever else you prefer). Now that we have our project set up just copy the simple schema codeblock below and paste it into your code area.

```gql
type Query {
  helloworld: String!
}

schema {
  query: Query
}
```

The schema is the first step for every GraphQL project - it defines the types of data that your GraphQL API can return. Now that we have it defined we can go ahead and start developing our resolvers!

We're not going to waste time writing resolvers ourselves since we have installed the [GraphQL Editor](https://graphqleditor.com/) CLI library to handle that for us. We'll simply use these two commands to do all the work:

```bash
gecli create backend
gecli codegen resolve
```

The first command `gecli create backend` is used for setup. It will create the basic file structure for your backend (`node_modules`, `schema.graphql`, `tsconfig.json` etc) install packages, log in and fetch the schema from the GraphQL Editor project.

After that is done we need to run the second one `gecli codegen resolve` it will detect the query and create a resolver for it in .ts file format (ie. helloworld.ts).

The code in that file defines the resolver for our `helloworld` query which is simply a function that returns the data requested by the query and will look like this:

```ts
import { FieldResolveInput } from 'stucco-js';
import { resolverFor } from '../zeus/index.js';

export const handler = async (input: FieldResolveInput) =>
  resolverFor('Query', 'Helloworld', async (args) => {})(input.arguments);
```

We can now set up our return code, since we want it to actually respond with something. So for this let's add this snippet as our return argument:

```ts
return 'Hello World!';
```

Now to start the server, we need to run the following command in our terminal:

```bash
npm run start
```

Open your browser and type in `localhost:8080/graphql`, as you see - you just created your first backend application!

To test the resolver, enter the following query into the left-hand side panel:

```gql
{
  Helloworld
}
```

All that's left is to click the run icon, once we receive our message its obvious that everything works!

## Conclusion

In this short blogpost we've gone over creating a simple Hello World app with [GraphQL Editor](https://graphqleditor.com/) and Stucco.js. We also learned how to generate resolvers using the gecli command and how to test the resolvers using the GraphQL Editor website. Obviously this is just a very simple, basic app and you can do much bigger things with Stucco and GraphQL Editor (just check out our repos on git hub to see some examples). If you want to play around with this tutorial project check our it out on [Github](https://github.com/TakSeBiegam/Hello-world-stucco-app/) & [GraphQL Editor](https://app.graphqleditor.com/this-is-my-first-app/hello-world-app).

 GraphQL Hello World app with GraphQL Editor and Stucco.js

If you’ve worked with TypeScript, React or Next odds are you’ve encountered an update that broke a number of features on your page. When that happens you’re left wondering if there’s some simpler or older technology you could use that would just be less hassle. Well at least that’s what we were talking about at the office after the last Next update with translations.

## Back to the past

Thinking about simplicity the things that come to mind are languages like css, html or even markdown. Simple is one thing and stability is another, there's zero chance we’ll get a groundbreaking markdown update next year, which will break our projects. That’s why we looked at some frameworks that could work with something as simple as that, going in the complete opposite from our usual TS, Next & React stack. That’s how I stumbled upon [Eleventy](https://www.11ty.dev/), a versatile SSG which works with a number of file formats - among them Markdown which is exactly what we were looking for and as simple as it gets.

![11ty performance](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/11ty-speed-1732203672796.webp)

## Setting up a simple blog page

So the next question was could we actually create a page using only simple languages like markdown? The answer is Eleventy and it's really simple to use just like we wanted. Obviously you’ll need to npm install the run it and since we’re already on a blog page let's use that for our example.

First we’ll need a `index.html` page from which we will be able to access our content and a posts folder for our blogposts in markdown. We can add an example post in markdown and run localhost to see eleventy will automatically render it to html (neat and simple just like we wanted)

```json
├── posts
│   ├── my-first-post.md
│   ├── my-second-post.md
├── index.html
```

We'll also need to do some layout for our blog, this is by default kept in a `_includes` folder, but it's easy to rename it in the settings if you want to call it layouts or whatever.

```json
├── posts
│   ├── my-first-post.md
│   ├── my-second-post.md
├── _includes
│   ├── layout.html
├── index.html
```

To use the layout for our index page we need to include it in a front matter section at the top of the page like this:

```json
---
layout: layout.html
---
the content of our page
```

We also need to tell the layout file where the content will go and for that we use double curly braces, reminiscent of liquid or nunjucks (more on that later btw.)

```html
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>Our blog</title>
  </head>
  <body>
    <h1>Welcome to our blog</h1>
    <div>{{ content }}</div>
  </body>
</html>
```

Obviously our blogposts will also need a layout and Eleventy has a neat trick to do it for all of them with just one line. We simply need to go to our posts folder, create a json file with the matching name (ie. posts.json) and point it to our layout file.

```json
{ 'layout': 'layout.html' }
```

## Front Matter

The fact we're using a json file to import the layout into our blog pages doesn't mean we can't also use front matter there. For example we'll definitely want to use different titles for our posts so we need to add them to the front matter:

```json
---
title: the title of our post
cover: /images/FirstPostCover.png
---
```

and then import them in the layout

```html
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>{{ title | default: "Our blog"}}</title>
  </head>
  <body>
    <img src={{ cover | default: "/images/default.png"}} alt={{ title | default:
    "Our blog"}} />
    <h1>{{ title | default: "Welcome to our blog"}}</h1>
    <div>{{ content }}</div>
  </body>
</html>
```

This is best suited for simple SEO tags like titles, meta descriptions, open graph tags etc. which we can now make sure will use dynamic titles, descriptions or images that we will specify in the front matter. For other things we can use something called collections.

## Collections

Collections let us iterate over a group of files, like our posts. To do so we need to set a tag in that same json file we created and set a tag for them:

```json
{
    "layout": "layout.html"
    "tags": "post"
}

```

Now we can for example list our blogposts on our index page. To do so we need to iterate over the post collection in the data:

```ts
---
layout: layout.html
---
{% for post in collections.post %}
<h2>{{ post.data.title }}</h2>
{% endfor %}
```

If the syntax looks weird to you it's Liquid - or Nunjucks here specifically, a simple templating language used for static site generators. If you don't like it you can also achieve the same result using JavaScript as Eleventy does support that as well but it would kinda defeat the whole purpose of going away from React.

## Static Site Generator

That said with these few simple steps we can get our blog page running in no time at all, which is exactly what we were looking for - quick and easy! I should say it's hardly a surprise that a static site generator works well for generating a pretty straightforward static site. I might've painted a too rosy a picture with this simple overview so I promise I'll go over some of the downsides of Eleventy in part 2 (where we'll get into components!)

Making a simple Eleventy blog template

TypeScript 5.0 is here and it brings a lot of changes to performance, adds decorators, and among other things enums. Enums have been much maligned for a while now and the TypeScript team has been hard at work to improve them, first with 2.0 which gave each enum member its type and then with 2.4 and the introduction of string enums. That signals that the typescript team knows that enums require a bit of work and they’re trying to improve them, so the question that remains is: are enums still bad?

*If you're already familiar with enums and just want to check out what's new -> head on over to the "What's new in 5.0" section down below*

## Enums 101

First of all, enums are a bit of a holdover from the early days of TypeScript. They’re not a native function of JavaScript, but they have been included as a bit of a nod to C#. While Anders Hejlsberg has stated he wouldn't have included enums if he could have a do-over, the team behind TypeScript is evidently trying to get them to work.

So before we get to the changes let's outline why enums are bad, or rather why a lot of developers don't like them. To start off let's just use basic numeric enums.

Let's say we have our typical enum with pokemon types

```ts
enum PkmnTypes {
  fire,
  grass,
  water,
}
```

Now if we console log this we’ll get 0, 1 and 2, this is because it complies to javascript like this:

```ts
var PkmnTypes;
(function (PkmnTypes) {
  PkmnTypes[(PkmnTypes['fire'] = 0)] = 'fire';
  PkmnTypes[(PkmnTypes['grass'] = 1)] = 'grass';
  PkmnTypes[(PkmnTypes['water'] = 2)] = 'water';
})(PkmnTypes || (PkmnTypes = {}));
```

While that’s ugly as hell it still works. The issue is when someone adds another pokemon type into that enum (e.g. lightning for pikachu) alphabetically - right above WATER.

```ts
enum PkmnTypes {
  fire,
  grass,
  lightning,
  water,
}
```

Now we can console log it again to see that lightning is now 2 and water is now 3. This will most likely cause a lot of trouble.

Sure we can get around that by either adopting a policy of only appending values in enums or using exact declarations like this:

```ts
enum PkmnTypes {
  fire = 0,
  grass = 1,
  lightning = 3,
  water = 2,
}
```

Now the issue is if we console log this we get all the keys and values, and that's because it complies to JavaScript as mentioned above.

```ts
console.log(Object.values(PkmnTypes))

[LOG]: ["fire", "grass", "water", "lightning", 0, 1, 3, 2]
```

```ts
console.log(PkmnTypes)

[LOG]: {
  "0": "fire",
  "1": "grass",
  "2": "water",
  "3": "lightning",
  "fire": 0,
  "grass": 1,
  "lightning": 3,
  "water": 2
}
```

There's also a weird interaction with functions. Let's say we want to assign our pokemon types, it will work as intended using both the number and the name of the type, the issue is that TypeScript allows **any number** here (even those outside the scope of the enum) without throwing errors, which makes it not type-safe at all.

```ts
function assignPkmnType(pkmntype: PkmnTypes): void {}

assignPkmnType(1);

assignPkmnType(PkmnTypes.fire);

assignPkmnType(999);
```

All of this can be avoided by using the aforementioned string enums:

```ts
enum PkmnTypes {
  fire = 'fire',
  grass = 'grass',
  lightning = 'lightning',
  water = 'water',
}
```

which complies to JavaScript as:

```ts
var PkmnTypes;
(function (PkmnTypes) {
  PkmnTypes['fire'] = 'fire';
  PkmnTypes['grass'] = 'grass';
  PkmnTypes['lightning'] = 'lightning';
  PkmnTypes['water'] = 'water';
})(PkmnTypes || (PkmnTypes = {}));
```

And this while still ugly will work as expected if we console log it:

```ts
console.log(Object.values(PkmnTypes))
[LOG]: ["fire", "grass", "lightning", "water"]

console.log(PkmnTypes)
[LOG]: {
  "fire": "fire",
  "grass": "grass",
  "lightning": "lightning",
  "water": "water"
}
```

Three issues remain though:

* it’s still a lot of unnecessary js code
* it still doesn't prevent u from the other pitfalls of enums
* it makes more sense as a const at this point

The last point is really the obvious drawback here, if you were writing it from the start without thinking about an enum you'd probably just make something like this:

```ts
const PkmnTypes = {
  fire: 'fire',
  grass: 'grass',
  lightning: 'lightning',
  water: 'water',
};
```

all we need to do from there is to create a new type with the same name and copy over the values

```ts
const PkmnTypes = {
  fire: 'fire',
  grass: 'grass',
  lightning: 'lightning',
  water: 'water',
} as const;

type PkmnTypes = (typeof PkmnTypes)[keyof typeof PkmnTypes];
```

Now we can even use numbers in our object and call them in our function and get the expected result:

```ts
const PkmnTypes = {
  fire: 'fire',
  grass: 1,
  lightning: 'lightning',
  water: 'water',
} as const;

type PkmnTypes = (typeof PkmnTypes)[keyof typeof PkmnTypes];

function assignPkmnType(pkmntype: PkmnTypes): void {}

assignPkmnType(PkmnTypes.fire);
assignPkmnType(1);
```

Essentially we're getting everything we would from an enum, without the drawbacks of actually using an enum. Yes, you can use a `const enum`, but that opens another can of worms on its own and is strongly discouraged by TypeScripts documentation itself.

## What's new in 5.0?

So back to the initial question - are enums still bad in 5.0? The new addition is that all enums are now union enums which means TS will now create a unique type for each computed member, regardless of what type of enum it is. What does that mean? That they are now typesafe and you can't just add any number in without getting an error, like in the example mentioned above:

```ts
enum PkmnTypes {
  fire,
  grass,
  lightning,
  water,
}
function assignPkmnType(pkmntype: PkmnTypes): void {}

assignPkmnType(1);

assignPkmnType(PkmnTypes.fire);

assignPkmnType(999);
```

The last line will now throw the following error: `Argument of type '999' is not assignable to parameter of type 'PkmnType'.`

While that’s a big step in the right direction it still leaves the other problems, and even when those get fixed the key issue of ‘why not just use a const’ will remain for those who find them entirely redundant. Regardless those who like using enums will likely really appreciate this fix.

## Unions & how to avoid using enums

While we're on the subject of unions, there's another object in TypeScript that makes much more sense to use than an enum, namely a union type.

```ts
type PkmnTypes = 'fire' | 'grass' | 'lighting' | 'water';
```

And because it's all types it compiles to JavaScript as completely nothing, saving us the trouble with the bloated enum compiles mentioned above. We cant access these values though so if we want to do that we just simply need to remake it as a const:

```ts
const PkmnTypes = ['fire', 'grass', 'lightning', 'water'] as const;

type PkmnType = (typeof PkmnTypes)[number];

type Pkmn = {
  pkmnType: PkmnType;
};

const Charizard: Pkmn = {
  pkmnType: 'fire',
};
```

That's it and we can now iterate over the values however we want, by just throwing them in a list. So in short: if you don't need access to the values in your enum just use a union type, if you do just get them into a list in a const and you can do whatever you need from there, without ever bothering with enums at all.

To sum up 5.0 for enums: if for whatever reason you like using them 5.0 is an upgrade in that regard and if you don't you can ignore them altogether just like you did before. There doesn't seem to be any specific benefit to using them (that I know of) so for those that are either starting out with TypeScript or those that are experienced users that don't bother with enums this will hardly be enticing enough to start using them now.

TypeScript enums in 5.0 (are they still bad?)

# React Native monorepo with shared components & TypeScript

To start we should ask a simple question: why should I use a monorepo for React Native apps? It's actually very useful when you have two (or more) similar applications. Monorepos enable sharing of components, functions and logic between all of the included applications. This can unlock a variety of benefits like core sharing, simplified ci/cd process and consistent tooling.

### Setting up workspaces with Yarn

When creating a monorepo for react native applications, it is better to avoid using nohoist because we don't need duplicates inside the root level and inside the project level `node_modules`.

### Project structure

Our projects need to be divided into subfolders. We treat them as separate entities. Here’s an example of how our project structure can look like:

![Project structure](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor1-1733901838493.png)

### Creating a package.json file in the root directory

1. open your terminal and go to the root directory `cd my-app`,
2. create a package.json file with `yarn init -y`,
3. open and check your package.json file. It should look something like this:

![package.json file](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor2-1733901910541.png)

* Private: true is required. That's very important because we don't want to make our workspaces public.
* Name: the name of your monorepo.
* Workspaces: our workspace with the projects structured in a tree. For now, it's okay as is.

### Creating React Native projects

To create React Native projects we can use the following commands:

```bash
cd packages
npx react-native init FirstApp --directory app1 --template react-native-template-typescript
npx react-native init SecondApp --directory app2 --template react-native-template-typescript
```

If your app names and directories match you can use this instead:

```bash
cd packages
npx react-native init app1 --template react-native-template-typescript
npx react-native init app2 --template react-native-template-typescript
```

where `app1` and `app2` are the names of both our apps and their directories.

Most likely your apps have now been created but pods will not install. No worries, we’ll fix this in the next step:

### IOS configuration

1. Open `Podfile` go into your app and change paths to the `node_modules`

![Node modules paths](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor3-1733901985977.png)

1. Open your terminal and install pods. If you are in the packages/app\* folder run:

```bash
	cd ios
	pod install
```

1. Open XCode and your project, select the Project navigator and click on the name of your project. This will open project settings.

![XCode](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/screen1-1730846450836.webp)

1. Click `Build Phases`, open `Bundle React Native code and images` and change the script paths:

![script paths](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor4-1733901994852.png)

![XCode](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/screen2-1730846453820.webp)

**!Remember to repeat this for each app in your monorepo!**

### Android setup

**For React Native below 0.71**

1. Open your `build.gradle` file and change the paths to `node_modules`

![build file](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor5-1733902003511.png)

1. Open your `settings.gradle` file and change the paths to `node_modules`

![settings file](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor6-1733902010604.png)

1. Open your `build.gradle` and override the default location of the cli

![cli path](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor7-1733902017735.png)

In the same file change these lines:

![react paths](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor8-1733903068544.png)

![react paths](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor9-1733903078072.png)

**For React Native above 0.71**

1. Go to your `build.gradle` file
2. Find and edit the following:

![hermesc](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor10-1733903086173.png)

1. then add the codegen directory path

![codegen dir](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor11-1733903092880.png)

1. and this:

![build path](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor12-1733903099962.png)

**!Remember to repeat this for every app in your monorepo!**

### Android setup

**For React Native below 0.71**

1. Open your `build.gradle` file and change the paths to `node_modules`

![node modules paths](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor13-1733903126778.png)

1. Open your `settings.gradle` file and change the paths to `node_modules`

![node modules paths](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor14-1733903526209.png)

1. Open your `build.gradle` file again and override the default location of the cli

![cli path](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor15-1733903532696.png)

In the same file change these lines:

![react paths](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor16-1733903539316.png)

![react paths](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor17-1733903546640.png)

**For React Native above 0.71**

1. Go to your `build.gradle` file
2. Find and edit the following:

![hermesc](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor18-1733903554152.png)

1. then add this

![build paths](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor19-1733903567091.png)

1. and this

![build paths](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor20-1733903573867.png)

**!Remember to repeat this for every app in your monorepo!**

### Metro configuration

Now we should indicate for metro where `node_modules` are located. Go to the `metro.config.js` file and add `watchFolders`:

![metro config](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor21-1733904224011.png)

### Shared package

Inside the shared folder, create a `package.json` file.

```bash
	cd shared
	yarn init -y
```

Your `package.json` file should look something like this:

![package json](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor22-1733904230203.png)

Close your `package.json` and now let's create a `tsconfig.json` file:

![ts config](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor23-1733904236292.png)

Now go into your shared folder, and create an src folder there. Its structure should look something like mine:

![structure](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor24-1733904242714.png)

Where `Test.tsx` is a React Function component :)

Now, we can export this via `index.ts` in a `shared` folder.

Now let's create a build of our `shared` directory:

```bash
yarn build
```

With that, we have finished setting up our `shared` folder. Now we should indicate this directory to our applications. So now we need to add our `shared` dependency to the `package.json` file in all our applications:

![dependency](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor25-1733904248620.png)

and for `metro.config.js`:

![metro config](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/monor26-1733904254436.png)

Then go back into your root directory and run:

`yarn`

Now we should be able to import things from `shared` directly into our React Native Apps:

```ts
import React, { type PropsWithChildren } from 'react';
import {
  SafeAreaView,
  ScrollView,
  StatusBar,
  StyleSheet,
  Text,
  useColorScheme,
  View,
} from 'react-native';

import {
  Colors,
  DebugInstructions,
  Header,
  LearnMoreLinks,
  ReloadInstructions,
} from 'Libraries';

import { Test } from '@my-app';

const Section: React.FC<
  PropsWithChildren<{
    title: string;
  }>
> = ({ children, title }) => {
  const isDarkMode = useColorScheme() === 'light';
  return (
    <View style={styles.sectionContainer}>
      <Text
        style={[
          styles.sectionTitle,
          {
            color: isDarkMode ? Colors.white : Colors.black,
          },
        ]}>
        {title}
      </Text>
      <Text
        style={[
          styles.sectionDescription,
          {
            color: isDarkMode ? Colors.light : Colors.dark,
          },
        ]}>
        {children}
      </Text>
    </View>
  );
};

const App = () => {
  const isDarkMode = useColorScheme() === 'dark';

  const backgroundStyle = {
    backgroundColor: !isDarkMode ? Colors.darker : Colors.lighter,
  };

  return (
    <SafeAreaView style={backgroundStyle}>
      <StatusBar
        barStyle={!isDarkMode ? 'light-content' : 'dark-content'}
        backgroundColor={backgroundStyle.backgroundColor}
      />
      <ScrollView
        contentInsetAdjustmentBehavior="automatic"
        style={backgroundStyle}>
        <Header />
        <Test />
        <View
          style={{
            backgroundColor: !isDarkMode ? Colors.black : Colors.white,
          }}>
          <Section title="Step One">
            Edit <Text style={styles.highlight}>App.tsx</Text> to change this
            screen and then come back to see your edits.
          </Section>
          <Section title="See Your Changes">
            <ReloadInstructions />
          </Section>
          <Section title="Debug">
            <DebugInstructions />
          </Section>
          <Section title="Learn More">
            Read the docs to discover what to do next:
          </Section>
          <LearnMoreLinks />
        </View>
      </ScrollView>
    </SafeAreaView>
  );
};

const styles = StyleSheet.create({
  sectionContainer: {
    marginTop: 32,
    paddingHorizontal: 24,
  },
  sectionTitle: {
    fontSize: 24,
    fontWeight: '600',
  },
  sectionDescription: {
    marginTop: 8,
    fontSize: 18,
    fontWeight: '400',
  },
  highlight: {
    fontWeight: '700',
  },
});

export default App;
```

**And that’s how it works! Enjoy!**

React Native monorepo with shared components & TypeScript

While managing state in react isn't exactly a Sisyphean task it can certainly become one if the right tools aren't used. The more complex the application the more complex and time-consuming state management can get, with often-seen issues like passing down data to nested props (or prop-drilling), state inconsistencies and in turn issues with performance and code. That’s why there are a number of handy tools that can help make react state management much easier.

## Why stick with Redux?

While many devs are still stuck with Redux various other tools offer numerous advantages over it. It's little wonder why React state managers seem to pop up so often as Redux isn’t held in high regard in the community (to put it very mildly) and most are on the lookout for an alternative. Redux requires a fair amount of boilerplate code, is often unnecessarily verbose even for simple actions and brings a lot of complexity which is usually overkill for smaller applications.

## A simple alternative

One such alternative is Zustand a minimalistic state manager from the same developers who made Jotai. the name is simply state in german and just as it implies simplicity is the main approach. It focuses on using hooks to manage state and minimize boilerplate code. The emphasis is on being simpler and quicker to use than Redux or other state managers. It's strong points are pretty appealing:

- way less boilerplate code (being faster to write should appeal to everyone)
- no time wasted on writing Context Providers (shorter & simpler code)
- renders components only when changes happen to the value of the state

What is easily evident from that is that its main aim is simplifying the things that are overly complicated with Redux. That's not all as it also boasts important fixes to:

- the zombie child problem (a common issue when a component is unmounted, but some of its children are not properly cleaned up - leading to memory leaks and potential errors)
- react concurrency (Zustand supports React Concurrency and is perfect for use with that feature due to its immutable state updates which ensure that state updates are predictable and consistent)
- context loss between mixed renderers (a problem that can occur in React when multiple rendering systems or libraries are used and cause errors due to different contexts)

Zustand's docs boast it may be the only state managers to get all of these right and from what I could find that just may be the case.

## Installation & usage

Well if you're sold on at least trying out Zustand here the gist of how you get to actually use it. In line with its simplicity-first approach it's really straightforward:

```ts
# NPM
npm install zustand

# Yarn
yarn add zustand
```

after installing this is how we import the `createStore` function from Zustand:

```ts
import { createStore } from 'zustand';
```

and then use the `createStore` function to create a new store (in this case a simple function which returns an object representing the initial state of our store):

```ts
const store = createStore(() => ({
  count: 0,
}));
```

Then we define actions that update the state of our store. For this example let's use the standard incremental counter example:

```ts
const incrementCount = () => store.set((state) => ({ count: state.count + 1 }));

const decrementCount = () => store.set((state) => ({ count: state.count - 1 }));
```

From there all we need is Zustand's `useStore` hook to access the state with our counter:

```ts
import { useStore } from 'zustand';

function Counter() {
  const count = useStore((state) => state.count);
  const increment = useStore((state) => state.incrementCount);
  const decrement = useStore((state) => state.decrementCount);

  return (
    <div>
      <h1>{count}</h1>
      <button onClick={increment}>Increment</button>
      <button onClick={decrement}>Decrement</button>
    </div>
  );
}
```

## Bear necessities

In any case, shorter writing time and simpler state management should be enough of a draw for anyone to want to try it out. You don't have to instantly fall in love with Zustand, but even testing it out should make its simplicity and ease of use shine especially compared to more complex state managers. If anything the main gripe with state managers is not that there are too few of them (quite the opposite in fact). Rather it's the fact that most devs are reluctant to let go of Redux and get on board with anything new due to being afraid it won't get enough steam and will get deprecated in half a year. With Zustand there’s no fear of that happening any time soon as it's being actively developed and maintained with version 4.3.3 coming about barely a couple of weeks ago. So don't be afraid to check it out as well and it just might turn out to be what you were looking for.

Check it out at GithHub: https://github.com/pmndrs/zustand


Zustand - react state management made easy

As 2022 drew to a close, and the distant stars of a million AI generated skies were everywhere you looked on your Galaxy Fold, I was doing some consulting for Stability.ai, helping with ideas for how to publish APIs around generative text to image models. While thinking about how researchers prototype their work, I realised that [GraphQL](https://graphql.org/learn/) was the perfect tool for quickly prototyping and sharing models.

The Python package inspired by these conversations, created with Chris Bishop and now called FastQL allows you to easily prototype and share models like Stable Diffusion, Midjourney or RunwayML in seconds. FastQL can be used to serve up any model or Python function and thanks to it’s use of Rust under the hood and the powerful Actix web framework, FastQL is lightning fast and keeps your API separate from your model code.

> “FastQL allows you to easily prototype and share models like Stable Diffusion, Midjourney or RunwayML in seconds”

FastQL is incredibly simple to use. We’ve included simple steps and Docker files that allow you to quickly spin up example Hugging face diffusion models and start running them on AWS in minutes. We even included a fun prototype that allows you to fine tune Hugging Face diffusers models on your own GDrive photo uploads. You can find the FastQL package on pypi with code and resources on [Github](https://github.com/happy-machine/FastQL). Go ahead and install FastQL with

```bash
pip install fastqlapi.
```

This is how simple it is to spin up a blazing fast GraphQL API around your model…

```ts
from fastqlapi import fastql_server

def my_callback(**kwargs):
  input = kwargs[‘input’]
  # do some transformation to your input params
return {‘output’: [f”https://s3.amazonaws.com/fastql/{input}”]}

fastql_server.start(
  callback=my_callback,
  query_name="Model",
  args={"input": { "type": "String!", "description": "This is my input param"}},
  fields={"output": { "type": "[String]", "description": "An array of image links"}
 })
```

First define your schema as a Python dictionary, give your GraphQL query a name and pass:
`fastql_server.start` a callback to call when a GraphQL request arrives. Then pull out your defined arguments from the request, work your magic on them and finally return a dict containing the fields you’ve made available for the response.

When you run your code, a GraphQL server matching your schema definition will spin up automatically in a separate process.

Configuration for the API server is all environment variables. In development a [[GraphQL Playground](/graphql-playground) UI](https://www.apollographql.com/docs/apollo-server/v2/testing/graphql-playground/) will be served up at localhost:8000/graphql for you to test your model.

![djfreshblog2.webp](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/djfreshblog2.webp)

If you haven’t tried GraphQL yet, you are seriously missing out! Originally created by Facebook, GraphQL’s popularity has been exploding with it being involved in 22.7% of application integrations. According to the last [dZone survey](https://dzone.com/trendreports/enterprise-application-integration) in 2020 usage of GraphQL had skyrocketed from its inception in 2018 to over 47% and in 2022 Apollo GraphQL was among the top 500 [fastest growing tech companies](https://dzone.com/trendreports/enterprise-application-integration). GraphQL is used in production by Meta, Airbnb, Adobe, Netflix, Twitter, Paypal, Github and over 2000 other large enterprise companies.

![djfreshblog3.webp](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/djfreshblog3.webp)

> “In our benchmarks FastQL performance was nearly twice as fast as an Ariadne and FastAPI implementation with the same schema.”

Along with the many benefits of GraphQL such as the incredible developer experience and tools like [GraphQL playground](/graphql-playground), [Hasura](https://hasura.io/) and with auto-documentation out of the box. FastQL also works really well with [Apollo Federation](https://www.apollographql.com/docs/federation/), enabling you to mix fixed and dynamic schemas to publish a federated API, aggregating multiple models into a single supergraph that is secure, simple to version and easy to extend.

The performance of Actix which is currently TechEmpower’s no.5 overall fastest web framework improves on the speed of native Python implementations and in our benchmarks FastQL performance was nearly twice as fast as an Ariadne and FastAPI implementation with the same schema, achieving sub 20ms response times according to Apollo tracing (available to activate by env variable in FastQL).

**This is just the beginning…**

![djfreshblog4.webp](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/djfreshblog4.webp)

**This is a passion project, we’d love your help! Message me on Twitter @djfreshuk if you want to get involved** ❤️

*Thanks to the folks at Huggingface, ActiX,* [Sunli@Async-Graphql.rs](https://github.com/async-graphql/async-graphql)*, the folks at* [Maturin](https://github.com/PyO3/maturin) *and Nin, Danjo & everybody from the* [Stable Diffusion community](https://discord.com/invite/stablediffusion) *for their help, libraries and inspiration!*

Python models in GraphQL with Rust backend in 1 line of code

The adoption rate for GraphQL keeps growing and a lot of big players like PayPal, Twitter, medium, Docker, GitHub or Shopify have gotten on board in recent years. If we’re going by google trends the interest has also been higher in 2022 than at any point before. In 2023 we can expect a large amount of major web applications to be running GraphQL in some capacity, as well as a continued steady rise in its popularity in both the open source and corporate environment. The industry will likely be buzzing with news on the latest tools, libraries and solutions to make working with GraphQL more secure and even more efficient. We’re also likely to see some new uses of GraphQL especially in regards to mobile development and real-time collaborations. GraphQL will become the go-to solution for many developers and businesses, especially with the continued popularization of no-code solutions. Obviously both those convinced it is the next best thing and those skeptical need some way to actually try it out, so let's look at some of the noteworthy tools you can check out for that.

## [GraphiQL](/graphql-playground)

[GraphiQL](/graphql-playground) is a popular lightweight client that is probably the go to tool for trying out GraphQL. Its popularity stems from the fact it is readily available, all it requires is the browser and you’re ready to go. You can play around with GraphQL, schema, queries and mutations and see what it's all about, before you decide if you want to use it professionally. It has recently gotten a 2.0.0 release and has a number of useful features like real time syntax and error highlighting, auto-complete for code and a history of used queries. The overall learning experience is also helped immensely by the documentation snipped feature which provides useful tooltips with documentation explaining the type, or string you just entered. The main drawback is that while it's a great tool for learning you will almost certainly move to some other [GraphQL IDE](/graphql ide) should you decide on actually working with it.

## Apollo Studio Explorer

Apollo is not really just a tool, it's more like a full stack with Apollo Client, Apollo Server or even the entire Supergraph. While both Apollo Server and Apollo Client are some of the most widely known and used developer tools, and that’s just as true for GraphQL as well, the dedicated [GraphQL IDE](/graphql ide) is Apollo Studio. It has a number of useful features like click out queries, hints, and a variety of searching, filtering and sorting options. Obviously it is also integrated with other elements of the Apollo ecosystem which usually means that whatever you want to do, Apollo likely has you covered with some of their tools. It's little wonder why it became the industry standard as the jack of all trades, which is definitely great especially for beginners. While Apollo has been one of the early adopters of GraphQL a lot of competition has appeared over the years and you can see that in the fact that its user retention rate is not the highest because people are looking for alternatives. Additionally it has become a bit bloated over time, [currently it's almost 200 npm packages](https://www.npmjs.com/~apollo-bot). If you’re wondering if you need all that to set up a GraphQL API, the obvious answer is no. That's simply the issue with the industry standard, trying to be a tool for everyone means including a lot of solutions not everyone needs. In short, while it's likely that you’ll start your GraphQL journey with Apollo, as you get more experienced you’ll probably find other tools, which can offer improvements and are simply more fitting for what you’re looking to do.

## Insomnia

Insomnia is a really battle-tested API development platform, it has been the preferred tool for many developers for years and for good reason. While Insomnia wasn’t designed specifically as a [GraphQL IDE](/graphql ide), it has included support for GraphQL since 2017 and over the years it has proven to be just as good for GraphQL API development. It focuses on quality of life features that focus on helping work more efficiently and comfortably in teams using functions like multiple workspaces, easy import/export and for those more related to GraphQL, automatic query completion, code snippet generation and real-time error checking.

## Postman

Like Insomnia, Postman is a very popular open source IDE used by developers around the world. It even cracked 20 million users earlier this year! Though it is primarily known and used as a REST client it can connect to any web protocol and can easily be used along with GraphQL. Postman has a number of great features like auto generated API documentation and the ability to connect to a mock server to simulate endpoints, which helps test queries and responses instantly without waiting for your own backend to set up. Postman does however suffer from the same drawbacks many industry-standard tools do: it lacks some of the features other IDEs, which aim to compete with it, provide. It also still is primarily geared towards REST APIs and though its GraphQL support is growing with the language, it's still unsurprisingly behind GraphQL-specific IDEs in that regard.

## GraphQL Editor

Seeing how GraphQL Editor has been appearing in rankings like this for a few years now and with version 6.0 released just recently, I feel like a little bragging is in order. We’ve gone through some of the most well known and popular features of other IDEs, and the big selling point it, GraphQL Editor has them as well. Not only does it have them, it also combines that feature-rich environment with the simplicity of requiring only the browser without requiring installation or hundreds of packages. This makes it useful for a wide variety of users from non-coders and those taking their first steps in GraphQL to experts who can make full use of all the features in their projects. Let’s break it down:

- **easy access**: Just like [GraphiQL](/graphql-playground) GraphQL Editor is instantly available, all you need is a browser and internet access. It even has a full [GraphiQL](/graphql-playground) Playground you can use to collaborate with your entire team online.

- **QOL features**: All those quality of life features you might know from Apollo Studio like click out queries, hints, searching, filtering and sorting are also present here. There are also the ones that might remind you of Insomnia like automatic query completion, code snippet generation and view resizing. On top of that it has a complete E2E test builder & runner.

- **simple connections**: Basic features like workspaces, easy import/export and schema stitching are accompanied by a GitHub sync feature and complex microservice integrations along with built-in templates & no-code resolvers.

- **auto-generated docs & mock backend**: If you’ve used Postman you’ll also see some familiar features here like programmatically generated schema documentation and a mock backend for testing out queries, mutations and responses right away.

- **rest-proxy**: a simple click-out REST to GraphQL proxy service. Just add the REST API url and use mapping to match the REST API arguments to the types and fields of your GraphQL schema.

## Just pick one for you

The truth is there is no [GraphQL IDE](/graphql ide) that will 100% certainly be best for you and a lot of it comes down to personal preference. The key thing is you won't be able to figure out what your personal preference is unless you at least try out a few different IDEs and tools. While data shows user retention is significantly lower for industry standard tools than for dedicated and more niche ones, a lot of users do stick with the industry standard without even considering that something else might better fit their needs. This is most apparent for React where a new framework appears almost every other week and despite that the much maligned industry standard is still widely used. Not to rag on Apollo (far from it!) but a similar thing can be noticed here where a number of other tools provide new functionalities and improvements and yet are a bit overlooked in favor of the more widely used one and we can hope that changes in 2023.


Top 5 GraphQL IDEs for 2023

As you probably already know REST has been the established industry standard for years and GraphQL is supposed to be an alternative if not an outright replacement. True it boasts a lot of significant improvements, but is that enough to declare it a successor and deep REST obsolete?

## Improvements

So what are those improvements? The most widely touted one is data fetching efficiency. With REST you query a number of endpoints to get the needed data. For a simple Twitter like app you’ll probably have a directory with users, posts, followers etc. and to get all data pertaining to a particular user account you might need to query all those endpoints with multiple simple queries. While this might seem like an insignificant problem it gets compounded the bigger or more complex the app, the more users it has and the more queries it has to execute to get the needed data. Long story short it should be quite obvious why Facebook decided to go a different route. With GraphQL you only need one endpoint and one query to get everything you need:

* **single source of truth**: GraphQL requires only one endpoint & one query. All you have to do is structure the query to get the data you need and it will get that with just one round-trip to a single endpoint.
* **no over or under-fetching**: The query will get exactly and only what you requested, no need for multiple queries and no issues with excess data. This as mentioned has an impact on bandwidth not only for singular mobile devices running the app, but even more so for large app providers running them for thousands of users.
* **type-safety**: With GraphQL all the types are defined in a schema written in SDL (Schema Definition Language) which is a strongly typed language. This means both frontend and backend teams know the exact structure of the data and can work independently right away and both also enjoy features like automatic validation and introspection.
* **easy prototyping**: Any updates to your app or for example UI are much smoother as you only need to adjust the one query if it now needs to fetch more or less data. With REST you’ll have to adjust the entire backend and every affected endpoint and probably also multiple queries to get that additional data you need.
* **data transparency**: With just a single, even if complicated, query all the information is in one place. This way understanding what data is exchanged is much simpler than crawling over a whole patchwork of endpoints and simple queries getting bits of data from here and there before you can make out the whole picture.

![](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/res-tfetch-1730821521111.webp)
Data fetching in REST by [howtographql.com](https://www.howtographql.com/)

![](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/media/graph-q-lfetch-1730821533691.webp)
Data fetching in GraphQL by [howtographql.com](https://www.howtographql.com/)

## Is it all bad?

While the advantages are clear it's also obvious that REST isn't all bad, if it was it wouldn't continue to be so widely used. REST is still better for simple apps where using GraphQL can be overkill as you’re unlikely to take full advantage of its features in a noticeable way. Additionally while GraphQL can drastically reduce the amount of work needed in a big and complex app it can actually make things more complicated for small and simple apps where instead of just a few fields you’ll get types, queries, resolvers and other components. The other big difference is in the learning curve which for REST, with its simple hierarchical structure, is much less steep than for GraphQL, where it can sometimes be a turnoff for beginners.

## Personal preference

The learning curve question opens a whole another aspect of this discussion. For one person learning a new language will be a fun addition and building their skills, for another it might look like wasted time. Similarly while GraphQL is designed as an improvement over REST you can still do much of the same things in REST that you can do in GraphQL. It just requires using some third party libraries. Sure GraphQL supports those functions natively and you’ll be dependent on those libraries being maintained and working as intended, but it is nonetheless possible if you just want to avoid using GraphQL. If we’re being honest a lot of devs are very stringent with how they like working and if they’re convinced they want to stick with REST they will be more than likely to jump a few hurdles to do so.

## Plan ahead

At the end of the day the key points to weigh is the functionalities you get with GraphQL vs the simplicity of REST. It does mainly come down to whether you want to learn something new that is gaining popularity or you just want to stick to your guns. On top of that while simple apps might not get much use out of GraphQL if you’re envisioning them growing at any point down the line it is much more efficient to jump to GraphQL earlier rather than later. Finally the key is actually personal preference and balancing how you like to work against what is required and weighing the benefits for you and your projects.

GraphQL vs REST API


The authors of State of JavaScript had been including GraphQL in their survey for a while, though it was a bit hidden under the Data Layer subcategory. It did tell us a lot about the incredible growth of GraphQL over the last few years. Usage skyrocketed from just 6% in 2016 all the way up to 47% in 2020 and other metrics were even more impressive. It recorded very high satisfaction at 94%, interest at 87% and awareness at 98% topping each of the three categories. In 2021 the authors opted to remove it from the State of JS survey as it was a bit out of place there, but now we have a dedicated version: the first ever State of GraphQL survey where we can do a deeper dive into the rapidly growing ecosystem.

## Language features

Feature knowledge and usage is indicative of the fact that GraphQL is a rapidly growing but still fairly new language. Core features were pretty well known and used but as far as directives only `@deprecated` was used by more than 40% of respondents, similarly for security & performance features only authentication cracked 50%. As for custom features subscriptions were by far the most used with over 40%, with schema stitching a distant second at 26%. All of that was pretty well illustrated in the knowledge score where the biggest group of respondents ranked at the bottom with 0-10% knowledge of the features, although on the whole over half of the respondents knew at least 50% of the features in the survey which hints at a pretty big group of GraphQL experts.

## Libraries

As far as actual usage of the language goes, the libraries were divided into 4 categories: Servers, Clients, API Generators and Schema Builders and ranked based on usage, retention, interest and awareness. Looking at usage first, obviously Apollo beats everyone else and that’s also reflected in the overall results for Servers and Clients (due to how widely used Apollo Server and Client is) but taking a closer look at the data reveals a few more interesting facts.

## API Generators: room for growth

A quite broad category encompassing various different tools that help with creating an API. It showed a diverse field with no clear winner in terms of popularity or usage, but some important hints in regards to high interest combined with high user retention, which are important strengths that can mean a lot of future growth.

- **usage**: the top were Contentful, Hasura, Strapi, AWS AppSync and [GraphQL Editor](https://github.com/graphql-editor/graphql-editor), however as neither cracked 20% the room for growth is evident here
- **interest**: GraphQL Mesh, Fauna, Sanity, Hasura, [GraphQL Editor](https://github.com/graphql-editor/graphql-editor) and Strapi were all around the 60% mark showing a lot of potential new users especially considering far lower usage numbers
- **retention**: [GraphQL Editor](https://github.com/graphql-editor/graphql-editor) was 1st with a near 90% user retention score with only GraphQL Mesh at 2nd cracking 80%

## Apollo’s dominance

Its no surprise both the Server and Client section showed a clear dominance of the Apollo Server and Client libraries. Though both were beaten by other libraries in terms of interest and user retention, which might signal users' willingness to jump ship to other libraries over time, especially if provided with a better alternative. The Schema Builders section also had one clear leader:The Guild’s GraphQL Code Generator which ranked 1st in all categories, but we're very happy to see our own [[[GraphQL Zeus](/docs/zeus)](/docs/zeus)](https://github.com/graphql-editor/graphql-zeus) also appear there.

## Most used Web framework, Database & IDE

It wouldn't be a complete survey without looking at other use cases and tools used in conjunction with GraphQL so the authors put the remainder in the 'other tools' section and ranked them based on declared usage:

- **Web Frameworks**: Next.js and Create React App led the pack with others below 10% usage
- **Databases**: PostgreSQL was by far the most popular database with over 30% usage, MySQL was a distant second with almost 14%
- **IDEs**: recently updated to 2.0 [GraphiQL](/graphql-playground) at 30% was slightly ahead of [GraphQL Playground](/graphql-playground) at 27%
- **Server Languages**: TypeScript was significantly ahead of JavaScript with other backend languages barely registering on the graph
- **Others**: Dataloader, Prisma and GraphQL ESLint registered fairly high usage hinting at possible integration options for larger tools

## GraphQL Use Cases

For API types, exposed APIs intended for use with own website/apps and private unexposed APIs for internal usage accounted for 75% of use cases. This highlights a lot of interest in the language but a bit of a hesitancy to using it for publicly available APIs. As for API clients, browsers were the unsurprising overwhelming choice with mobile apps a distant second. The data sources category showed a significant number of respondents still using REST backends as REST APIs were second only to databases. As for industry sectors Programming was obviously first, but with barely 16% it does highlight that GraphQL is now used broadly and in almost every business sector.

## Strong Points and Pain Points

This section showed the main reasons for using GraphQL: Type-Safety, avoiding over-fetching, introspection and aggregating results as the main reasons. While community ranked last for strong points, it's not like it's some damnation of it as tooling and ecosystem ranked pretty high. It’s likely simply a question of its size, as even though it is rapidly growing it still is very little compared to other languages, but looking at the broader picture we can be certain that will surely change. For pain points the main selected were error handling, performance, security and client-side caching which should also indicate a direction for the community.

## Continued growth and the road ahead

GraphQL is now clearly a mainstay on the programming scene and it's hardly a suprise to see it used more and more for application development. The ecosystem and community is still rapidly growing though and there is a lot of space for improvement and building on top of its strengths. As far as pain points go, there is a growing number of tools and companies dedicated to finding better solutions for security, caching, error tracing and more so it only remains to be seen how those will be handled in the future. Regardless of that it’s clear that the community is growing and interested in trying out a variety of new tools and libraries which makes it apparent the overall growth trend will probably only continue down the line. It also obviously means growth for us as well! We're very grateful 🎉 to the community for appreciating both [GraphQL Editor](https://github.com/graphql-editor/graphql-editor) and [GraphQL Zeus](https://github.com/graphql-editor/graphql-zeus) and we promise we're going to keep improving them both and climbing the ranks in the survey in the future 🚀.

view the survey directly at stateofgraphql.com


Blog