Created and maintained with ❤️ by LoopStudio
- Main Characteristics
- Other Gems
- Getting Started
- Code quality
- Tests
- Graphiql
- Pagination
- Continuous Deployment
- Contributing
- License
- Language: Ruby 2.7.2+
- Framework: Rails 6.1.1+
- Query language: GraphQL 1.12.2+
- Webserver: Puma
- Test Framework: RSpec
- Databases: Postgres & Redis
- Async Processor: Sidekiq
For environment variables.
For the implementation of GraphQL query language in ruby.
graphiql is an interactive in-browser IDE that simplifies the testing of your API and exposes the API available mutations, queries, and subscriptions.
For detecting N+1 issues.
For allowing queries to be batched to avoid the N+1 issues. You can read the documentation Here.
To generate the tokens required to authenticate we use JWT.
- Make sure that you have Rails 6, PostgreSQL, git cli, and bundle installed.
- Clone this repo using
git clone --depth=1 https://github.com/LoopStudio/rails-graphql-api-boilerplate.git <YOUR_PROJECT_NAME>
- Update the values of the
.env.template
file to match your app - Create your
.env
file. You have an example at.env.template
. You should be able to copy it and set your own values. It's a good practice to keep the.env.template
updated every time you need a new environment variable. - It is required to set the ENV variable
JWT_ENCODING_KEY
with the result of runningOpenSSL::Digest.new('sha256')
on the rails console to enable the token authentication. - Run
bundle install
- Run
bundle exec rake db:create
- Run
bundle exec rake db:migrate
- Run
bundle exec rake db:seed
- Check the test are passing running
rspec
At this point you can runrails s
and start making your API calls athttp://localhost:3000
- Edit or delete the
CODEOWNERS
file in.github
directory - Edit this README file to match your project title and description It's a good practice to keep this file updated as you make important changes to the installation instructions or project characteristics.
- Delete the
.github/workflows/deploy.yml
file, and uncomment the other workflows or configure your continuous deployment workflow since you might use different environments. - Modify the
.github/CODEOWNERS
file
You can run the unit tests with rspec
or rspec
followed by a specific test file or directory.
With rake linters
you can run the code analysis tool, you can omit rules with:
-
Rubocop Edit
.rubocop.yml
When you update RuboCop version, sometimes you need to change
.rubocop.yml
. If you use mry, you can update.rubocop.yml
to the latest version automatically. -
Reek Edit
config.reek
Pass the -a
option to auto-fix (only for some linters).
Graphiql will be mounted on the path /graphiql
, only if you have set the environment variable EXPOSE_API_INSIGHTS
in "true"
.
For example http://localhost:3000/graphiql
if you are running your server on 3000 port.
GraphiQL does not allow us to send headers in the request so if you want to use it as a signed-in user you should get the session token and set it as the environment variables GRAPHIQL_SESSION_TOKEN
, restart the server and then you should be good to go.
You can find a detailed guide on how to implement pagination here.
You can always check all the Mutations and Queries available by going to /graphiql
and looking at the Docs.
- Sign up
- Sign in
- Update profile
- Delete user
- Show profile
This boilerplate contains commented out code for a quick Continuous Deployment setup using Github actions and deploying to the Heroku platform.
(If you are not using those two tools you might simply want to remove the workflows directory and disregard the rest of these instructions.)
Since we are used to using git-flow for branching and having three different environments (dev, staging, and production), this boilerplate includes three commented out files on the .github/workflows
folder so that, when using this repo for an actual project, you can keep these environments updated simply by doing a proper use of the branches.
-
Deploy to dev: Triggered every time
develop
branch gets pushed to. For instance, whenever a new feature branch gets merged into the develop branch. -
Deploy to staging: Triggered every time somebody creates (or updates) a Pull Request to master. We usually call these branches using the format:
release/vx.y.z
but it will work regardless of the branch name. We create a release Pull Request at the end of each sprint to deploy to staging the new set of changes, and we leave the Pull RequestOn Hold
until we are ready to ship to production. -
Deploy to production: Once the staging changes are approved by the Product Owner, we merge the release branch Pull Request into master, triggering a push on the master branch which deploys to production.
For this to work you will need the configure some Secrets on your GitHub repository. To add these go to your Github project, click on Settings
, and then Secrets
.
You need to add the following Secrets:
- HEROKU_EMAIL: Email of the owner account of the Heroku apps.
- HEROKU_API_KEY: API Key of the owner account of the Heroku apps. Get it by going to your Heroku account,
Account Settings
and Scroll down to reveal theAPI KEY
. - HEROKU_DEV_APP: Name of the development app. Eg.
my-project-develop-api
- HEROKU_PROD_APP: Name of the production app. Eg.
my-project-api
- HEROKU_STAGING_APP: Name of the staging app. Eg.
my-project-staging-api
-
You can disregard and remove the
deploy.yml
file since we use it to deploy the boilerplate code itself as we work on it, but it will probably be useless to you once you clone this repo for your real-world use case. -
If you use a different branching strategy or different environments layout, simply delete the files under the workflows directory and set up your own.
If you've noticed a bug or find something that needs to be refactored, feel free to open an issue or even better, a Pull Request!
This project is licensed under the MIT license.
Copyright (c) 2020 LoopStudio.
For more information see LICENSE