DEV Community: Musthaq Ahamad

Use any app as your backend API instantly

Musthaq Ahamad — Sat, 10 Feb 2024 12:21:57 +0000

Building on a new idea can be very exciting, but the moment you want to get access to APIs of third party SaaS, it becomes borderline frustrating. This is the case with integrating most of the apps out there, be it Google sheets, Slack, Airtable, HubSpot or more.

Well, you are not alone if you relate with this problem. While building a lot of my projects, this was the case with me and my friends. We spent hours trying to get things to work with other apps, rather than actually building the app.

Building apps without writing a single line of backend code

You would be surprised to know about projects minting revenue in thousands of dollars out there started with just Google sheets as a backend!

Level.fyi scaled to millions of users just with Google Sheets as a backend. Nomadlist.com started with Google Sheets as a data store for the website. There are tons of examples out there, having third party apps as a backend or database can help you build and validate ideas faster.

API Integrations take time and effort

While using any of these third party SaaS with your app, it takes quite a lot of effort in most cases.

You have to set up OAuth apps, or go through API Consoles to get access to APIs. In some cases, you might have to even verify the app with the platform to start using the APIs.
You need to spend hours going through the API docs and figuring out how to use the APIs.
Once you have figured out the APIs, you have to spend time on setting up an API client like postman to test out the APIs
If you are using APIs via OAuth, you need to write code to manually store the refresh tokens, and mechanisms to refresh the tokens.
Due to security reasons, you cannot expose these APIs directly to frontend without writing backend.

While building apps with Google Sheets, Airtable, or other SaaS as a backend sounds easier, the process of getting the APIs aren’t so friendly.

Using Apico to use any app as a backend API

From being frustrated about the time and effort we are spending on integrating APIs and to write code that handles OAuth mechanisms, we built Apico!

Apico is a no-code API development platform which can help you get access to these third party SaaS APIs instantly. It also comes with some sweet features to help you focus on building your app rather than wasting time figuring out integrations.

Not just APIs, Apico provides a full-blown API explorer and a powerful proxy with fine-grained access controls to help you get hands-on with the API in seconds. To use the APIs without any backend, you can lock the APIs you don’t want to expose to the frontend easily within a single click. This way, you can use APIs within your frontend or no-code apps easily.

You can sign up to Apico and quickly create API for some of the most popular apps out there. Here are some of them -

Google sheets
Airtable
Hubspot
Slack
GitHub
Google Calendar
Shopify
and more…

Large Scale Geospatial Visualization with Deck.gl, Mapbox-gl and Vue.js

Musthaq Ahamad — Wed, 26 Feb 2020 10:43:05 +0000

Geospatial visualization and analytics can open up lots of opportunities for any company which collects location data. More than any external data, internal data can help much more in growing your products. Understanding the patterns, affluence and much more can help you aid in forming effective marketing, distribution or utilization strategy. We all do not doubt data being the driving force of growth in startups, but most of the time location data ends up as just another column in your CSV files.

Maps can add an invaluable component of location context into your data. They help you understand the where from your data, which otherwise ends up as just latitude and longitude columns. Seeing things on a map gives much more valuable information about how your entities move and interact with your on-ground assets. Let's see how we can build beautiful large-scale visualization on the web using Vue and deck.gl.

What is Deck.gl?

Deck.gl is Uber's opensource visualization framework. It helps to build high-performance GPU powered visualization on the web. It is built to handle large-scale datasets without much performance issues. Deck.gl is part of uber's opensource visualization framework suite vis.gl.

Deck.gl follows a reactive paradigm which makes it extremely easy to integrate with modern UI development libraries and frameworks. The vis.gl suite comes with a React.js wrapper, but we'll be using the @deck.gl/core sub-module which doesn't have React dependency and will be integrating it with Vue.js components.

Installing Dependencies

We'll be using Mapbox-gl for rendering maps and Deck.gl for visualizations in an existing Vue.js application. Deck.gl has out-of-the-box support for React, this article will be mainly focused on building an application using these technologies with Vue.js.

Use the following command inside a bootstrapped Vue.js application to install the dependencies.

$ npm install --save mapbox-gl @deck.gl/core @deck.gl/layers

Working with Deck.gl and Mapbox-gl

There are two main ways we can use Deck.gl with Mapbox-gl in a Vue.js application.

By using Deck.gl layers as custom Mapbox layers
By using Mapbox as a base map and overlaying Deck.gl canvas

We'll discuss how we can build an app with both of these methods.

Using Mapbox's custom layers

The @deck.gl/mapbox sub-module helps us create Deck.gl layers that can be used as custom Mapbox layers. It's the easiest way to work with both the libraries but comes with some known limitations. This particular method is still experimental and can cause unexpected bugs. This method is not recommended if you have layers that need frequent updates/rerendering.

By using this method we can tap into the full-power of Mapbox's visualizations and interleave Deck.gl layers with Mapbox Layers to create beautiful visualizations.

We can simply create a Mapbox instance in a component, and add the deck.gl layer as a custom layer.

1. Creating the map

We can use the mapbox-gl library to quickly add a map inside our component.

<template>
  <div class="container">
    <div id="map" ref="map"></div>
  </div>
</template>

<script>
import mapboxgl from "mapbox-gl";
export default {
    data() {
        return {
            accessToken: process.env.VUE_APP_MAPBOX_TOKEN,
            mapStyle: "mapbox://styles/haxzie/ck0aryyna2lwq1crp7fwpm5vz",
            mapData: "https://raw.githubusercontent.com/johan/world.geo.json/master/countries.geo.json",
            latitude: 35.4832668,
            longitude: 12.9491635,
            zoom: 10,
            bearing: 0,
            pitch: 0,
        };
    },
    created() {
        // creating a non reactive map object
        this.map = null;
    },
    mounted() {
        // initialize the map
        this.map = new mapboxgl.Map({
            accessToken: this.accessToken,
            container: this.$refs.map,
            style: this.mapStyle ,
            center: [this.viewState.longitude, this.viewState.latitude],
            zoom: this.viewState.zoom,
            pitch: this.viewState.pitch,
            bearing: this.viewState.bearing,
        });
    },
}
</script>

