DEV Community: Ralph Vaz

We built an API Builder for our API-based automation platform

Ralph Vaz — Thu, 03 Jun 2021 07:27:48 +0000

Pathfix Automation runs on APIs only (think: if Zapier and Postman had a baby), so it made sense for us to spend a lot of time to build out a slick and easy to use API builder.

With Automation, we want to give our users the ability to:

build complex workflows (both internal and user-facing)
call any API
enrich the data
transform data
send to the next API

……..and essentially, work the way they wanted – without any limitations!

This made the API builder a very cruicial feature in our platform.

(But first, a little introduction)

What is Pathfix Automation?

Automation is an API based automation platform that allows users to build flows using only APIs. Users can add multiple APIs and then stitch them all together to build out any automation they want.

The Automation platform came from the idea that existing tools are a bit too restrictive and doesn’t allow you to simply work with APIs.

So, based on many (many!) user requests, we decided to build a platform that ran purely on APIs, this meant that you can automate any process with any provider that has an API available.

Not just internal automation – More exciting is that you would be able to add user facing automation (integration) to your platform.

The API Builder

We needed to start by answering the basic questions:

How many APIs will our users have
Should we have one dedicated page for APIs built (or, have it accessible from a popup)
Allow for Search by multiple methods (keywords, url etc.)

We knew our users will have multiple APIs (I mean, ours is an API ONLY automation platform) but, we did not want them to lose context by leaving their design environment.

Enter – Single Page App

We added Design, Connections, Constants and the most important APIs as a quick popup – all without the user ever leaving their design environment.

Et Voila!

Design With Function
We just had one goal – make adding APIs effortless!

To achieve this, we started to look at other API builders and connectors. Read reviews, researched on forums to understand what users wanted and what caused them the most pain while adding APIs.

Here’s where we settled:

It needed to be nocode (read: no nonsense)
Postman was the standard when it came to working with APIs. It’s ease of use and general ‘known’ feel was unmatched of course
Bubble.io’s API Connector was simple, to the point and had a few elements we knew we could use (yes, the API Connector is a bit complex and has wayyy too many options that complicate makers. But we’re not gonna go there 🙂 )
With this in mind, we started building out the API Builder. We knew we had to have the basic functionality including calling multiple methods, endpoint, Body, Headers and Query Params

Here’s what the builder looks like:

Apart from these, we added a few features that checked the ‘convenience factor’ box.

Import configuration from library (ours and yours)
Import from CURL
Import from JSON
Export to JSON

This just made it super easy to work with APIs. So if you are not familiar with working with APIs, simply import a curl and we will get you all sorted!

Dynamic Values
The power of Pathfix Automation was in the fact that we allowed users to play with the data received, handle the transformation and push dynamic data to another API.

Since Dynamic Values was pretty important, we added the easiest way for users to add this – add <> brackets to any dynamic field.

Once added, users can simply select the dynamic values for these fields from any API calls made in the flow.

See what we did there? Our 4th task used data pulled from our 2nd and 3rd task. Just select the API and select the field.

Automation takes care of the rest!

API Builder Video
We created a video that details how you can use the API builder and walks through how it works.

Conclusion
Building the API Builder was definitely a challenge. The team at Pathfix took on the challenge head-on and fun along the way!

Login Management for SPA and Everyone Else (Part II)

Ralph Vaz — Tue, 01 Sep 2020 09:52:41 +0000

This article picks up from my original post (if you haven't read that, you can read it here: Login Management for SPA and Everyone Else )

In this post, we will complete the implementation and add the Login with the providers we want.

There are two ways to achieve it.

The easy way
The not-so-easy way

I will go through option 1 :)

The Easy Way

I take the code for the login extension available in Pathfix App.


    <div>
        <script id='pinc.helper' 
          src='https://labs.pathfix.com/helper.js' 
          modules='pinc.auth.min,ui.auth' 
          data-client-id='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' 
          providers='msazuread,discord,fb,github,google,linkedin,ms' 
          data-ui-button-prefix='Login with' 
          data-on-logged-in='onLoggedIn()' 
          data-on-logged-out='onLoggedOut()' 
          data-auth-success-url=''></script>
    </div>

The code from Pathfix will handle the steps involved in N1:/N2:/N3:/N4: from the login flow chart (as below)

As soon as this is placed I see the login buttons like so...

