About the Author
Mat Warger

Mat Warger

I'm a software consultant with Keyhole Software in Kansas City. I am a coder and life-long student, also enjoying technology, learning, cooking, and gaming. Recent projects have included React, Angular, and Java.

Generate Strongly Typed React Components with GraphQL

Mat Warger AWS, GraphQL, JavaScript, Programming, Technology Snapshot Leave a Comment

When developing in React, using a type system (like Typescript or Flow) can be a great help. You can be sure that your props and state are what you expect, at build-time, and code your components to match.

But what happens when you’re calling to an API to fetch some data, and the shape of that data is what really matters? Maybe the data get passed as props to a child component? You can create types for this, sure, but are they correct? Probably not! Or at least, probably not for long! Things change. Wouldn’t it be great if your types changed too?

In this post, we’re going to take a simple component from zero type awareness to fully typed, with local variables and GraphQL queries included, with a simple workflow. Grab a cup of coffee and a snack, and let’s see how this we can use GraphQL to generate type-safe components in React.

AWS AppSync with Lambda Data Sources

Mat Warger AWS, GraphQL, JavaScript, Technology Snapshot, Tutorial Leave a Comment

The power of GraphQL lies in its flexibility. That is especially the case regarding resolvers, where any local or remote data can be used to fulfill a GraphQL query or mutation.

In this post, I’m going to demo a quick example of what this looks like, and a couple gotchas that were apparent in working with Lambdas as a data source for AppSync. Let’s gooooo!

Go Forth and AppSync!

Mat Warger AWS, GraphQL, JavaScript, Technology Snapshot 1 Comment

In a previous post, we discussed the basics of GraphQL and how it can be a great REST API alternative. In this one, we’ll see how AppSync can be more than just a great API alternative — it gives you a soft landing into the world of GraphQL.

Recall our Game API example? Let’s start with the basic type of a game. Follow along and we can implement a simple schema in AppSync together….

Rethinking REST Practices: An Introduction to GraphQL with AWS AppSync

Mat Warger AWS, GraphQL, JavaScript, Programming, Technology Snapshot Leave a Comment

The basic premise of data transfer and involves requesting and receiving lists. This is simplistic, but it gets to the root of why we’ve developed the technologies and best practices to pass data using web services. RESTful APIs have grown to serve the needs of numerous individuals, startups, and enterprise companies across the world. They are useful, productive, and the concepts surrounding them are relatively standardized. If you don’t know how to create one, you can quickly find information building a great API that can grow to fit your needs. That’s when things get complicated…

If you start digging into REST, you’ll realize there’s quite a bit more to throwing lists. There are common threads that many people encounter when developing an API, and you begin to encounter many of the same questions so many others have before, such as: How strictly should you adhere to the principles of REST? How should you handle versioning? Should you bother? How do you want to structure your objects? Are users able to easily figure out what API endpoints are available and how they should be used?

There are many ways approach these. It boils down to communicating the structures that a given endpoint will return or accept. The cascade of questions that results from the choices made here will ripple through from the back-end to the client. The secondary issue is that these questions and choices are not at all uncommon. There are answers to these that follow Best Practices. But there is still plenty of ambiguity involved when attempting to build a flexible API that works well. These are the Commonly Tolerated Situations.

If you hadn’t already guessed, there is a solution that frees us from the dogma of REST and allows us to solve all these issues in a declarative, powerful, and fun way. That solution is GraphQL. In this blog, I’ll provide an introduction to the GraphQL specification with code examples…

Thoughts on Application State

Mat Warger AWS, JavaScript, React Leave a Comment

Use Redux! Use MobX! Just use `setState`!
Redux is functional! Mobx is reactive! `setState` is built-in!
But Redux has so much boilerplate! But MobX is more difficult to debug! But `setState` doesn’t scale!
Why don’t you just use Rematch to abstract the Redux boilerplate? Do I use redux-thunk? redux-saga? redux-observable?
How about using Unstated? How about just using the Context API?

:head-explodes:

There are a lot of options for developers regarding how and when to use state management libraries (SML).

Remember those last two articles (The Joy of Forms with React and Formik & One Router to Rule Them All: React Router) about the massively underplayed game library? There was a third part to come — a follow-up meant to implement an example of state management for an application. The application was small, granted, but this somewhat contrived example would tie it all up. It’d be the cherry on top. It would complete the rule of threes. 😉

There is not going to be another tutorial about which state library we can use to better manage our game library. Rather, in this post, we’re going to look at how and why you might use a library to manage your application’s state, and why that particular application is a perfect example of when you might not need a SML at all.