DEV Community: Luke Czyszczonik

🪄 gql.tada makes a GraphQL great again

Luke Czyszczonik — Thu, 29 Feb 2024 10:36:03 +0000

I began exploring the GraphQL ecosystem in 2018. At that time, REST APIs were a significant part of my daily work, but I was always exploring and looking for new challenges. During that period, I invested much of my time transitioning from the PHP ecosystem to React, React Native, Node.js, GraphQL, and TypeScript.

Leaving GraphQL

While GraphQL enhanced communication between frontend and backend, there were several gaps and obstacles in making it work effectively. Tools like Apollo and now urql have improved the client-side experience with GraphQL. However, ensuring a type-safe experience requires using GraphQL CodeGen. The Guild has made remarkable efforts to streamline this experience, yet there is still room for improvement.

I transitioned from the GraphQL ecosystem to the tRPC world to enhance my daily workflow more than a year ago. This shift was swift and relatively issue-free, resulting in faster and simpler project development backed by TanstackQuery on the front end. Although some costs were involved, the overall benefits and experiences have made it worthwhile.

🪄 gql.tada Makes GraphQL Great Again!

Since last week, I've been testing gql.tada, the new library created by Phil Pluckthun and Jovi De Croock that eliminates the need for codegen and seamlessly integrates GraphQL with TypeScript like never before.

The initialization process is straightforward, requiring only three lines of code in tsconfig.json and one file to export the typed client. The best part is that everything works without additional background processes and is baked into TypeScript.

Three features have made me miss the GraphQL ecosystem again! Let's explore them and see how they change the way you work with GraphQL on the client side.

Autocomplete

The first notable feature is the autocomplete, which feels like having a GraphQL playground built into the TypeScript editor. For me, autocomplete is essential when working with GraphQL. The visibility of available queries, along with their corresponding fields, mutations, and arguments, enhances the developer experience.

Another thing to note is the argument handling by the urql client. It quickly provides feedback about missing arguments or incorrect types.

Fragment masking

The next one is Fragment Masking. Gql.tada adds a layer of "security" to Fragments by preventing accidental access to Fragment types. This feature stops the direct use of fragment data in components without explicitly reading the data. Instead, you must use the readFragment() hook to explicitly read (unwind) the fragment data type. You can learn more about this feature here

GraphQL Fragments can help reduce duplications, as multiple types within the GraphQL Schema can utilize the same fragment. This creates boundaries for composing data structures. As you might have seen in the video, gql.tada also warns you about unused fragments in your codebase.

Unused warning

One of the advantages of GraphQL is its requirement for explicitness; you always have to specify the data set you want to fetch. This can lead to overfetching when unused data is not immediately visible, particularly without an effective tooling. However, with gql.tada, this problem is resolved as it immediately highlights unused fields as you type.

Wrap up

GraphQL demands a degree of explicitness when specifying the data developers want to use. Without appropriate tooling, this could be cumbersome. However, gql.tada fills this gap perfectly. Its features make working with GraphQL enjoyable once more!

All the codebase used for this blog post is here: https://github.com/czystyl/expo-tada

Safe component state with useReducer and TypeScript

Luke Czyszczonik — Thu, 12 Jan 2023 19:31:09 +0000

Photo by Nelly Antoniadou on Unsplash

Using multiple useState's to control component state is a common practice in React codebases, but it can result in unexpected behavior, such as a forever loading component or a disabled submit button.

Let's see what such components usually look like:

...
const [email, setEmail] = useState('');
const [loading, setLoading] = useState(false);
const [error, setError] = useState<string | null>(null);
const [success, setSuccess] = useState<string | null>(null);

async function handleEmailSend() {
  setLoading(true);
  setSuccess(null);
  setErrorMessage(null);

  if (!isEmailValid(email)) {
    setLoading(false);
    return setErrorMessage('Invalid email');
  }

  try {
    const response = await sendToAPI();

    setLoading(false);
    setSuccess(response);
    setEmail('');
  } catch (error) {
    if (error instanceof Error) {
      setErrorMessage(error.message);
    }

    setLoading(false);
  }
}

You can imagine that one missing setState can make an invalid UI state that we do not want.