To handle the post login event I add the following code:


    function onLoggedIn(){
        //N5:
        console.log($pinc.auth.profile)
    }

    function onLoggedOut(){
        //Code to redirect to login page
    }

That's it.

Let's talk OAuth infrastructure for native integrations

Ralph Vaz — Sun, 30 Aug 2020 07:09:18 +0000

Integrations. According to a recent study by Gartner, through 2020 SaaS companies will be spending 50% of development time on integrations.

Platforms all over the world are implementing integration-first strategies to grow and scale their product usage. However, before you can offer any in-app integrations to your users, there is a crucial piece of technology implementation you need to know – OAuth.

While there are several solutions that offer integrations, these mostly handle internal automation and not necessarily user facing (read: native) integrations. This is where OAuth comes in. To know more about the difference between a workflow automation tool and an oauth solution, read our post on Pathfix Vs. Zapier.

TL;DR - Building an OAuth module requires several hours of engineering time from setting up of servers, finding SDKs that work, building token management systems and setting up the right flows. Pathfix saves hours of OAuth engineering productivity with its middleware API for OAuth integrations.

What is OAuth?

In simple terms – OAuth allows you to receive authorization from your users to get access to their data. This data does not only mean user identity, but access to data they have with their providers. OAuth framework is the most secure and preferred method adopted by most providers globally to allow for communication between applications. This is largely a two-way communication, pushing data to platforms and/or pulling data into your platform.

OAuth Scopes

Scopes limits the SaaS application’s access to the user’s data. During authorization, the user is presented with a consent screen that shows the scopes it wants to access. The user can then allow or deny access to the scope presented. The SaaS app can request access to one or more scopes which will show up in this consent screen. Scopes are always defined by the service provider; they define what data can be accessible by 3rd party and what cannot. While accessing, it is always a good idea to check the scopes permitted by the provider and enter that information that is requested as-is.

OAuth Grant Flow

The most common grant type is the Grant Flow. This flow exchanges an authorization code for an access token. Here is how a typical Grant Flow works:

Token Management System

As shown in the flow above, tokens are required during the process of receiving consent and permission from the user to access data.

These are:

Access tokens – Applications use access tokens to gain and make API requests on behalf of the user. This token grants the requesting application access to specific data granted by the user.
Refresh tokens – Used when an access token is expired, a refresh token is sent by the client to refresh expired access tokens. Your token management system needs to verify tokens, refresh expired access tokens, store tokens in secure and confidential data storage that is accessed by the provider only and most importantly, be secure in-transit and at-rest.

OAuth Authorization Server

The OAuth Authorization Server (AOS) is a gatekeeper that providers authentication and issues tokens. Also, it validates or rejects tokens before calls are redirected to the internal API server

The final piece, SDK’s

SDK stands for Software Development Kit (or devkit) is essentially a collection of tools you need to build on a platform. They are designed to perform specific tasks, programming, or languages. This means if you are looking to build an integration to Google Sheets to pull all new entries into your application, you will need to look for and/or build an SDK that performs that exact task complete with the programming language, API and endpoints. Most often, during the OAuth programming stage, this step consumes the most time as this requires research and finding the right and stable devkit to complete the actions you are looking for.

Or, Get Serverless OAuth Instead

So yes, building an OAuth module with the right server, SDK, token management and flows is time consuming and a bit complicated. Most service providers have their own structures and flows that you need to build for. Which means, one size does not fit all. If you are looking to integrate with multiple providers, you will need to go through this entire process again.

With Pathfix, instead of all that manual work, you can get oauth connected and start using any providers APIs in just a matter of minutes.

Pathfix is a middle API for oauth integrations that gets you connected to any provider with just a few lines of code. It handles the entire framework, token management and servers, without needing SDKs ever, all ready to go.

Reference Links

We recommend going through some of these reference links if you are looking to build the entire OAuth structure yourself https://oauth.net/2/
https://www.oauth.com/

Login Management for SPA and Everyone Else

Ralph Vaz — Thu, 27 Aug 2020 08:42:59 +0000

Login Vs. Profile

Adding social login to your existing login module has multiple benefits. ( Click here if you want to read why you should add social login to your login module. )

There are 2 elements to social login management – Login and Profile.

Login

AKA Identity, gives us identifiable information about the logged in user. Login also manages session state for us. i.e. If logged in with Github then every time the user comes to your app and he has authenticated using GitHub they will show as logged in.

This is a two-step process:

