DEV Community: Prashanth Krishnamurthy

Commit to blog daily - it's smart and it's stupid

Prashanth Krishnamurthy — Mon, 30 Sep 2019 00:00:00 +0000

Daily blogging by itself is not a bad thing.

I changed tracks a year back to get back to development after a million years of doing something else. I thought through the idea of blogging daily, what I was going to write about, and how that would pan out through days and months.

The premise was simple - learn something, and record that for yourself. The world may benefit from it if it chooses to.

The idea worked out well at the beginning. I started a new blog at techformist.com, and was fairly regular (if not daily).

Thanks to my tech background, I had a few things that I could write about from the very beginning
I was learning at a quicker pace than anticipated. So, I was getting “more stuff” all the time

But, as it is with all things with humans, things slowed down.

I faced the same challenges that I faced elsewhere - I missed out on stuff that I thought was trivial, I regularly failed to record things that I was doing so that I can recall them for future topics, and caught myself worrying about what would be the next big topic to write about.

I could see clear challenges in sticking to the schedule. In hindsight, I should have known better - especially with my “experience” of blogging since a decade on wide range of topics incl. internet marketing, CRM, gardening, humour and more.

But, what was different this time was my stupid determination to see it through. I took a vow to continue with the daily blog for an year (target: 2019-10-15), and re-evaluate the state of affairs at that time.

I took breaks in between running a new company just to stick to schedule. I went completely berserk several times in the last two months to “fill in the gap days”, publish/complete my often incomplete drafts, and fulfil my obsession about this blog being a “daily blog”. I scourged my code for newer tips that I could write about, compared notes with Reddit / Stackoverflow / and even Quora to check what people were asking about, looked at what other daily bloggers were doing, and did everything except visiting a mental health professional.

I wrote-in the topic for 15-Oct last week, and despite loving what I do - I heaved a sign of relief and have made up my mind to stop the current way.

Here’s a run down of things that went right and wrong out of 365 days of blogging.

What went right?

I forced myself to really “see” many things that were otherwise not paid attention to in a “hectic development schedule”. For example: currying in Javascript, reusable functions for memoization or why would someone use maps vis-a-vis an object.
to an extent - I could hold myself accountable to the wider world to churn out new stuff ( world = those who dared to read the blog). Even if the said stuff meant little to them over the course of time. For example, bubble sort, or more than a few posts about how to generate Fibonacci series.
I proved to myself for the umpteenth time that I could stick to boring things just so to see it completed

What went wrong?

Technically, nothing. But practically -

Quality suffered at the expense of number of posts. This should not be the case in an ideal world, but I am not a member of one
Topics tend to focus on solving something small - my whole purpose on the blog seemed to be focused on “satisfying the quota”. This is a wrong approach for learning or for sharing of anything worth sharing. Long-form topics were shunned if I had some catching up to do on the daily blog requirements - and this was (seemingly) all the time
It is ok to blog for self. But you cannot hold attention of readers on small, seemingly adhoc topics (even though the thread of web development holds everything together). Long-form posts are loved and respected by both readers, and as a consequence, by search engines. People read through at the posts for a longer time, seem to appreciate the deeper coverage a bit more, click-through to browse a few other topics, and possibly subscribe to future updates anticipating similar value
It is ok to solve a small problem in a post, but very few readers stick on to browse through other topics
I should have followed up my daily blog with a book, videos or something else. This did not quite happen in the same way that I envisioned it to happen

None of these points are anything new (even for a being like me) but I derive satisfaction in looking back, seeing the bigger picture and to validate, yet again, that the tract of ‘humanity repeating itself’ is intact.

What’s in it for you?

Take-aways for anyone interested in the topic -

You will enjoy blogging daily if you are interested in the topic. You will subject yourself to suffering if you hold yourself accountable to it
Prefer long-form posts and deliver more value within a single post rather than splitting things in multiple posts just for the sake of it
Daily tips are ok, but don’t be afraid to repeat them at the risk of infuriating your loyal readers. Daily blogs are best run through email if you are looking forward to taking your message to the world

A simpler curry for Javascript

Prashanth Krishnamurthy — Wed, 25 Sep 2019 00:00:00 +0000

Here's a simpler way to do curry functions in Javascript.

We have previously seen currying in Javascript. A simple form and application of that concept is demonstrated below -

const addThem = add.curry(2);
const addTotal = addThem(1);
console.log("addTotal: ", addTotal); // 3

Alternatively, we could avoid an external function or library and curry using bindings ..

function add(x) {
  return function(y) {
    return y + x;
  };
}

const addEm = add(1);

console.log(addEm(2)); // 3

But, there is a simpler way to get the same result.

We just use arrow functions to collect arguments at different times.