<style lang="scss">
.map-container {
  width: 100%;
  height: 100%;
  position: relative;
  overflow: hidden;
}
</style>

2. Attaching the deck.gl MapBox Layer

Using the @deck.gl/mapbox module we can create a custom Mapbox layer and include a deck.gl layer within. Once you add them both, the component should look like this, and you are ready to go!s

<template>
  <div class="container">
    <div id="map" ref="map"></div>
  </div>
</template>

<script>
import mapboxgl from "mapbox-gl";
import { GeoJsonLayer } from "@deck.gl/layers";
import { MapboxLayer } from "@deck.gl/mapbox";

export default {
    data() {
        return {
            accessToken: process.env.VUE_APP_MAPBOX_TOKEN,
            mapStyle: "mapbox://styles/haxzie/ck0aryyna2lwq1crp7fwpm5vz",
            mapData: "https://raw.githubusercontent.com/johan/world.geo.json/master/countries.geo.json",
            latitude: 35.4832668,
            longitude: 12.9491635,
            zoom: 10,
            bearing: 0,
            pitch: 0,
        };
    },
    created() {
        // creating a non reactive map object
        this.map = null;
    },
    mounted() {
        // initialize the map
        this.map = new mapboxgl.Map({
            accessToken: this.accessToken,
            container: this.$refs.map,
            style: this.mapStyle ,
            center: [this.viewState.longitude, this.viewState.latitude],
            zoom: this.viewState.zoom,
            pitch: this.viewState.pitch,
            bearing: this.viewState.bearing,
        });
        this.loadLayer();
    },
    methods: {
        loadLayer() {
            // create a new MapboxLayer of type GeoJSON Layer
            const layer = new MapboxLayer({
                id: 'geojson-layer',
                type: GeoJsonLayer,
                data: this.mapData,
                filled: true,
                lineWidthScale: 20,
                lineWidthMinPixels: 2,
                getFillColor: d => [245, 133, 5, 0],
                getLineColor: d => [245, 245, 245],
                getLineWidth: 1,
            )};
            // add the layer to map
            this.map.addLayer(MapboxLayer);
        }
    },
};
</script>

<style lang="scss">
.map-container {
  width: 100%;
  height: 100%;
  position: relative;
  overflow: hidden;
}
</style>

Using MapBox as base map and Overlaying Deck.gl

In this method of using deck.gl we are using MapBox as just a base map to render the maps and deck.gl for visualisations and interactivity. We give full interactivity control to deck.gl so that every zoom, pan, and tilt happening to the deck.gl canvas will be reflected upon the base map. By far, this is the most robust implementation of deck.gl we can use in production.

1. Setting up the template

While building a component in the above-mentioned method, we need to add both deck.gl canvas and mapbox-gl element to the template. And make sure, the deck.gl canvas stays atop of the mapbox element.

<template>
  <div class="deck-container">
    <div id="map" ref="map"></div>
    <canvas id="deck-canvas" ref="canvas"></canvas>
  </div>
</template>

<style scoped>
.deck-container {
  width: 100%;
  height: 100%;
  position: relative;
}
#map {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  background: #e5e9ec;
  overflow: hidden;
}
#deck-canvas {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}
</style>

2. Connecting MapBox-gl and Deck.gl Instances

Next, we need to initialize both the map and deck.gl instance in the component and connect the interactivity. We can use the mounted hook to initialize both of them and assign them to a non-reactive variable for future use-cases.

import { Deck } from "@deck.gl/core";
import mapboxgl from "mapbox-gl";

export default {
    data() {
        return {
            viewState: {
                latitude: 100.01,
                longitude: 100.01,
                zoom: 12,
                pitch: 0,
                bearing: 0
            }
        }
    },
    created() {
        this.map = null;
        this.deck = null;
    },
    mounted() {
        // creating the map
        this.map = new mapboxgl.Map({
            accessToken: this.accessToken,
            container: this.$refs.map,
            interactive: false,
            style:
                this.mapStyle || "mapbox://styles/haxzie/ck0aryyna2lwq1crp7fwpm5vz",
            center: [this.viewState.longitude, this.viewState.latitude],
            zoom: this.viewState.zoom,
            pitch: this.viewState.pitch,
            bearing: this.viewState.bearing,
        });

        // creating the deck.gl instance
        this.deck = new Deck({
            canvas: this.$refs.canvas,
            width: "100%",
            height: "100%",
            initialViewState: this.viewState,
            controller: true,
            // change the map's viewstate whenever the view state of deck.gl changes
            onViewStateChange: ({ viewState }) => {
                this.map.jumpTo({
                    center: [viewState.longitude, viewState.latitude],
                    zoom: viewState.zoom,
                    bearing: viewState.bearing,
                    pitch: viewState.pitch,
                });
            },
        });
    }
}

3. Creating and Rendering Layers

Since deck.gl has an internal interactivity built-in, we can simply set the layer props of the deck.gl instance and it'll render the layers efficiently. We need to trigger this rerender by using deck.setProps({}) whenever the layer's data is being changed. The below example illustrates well how to achieve this.

import { PathLayer } from "@deck.gl/layers";

