When coding your GraphQL resolver for the Task type, you might write a resolver for comments that requests that particular task’s comments. Let’s say your back end has endpoints getTasks, getTask, getTaskComments, and getComments. On each task, let’s say you could have a list of Comments. Let’s say you also have a page where you request just a single Task. One of the biggest gotchas to look out for, is inefficient resolvers that could trigger LOTS of network requests.
#YML DEVDOCS HOW TO#
This section will grow as we find and document them for developers to be aware of and how to properly code around them. GraphQL can be amazing for API design and reuse, but it can have some “gotchas” to look out for. This project structure is very simple, but makes navigating the different services fast and simple. This means that all functions related to the users resource, whether it be creating, reading, updating, or deleting, will all be grouped together for quick access. For example, a function that requests a list of Users would be usersGet.go. The file naming convention is to name each file as. The directory contains all the functions that: Check the cache, make requests to core Agility, format/map responses, write to cache, return core Agility responses/data. These resolvers then reference and use the functions defined in our directory. schema.go contains our root query and mutation definitions, and maps them to each resolver that is also housed in the gql folder. If you are unfamiliar with GraphQL and what resolvers are, please read the Apollo GraphQL getting started guide. Gql is the directory that houses our graphql schema definition, and all the resolvers and their types. Others are allowed, such as utils to group files that don’t belong in these directories. This is where we setup our service.īeyond the basics, we have 2 critical directories.
![yml devdocs yml devdocs](https://res.cloudinary.com/practicaldev/image/fetch/s--GbqCTiaE--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://wakeupandcode.com/wp-content/uploads/2020/06/yaml-azdo-edit-1024x556.png)
Last for the root is our entry point: main.go. circleci directory that contains our release pipeline configuration, and a Dockerfile for the CI/CD pipeline to use for image creation.
![yml devdocs yml devdocs](https://www.kevinboosten.dev/assets/images/posts/2020-05-16/1.png)
At the root of the service, we need all the basics: a gitignore, changelog, readme. Project StructureĪll our -api projects follow the structure described below: > -api
![yml devdocs yml devdocs](https://res.cloudinary.com/practicaldev/image/fetch/s--osJtItbP--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://bemnlam.github.io/img/documentation-makes-easy-with-mkdocs/01_welcome.png)
If you are creating a new service, please read Creating A Middleware Service.
![yml devdocs yml devdocs](https://user-images.githubusercontent.com/54664124/64028945-36f33a00-cb76-11e9-8d24-e9c4c0c8f013.png)
Try to keep your services named appropriately and limited in scope to their responsibility. All our middleware services follow the naming structure of -api where is the domain of the service.įor example projects-api solely deals with Projects, Phases, Tasks, and Installers for installed sales projects. That said, let’s get into our Best Practices sections. Knowing of the above utilities will help you maintain and develop new services in our middleware ecosystem with minimal reinventing of the wheel.