const add = x => y => x + y;

const addEm = add(1);
console.log(addEm(2)); // 3

We can make the code more readable with a different notation to do the actual curry -

const add = x => y => x + y;
console.log(add(1)(2)); // 3

Of course, you have to rely back on the previously provided example if you don’t have all arguments in one go.

What is GraphQL and why I should use it?

Prashanth Krishnamurthy — Wed, 21 Aug 2019 06:30:00 +0000

Why do I use GraphQL? Also, the case for not using GraphQL.

You must have seen the previous post where I waxed eloquent about how I mess up my Rest APIs. There was no way I would be satisfied doing that to a single technology stack.

Ergo, GraphQL.

What is the need for GraphQL?

Google GraphQL and refer docs- there are smarter people with better answers than me.

But, since the Internet can be a scary place and I love to write about things that I am not an expert in - here's a gist about what I think.

Back to the story..

GraphQL is the SQL for APIs.

Before you say .. 'ah.. I now know everything!', read on.

You see - most of the transactions on the web involve fetching some data or the other.

Clients need to be authenticated, authorised and then request data for those transactions to happen. Servers, which supply the data, will comply with client requests based on pre-defined rules.

Rest is an architectural style that allows you to standardize and streamline client-server requests. You can control resources (accounts, contacts etc.) and the operations (GET, STORE etc.).

So far so good. You may even think that you reached a Nirvana state with what has been described so far, but imagine what would happen if you start a series of requests -

You: Give me contacts
Server: Here are 100 contacts with 501 fields per contact

You: Give me contacts and activities for each contact
Server: Here are 1000 contacts and 1 million activities per contact

You: Give me contact detail
Server: Here you go - 1000 fields of the contact
You: Give me address for the same contact
Server: Oh God, you again? Here's the address. And, can you please stop this madness?

You will see such examples in the real world - the problems described are referred as 'over-fetching' (getting more data than I need) and 'under-fetching' (getting less data than I need).

The properties of over-fetching -

server fetches more data from database (or may query for related entities that are not always required)
more data is pushed through the pipe
client gets more data than required and has to process data to selectively pick and display data.

And, those for under-fetching -

client does not require all data in one-go, requests for related entities or fields
additional network requests and more needless traffic
more time to render UI with complete data

The back & forth between server and client frustrates the server - as seen in above conversation, and more importantly, impacts client-side performance.

The multiple back & forth requests make Rest "chatty".

Ergo, GraphQL.

(I assure you - Matrix has very little to do with me using 'ergo' all the time.)

But really, why do I use GraphQL?

I certainly do not use GraphQL because it -

is the in-thing in web development today
is revered by everyone who say there is nothing more wonderful
is typed, and that makes it so magical
provides a really good looking IDE that makes it so easy to develop the queries
makes services so easy to code (all it needs is a gesture and all the little thingies arrange themselves in perfect harmony)
drastically reduces chatty network traffic and improves the speed to 'burn rubber' levels even before ignition is turned on
uses in-built security rules that makes it so easy to provide role-based authorization
is loved equally by server and client tech stacks
specifies a good abstraction layer for databases
has subscriptions and those are so so amazing
is developed by Facebook. I happen to adore Zuckerberg

Or, I may be using GraphQL for a couple of points mentioned above and that is embarrassing to admit (or downright stupid).

The primary reasons for me to use GraphQL are -

it reduces work on the server-side (surprise, surprise!?). I do not have to write APIs for each and every request, or over-engineer APIs imagining all possible scenarios. Since most of my services are data-heavy, I particularly like the fact that I don't need to maintain a dozen end-points
development iterations are easier on client. I can make adjustments to client code to fetch more or less data
pass only the required data b/w client and server

But, on the other hand -

GraphQL makes it harder to code server-side services (that is just me, not the fault of GraphQL per se).
I also find it harder to control the queries that clients request while they snicker in the background (the developers of the said client, not client-users. Since I am the only developer in many of my applications, I snicker to myself about myself. I need help!).

I find it easier to just enable standard Rest pattern to start with (scaffolded most of the time). Then, I start enabling GraphQL services for specific transactions and go from there.

Err.. what are you even talking about?

Let's see a few examples.

If I need to get a specific contact, I would do the following transaction in REST -

GET https://api.com/contact

The response will be -

data: {
  contacts: [
    {
      planet: "earth",
      name: "Rama",
      age: 42
    },
    {
      planet: "mercury",
      name: "Kris",
      age: 21
    },
    {
      planet: "mars",
      name: "Joe",
      age: 63
    }
  ];
}

I can do the following in GraphQL and send it as a POST request to server -

query {
  contacts(name: "Rama") {
    name
    age
  }
}

The response will be like so -