export default {
    data() {
        return {
            // all your data properties
            pathData: [
                {
                    path: [[100, 10], [200, 30]...],
                    color: [255, 255, 255, 50]
                },
                ...
            ] // some geo data
        }
    },
    computed: {
        // a reactive property which creates the layer objects whenever the data is changed
        getLayers() {
            const paths = new PathLayer({
                id: "path-layer",
                data: this.pathData,
                widthScale: 20,
                widthMinPixels: 2,
                getPath: d => d.path,
                getColor: d => d.color,
                getWidth: d => 1
            });

            return [paths]
        }
    },
    methods: {
        renderLayers(layers) {
            // setting the layers to deck.gl props
            this.deck.setProps({
                layers
            })
        }
    },
    watch: {
        // whenever the layer data is changed and new layers are created,
        // rerender the layers
        getLayers(layers) {
            this.renderLayers(layers);
        }
    }
}

You can even abstract this method to be just used for rendering and make it a separate deck.gl wrapper component. Once you have this component ready, you can compute the layers outside the component and pass it as props to your deck.gl wrapper component.

You can learn more about deck.gl and it's APIs at deck.gl

Love reading about GeoSpatial visualizations? Stay tuned for more in-depth articles about how you can use deck.gl in your applications in production.

Hi there! I work as a UX Engineer at Locale.ai solving Geo-Spatial problems for our B2B customers. If you think you love solving UX problems for users, love designing and want to work with a team of enthusiastic individuals, check out the job openings we have at Locale.
Wanna talk? You can find me on Twitter, Instagram and GitHub.

Originally published on haxzie.com

The Chicken and Egg problem in building digital products

Musthaq Ahamad — Sun, 12 Jan 2020 14:43:58 +0000

"Which came first? Was it the chicken or the egg?"

This is a known paradox we all have came across throughout our lifetime so far. Still, most of us might not have a good answer to this. This is not just a question, but a strategy problem exists in different industries and fields. Just like how we all used to blame "You need experience to get a job, but you need a job to get experience". In beautiful words, the chicken and egg problem can be described as:

"The dependency of value proposition of two separate entities on penetration into each other"

In Digital products this is a pretty common problem. Here are a few examples to get a better understanding of this

If you don't have good product reviews, users won't buy online and if users don't buy your products, you won't have reviews.
If you don't have apps for your platform, users won't use it. If only users are present in your platform, developers will build apps.
If you don't have good posts on your social media platform, users won't use your platform. if you don't have users, there won't be any good posts/contents.

How to solve this?

If we look around, there are few well-known methods to solve "Chicken and Egg" strategical problem. We'll talk about some of these strategies here, which can be easily understood.

1. Bribing the chicken

Yes, you heard it right! bribing some of those chickens is one way to quickly get some eggs!

Here is a good example of bribing the chickens. Men goes to pubs to meet attractive women, and women goes to pubs to find successful men. This is clearly a chicken and egg problem. So, they simply solved it by making the entry free-of-charge for women, but charge men. In other words, bribing women to get into pubs, since it is free for them, and attract men to come join them. Result? Profit!

In digital products we have seen it everywhere. Amazon Alexa incentivizing developers with swags for building Alexa skills, so that it can attract users. Something what Trell, a social media for travelers did to attract users is to pay some initial users to post good contents related to travel and tourist destinations.

This is the easiest way of solving the problem, but it's really common. Just like how the founders of Reddit used to do when Reddit was in its initial stages. Alexis Ohanian, co-founder of Reddit had around 5-6 accounts which he used to post links and upvote the links on Reddit. Just to make sure the site looks active :)

2. Sacrificing the egg

Sacrificing the egg means, giving away the eggs so you can get the chickens. In other words, making the eggs dead cheap so that people starts buying it and it turns out to grow more chickens.

Well, if we look at how printers are being sold, we can understand this clearly. Most of the companies sell their printers for near to no profit or even at a loss. But, the profit is gained by selling the refill cartridges. More the people buy printers, more the cartridges they buy to use with the printers. If we look carefully, most of the printer cartridges are overly priced, just to overcome the sacrifice the companies made while selling the printer.

Jio, one of the biggest mobile service providers in India has done it beautifully. India had less than an average number of population with smartphones or devices which could use 4G networks. Jio made mobile phones cheaper than ever to get these users onboard and sold them 4G data packs in plenty. They even went another way of completely making the data packs free to get more users with smartphones to use their services.

3. Selling both the chicken and egg to a farmer

If two of the above solution didn't work. The final hope is to make profit by selling both the chicken and egg to a farmer who already have chickens and eggs. Confused?

Introducing the product to a market which already have both the chicken and the egg to spare can solve the problem. Here, you aren't making profit by selling chicken or egg but the idea! You have an amazing startup idea, but it has the typical chicken and egg problem. Instead of solving this problem by yourself, you sell the startup to a company who already have solved the chicken and egg problem.

If you are building a social network, selling your product to another social media company. If you are trying to build an e-commerce platform, selling your platform to another e-commerce company who already sorted their problems. This doesn't always needs to be "selling" your idea or the company, it can be just partnering with other companies who already have the users or the content to solve your "chicken and egg" problem.

Coming back to the printer problem. You find people who are in need of the both printer and its cartridge. think of them as the chicken and egg to someone who already needs it. A farmer? in our case places where the printer is most used! Selling printers to corporate offices, schools and government organizations where they are ready to pay for both the printer and its cartridges.

Considering the case of Jio too, when Jio invaded the mobile service provider market, most of the other service providers were pushed to near bankruptcy. What they did was, merge with other service providers to become one. So that there becomes more customers under a single company instead of two different ones.

This is part of one of the many articles from my startup Journal. Stay tuned for more!

Originally posted on haxzie.com

From Thoughts to Visuals - What Design Means to Us!

Musthaq Ahamad — Tue, 29 Oct 2019 10:53:35 +0000

Design is everywhere. Good design can solve complex problems by abstracting away the complexity from users. I have always been fascinated by how design blinds complexity with beauty , simplicity , and clarity.

