![]() Turning our attention back to our GraphQL Types, here's what our current PaymentType and its fields look like: Update PaymentType with the new :status field ![]() Now let's connect this functionality to our GraphQL query! Great! Now we can chain to use this filter. Payment Load (0.4ms) SELECT "payments".* FROM "payments" WHERE "payments"."order_id" = ? AND (status = 'Successful') LIMIT ?, ] Running via Spring preloader in process 6277 Open up our Order model, and build out the has_many declaration by adding a do.end block: The article itself demonstrates this with a has_many-through relationship, but the pattern works the same for simple has_many relationships too! However, a great StackOverflow discussion showed me we can expand a has_many declaration with additional functionality. In my previous Rails projects, I didn't do much in my Models' files beyond setting up has_many / belongs_to relationships. Now, let's look at filtering our results to only return "Successful" payments with our GraphQL queries! Payment Load (0.2ms) SELECT "payments".* FROM "payments" WHERE "payments"."order_id" = ? LIMIT ?, ]Ĭool! We can see that our first Order has both a "Successful" and a "Failed" payment in its associations. Order Load (0.2ms) SELECT "orders".* FROM "orders" Order Load (0.5ms) SELECT "orders".* FROM "orders" Loading development environment (Rails 5.2.3) Running via Spring preloader in process 6225 Open it up, and create a new column for status on the Payments table: This will create a new database migration file. Run rails g migration AddColumnStatusToPayments. This would allow us to use only "Successful" payments when doing things like calculating a total balance, generating receipts, or other situations where we don't want to expose every single payment. Let's say we want our API to know the difference between "Successful" and "Failed" payments. write and execute a GraphQL query to demonstrate the filter in Insomnia.add a custom field to our GraphQL order_type to call the.add a successful class method to our Order model to filter by "Successful" payments.add a status column to our Payments table (and update our seed file).In this third article, we'll go through the steps to: Once again, this tutorial is largely adapted from this AMAZING tutorial by Matt Boldt. We will add a status column to our Payments table, and add a filter to only return "Successful" payments in our queries. Class Methods directly on our Rails Models (as inspired by this great StackOverflow response).Your UsersController should also use the jwt_token and current_user methods we created in the application controller.Building on our Rails GraphQL API from previous articles, we will now look at filtering data using two tools: Your master key is NOT the JWT token key we created, but the Rails master key found in the masterkey file.Ĭode the RESTful actions that seem appropriate to your controllers: index, create, show, update, destroy. Having trouble accessing this secret key when migrating to Heroku? Try this command out in your heroku terminal: You are now free to resume committing to Github. For a more in-depth look at how Rails credentials work, check out Derya Tanriverdi ‘s tutorial The Secret to Rails. Once you are done adding your secret keys, save and close the file. You can also hide other information in the same way. Hide the secret key by typing in your terminal:ĮDITOR="code -wait" rails credentials:edit Notice the jwt_key variable? We will be hiding this code with the following command. Render json:, status: :unauthorized unless logged_in? User = User.find_by(username: user_login_params) Go back to your terminal, and while in your project directory, type the following:Ĭlass Api::V1::AuthController < ApplicationController In your Github account, create a new repository. It's recommended to start early so you can save as you go. You can connect your project to your Github at any time. You do not necessarily need to hook up your database to Postgres, but platforms such as Heroku require it. It also hooks your database up to postgresSQL. This command populates specific gems in your gem folder and forgoes view files. This creates a new Rails project specifically for API use. Rails new my-project -api -database=postgresql You’ll want to start out cding into a folder to store your project. Create the API with a PostgresSQL DatabaseĬreating the API and Hooking it up to PostgresSQL.You will be able to set up a Rails API with CRUD functionality and (hopefully) not open a million tabs in the process. This guide is intended for developers comfortable with Ruby on Rails. At the end of the day, I had tabs galore and knew there had to be a better way. I recently sat down to create a Rails API and found myself googling like mad.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |