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


State of GraphQL 2022 survey

In 2018 Node.js creator Ryan Dahl gave his famous talk titled "10 Things I Regret About Node.js". It outlined regrets he had about some fundamental decisions made during the creation of Node like the package management, the build ecosystem, GYP and the lack of core TypeScript support. That’s why in the same talk he announced Deno, a completely new JavaScript runtime made from scratch, to avoid the drawbacks of Node and written in TypeScript and Rust. Deno had a lot of hype and the community was a bit split on the subject with some wanting to hop over to Deno asap and others wanting to stick with Node.

## Deno vs Node

While Deno is obviously an upgrade over Node (it's made by the same person after all) and has many interesting improvements, there has been a lot of hesitancy about moving over due to various reasons. Deno is fairly new (ver 1.0 came out in May of 2020) so it hasn't been that battle tested yet, and it has a much smaller community, so third party packages are way less abundant and most importantly while it is an improvement over Node in a lot of aspects, it still is often in the same ballpark performance-wise. That will obviously probably change as Deno becomes more mature and if things go well it might even replace Node. But what if I told you that you don't have to wait for that anymore and its no longer just a two horse race?

## Bun

Bun is a new all-in-one JavaScript runtime and a competitor to Node and Deno. It's written in Zig, a somewhat new (2016) low level programming language designed for “robust, optimal, and reusable software”. The creators of Bun point out Zig as one of the main reasons for its performance saying its low level control over memory and lack of hidden control flows make it better suited to write fast software. The other key is the engine as, unlike Deno and Node, Bun is not based on Google’s V8 engine but on Apple’s JavaScriptCore, the engine used in Safari and many MacOS apps, which claims to be significantly faster. Its JIT compiler is named FTL for 'Faster Than Light' so you get the idea.

## Can this really challenge Node and Deno?

Well the big selling point for Bun is performance, it's not just faster by a bit in this or that use case, it's faster by whole orders of magnitude. Sure it's always good to take measurements you get from the creators with a grain of salt, but in this case we can easily find various tests done by a number of people all pretty much confirming the same thing: it's blazingly fast. Going by Bun’s official benchmarks:

* **bun.serve**: 3 times faster when server rendering react
* **bun.sqlite**: almost 3 times faster when running database queries
* **bun.ffi**: almost twice as fast when executing native code with foreign functions

Speed has been the main focus since that is the thing that jumps out at you first and that justifiably has fueled a lot of the hype Bun has gotten over the past couple of weeks. But Bun also has a number of quite enticing features related to dev experience and some neat quality of life solutions. It also uses a bit of a best of both worlds approach. Like Deno it has top-level await and prioritizes WebAPI’s like `fetch`, `WebSocket` and `ReadableStream`. As for Node it supports a lot of Node core modules already and has a Node API which will support a number of npm packages as well. It also uses Node’s module resolution algorithm so you can install from npm and do it a lot faster as well. And that's not all:

* **native bundler** instead of relying on something like Webpack
* **native transpiler** for built-in TypeScript support and auto transpiling JSX
* **native test runner** like Jest which runs really fast
* **automatic loading of environment variables** from .env files so no more `dotenv`

## Great things have small beginnings

Bun started out as a side project simply because its creator Jarred Sumner thought Next.js was just too slow. The idea behind it is clear, max performance and better dev experience to work both faster and with less hassle. It blew up and its scope is now quite a bit bigger. It's obvious Bun is not production ready just yet, it's just version 0.1 after all and its creator freely admits there’s a lot of bugs and he just wanted to get it out before he ran out of steam. But there is really a lot worth checking out here and the hype is definitely justified. I think a lot of people jumped at it simply because the whole Node vs Deno debate got a bit stale and they got bored of waiting for some kind of resolution. Bun on the other hand is something to be excited about already as it brings a lot of new stuff to the table and offers taking a big leap instead of taking gradual steps in terms of improvements, especially if we’re looking at performance. Obviously I wouldn't assume Node and Deno are dead just yet, but it's worth it to check out Bun just to get some idea of all the possibilities it has just opened.

Check it out on GitHub: [https://github.com/oven-sh/bun](https://github.com/oven-sh/bun "bun")

Bun: a new and really fast JavaScript runtime

It seems you get a new JavaScript framework almost every week now. Most of them aim to improve upon this or that shortcoming of React by doing something a little better, but so far many of them have lacked staying power and React still remains the go to tool it has been for a long while now. So while we all eagerly await something that will finally beat React, this time we can fortunately take a look at something a bit more Fresh.

## Deno

Before we get to Fresh we first need to mention Deno. It’s a JavaScript and TypeScript runtime and an alternative to Node.js. A very good one at that, since it was introduced by Node.js creator Ryan Dahl is his talk “10 Things I Regret About Node.js" Yes the name is an anagram of Node but it's not a fork of Node at all, it's a completely new implementation based on modern JavaScript features fixing all the mistakes its creator mentioned. It ships as a single executable with no dependencies, so no more compiler, builder and bundles, just a single TypeScript file. If that file needs packages it just fetches what it needs from URLs instead of using npm install.

## A Fresh framework

With Deno being that different from Node, Next.js just isn't fit to run it. So the obvious conclusion is that you need a dedicated framework for it and hence the solution to that, Fresh. Starting fresh (no pun intended) instead of refitting an existing framework does have its benefits though, you’re free to choose whatever approach you think is best and with Fresh that is: keep it absolutely minimal. Basically every single time I do an overview of a new framework or library I focus on the features it has, but here I'm going to do the opposite and focus on what Fresh does not have:

- **No runtime overhead**: by default Fresh ships no JavaScript to the client, instead using a “Island based client hydration" approach (more on that later).
- **No build step**: unlike other frameworks, which focus on speeding up their build step, Fresh doesnt have one at all. Fresh builds can be deployed to the edge instantly via Deno Deploy.
- **No configuration**: Works instantly out of the box and you can get right to writing code.
- **No typescript compiler**: Pretty much an extension of the above, Fresh provides TypeScript support out of the box just like Deno itself, so no compiler is needed.

## What does it have?

How does that make sense? Well the usual approach with frameworks is focusing on what some other framework does inefficiently and improving a bit on that. With Fresh the approach is different: keep everything at an absolute minimum to get peak performance and reduce stress on the client. It's basically made of two core parts:

- **Routes**: These contain a handler and a component (either or both) and take care of how your app responds to requests. Handlers are functions called for every request to the route, which then send a response with whatever is needed to the client. The component is a template, a server-side rendered JSX element which can receive props to determine what exactly needs to be rendered.

- **Islands**: These are isolated Preact components that are rendered on the client side and are sent to the client by routes. This is for those small parts of your app that need JavaScript to be interactive. It's the only part of Fresh that renders client side and Fresh handles updates automatically to reduce load times for the client. Props can be passed to islands, but that is currently limited to JSON serializable objects: primitive types, plain objects and arrays, but that might change in the future.

## Not your regular JavaScript Framework

New routes are put into /routes directory and the same with islands into /islands. This makes the whole concept quite simple. Fresh renders everything into static HTML on the server which means the user only gets a static HTML page. When more interactivity than static HTML is needed it can opt into JavaScript in individual islands so every page is still server-side rendered. This is different from Next.js where after the initial page all others are rendered by the router, which is client-side. Since almost all the processing is done on the server side, Fresh loads pages considerably faster than client-side frameworks and even beats a lot of server-side frameworks in that regard.

The whole approach isnt that revolutionary and is more of a throwback to traditional apps, especially in the age of React single page applications. That said Fresh is definitely a step in the right direction for Deno. Yes we’ve all heard enough about new JavaScript frameworks, but this one is actually different and the minimalistic approach is very efficient. While it's probably not ready for work just yet, the Deno ecosystem is taking an interesting route and with how fast and simple Fresh is, it should be a draw to make people keep an eye out for what more they can come up with.


Fresh: an extremely fast and simple web framework from Deno


As far as JavaScript frontend frameworks go most people stick with React and it has been by far the most widely adopted framework and has enjoyed pretty high levels of user satisfaction (67% per State of JavaScript Report). Although there were a number of other frameworks, for a long time React together with Angular and Vue made up the big three and the main competition was between them. This changed a bit in 2019 when a new framework called Svelte entered the scene and reached high levels of interest almost immediately due to a completely different approach.

## Svelte

Unlike traditional frameworks which use virtual DOM and do most of their work on runtime, Svelte opts for a dispersed approach, compiling HTML templates to specialized code which manipulates the real DOM directly. App code is processed by the compiler, inserting calls to automatically re-compute data and re-render UI elements only when the data they depend on is modified. This means much improved performance, less data needed to be transferred and most importantly: no overhead in the shape of virtual DOM. These advantages clearly explain why the appearance of Svelte had generated a lot of interest. While adoption has not entirely followed suit it has been steadily growing every year, from not even 7% in 2019 to almost 18% last year. I absolutely wouldn't want to discourage you from jumping on the Svelte hypetrain, but there is an even newer framework that builds on its idea and can gain even more interest!

## SolidJS

SolidJS is based on a similar idea as Svelte, the key aims being focusing on pragmatism and performance. At first glance it actually shares a lot of similarities with React, little wonder since it emphasizes true reactivity. It’s still components and JSX so if you’ve used React and Hooks it should be very familiar, but there are some key differences:

- **no virtual DOM**: Similarly to Svelte, instead of making changes to virtual DOM, then comparing them to the real DOM and merging both, Solid uses a compiler to convert your code to vanilla JavaScript and work with only the real DOM. This means with state updates only the code it depends on runs, instead of running all that overhead code.
- **no unnecessary re-renders**: Solid brags about fine-grained updates, and rightfully so. It can track the changes happening in components and doesn't need to re-render them every time they’re used, unlike for example React. Components get rendered only once and then only the JSX expressions and primitives which are being used in the component are updated.
- **the king of performance**: As we can see on [The JS Framework Benchmark](https://krausest.github.io/js-framework-benchmark/current.html) Solid is way ahead of other frameworks in terms of speed and is even really close to vanilla JavaScript's speed. Sure you might think other frameworks are fast enough, but keep in mind its not doing that via some complicated hacks, it's mostly a byproduct of its pragmatic approach and you’re getting all that in just 6.4 kB!
- **still plenty of features**: Performance and tiny size doesn't mean you’re missing out on anything. Solid still provides basically the same developer experience as all those bigger and slower frameworks. You get full JSX and TypeScript support and a number of features you should be familiar with from React like: context, fragments, SSR, hydration, directives, portals, fragments and a lot more.

## React as React should be?

One reaction to Solid I’ve seen in a lot of places is: “Why doesn't React work like this?” It makes sense since it is so familiar and is actually ‘truly reactive’ unlike React itself (which uses a scheduler, which marks which components should be updated and then updates and re-renders them all). To me it's clear that Solid has improved on those concepts of React, but that quote is actually really telling. We're still thinking of React when looking at Solid and that's because we all know it and most of us use it. That's the one area where React has Solid beat, the community is much larger, there's more third party tools, libraries and resources. All because it's been here much longer and is so widely adopted. So while you might not get to work with Solid on every project just yet, it's still great to check out. It's clearly better and simpler in certain aspects and because of that you can't say for certain it won't be the new big framework in a few years.


Blog