Before taking up my first job as a UX Engineer at Locale.ai, I was curious about how visual design in digital products makes human interactions natural, and how these designs align with human psychology to make the experience seamless.

At Locale, I got the opportunity to work hands-on on crafting the ideal experience, look and feel for our users at every step of the way. After all, it is really exciting to be an integral part of a journey where the path itself is defined by you.

In this blog post series, I’ll talk about the lessons learned on every major decision we took in terms of design and research and the steps we usually follow whenever we are solving a design problem.

1. Understanding the Problem

“A problem well stated is a problem half solved”

— Charles Kettering, Head of Research at GM

The most important step before solving any problem is to understand the problem in depth. Be sure about what you are building and more importantly why you are building it.

Because you don’t want to end up designing combs for the bald. It’s also part of understanding the problem to do more research on available solutions, how they built it and why there is a need for something better.

To give you a better example, if you are building a product similar to Uber, you should always ask yourself and the customers you are targeting , why would anyone use your product instead of Uber?

What are you doing better that will ultimately make users shift from Uber to your product? If you are not innovating in a market that’s well established, it will be really hard to sustain a product.

Your solution to the problem lies in your market. All the above pointers can be summed up to the term “ Finding the Product Market Fit ”, which is identified as a first step to building a successful venture in which the company meets early adopters, gathers feedback and gauges interest in its product. You can read more about Product Market Fit from the YC Blog to understand your market better.

2. Understanding your Users

“Design isn’t finished until somebody is using it.”

— Brenda Laurel

Design is not just about making things beautiful, it’s the art of making things usable and intuitive. If you are not aware of the people using your product, their habits, their secret desires, it will be nearly impossible to build something that your users will love!

This is why User Research is one of the most important parts of designing a better User Experience for any product. It’s all about knowing your users as much as possible — What do they do? How will they use your product? How much do they need your product? How much does your product solve their problem? How long will they usually use your product?

As far as design is considered, it is an iterative process. You are not likely to hit a perfect “Mona Lisa” in your first shot. As Salvador Dali said, “Have no fear of perfection, you will never reach it”.

Your designs should incorporate your users in every step with a continuous feedback loop. Sit together with them while they use your product, ask them to think out loud while they navigate through your product. Of course, this will only happen when you have a product (or an MVP) to show your users. We’ll talk more about that in-depth in upcoming sections.

Also, always keep in mind that you are biased!

Your problems are not the same as your user’s problem. They are different. It’s common practice to assume what your ideal users look like and what they need and you should stop doing that. The only way to know what your users need is to directly talk to them and prepare User Personas.

A user persona is a fictional version of your ideal customer. It can be more than one type, but it should be detailed so that it communicates the user's needs effectively and helps you understand your users better.

Once you have a user persona, it will make the target users memorable to your product team throughout the journey and help them align to designing what your users needs. Keep in mind, having more than two user personas is not ideal since it will create confusion and create a gap between the understanding of your ideal user.

Whenever you are planning to design a new feature, always ask this question to yourselves, your team and your users, “Do we need it?” It’s common for some people to just keep implementing new features without even understanding the need, urgency and impact.

This might also cause problems if you are not concentrating on the priorities of solving the problem. You don’t need bells and whistles if your train isn’t running.

3. Researching for Existing Solutions

“The next big thing is the one that makes the last big thing usable.”

— Blake Ross, Co-creator of Mozilla Firefox

You don’t need to reinvent the wheel. Whenever you are designing something, it’s highly likely that someone else has already tried. There might be an existing solution, or there might be something similar to what you are designing.

Explore the interwebs and find lots of inspiration. If you are designing a product, look at your competitors and find out how they have already solved the problem.

While designing products, especially digital products, you need to keep an eye on every small detail of your product. Follow the standard principles as possible.

Designing a login screen? Make sure you read about best practices. Designing a complex form? Make sure you learn about the steps or methods involved in breaking them down and making it easier for the user.

Finding inspirations from the internet can be a double-edged sword most of the time. A really good visual design might not always be easily implementable. Or, all those eye-candy UI interactions you see on Dribbble or Pinterest might not make any sense when you consider the UX.

Photo by Harpal Singh on Unsplash

You need to look into both the sides, the good and the bad. If you are researching existing products or methods, make sure you also learn about their limitations and drawbacks. This will give you a fair advantage in designing better products.

Keep note of the interesting and best design decisions that you have found during your research. Learn about why those decisions are made and what were the trade-offs of implementing that design.

Before you start designing anything, think about your users. Think how will they use it, run the design outcomes with the user personas and have a chat with your team or a user to know whether they like those designs.

4. Action! Building a Prototype.

“Design is intelligence made visible”

— Alina Wheeler

It’s time to bring your research to life! Once you have gathered enough insights and built an ideal mind map of the design, it’s time to see it in action. Being a UX designer, there are tons of tools in the wild which will make your lives easier.

If you have a little experience in programming, you might have heard the term “ Think twice, code once!”. As a UX Engineer, who designs and converts ideas to life, it’s important for me to experiment a lot with designs before delving into code. Even before finalizing a design and handing over to the developers, it is important to do it inside a feedback loop.

Gain mastery in tools like Invision, Figma, Adobe XD, Sketch, etc. to quickly build a mock-up of what’s in your mind. If you are working in a startup, you will be always racing against time. Experimenting ideas real quick and gathering feedback will help you refine the ideas into working prototypes fast.

Photo by Hal Gatewood on Unsplash

If you are only designing, make sure to gain feedback from the developers to know about the feasibility of implementing such designs from the initial phase itself. This will help the team to build out features even faster without leaving any gap for miscommunications.