Check if the current user has previously authenticated with GitHub (usually done by storing a cookie)
If he has, then combine cookie information with stored token information (in server) and get user identity. Pretty straightforward.

Profile

Each provider will return some information about the user. This is more than just the login and could include things like name, a profile picture and some form of ID. Let's assume that we use the user's email as the identifier. We then store information against this identifier to Profile the user.

When I say profile the user, I mean store more information about the user than is provided by the Identity Provider. i.e. Company Name, Designation, App Personalization Information etc.

With this you have Login and Profile both.

The code flow to get, say GitHub Identity, would be something like this:

In the above flow, N5 gives me the JSON object which is the identity that I am looking for. From here on I take the user identifier (i.e. email) and extend the profile of the user in my db.

Security note: No login provider, including GitHub, will give you a user ID and password for a user. This ensures security since there are no passwords to maintain, there is reduced chances of being hacked or stolen passwords.

In the next post, I will share a few code samples behind the code flow.

Want to add login to your platform? Get your code at Pathfix .

Why I built Pathfix, the OAuth middleware for devs.

Ralph Vaz — Mon, 24 Aug 2020 14:01:30 +0000

I have been a developer all my life (25 years and counting) and I absolutely love it. Coding gives me a so much joy, I always say “it’s not work, it’s a hobby”.

Over the years, I have built over 8 different SaaS platforms. Ranging from a no-code app development platform to conversational chatbots.

During each build, one thing always remained a constant need. Integrations.

This is a post on why I built Pathfix.

What is Pathfix?

Pathfix is a middleware API for OAuth integrations. Engineering teams can add multiple platform integrations directly into their app, in minutes, without ever having to deal with OAuth or manage integration servers.

The Motivation

With each development sprint on my previous products, there was always a significant amount that was spent on integrations. My team collectively spent anywhere from 4 weeks to over 3 months just building out the connection to different service providers.

Why? Its simple really. Although OAuth is an industry protocol for authorization, it servers more as a guideline. Which meant, each provider had their own setup process. Each setup was different. Each connection required hours of research. Each had their own way of handling authorization tokens.

And of course, there was the SDK problem. To access the providers API endpoints, you need to run an extensive search to find the right SDK for the integration you are building.

This not only meant ‘getting lucky’ finding the right SDK, it also meant setting up a server, managing the logs, monitoring connections, and maintaining security protocols (you are accessing customer data after all!).

Standard OAuth integration elements

Let’s break this down. For you to add OAuth based integration in your platform, you will need to do the following:

Setup and configure OAuth
Implement OAuth flow
Implement secure storage for tokens
Implement logic to refresh access tokens when needed
Build and implement logic to properly handle revoked refresh tokens
Logic to handle reliable issues and outages
Build and implement systems to track errors
Find and implement the right SDKs
On-going server maintenance

To add 5 integrations, this could take over 2000+ engineering hours to get done. Which is approx. $160,000 (yes, we did the math, we had to).

This is why I decided to build Pathfix.

OAuth Integrations With Pathfix

Pathfix is the only API you need to integrate with any provider. It handles all the configuration and framework required to build integrations to any platform and access any providers API endpoints. It is a pass-through server that handles user authorization and API requests between platforms.

And of course, its all white-labeled. Users never see Pathfix anywhere.

Authorizing Users
A simple one line code that enables user authorization

Sample Code for Authorization:

<div data-oauth-ui="list" data-oauth-ui-switches="checkBoxes,statusOn,disconnect" data-oauth-ui-providers="" data-oauth-ui-providerTypes=""></div>

Pass-through API
Once authorized, use the pass-through API code to access any providers API endpoints

Sample code for pass-through API:

POST https://labs.pathfix.com/oauth/method/googleanalytics/call?user_id=AcmeSaaS_end_user_id&public_key=733AC521-199E-496C-8250-FFCAD67355AB&private_key=E7804D26-0625-428F-8550-CDF073D3CF61                            
Content-Type: application/json
{
    "url":      "url_to_googleanalytics_API",
    "method":   "method_to_use_with_this_call",
    "payload":  {payload_as_requested_by_googleanalytics},
    "headers":  {header_if_requested_by_googleanalytics}
}

That’s it!

Compare it to the code and time you would need to create and maintain, Pathfix solves it in the most elegant way. With:

√ No additional code to maintain
√ Zero learning curve
√ Log monitoring
√ Secure encryption
√ Firewall settings
√ Notification engine

My site URL