In the first post of this series we have looked at how to rapidly bootstrap your full stack graphql application scaffold using GRelDAL starter. In the next post we have explored what all is happening in the backend of this scaffold and got a taste of how GRelDAL helps us easily connect to relational databases and expose the data stored in them as a user friendly graphql API.
Note that there is nothing react/apollo specific in GRelDAL, and multiple frontend technologies can be used to built your frontend. However we do think that if you don't already have a preferred frontend stack React+Apollo is a great first choice that will help you get started rapidly.
We will assume some familiarity with React below. If you are new to react, you might want to check out React's Getting Started tutorial first. The frontend scaffold is essentially a modification of create-react-app so their getting started guide and documentation also apply for our case.
The starting point of our client side application is src/index.tsx which renders our top level App component in the DOM. The App component is mostly informative except for the embedded WizardBrowser component which is where most of our GraphQL integration happens.
Our WizardBrowser component is where things get interesting.
At the top of the file you'll note something like this:
So what is this
generated directory ? Let's find out.
Code generation for type-safe GraphQL interaction
So for a GraphQL query specified in our get-all-wizards.graphql:
We have the following code auto-generated:
Along with the types of the typescript types corresponding to the GraphQL input/output types relevant to our query.
The code generator is configured through a codegen.yml file, that specifies how the code generator can connect to our backend during development to fetch the schema so it can identify these GraphQL types.
These generated types are compatible with Apollo client and the components exposed by apollo's react integration.
So we can query the backend using something like:
However, if we do the above, then we will realize that we will have to specify the type of arguments to our render props explicitly.
Thankfully, that is also something the code-generator has taken care of for us. It generates react integration code for wrapper components that interact with our backend using the above query:
So now, when we use these components, we don't have to actually specify any types for our render props because they are inferred for us:
We note that the above snippet also uses a
DeleteAccomplishmentComponent which is similar to our
GetAllWizardsComponent except instead of loading data through a graphql query, it enables us to modify data through a GraphQL mutation.
Running the server
We can start out server by running
yarn run start.
This starts our webpack development server and will live reload the application on code changes.
We can take a closer look at the timeline of the application to see what happens when:
Our WizardBrowser component renders the Apollo Query component, and when the Query component mounts, it makes a request to fetch the list of wizards along with their accomplishments.
During development, our webpack dev-server is configured to proxy to the backend server, so we don't have to bother with CORS and our client can make requests against
Taking advantage of tooling
It is worth pointing out that both React and Apollo come with great tooling support.
Using react-devtools extension we can interactively explore the component hierarchy of our application and inspect the props and state of any component:
Using the apollo-client-devtools extension we can explore the current state of the cache, and try out GraphQL queries & mutations and explore the schema from the browser devtools.
These utilities are invaluable during getting started, as well as when working on large applications.
At this point it would be worthwhile to explore the apollo tutorials explaining more about fetching and modifying data. Since there is nothing GRelDAL specific in the client scaffold, all of the Apollo docs there apply for our integration as well.
This concludes our introduction to GRelDAL starter. While GRelDAL doesn't solve all challenges associated with a full-stack GraphQL app, we do play well with the wider GraphQL ecosystem and we hope that this series at least familiarizes you with the pieces of the puzzle.
We are excited to hear about what you build with GraphQL and GRelDAL.
Be the first one to comment