If you are new to UX designing, make sure every major feature you have prototyped hits the perfect feedback flow before landing into the actual product.

It is also important to understand how certain aspects of visual elements are to be designed based on any given context. For example, whether to use a drop-down or radio buttons, tabs or side navigation, lists or grids, and more.

There are many research articles from famous designers on these concepts. Make sure you have done a fair amount of googling when you feel a bit ambiguity on which element suits good to implement and where. We’ll have a detailed discussion about some of these concepts in my upcoming posts.

If you are building for the web, I’d highly recommend reading the book “Don’t Make Think” by Steve Krug. He explains best practices in web usability and gives a better understanding of how people use the internet.

5. Feedback and back to the loop.

“I think it’s very important to have a feedback loop, where you’re constantly thinking about what you’ve done and how you could be doing it better.” — Elon Musk

Feedback is crucial to shaping your design to match your user needs. But keep in mind, not all the users are the same. Every user you have will be unique.

If you are building for the web, you can never be sure about what your users think while using your product. There might be users who are really experienced with using the internet, or there might be people who just got into using the internet.

There are people who don’t like certain colors, and there are people who just prefer one color of their choice everywhere. It will be chaos if you go out to design for everything. This is where the common design principles come into picture followed by user feedback.

Make sure your designs are accessible for the vast majority of your users with no modifications. Whenever you get the feedback, thoroughly evaluate the response if it affects just a group of people or is it something that affects every user. Always try to include changes that are targeted to everyone and not to just the majority of your users.

You know too much about your product and its design. But when you get feedback from a user who has never seen or used it, it is likely to be unbiased. But, it’s not just the users who will give you feedback. As a designer, everyone in your team will have their own imagination of the product.

All you gotta do while having a design review is, not to lead it to a religious debate. What I meant by religious is; the CEO, the marketing team, the developers and the designers have a different perspective of designing a product.

Sometimes, the feedback reviews tend to be about their own personal preference without any principles to back it up. This is where you need to quickly test out the theories.

Testing is inevitable when it comes to having a good design. There might be a lot of disagreements on what’s acceptable, what’s not, what needs to be incorporated and what needs to be left behind.

In such situations, designing an alternate version quickly and testing it out with more feedback from users will solve the problem. There might be a few ideas and feedback suggestions that will play out to be better than the current design. Even though it might not make sense to us in the first place, testing the theories does put an end to unwanted arguments and discussions.

With all the feedback you have gained, analyzing them and prioritizing it for new changes.

And…the loop continues!

What’s Next?

We’ll dive deep into more concepts related to User Experience design and how User Research helped us to improve our product. These concepts we discussed here for User Experience design will stay as a cornerstone for upcoming posts. Meanwhile, if you liked the article, show us some love ❤

To, get a better understanding of what we do, read more about the unexplored territories of Geo-Spatial Analytics here:

How analyzing supply-demand gaps can optimize your unit economics!

Hi there! I work as a UX Engineer at Locale.ai solving Geo-Spatial problems for our B2B customers. If you think you love solving UX problems for users, love designing and want to work with a team of enthusiastic individuals, check out the job openings we have at Locale.

Wanna talk? You can find me on Twitter, Instagram and GitHub.

Originally Posted on haxzie.com

Cover photo by Joanna Kosinska on Unsplash

Architecting HTTP clients in Vue.js applications for efficient network communication

Musthaq Ahamad — Sun, 20 Oct 2019 12:27:18 +0000

Modern web apps highly rely on network communication with API servers and external services. From real-time data to static assets, everything is done through the network connection. It is important to design the network interface layer or the HTTP client which helps your application to call the API endpoints to be efficient and robust. In this article we'll discuss ways to design the HTTP clients and making network requests in your Vue.js application, considering some of the best practices and techniques.

We'll look into the following concepts in detail and how to implement them in our application. I prefer using Axios since it gives more flexibility, control, and has an exceptional browser and node.js support.

Creating HTTP Clients using axios instances
Structuring your API endpoints
Making network requests inside Vuex actions
Managing Auth Credentials using interceptors
Handling network errors and logging
Caching and Throttling

Before we start, the code snippets below are written keeping Vue.js developers in mind. But, these can also be used for React or any other frontend library/framework.

This is the second part of the "Architecting Vue application" series. You can find the first part here where I talk about how to Architect Vuex store for large-scale Vue.js applications.

1. Creating HTTP Clients using axios instances

Axios provides out of the box support for having a persistent configuration for all of our API calls using axios instances. We'll be using axios instances as HTTP clients in our application with our configurations. If you are working on a large scale application, it is possible that your application needs to communicate with different API endpoints. In this case, we might need to create multiple axios instances, with its own configuration and separate them out to individual files.

Install axios in your project

$ npm install --save axios

Import axios into your project

Considering best practices, it is recommended to add API URLs into .env files while developing large scale applications. In Vue.js applications, to be able to access the env variables inside your project, we need to prefix it as VUE_APP_. So, if you want to save BASE_URL, create a .env file in the root of your project directory and add the following line.

VUE_APP_BASE_URL=https://myApiServerUrl.com

Once we have our environment variables in place, we can retrieve them while creating axios instances. We can additionally pass all our configuration into this instance, including headers and use this instance to create HTTP requests.

import axios from axios;

const httpClient = axios.create({
    baseURL: process.env.VUE_APP_BASE_URL,
    headers: {
        "Content-Type": "application/json",
        // anything you want to add to the headers
    }
});

export default httpClient;

One more thing to keep in mind, Axios by default has the timeout set to 0, which means no timeout. But in most cases, we need to set request timeouts in our application along with a retry period. We will discuss how to retry a failed request in the below sections but you can change the default timeout of our httpClient while creating it.

