Anatomy of Sails.js API With GraphQL
Anatomy of Sails.js API With GraphQL
Though this isn't a common combination of tools and technology, it presents an interesting puzzle to backend and full stack web developers.
Join the DZone community and get the full member experience.Join For Free
Access over 20 APIs and mobile SDKs, up to 250k transactions free with no credit card required
Since this is not an every-day combination of technologies, it was challenging to define the anatomy of such an app and its tests, but we did it!
Are you asking yourself questions like:
- How will I organize all the queries and mutations?
- Where will the schema be defined?
- What should I do with the authorization and other utilities?
If the answer is yes, this article has the answers to all of your questions!
$ sails new graphql-app
If generated successfully, you should get a small app with a structure like this:
First, we will go through the api/ folder and what it, and its subfolders, contain:
As the name implies, this folder will contain our controllers, or, may I say, a controller since we are using GraphQL.
This sentence really needs a text-decoration:underline - GraphQL needs only one controller to handle all the requests sent to the API.
The purpose of the controller is to redirect requests to the right query or the mutation field and return the resolved value back to the client.
This folder won't be created by default, so we'll need to create it ourselves.
Here, we will store all of our GraphQL related files: queries, mutations, types, schema, etc. We created a folder for each entity in our app's model and stored the queries and mutations for it, and also defined type and utils regarding the entity in that folder.
So, the user model will have its own folder with UserQueries.js, UserMutations.js, UserType, and UserUtils.js (if necessary); the profile model will have its own related files and so on...
Here's a visual representation:
The root folder will contain the schema.js file, in which we'll combine all the queries and mutations into one big GraphQL schema.
We initially chose Sails.js due to how similar it was to Rails.
Once again, this is a self-explanatory directory which will contain all of our app models.
A model represents a collection of structured data, usually corresponding to a single table or collection in a database. We will hold basic models in the root of the model/ folder, and all the models related to our basic models in a separate folder.
For example, basic information about a user will be held in the User.js model, but their details will be stored in the Profile.js model, which will be contained in the subfolder models/user/ :
Policies in Sails.js are versatile tools for authorization and access control. The policy file is defined for a specific route and since we will have only one controller accessed through POST /graphql, we will have only one policy file.
Through the policy, we will allow or deny clients' access to our GraphQL controller (our client is a universal React.js app!).
Sails comes with a handful of the most common response types by default and they can be found in the api/responses directory. You are free to edit them, add new ones, or remove them if you think they are unnecessary.
Since all the traffic is going through one specific controller, we will keep only 2 of those responses and create a new one. We will keep ok.js and badRequest.js, since those are the only 2 responses our GraphQL controller can provide us, and we will create unauthorized.js which we will send if the request hasn't passed our policy mentioned above.
Services are stateless libraries of functions ( helpers) you can use from anywhere in your Sails app. For example, you might have an EmailService.js which tidily wraps up one or more helper functions so you can use them in more than one place within your application.
Services and their helpers are the best and simplest way to build reusable code in a Sails app. The greatest thing about them is that they are globalized, which means you can use them without having to require() or import them.
We use api/services/ for reusable tools like S3Upload.js, Honeybadger.js, PusherService.js, etc.
With the text above, we covered the structure for api/ and it's subfolders. I won't go through assets/ , config/ and tasks/ since they are best left as they come out of the box.
Let's now take a look at how the tests should look.
Sails does not automatically create a test/ folder for us, so we'll go ahead and create one ourselves. The test folder should mimic the structure of our API folder which will lead to better DX, easier debugging of the code and resolving issues (everything a good programmer wants).
To create some quality tests, we will need an assets/ folder for holding the files we need in tests, we will need factories/ for a clean way to create our test data objects, graphql/ where we will put the tests dedicated to testing queries and mutations, and models/ for unit testing.
As said before, the anatomy of test/ folder is identical to api/ folder structure, except we have additional folders for factories and assets.
This covers all the details regarding how we organize our code. We hope that this article will inspire you to write some great, well-structured Sails apps!
Published at DZone with permission of Nesha Zoric , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.