We can use useReducer to make the code much cleaner and less error-prone.

Let’s start by defining all the different possible component states we want to handle:

type Typing = { type: 'typing'; email: string };
type Fetching = { type: 'fetching' };
type FetchSuccess = { type: 'success'; message: string };
type FetchFailed = { type: 'failed'; error: string };

We used type intersection to distinguish the correct type based on the type property. Our reducer state will be a union of all defined above types plus email filed.

type ResponseState = Typing | Fetching | FetchSuccess | FetchFailed;

type BaseState = {
  email: string;
};

type State = BaseState & ResponseState;

The reducer requires action types, which typically include a "type" property. We can utilize the valid UI states that we've already defined, eliminating the need for duplicating code when defining our actions.

type Action = Fetching | Typing | FetchSuccess | FetchFailed;

function reducer(state: State, action: Action): State {
  switch (action.type) {
    case 'typing':
    case 'fetching':
    case 'failed': {
      return { ...state, ...action };
    }

    case 'success': {
      return { ...action, email: '' };
    }
  }
}

The reducer is straightforward, thanks to the reuse of types from the reducer state for the actions, and the fact that their shape aligns with the reducer action pattern. The only exception is the success action, where we also clear the email input value. By connecting the reducer actions and state in this manner, unexpected states should no longer be an issue.

Let's see how we can simplify our handlers:

async function handleEmailSend() {
  if (!isValidElement(state.email)) {
    return dispatch({ type: 'failed', error: 'Invalid email' 
 });
  }

  try {
    dispatch({ type: 'fetching' });

    const response = await sendToAPI();

    dispatch({ type: 'success', message: response });
  } catch (error) {
    if (error instanceof Error) {
      dispatch({ type: 'failed', error: error.message });
    }
  }
}

The component render is also pretty clear and easy to understand:

<div>
  {state.type === 'failed' && <ErrorMessage error={state.error} />}
  {state.type === 'success' && <Success message={state.message} />}
</div>

The above example dismissed the invalid states and made our component safe, so we can assume that we archive the goal!

Please let me know in the comments what you think about that kind of reducer typing and if you have used it before!

If you want to explore the full example, here is the live example

Google Cloud Functions in monorepo

Luke Czyszczonik — Wed, 16 Feb 2022 13:25:02 +0000

Cover photo by alevision.co on Unsplash

The Google Cloud Functions (GCF) and serverless architecture have gained a lot of attention during the last few years. Serverless functions intend to be small and easy to use. With GCF, you can start from a single JavaScript file, and you do not need anything else.

I recently worked with the system that has ten separate Github repositories. All of those repositories are somehow connected and depend on one another. This situation decreased the development speed and experience, so I merged all the pieces into a monorepo. The migration went smooth.
The API services use the internal packages, so I didn’t need to publish them into private NPM anymore. This change increased development speed, experience, and confidence that services use the correct versions of packages. The whole codebase was written in TypeScript, which was an obvious benefit from monorepo because I could use features like path mapping.

Unfortunately, I ran into a few issues with GCFs and the use of local packages that stopped me from finishing the integration. I looked through a lot of Github Issues and StackOverflow threads and I saw that people had similar problems to mine. I tried a few solutions from those threads but none of them were good for my use case so I ended up with a different solution.

Let me describe some of the steps that I ran into to make the GCFs work with the monorepo.

Monorepo and Typescript

I used the Yarn Workspace to manage the monorepo dependencies. In the monorepo, every package and function uses TypeScript so path mapping was the way to go for me as well.

Development

The development process of GCF is not as simple as I expected. After some time I managed to establish this process.

In line 8. we have yarn dev script that is used in development. The script generates entry file (if needed, but this will be described below) and run two scripts. One of them is build process in watch mode. The second is responsible for re-run function to see the changes.

GCF do not support hot reloading by default.

Using local package

Up until now, development and deployment works smoothly and without any issues. To get this working, I modified the TypeScript configuration to include all the code related packages into the distribution directory. This step changed how the distribution directory looks and also affected the development and deployment process.

After that change, the distribution directory contains function source code and all related packages in the same shape that they are structured in the monorepo.

Another problem was that after building code using the TypeScript compiler I still have original paths to local packages, see the line 7.

