Parallelise Development by Using Mock Resolvers With AppSync

An API-first approach using GraphQL with AppSync

Here’s a technique I've successfully used with teams when building functionalities that require both backend and frontend development.

I call it mocks resolvers. The idea is stupidly simple, but it has the potential to unblock and parallelise separate streams of development, thus reducing unnecessary blockers and dependencies.

In a nutshell, the mock resolvers technique requires that the team’s first task be to design any GraphQL statements (queries, mutations, etc) needed to build a feature. Immediately after that, a hardcoded set of responses is attached to each query, so that all GraphQL operations are able to receive and respond with the appropriate payload.

At this point, a contract of sorts is established. The frontend team can proceed to build the interface that’s going to use those GraphQL operations, whereas the backend team can focus on building the business logic that will eventually be invoked by AppSync.

Typical “mock resolvers” workflow on a 5-day sprint/cycle

Typically, the first step can be done on day 1 of a sprint/cycle: a developer makes a Pull Request with the proposed GraphQL schema, and then everyone else can make comments, suggest changes, ask questions, etc.

In that same PR, “mock resolvers” (usually made up of a few lines of VTL¹) are set up. Those can be discussed and changed based on everyone’s feedback too.

Within a few hours, the GraphQL “contract” is decided upon. We now have a set of API operations that the frontend team can reasonably be expected to build the UI around, even if it’s just presenting mocked data. At the same time, the backend team is crystal clear on what types of inputs and outputs it will have to deal with.

At this point, frontend and backend developers can happily split up and focus on their part of the job. No dependencies, no blockers.

Towards the end of the sprint/cycle, the backend team is ready to replace the mocked resolvers with actual resolvers running real-world business logic. A few integration tests are helpful at this stage, and minor adjustments may be necessary.

This approach is very productive and quite pleasant since it requires just a little bit of upfront, all-team thinking. After that, everyone is free to get in the zone and focus on their tasks, undisturbed and uninterrupted.

If you feel that “mock resolvers” could be a useful technique for you, feel free to get in touch with me. I’d be happy to help and/or answer any question!

1. In production, I avoid VTL like the plague. I am a big fan of Lambda resolvers instead unless response time is a critical requirement.