const httpClient = axios.create({
    baseURL: process.env.VUE_APP_BASE_URL,
    timeout: 1000, // indicates, 1000ms ie. 1 second
    headers: {
        "Content-Type": "application/json",
    }
});

2. Structuring your API endpoints

As per REST design principles, most of our endpoints might have CURD operations associated with it. So, grouping together the endpoint with all it's request methods is one way to organize your API calls. We can import the required HTTP-client and export all the required requests as methods. Here's an example of grouping all the requests related to Users into a single file.

import httpClient from './httpClient';

const END_POINT = '/users';


const getAllUsers = () => httpClient.get(END_POINT);

// you can pass arguments to use as request parameters/data
const getUser = (user_id) => httpClient.get(END_POINT, { user_id });
// maybe more than one..
const createUser = (username, password) => httpClient.post(END_POINT, { username, password });

export {
    getAllUsers,
    getUser,
    createUser
}

We can follow a simple directory structure for storing all these files.

api/
  ├── httpClient.js  --> HTTP Client with our configs
  ├── users.api.js
  ├── posts.api.js
  └── comments.api.js

And we can use them in our Vue.js components and Vuex store by simply importing them.

import { getAllUsers, getUser } from '@/api/users.api';

3. Making network requests inside Vuex actions

Moving all the business logic into Vuex store, including all of your network requests makes the view components independent. We can use actions in our store to fetch the data and store it in the state object. Vuex actions are synchronous by default, but the only way to know if an action is complete is by making your actions async or returning a promise. We can commit the data to the store through mutations using actions. Here's an example of a store module with actions, which fetches the data and commits to the store.

/*
*   store/modules/users.module.js
*/

// import the api endpoints
import { getAllUsers } from "@/api/users.api"

const state = {
    users: []
}

const getters = {
    getUsers(state) {
        return state.users;
    }
}

const actions = {
    async fetchUsers({ commit }) {
            try {
                const response = await getAllUsers();
                commit('SET_USERS', response.data);
            } catch (error) {
                // handle the error here
            }    
        });
    }
}

const mutations = {
    SET_USERS(state, data) {
        state.users = data;
    }
}

export default {
    namespaced: true,
    state,
    getters,
    actions,
    mutations
}

In our Vue.js component, we can first check the store if there are any data and avoid additional network calls. Or, if there aren't any data, we can use actions to fetch the data.

<template>
    <!-- Your template here -->
</template>

<script>
import { mapActions, mapGetters } from "vuex";

export default {
    data() {
        return {
            isLoading: false;
        }
    },
    computed: {
        ...mapGetters('Users', ['getUsers'])
    },
    methods: {
        ...mapActions('Users', ['fetchUsers'])
    },
    async mounted(): {
        // Make network request if the data is empty
        if ( this.getUsers.length === 0 ) {
            // set loading screen
            this.isLoading = true;
            await this.fetchUsers();
            this.isLoading = false;
        }
    }
}
</script>

4. Managing Auth Credentials using interceptors

Creating interceptors to inject headers is an easy way to secure your requests with Auth credentials. If you are building an application with user login, we can use interceptors to inject Auth token into the headers of each request. In our httpClient.js file we can add the following code to create request interceptors.

import axios from axios;

const httpClient = axios.create({
    baseURL: process.env.VUE_APP_BASE_URL,
    timeout: 5000
});

const getAuthToken = () => localStorage.getItem('token');

const authInterceptor = (config) => {
    config.headers['Authorization'] = getAuthToken();
    return config;
}

httpClient.interceptors.request.use(authInterceptor);

export default httpClient;

5. Handling network errors and logging

Is it easy as response.status === 500 in every request? It's not ideal to check the status and logging these errors in every network request we make inside our actions. Instead, axios offer abilities to intercept the error responses, which is a perfect spot to find errors, log or show a cute notification to the user saying the server effed up. We can also use this to log-out the user from your application if the requests aren't authorized or if the server informs of an expired session.

In the below example, I am using vue-notifications to show tiny notifications on the screen

// interceptor to catch errors
const errorInterceptor = error => {
    // check if it's a server error
    if (!error.response) {
      notify.warn('Network/Server error');
      return Promise.reject(error);
    }

    // all the other error responses
    switch(error.response.status) {
        case 400:
            console.error(error.response.status, error.message);
            notify.warn('Nothing to display','Data Not Found');
            break;

        case 401: // authentication error, logout the user
            notify.warn( 'Please login again', 'Session Expired');
            localStorage.removeItem('token');
            router.push('/auth');
            break;

        default:
            console.error(error.response.status, error.message);
            notify.error('Server Error');

    }
    return Promise.reject(error);
}

// Interceptor for responses
const responseInterceptor = response => {
    switch(response.status) {
        case 200: 
            // yay!
            break;
        // any other cases
        default:
            // default case
    }

    return response;
}

httpClient.interceptors.response.use(responseInterceptor, errorInterceptor);

6. Caching and Throttling

Axios adapters provide abilities to add superpowers into your HttpClient. Custom adapters are a clean way to enhance network communication in your application using caching and throttling. We'll be using axios-extensions to attach caching and throttling adapters to our httpClient.

Note that caching from client side is not recommended because your server has more knowledge on when the data changes. As @darthvitalus pointed out, it is better to set the cache headers to tell the browser what caching strategy to use. You can follow the below examples, if you still want to use caching from the client side.

Install axios-extensions

$ npm install --save axios-extensions

Caching

import axios from 'axios';
import { cacheAdapterEnhancer } from 'axios-extensions';

const cacheConfig = {
    enabledByDefault: false, 
    cacheFlag: 'useCache'
}

const httpClient = axios.create({
    baseURL: process.env.VUE_APP_BASE_URL,
    headers: {
        'Cache-Control': 'no-cache'
    },
    adapter: cacheAdapterEnhancer(axios.defaults.adapter, cacheConfig);
})

