Data API Calls

This story is around simple CRUD queries with Postgres DB, running on Hasura.

Let’s pin this down with the story on how my Data models evolved.
Share, test, document & monitor APIs

What is Postman?

From my acquaintance with Postman, I put it in my own words.

Postman is an API tool to build API requests and test the endpoints across Development environments.

From IMAD, I know how crucial it is for the role of developers in the API Economy :)

Of course, you can use a different tool to hit APIs, the one that is featured from IMAD, ‘curl’ to make a GET/POST request.

A curl request to the login end-point of my IMAD app. -v shows the response headers. -X takes in the required REQ method, -H takes the type of the REQ body, — data takes the REQ body and atlast the URL.

Cool thing here is you can even run a curl on a text file hosting the request. Thanks to @tanmaig for the demo.

But, I prefer Postman for the compelling UI and the collections.

What are the Collections anyway?

I would say, its a box to put all your requests in one place and share with your team, a typical corporate logic for large scale API integration.
Its simple to create a collection, just click on the + icon, name your collection, describe it and create it.

You can run collections, clicking on Run and it iteratively goes through a demo of making API requests and rendering the test run response-results.

Sharing Collections: To share collections, you’ve got to sign in with Postman.
Via Embed: Then you can share a Run Embed, that is, a running instance of your collection gets uploaded on Postman servers at the shown URL and a HTML code gets generated, which makes it easy for anybody to import and run your collection from your docs, provided you have got the script embedded in it.
Via Link: This should be really simple. Just get a link and the collection at that point in time is packaged into a JSON and ready to run on some instance of Postman. I use the Documentation Share to publish Postman blogs as my Collection docs.

The HTTPS Layer

The API Gateway fronts the subdomain on Hasura running a TCP service. So your API calls are as safe as ever with SSL encryption to prevent random people from making requests to upstream services.
The HTTP Client is filtered out in the HTTPS layer as shown. This helps defining access permissions for various roles. Another security feature for Postgres is the tunneling via SSH to run SQL commands.

Down to the Ground

For any app, Data API calls are imperative to sustain long-term data, unlike the web-counter we did on IMAD. I give here some insight into API calls I make to Postgres.

Insert User Data

When an user first signs up for my app, I log the user into my DB.

I ask for their Profile name(unlike the username, this is featured when you connect with people), workplace(to extricate users with same names), city, passion with music(their personal tastes and stories) and a self-description spanning a few lines.
I’ve spoken extensively about the must-fill-in fields & here’s the insert query.
For a 200 success response, it affects an “user” row.

Update User Data

I save user stories(their music story and personality briefing) for later. So that they can update these fields on the go, anytime.

Say, the user updates his Music style to Pop later on. I save the updated user_info into my “user” table. For a better view, look into my Postman collection.
I get a success reply for the intended update action.

The Action Arena

This a place for you to ping your friends with requests or affirm a pinging friend :)

Invite your mate to Crashz

Insert a new record into friend relation, and you are done.

I’ve invited 74 to the fair :)

Vouch an invite

Simply flag the confirm to true and you are mutually connected.

Voila, 74 has confirmed. Cool.

The ‘Fetch’ Show

I have already seen to how this works with 2 views — ‘send_an_invite’ (your intended audience) and ‘confirm_invitees’(respond to requests).

Fetch people who you may lend out invites

If you wanna get this notorious list, its simple, as it comes pre-processed in a view for every user indexed by the user_id.

Just get the friend_id corresponding for your user_id.

Fetch people from whom, you are in receipt of an invite

You’ve just got to confirm your friend here and its simple, I’ve a view doing this for me, with a list of friend_ids that a user might confirm to, like a hashmap index.

I give my id and I get a list of friend_ids

Fetch your friends

I recall from the data modeling blog that I just need to feed my hasura_id and it gets me my friends, looking up on the your_friends view.

I get my friends with just my id.
Note: I’ve not actually shown the responses, because, we are dealing with real-time users here and can’t afford to leak data. But the response schema is always at hand with the story on Data Models.

Insert a Song

I’ve no working implementation or ideas for this, but I’m positive that, I’ll come up with some action-plan, hoping the filestore docs come up pretty soon. Though there is a song relation, with primo attributes, as follows :)

Fetch mine or my friends’ songs

I get the complete info pertaining to a song into an UI tab, by just selecting * from songs_likes_comments_info, on songs relevant to my friend’s id or my id, if it were my own songs.

I recall that, every song comes pre-processed with a song_id, song_name & composer_name( just to credit the composer).

Insert a comment or a like

Any record insert into these relations count for a comment or a like. That way, job’s done.

Like inserted into ‘Like’ Table for the song 18 by user 74
This is a comment, with a comment text on the same song.

What would you expect for a response?

A success response reflecting an affected row.

Delete a like

You might want to take your ‘Like’ back, as with people tastes keep floating :)

Delete your like for the song

Get the comments for a song

Comments make user-experience richer, and some songs do have a bunch of associated text in the comments section, referenced by a FK song_id. It’s easy to fetch comments this way :)

Note: Comments for a song can’t be pushed into a view. Its an array relationship, right? I know normalization techniques to some level from IMAD :)

End Note

Please find my postman collection here. Its taken me lot of effort to document the same :)

It’s a Know-Your-Schema approach to first design APIs and then give them justice at the right time with app code integration. I realized this for the day,

Querying is indeed a part and parcel of building APIs.

So Long for the next story :)