To solve this issue I decided to use the module-alias package and custom “entry point” file to build the function code.

These solutions allow me to have a good local development experience and I also have the single entry point for my deployment.

GCF deployment dependencies

The last problem was missing that some dependencies and yarn.lock was missing during deployment. The function’s package.json file didn’t include the dependencies from used local packages.

To have the correct dependencies and their versions, I had to copy the yarn.lock file into the function directory and add all the used packages’ dependencies.

Summary

You can find all described solutions in the example repository: https://github.com/productbrew/gcf-monorepo

Elixir in the eyes of Node.js developer

Luke Czyszczonik — Mon, 20 Dec 2021 13:50:33 +0000

Cover photo by Kaizen Nguyễn on Unsplash

I got into Elixir some time ago, but at that time, I was more interested in statically typed languages. I didn't exclude Elixir at that time, but instead, I moved it to a second plan. One of the signals to give Elixir a try was the talk from Saša Jurić - The Soul of Erlang and Elixir. I highly recommend watching this talk. I discovered that the BEAM VM and Elixir features could offer many benefits. So I decided to try and see how all the pieces are working together in an actual application. I'd like to share some critical ecosystem points that convinced me to try.

Community
One of the first things that I noticed when I started was the community libraries. Almost all the libraries shared the same structure and had all the API interfaces generated along with the type spec. So I searched for a few libraries that I often use, like web framework, GraphQL implementation or Database management. I can say that all of them look solid, and the documentation also contains a lot of guidelines, so I didn't need to leave the page to have a good understanding of them.
Phoenix framework
The Phoenix is a web framework that makes building web servers easy and fast. Great thing is that Phoenix has a built-in code generator. This generator is done via the mix task and you can generate almost all needed parts for creating an endpoint, context or database schema. Additionally, the documentation and guidelines described in the next point make you much more comfortable in the first place.
Testing and documentation
When looking back on different projects, documentation and testing are some of the forgotten things during development. Within the Elixir, those things are built in the language, making a considerable change for development and maintenance. You can write the documentation and examples right next to the code, and as we advance, you can turn these examples into quick tests. It was a nice thing that convinced me to write more tests and documentation.
GenServer

The GenServer allows you to abstract logic around small services. For example, all these services might have a separate state and business logic encapsulated inside. The service code is executed as a lightweight BEAM process, which is fast compared to standalone microservice solutions. Therefore, you do not need any extra HTTP layer or queue to communicate within the service.
Type system, pattern matching and language itself

I need to say that I'm a big fan of statically typed languages. So, when I heard about the Elixir for the first time, missing a type system was a big downside for me. Also, I understand that making such a dynamic language static would be a big challenge. To fill this gap, I used Dialixir and Typespecs. The experience is slightly different, but you have some tangibility of the type system, called success typing.

Elixir has a functional language style that fits my personality best, but everyone can feel differently. On top of this, you have a great set of language features like With statements, function guards, the pipe operator and excellent pattern matching.
BEAM virtual machine
I think it was one of the biggest deal-breaker for using the Elixir heavier. The BEAM architecture, combined with the language features described above, make it a great combo!
The virtual machine is responsible for running your code in small, cheap and fast processes. One of the philosophies that are coming from Erlang is Let it fail. The philosophy allows writing the system that is working more consistently and reliably. I could compare this to our systems like Linux, Windows or macOS. The system is working, but some programs that we installed are crashing from time to time, but usually, your system is still working, and only what you have to do is open your program once again. Like BEAM VM, one process might crash, but the whole system is still working as usual.

Overall, I feel surprised how good working with Elixir was. One of the gaps is the lack of a static type system. To fill this gap, I used Credo, Dialixir and TypeSpecs to analyze the codebase statically. The language features make writing the code quicker, easier and cleaner to maintain. For example, built-in documentation and testing might turn your codebase into an environment that is a pleasure to work with. The last piece of this whole stack is that all of this runs on BEAM VM, which is the cherry on the cake! So I need to say that the lack of a static type system is no longer a significant disadvantage with such a combo!

It is the first blog about my elixir journey, and I plan to share more detailed knowledge soon in my next blog.