diff --git a/_includes/head.html b/_includes/head.html
index 69fdd85..1432c50 100755
--- a/_includes/head.html
+++ b/_includes/head.html
@@ -3,7 +3,7 @@
- {% if page.title %}{{ page.title }} - {% endif %}{{ site.title }}
+ {% if page.title %}{{ page.title }} - {% endif %}{{ site.title }}'s logs
diff --git a/_posts/2016-02-19-graphql.md b/_posts/2016-02-19-graphql.md
new file mode 100644
index 0000000..255fa95
--- /dev/null
+++ b/_posts/2016-02-19-graphql.md
@@ -0,0 +1,154 @@
+---
+layout: post
+title: "On GraphQL"
+excerpt: >
+ First impressions on GraphQL. Growing community, tooling, and
+ languages support. It could be a win!
+---
+
+**Disclaimer:** This is not a GraphQL tutorial or a getting started guide.
+
+Late last year, I happened to come across a point where I had to soon, begin work
+on a greenfield project. It required both web & mobile apps. I was a ruby guy and
+so I decided straight away that my server will be powered by ruby. But I was
+looking for a good client side solution that'll help reduce the learning curve
+for building for both web and mobile since I haven't done any native iOS or
+Android programming. I ended up with React, React Native as they seemed like it
+fit the bill wrt to the project. And then, when I was reading more, this happened:
+
+`React --> Relay --> GraphQL`
+
+I landed up reading about GraphQL and it gave me a good first impression.
+
+Here's what it is, from the official homepage:
+
+> GraphQL is a data query language and runtime designed and used at Facebook to
+request and deliver data to mobile and web apps since 2012. -- [graphql.org](http://graphql.org)
+
+Though Facebook has been using it since 2012, it was released as an open source
+RFC with a reference implementation in javascript (obviously), only last year.
+So it was already running almost 2-3 years in a heavy-traffic production environment.
+
+__TL; DR:__ *GraphQL aims at replacing your REST endpoints.*
+
+## What?
+
+Client specifies a *query string*. Server interprets it and returns data in the
+specified format. Let's take the following example.
+
+Sample query:
+
+~~~ graphql
+{
+ user(id: 3500401) {
+ id,
+ name,
+ isViewerFriend,
+ profilePicture(size: 50) {
+ uri,
+ width,
+ height
+ }
+ }
+}
+~~~
+
+returns:
+
+~~~ graphql
+{
+ "user" : {
+ "id": 3500401,
+ "name": "Jing Chen",
+ "isViewerFriend": true,
+ "profilePicture": {
+ "uri": "http://someurl.cdn/pic.jpg",
+ "width": 50,
+ "height": 50
+ }
+ }
+}
+~~~
+
+*(Example taken from the official GraphQL docs)*
+
+That's it. Client gets exactly what it asked for. The query string itself, looks
+like how the data it wants to be like and IMO, this looks and feels very
+intuitive
+
+## How?
+
+I've always had a small problem trying to wrap my head around HTTP verbs for
+laying out the right way to structure my REST API. When you talk GraphQL via
+HTTP, it essentially replaces your multiple REST endpoints to a single endpoint.
+This is insanely sane. Imagine fetching data for a mildly complicated view. REST
+would require multiple round trips between the client and the server to render
+that single view. With GraphQL you make one HTTP call. The GraphQL server knows
+what all queries it needs to aggregate and run in order to get what the client
+asked for, like the above example. It's naturally parallelizable and you can
+scale it however you want.
+
+One important point to note here is that, GraphQL is only an *application layer
+protocol* and that makes it even more powerful. It's not coupled to any specific
+transport layer, in other words, no one says it should work only via HTTP.
+
+This is especially important in today's world where we're moving beyond web and
+mobile.
+
+## Tooling
+
+You'd expect only modern tooling from modern technologies and GraphQL is no
+different. [GraphiQL](https://github.com/graphql/graphiql) is an in-browser IDE
+for exploring GraphQL. Checkout the [live demo](http://graphql-swapi.parseapp.com).
+It's super awesome and self-documenting. This would be your most used tool if
+you're working with GraphQL. It's really a killer stuff to have.
+
+Tooling in GraphQL makes use of the types and introspective capabilities of the
+spec. Take a look at the [awesome-graphql](https://github.com/chentsulin/awesome-graphql)
+repo for more and more tooling.
+
+## Community
+
+GraphQL will win only if the wider community adopts it. Whatever is your primary
+language, you should be able to talk to the GraphQL servers.
+
+I now come from the [Elixir](http://elixir-lang.org) community and I can assure
+you that there's some good work going on. Visit
+[graphql-elixir.org](http://graphql-elixir.org) for more info on that aspect.
+But I believe there are faster or equally growing communities like
+[Ruby](https://github.com/rmosolgo/graphql-ruby),
+[Python](https://github.com/graphql-python/graphene) and other languages. I'm
+planning to write a subsequent post on GraphQL from an elixir community viewpoint.
+
+Firstly, if you want to get started, you should definitely go through the
+[RFC](http://facebook.github.io/graphql) and the
+[official docs and notes](http://graphql.org) around it. You'll understand more
+about GraphQL and why Facebook built it in the first place. Then find out on-going
+efforts regarding GraphQL from your community (hint: checkout the awesome-graphql
+repo I linked above). Try to understand what % of the spec is implemented and
+what is the community focusing on next. Try to contribute, build small projects
+using GraphQL so that you unravel difficulties along the way and likely provide
+solutions to solve them too.
+
+## More
+
+There's more to GraphQL than all this. As of this writing, I wouldn't say
+GraphQL is super mature for production, though its been running on Facebook's
+servers for the last 2-3 years. This implies there are so many other things
+revolving this that requires attention. For ex: the official spec doesn't say
+how to perform pagination, etc. There's no official way to do
+authentication/authorization. I'd argue that GraphQL is just a query language
+and it's up to each app to figure out it's auth story.
+
+More on the postive side, this kind of abstraction provides us with a huge power.
+You can decouple your stack in a way you couldn't have imagined previously. A
+good example is [Meteor](https://www.meteor.com). It's a lock-in and super
+highly opinionated framework. They recently realised that GraphQL could help them
+be more less opinionated. The MDG is focusing on a new framework called Apollo
+that makes use of GraphQL to achieve an awesome abstraction. Read more about it
+[here](http://github.com/apollostack/apollo).
+
+If this piqued your interest in any way, I strongly urge you to try it out in
+your primary language. The best part is, you can incrementally move to GraphQL
+and it could just work as an abstraction layer on top of your already up and
+running implementations.
diff --git a/index.html b/index.html
index 287c41a..f680af4 100755
--- a/index.html
+++ b/index.html
@@ -1,6 +1,6 @@
---
layout: default
-title: logs
+title: home
---