Once we have set up the cache adapter, we can config each request to be cached after it's first request. In our file, where we defined the end points we can pass an additional parameter indicating that the response should be cached.

const getUsers = () => httpClient.get('/users', { useCahe: true });

All the subsequent calls after the first call will be responded from the cache.

getUsers(); // actual network request and response gets cached
getUsers(); // from cache
getUsers(); // from cache

Throttling

In our use case, throttling means limiting the number of requests made in a particular amount of time. In large scale applications where each request to the server amounts to a larger cost of computing, caching is one way to achieve throttling.

What if there is new data coming in every once and then? In that case, we can use throttling to respond from cache for a limited time and then make an actual request after the specified time period. Axios-extensions comes with a throttleAdapterEnhancer which can be used to throttle the network request in our application. If we are using throttling, we can avoid using a persistent cache.

keep in mind it is not recommended to use throttling for time-sensitive data. If your data changes quite often, your server is the only entity that knows about the data. Use cache headers instead to let the browser know about what chaching strategy to use.

import axios from 'axios';
import { throttleAdapterEnhancer } from 'axios-extensions';

const throttleConfig = {
    threshold: 2*1000 // 2 seconds
}

const httpClient = axios.create({
    baseURL: process.env.VUE_APP_BASE_URL,
    adapter: throttleAdapterEnhancer(axios.defaults.adapter, throttleConfig)
});

export default httpClient;

If we have set up throttling, Same requests made within the threshold period will be responded from the cache. Only real request is made after the threshold period.

getUsers(); // actual request
getUsers(); // responds from cache
getUsers(); // responds from cache


setTimeout(() => {
    getUsers(); // threshold period passed, actual request.
}, 2*1000);

Thanks for reading this article 💖. Liked the article? have some feedback or suggestions? leave a like and a comment. This will help me understand better and write more amazing articles for you 🙂.

What's next?

In my upcoming posts, we'll discuss more Architecting large scale Vue.js applications in terms of performance and your productivity.

Hi there! I work as a UX Engineer at Locale.ai solving Geo-Spatial problems for our B2B customers. If you think you love solving UX problems for users, love designing and want to work with a team of enthusiastic individuals, check out the job openings we have at Locale.
Wanna talk? You can find me on Twitter, Instagram and GitHub.

Originally posted on haxzie.com

Architecting Vuex store for large-scale Vue.js applications

Musthaq Ahamad — Sun, 13 Oct 2019 04:48:00 +0000

At the heart of all large-scale Vue.js application lies the store which holds all its data. The Vuex store in a Vue.js application acts as a single source of truth which provides great performance and reactivity out of the box. As your application grows in complexity and code, Vuex stores get easily cluttered and become hard to manage. Architecting the state management of your application considering the best practices can solve most of the problems that grow with complexity.

In this blog post, we'll discuss some of the best practices and tips to architect state management on a large scale Vue.js application. We'll cover the following 5 concepts to help architect your store better.

Structuring the store
Modularizing the store
Auto importing modules
Resetting module state
Global module state reset

1. Structuring the store

A Vuex store contains 4 main components:

The state object
Getter functions
Actions
Mutations

If you are not yet familiar with these 4 concepts, here's a quick teardown of the above. The state object holds the data of your application as a large JSON. The Getter functions help you to access these state objects outside the store, they can act as reactive computed properties. Mutations, as the name suggests is used to modify/mutate your state object. Actions are quite similar to mutations, but instead of mutating the state, Actions commit mutations. Actions can contain any arbitrary asynchronous code or business logic.

Vuex recommends the state object should only be mutated inside the Mutation functions. It is also recommended not to run any heavy or blocking code inside the Mutation functions since it's synchronous in nature. Instead, we should use Actions, which are to be designed asynchronous to carry out all the heavy load or make network requests and commit mutations. Actions are also the best place to keep your business logic and data processing logic. Since it can store the data back to the store or can be used to retrieve the data directly into your Vue components, actions are ideal for such use cases.

It is a good practice not to directly access the state object and use the Getter functions instead. The getter functions can easily be mapped into any Vue component using mapGetters as computed properties.

2. Modularizing the store

It's no wonder that with increased size and complexity, the store gets cluttered and hard to understand. Vuex provides out of the box ability to split your store into separate modules with specific purposes as per your application. differentiating the business logic with the help of store modules increases the maintainability of the application. So we need to make sure each module is name-spaced and not to access them using the global store scope.

Here's a quick example for authoring store module and how to combine all the modules in the main store.

Directory Structure

store/
   ├── index.js    ---> Main Store file
   └── modules/
       ├── module1.store.js
       ├── module2.store.js
       ├── module3.store.js
       ├── module4.store.js
       ├── module5.store.js
       └── module6.store.js

Note that, each module is named as ModuleName.store.js this will help us to auto-import these modules and we'll discuss it in the next section.

Authoring Modules

We can move the network calls into a separate JavaScript file, we will discuss that in another blog post about architecting the network layer of the application. We can even separate out the state object, getters, actions and mutations into separate files for readability. It is good to keep all the related functions together and modularize away the store into modules further if it's still large and complex.

/* Module1.store.js */

// State object
const state = {
    variable1: value,
    variable2: value,
    variable3: value
}


// Getter functions
const getters = {
    getVariable1( state ) {
       return state.variable1;
    },
    getVariable2( state ) {
       return state.variable2;
    },
    ....
}


