The Ruby on Rails framework is powerful in many ways. One of its strong points is that Ruby on Rails is being shipped with ActiveRecord - an Object Relational Mapping system. ActiveRecord comes up with its own DSL, which lets you write Ruby code, which in turn is translated to SQL, allowing you to use database native features, including “locking”.
Today we are going to add specs (again, we will focus only on the happy paths) for GraphQL queries. But there is one thing about the current implementation of the queries that I don’t like. We have everything defined in one file: `app/graphql/types/query_type.rb`
In the last article we added a few GraphQL mutations to our test application. It is time to create automated tests for each of them. But first things first, we need to set up `RSpec` in order to write better specs.
In this article, I would like to focus on adding GraphQL mutations. We will be working on the test application we created previously in this article. It might be helpful for you to know the structure, models, and types we are using so I encourage you to take a look.
GraphQL is an open source query language created by Facebook. It is a powerful tool that you can use for building your API. It is not a silver bullet but it can definitely help you solve some challenges like getting many resources in a single request.
If we type Ruby on Rails 2019 in Google we will most likely get results from blog posts and forums dedicated to Ruby’s alleged death, but the truth is, Ruby is doing great and still remains a good technology to choose in 2019 and here is why.
Naming things in programming may not be hard (a matter of imagination), but it is definitely hard to do it right. Also, it turns out to be very unclear what “right” means in each and every context. It doesn’t change the fact that in 8 out of 10 PRs I review, I provide a feedback related to naming, be it naming of classes, methods, fields, variables… you name it