data: {
  contacts: [
    {
      name: "Rama",
      age: 42
    }
  ];
}

The responses in the two transactions speak for themselves!

What are GraphQL operations? And, why should I care?

No matter what we do in the client-server world - we are trying to do one simple thing -

Share data and business logic b/w server and client

One can query, insert, update or delete data and can initiate those transactions from client. This can either happen -

with the server not caring about the "state" of the client. i.e., client sends request (with authentication incl. as part of request if required), and server answers the call
server keeps client interests in mind, has an open channel with the client, and keeps track of data so that clients get changes as they happen

GraphQL builds a layer on top of a database to assist you to transmit data in both cases.

Query

GraphQL queries help you to fetch only the records and attributes you need - we have seen examples earlier.

You can also include different entities (think 'tables' as an analogy) in the request. Use GraphQL to fetch records with specified relationships, rather than making separate requests for distinct entities.

Mutation

GraphQL mutations are used to insert/change data.

mutation createContact {
  addContact(name: "Joe", age: 100) {
    id
  }
}

The above query provides instruction to use a mutation called createContact that in turn uses addContact to add a contact record with name Joe and age 100.

Subscription

Subscriptions establish a channel between server and client. Clients can subscribe to record updates and get notified (through a simple notification, or by actual 'push' of the data from server) whenever there are changes.

Subscriptions use 'web sockets' under the hood. This is a battle-tested piece of technology that enables real-time data updates to client.

For example - clients can use the below subscription to get the list of contacts who won the lottery.

subscription listenWonLottery {
  wonLottery {
    name
    deals
  }
}

Let's see the flow -

Clients subscribe to contacts
One or more of the contacts get updated in the database when they win lottery
On database update, a notification gets triggered to clients
The notification contains contact's name and deals associated with contact
Client can thereon show a popup with contact name and show flying balloons for effect

What are the different components required to implement GraphQL?

GraphQL is just the language for API and runtime for executing them queries. It is not hardwired to database and does not specify how the database operations need to be executed.

The different components that implement GraphQL stack are below. These components are not part of GraphQL specifications but are just part of the stack that support transactions using GraphQL.

Server

The implementation/tech stack decides how GraphQL is incorporated in the transaction. Server receives GraphQL requests from clients, establishes connection to database, converts graph queries to a language understood by database, fetches results and sends the responses back to clients.

A server may also include the functions expected from a "normal" server -

apply business logic to data
listen to supported types of requests on specified network ports
takes care of all the supporting infrastructure required to serve requests to clients.

Database

Stores data and maintains atomicity, consistency etc. etc. for data. It is a glorified file system that supports individual transactions and does not mess up the data just because the network went kaput, or your client decided to play a game.

Client

Can be a browser, mobile app or anything that requests data from server and consumes server response to do "something". We create GraphQL queries, mutations etc. and send them over in a simple POST request.

What are the terms that I should be familiar about?

Schema

A schema is the building block of GraphQL. It is described using a language that we can understand - it can be any language, but a simple option aptly named "Schema Definition Language" is used in the standard implementation.

Consider the below example -

type Contact {
  name: String
  deal: Deal
}

type Deal {
  description: String
  value: String
}

The schema definition helps a client-side developer to see and understand the relationships b/w data entities, and thereon construct a GraphQL query.

Resolvers

A resolver is a function that returns data in the shape specified by schema.

For e.g. -

const resolvers = {
  Query: {
    contact(root, args) {
      return contacts.filter(contact => contact.id === args.id)[0];
    },
    deals(root, args) {
      return deals.filter(deal => deal.id === args.id)[0];
    }
  },

  Contact: {
    deals: contact => {
      return deals.filter(deal => deal.contactId === contact.id);
    }
  }
};

We use a resolver to write queries, mutations and subscriptions.

Object type / fields

In the GraphQL query outlined above -

Object type is 'Contact' and 'Deal'
Fields are name, description, and value

This is so cool that I slept through the article. Give it to me straight - should I use GraphQL?

Not everywhere.

Use GraphQL when you need to fetch a lot of data having varying shapes / many relationships. Use GraphQL to simplify the data passed between client and server.

At the same time -

Remember that plain Rest API implementations are simpler
Even in data-heavy applications, I do not see a big advantage of applying GraphQL everywhere (except architectural uniformity/ standardization, maybe). For e.g. if you have narrow relationships between entities that do not require related data views all the time
Keep track of how clients use GraphQL - crazy queries can lead to performance issues

Why do I find Rest services simpler?