// Actions 
const actions = {
    fetchVariable1({ commit }) {
        return new Promise( (resolve, reject) => {
               // Make network request and fetch data
               // and commit the data
               commit('SET_VARIABLE_1', data); 
               resolve();
        }
    },
    ....
}
// Mutations
const mutations = {
    SET_VARIABLE_1(state, data) {
       state.variable1 = data;
    },
    SET_VARIABLE_2(state, data) {
       state.variable2 = data;
    },
    ....
}
export default {
    namespaced: true,
    state,
    getters,
    actions,
    mutations
}

Combining Modules

/** store/index.js **/
import Vue from 'vue';
import Vuex from 'vuex';
import createLogger from 'vuex/dist/logger';
import Module1 from './modules/module1.store';
import Module2 from './modules/module2.store';
...
Vue.use(Vuex);
const debug = process.env.NODE_ENV !== 'production';
export default new Vuex.Store({
   modules: {
      Module1,
      Module2,
      ...
   },
   strict: debug,
   plugins: debug? [ createLogger() ] : [],
}

3. Auto importing store modules

As I mentioned, if the modules are getting more and more complicated, we need to further split them into individual modules to reduce the complexity. When the number of modules increases, it becomes really hard to manage these modules individually and manually import each and every one of them. We'll have a small JS file inside the modules subdirectory to do this job for us. This file will take care of bringing all the modules together.

To make this happen, it's recommended to follow a strict naming pattern for the module files. After all, having a standard naming pattern will increase the maintainability of the entire project. For making things easier, our modules can be named using camelCase followed by .store.js extension. eg. userData.store.js and we need to add an index.js file inside the modules sub-directory to find all these modules and export them into the main store.

store/
   ├── index.js    ---> Main Store file
   └── modules/
       ├── index.js   --> Auto exporter
       ├── module1.store.js
       └── module2.store.js

Auto export script

/**
 * Automatically imports all the modules and exports as a single module object
 */
const requireModule = require.context('.', false,  /\.store\.js$/);
const modules = {};

requireModule.keys().forEach(filename => {

    // create the module name from fileName
    // remove the store.js extension and capitalize
    const moduleName = filename
                   .replace(/(\.\/|\.store\.js)/g, '')
                   .replace(/^\w/, c => c.toUpperCase())

    modules[moduleName] = requireModule(filename).default || requireModule(filename);
});

export default modules;

Now, our auto-export script is in place, we can import this in our main store and have access to all modules.

import Vue from 'vue'
import Vuex from 'vuex'
import createLogger from 'vuex/dist/logger'

// import the auto exporter
import modules from './modules';

Vue.use(Vuex);
const debug = process.env.NODE_ENV !== 'production';

export default new Vuex.Store({
  modules, // all your modules automatically imported :)
  strict: debug,
  plugins: debug ? [createLogger()] : [] // set logger only for development
})

Once you have used the auto importer in your main store, all the new modules getting added to the modules sub-directory will be automatically imported. For example, if you have a file named user.store.js this will be imported as a store module name-spaced as User. You can use this name-space to map the Getters and Actions into your components use mapGetters and mapActions.

4. Resetting module state

If you have worked with Vue+Vuex applications which manage a lot of data in the store modules. You might have come across a scenario where you need to reset the state of the store. It is quite common to have a reset feature when you have user authentication in your application so that you can reset the store when the user logs out.

To reset the store we need to separate out the state object to an initial state and copy that to the main state. we can use a simple function that returns the initial state to achieve this. So, in your store module, create a function called initialState() that returns the actual state object.

const initialState = () => ({
    variable1: value,
    variable2: value,
    variable3: value
});

const state = initialState();

Now we have a separate initial state, any changes we make to the state will not affect the actual initial value. So, we can use this to reset the store. Create a mutation function that basically mutates the entire store object with the initial state.

const initialState = () => ({
    variable1: value,
    variable2: value,
    variable3: value
});

const state = initialState();

// Getters

// Actions

// Mutations
const mutations = {
    RESET(state) {
      const newState = initialState();
      Object.keys(newState).forEach(key => {
            state[key] = newState[key]
      });
    },
    // other mutations
}

Once we have the RESET mutation in place we can use this function to reset the store easily either by calling an action or directly committing the RESET mutation.

// Actions
const actions = {
   reset({ commit }) {
       commit('RESET');
   },
}

5. Global module state reset

What if we need to reset the entire store? including all the modules? If you have followed the 4th and 5th points on setting up the auto importer and module state reset mutation in all your modules, we can use the following action in our main store file to reset all the modules at once.

import Vue from 'vue'
import Vuex from 'vuex'
import createLogger from 'vuex/dist/logger'
import modules from './modules';

Vue.use(Vuex);
const debug = process.env.NODE_ENV !== 'production';

export default new Vuex.Store({
  modules,
  actions: {
    reset({commit}) {
      // resets state of all the modules
      Object.keys(modules).forEach(moduleName => {
        commit(`${moduleName}/RESET`);
      })
    }
  },
  strict: debug,
  plugins: debug ? [createLogger()] : [] // set logger only for development
});

Note the action we created is in the main store file and not inside any module. This action can be triggered anywhere from your Vue component using the following line of code.

this.$store.dispatch('reset');

What’s next?

Liked this article? leave a like and follow to be in the loop. In our upcoming blog posts, we’ll discuss in-depth how to architect the networking aspects of our Vue.js application. We'll cover techniques used to how to manage auth credentials, intercepters and error handling in network requests.

To, get a better understanding of what we do at Locale.ai, read more about the unexplored territories of Geo-Spatial Analytics here.

Special thanks to Chris Fritz for his amazing talk 7 secret patterns Vue consultants don’t want you to know which gave us some of the ideas we used in this article.

Hi there! I work as a UX Engineer at Locale.ai solving Geo-Spatial problems for our B2B customers. If you think you love solving UX problems for users, love designing and want to work with a team of enthusiastic individuals, check out the job openings we have at Locale.
Wanna talk? You can find me on Twitter, Instagram and GitHub.

Originally posted on haxzie.com