GraphQL is a “Better Way”

 

After reading articles purporting the amazingness of GraphQL over RESTful, I decided to explore it with a “getting started” tutorial. It was a breeze to set up on the server side.

The beauty of GraphQL is that it allows the client to specify what data it requires whereas a RESTful API would deliver the entire contents of a table unless a custom endpoint were created and maintained.

It also allows for collation from multiple resources and delivers the results via a tidy JSON object.

My first reaction to hearing about it was that allowing for such specificity would involve learning a new query language. I was wrong. The format is elegant and intuitive. A request looks almost just like the JSON response without the values. Here’s an example of a request:

{
  user1: user(login: "tj") {
    name
    email
    about
    following
    followers
  },
  user2: user(login: "ekendra-nz") {
    name
    email
    about
    following
    followers
  }
}
GraphQL Request

And here is the response. See how the query and response work like a Q and A? How smooth is that?

{
  "data": {
    "user1": {
      "name": "TJ Holowaychuk",
      "email": null,
      "about": "Founder of Apex\r\nhttps://apex.sh\r\n@tjholowaychuk on Twitter & Medium.",
      "following": 48,
      "followers": 30215
    },
    "user2": {
      "name": "ekendra-nz",
      "email": null,
      "about": "PHP/JS Webdev",
      "following": 0,
      "followers": 0
    }
  }
}
GraphQL Response

 

MariaDB + Ruby on Rails

Today we completed the Ruby on Rails official getting started guide blog example to demonstrate CRUD using Maria DB instead of the default sqlite3.

It ran smoothly and gave me the ability to use phpmyadmin to poke around my database. Some issues encountered were that, despite declaring relationships between tables on the model level, by default the database does not show any cascading or auto-delete.  It may well be something that was beyond the scope of a quick start tutorial, or the functionality may not exist at all.

Switching from Sqlite to MariaDB involved two steps:

In the Gemfile, comment out gem ‘sqlite3’ and add a line gem ‘mysql2’

# Use sqlite3 as the database for Active Record
# gem 'sqlite3'
gem 'mysql2'

In config/database.yml comment out the existing database connections and add this block (replacing it with your MariaDB credentials).

development:
  adapter: mysql2
  encoding: utf8
  database: yourDatabaseName
  pool: 5
  username: yourDatabaseUsername
  password: yourDatabasePassword

Of course this is only working in the dev environment but you’d only need to define it for production in the same file by replacing development: with production:

Exploring Ruby on Rails

Ruby on Rails is my latest adventure. At this point, after doing a basic blog tutorial to demonstrate CRUD, it seems like a solid framework. It preempts developer error by not allowing much freedom in how you go about things.

The error messages are full of information and allow a full stack trace or segmented. There are lots of command line shortcuts for instantiating MVCs for any component.

What really impresses me the most is how they’ve abstracted the database layer. It seems completely agnostic in terms of data storage. If you want sqlite3 (default) then leave it alone, MySQL setup involved changing one line in the Gemfile (config) and replacing the database.yml with the credentials for MySQL.

I’ve heard recently that the buzz for RoR is starting to fade but I feel that it is a great thing to have in my toolkit. The speed of development, once you get your head around the MVC, is blazingly fast.

Kia Ora!

So this is the first post on my new development blog.

I’m starting this blog not only for the purpose of extroversion, but lately I’ve been sensing the need to document my progress as a developer.

I’ll probably add my thoughts on different frameworks, languages and lots of notes to myself for configuring dev environments.