Endpoint setup is simple on the server. Expose an API or two, and use an ORM to fetch/update data in one or two steps - no sight of fields and related entities anywhere unless you want to deal with them
In addition to the previous point, or supplementing it, is the fact that the tooling is amazing - the technology is so old and supported so well that most of the time it just requires a couple of clicks (or lines of code) to fully set up
I control queries in the back-end - easier control on who accesses the data and how. I also find it easier to solve potential performance issues since I control filters and sort on the server
But all said and done, I may be finding Rest easier since I have spent so much time with it :)

Ok, I am in. Where should I start?

I find the following technology stacks easy to follow and useful to learn for the long run. The recommendations are skewed towards Vue since I use Vue all the time and strongly believe that Vue is easier on beginners.

Enable GraphQL server-side

It is a good idea to create a server on your own and see GraphQL flow in the back-end for real.

Category	Recommended	Remarks
I know SQL and understand DBs	PostGraphile	Refer this
I want to learn more of serverless	AppSync	Sign up for 1-year limited free servers on Amazon AppSync
I want to learn GraphQL using a CMS	StrapiJS	In beta, but good for production
I want to experiment with static sites + GraphQL	Gridsome	New, but promising.
I know PHP	Laravel + Lighthouse
I am looking forward to a long-term relationship	NestJS	Good server capabilities + good GraphQL
I am a master	Guide me towards enlightenment, maybe	What are you even doing here?

Use GraphQL on the client

Vue + Vue-Apollo
Svelte + Apollo.

Also see: create a simple to-do with Svelte + GraphQL

Finis

It ends here :)

Spin up your own local GraphQL server within 15 min

Prashanth Krishnamurthy — Thu, 21 Feb 2019 15:30:00 +0000

Create your own GraphQL APIs in 15 min flat using a Postgres database and a bit of help from PostGraphile. No GraphQL server configuration needed.

No frontend beginner developer ever said - "I want to play around with servers to understand their internals byheart before I venture forth with my beautiful Vue application".

If you are building on REST APIs, you have public services like JSONPlaceholder. These services provide quick access to much-loved sample APIs for to-do, posts, users etc.

There are not a lot of choices if you are building on GraphQL. There have been efforts towards providing such an API in the past but none last long. The solution - create them locally.

Local GraphQL can be cumbersome.

When you start, one may be left wondering on Express + GraphQL + a bit of configuration + write more than few lines of code to get started to serve any new API. There are tools like json-graphql-server that claim to speed up this process. However, they are not kept up to date and seemingly are not meant for Windows(?).

So, I did the next logical thing that was easy and quick. Create an environment of your own using PostgreSQL and PostGraphile.

Initial Setup

Download and install PostgreSQL.
Alternatively use Laragon with Postgres - it is a really good control centre for local development.
Open pgAdmin - the DB admin application for Postgres. Use an existing database or create a new one. Right-click on Schema > Tables and click on 'New Table'. I will assume that you will use a database called 'test'. Create a table called 'todo'.
Create a few columns
Start your very own GraphQL server. The server uses port 5000 by default, but we will change it to 5050 for the heck of it (also because 5000 is used by a few other front-end apps)

   npx postgraphile -c test --watch -p 5050

Start playing around

Go to [http://localhost:5050/graphiql]. Copy/paste the GraphQL statements to perform different operations.

Query data

Query for data. Of course, you will not find anything at this time.

{
  allTodos {
    nodes {
      id
      title
      done
    }
  }
}

The output will be -

{
  "data": {
    "allTodos": {
      "nodes": []
    }
  }
}

Insert data

Insert 'to-do' data in your database.

mutation {
  createTodo(input: { todo: { title: "Create GraphQL server", done: true } }) {
    todo {
      id
      title
      done
    }
  }
}

This statement will create a single to-do, query back id, title, & done fields, and display them at the right-hand side of the screen.

Output -

{
  "data": {
    "createTodo": {
      "todo": {
        "id": 10,
        "title": "Create GraphQL server",
        "done": true
      }
    }
  }
}

You can repeat the query operation and find that it can display data too!

Configure additional APIs

By now you have a full-fledged server that is serving to-dos. You can add filters, do magic on inserts/updates using functions, and eventually find that the world is the limit.

But, what about additional APIs? Similar to to-dos, you can start creating entities and find them available to your GraphQL without any additional effort. That is the magic of PostGraphile.

Why use this setup for local GraphQL environment?

Quicker setup. Type in a few commands + configure DB table - and you are done
Minimal effort to setup new APIs - you are not limited to standard APIs but can go all wild
You can take this to your production environment too. I have used Postgraphile for projects and it rocks!
PostGraphile uses your friendly, neighbourhood Javascript. So we are right at home

You say?

What do you say about this folks? Super..? Stupid? Somewhere in between?
Or, simply "what am I doing on this planet when people like this exist"..?

Originally published at https://techformist.com/spin-up-your-own-local-graphql-server-within-15-min/