Your Site's RSS Feed

Webhooks

Tue, 26 Oct 2021 00:00:00 GMT

Webhooks, sometimes called web callbacks or HTTP push APIs, are simple on-to-one connections that allow real-time data to be sent from one application to a unique URL provided by another application whenever a specified event occurs.

Consuming a Webhook

The first step in consuming a webhook is giving the webhook provider (where the event is triggered) a URL to deliver requests to. This is most often done through a backend panel or an API.

Once a tracked event occurs on the trigger application, data is serialized and sent to the webhook URL of the destination application via an HTTP request. The destination application contains the logic to be executed upon receiving the webhook request payload. It can then send a callback message, often with an HTTP status code such as 302 if the data was received successfully, or 404 if not.

Webhooks take the form of GET or POST requests depending on the webhooks provider. While GET requests have payloads appended to the webhook URL as a query string, POST webhook requests contain the payload in the request body, and might also include additional properties such as authentication tokens. The majority of webhooks will POST data in one of three ways: as JSON, as XML, or as form data.

For example, say an application needs to dispatch an emailed copy of a receipt immediately after a customer checks out at a store. If there is a webhook URL registered to this payment action, the trigger application (where the event occured) might send a HTTP POST, with a body containing order information, to the webhook route belonging to the destination application. Upon receiving this information, further action to compose and send that automated email will take place.

Webhooks vs APIs

Similar to webhooks, APIs provide applications with a means to receive data. While webhooks involve pushing data to an application when specific events occur, APIs allow clients to make requests to retrieve, edit, add, and remove data residing elsewhere.

If a client wishes to detect when new information is available or be notified of backend events via an API, it must periodically send a request to the relevant API to check for updates. This pattern of making requests at fixed intervals regardless whether or not data has changed is known as polling.

Polling intervals must be highly frequent for returning “real time” data. In contrast, webhooks send data to an application if and only when that data has changed.

However, polling may be better suited for use-cases not requiring real-time updates. In the event of rapidly changing data, polling a server every five to ten minutes to fetch needed information is less work for a system and could potentially consume fewer resources than webhooks, which will fire after every tracked change. Improperly configured servers may be overwhelmed by the high load volume of requests. Applications must therefore be designed with the expected scale of each webhook in mind.

What about WebSockets?

Webhooks and WebSockets both solve the problem of real time communication in different ways.

While webhooks are mostly used by two servers to pass information, WebSockets are used primarily for server-to-client (mostly web browsers) communication.

WebSockets facilitate a two-way information stream between server and client, and keep the socket connection open for as long as required to allow numerous transfers of information. With webhooks, the connection is terminated once a response has been returned.

With regards to communication protocols, WebSocket uses its own custom WS protocol while webhooks use regular HTTP.

Conclusion

In short, webhooks are a tool for automatically pushing fresh data to a server sans polling. Due to their utility and ease of implementation, webhooks are quickly becoming ubiquitous in real-time software architectures.

Debounce vs. Throttle

Wed, 01 Jul 2020 00:00:00 GMT

After setting up document or window event listeners such as resize or scroll, events are emitted, captured, and handled many times a second. This high rate of execution can significantly impact the performance of a website or application. Here, debounce and throttling methods can really shine.

Debouncing and throttling are two techniques used to control the number of times your event handler responds to emitted events. These are the main differences between them:

Debouncing

Debouncing is used to group a burst of events into one. This is particularly useful for features like autocomplete. Using a debounce function from a utility library like Lodash, users can define whether they would like their event to fire at the beginning of the burst, or at the end. An autocomplete implementation would use a debounce to wait until events have stopped firing (users have stopped typing) before executing the event handler.

Throttling

Unlike with debouncing where an event is handled at the beginning or end of a burst, throttling guarantees a constant flow of callback executions every X milliseconds. This is useful in situations such as when a user needs to detect the scroll position of a page to trigger an animation. A throttle function is also available via Lodash.

One important thing to note about a lot of throttle functions is that they do not fire the callback at the end of the throttling phase. This can result in the last call being skipped, and can negatively impact interactions that require this final call.

Alternatively, using requestAnimationFrame to throttle events like resize, scroll, wheel, keydown, mousemouve, touchmove, and pointermove might be a preferable approach. See here

requestAnimationFrame

requestAnimationFrom is a throttle alternative that is supported natively in the browser. requestAnimationFrame will limit the execution of an event handler to six times a second.

Debounce, throttle and requestAnimationFrame all work to optimize the handling of rapidly emitted events. If ever you are experiencing lag due to expensive event listeners, take a shot at implementing whichever of these solutions best fits your use case.

Javascript's Function Argument Object

Tue, 30 Jun 2020 00:00:00 GMT

arguments is an array-like object available within Javascript functions. As its name suggests, arguments contains the values of the arguments passed to the function within which it is accessed.

Similar to arrays, the arguments object has a length property. In addition, its values are ordered, and can be retrieved via index:

Unlike arrays, arguments does not have any built-in array methods like map(), filter(), splice(), etc.

Nevertheless, we can convert arguments into an array easily:

This information is particularly useful when working with functions that are called with more arguments than they have been declared to accept. It’s also useful for creating functions that can be passed a variable number of arguments:

Arrow Functions and the `rest` Parameter

Arrow functions do not have an arguments binding in their scope. In other words, no arguments object is created they are called.

However, if you do want to capture arguments in an arrow function, you can use the rest parameter.

With the rest parameter (…args), the memoize function below will accept a function as a parameter, and call it with whatever number of arguments are provided. This pattern allows memoize to be incredible flexible in it’s application.

Another familiar example is the debounce method. Here, a generic callback function can again accept any number of arguments:

Rest parameters can also be combined with other parameters, but must always be included as the last parameter

Gists, Gatsby, and MDX

Thu, 25 Jun 2020 00:00:00 GMT

I really enjoy working with Github gists. They have a great look without having to tinker around with themes (such as with Prism), are highly readable, and provide out-of-the-box syntax highlighting and line numbering for numerous languages and formats.

I also like having all of my code snippets stored in one central place. Whenever I need to reference or update them again, it’s easy.

For these reasons, I wanted to use gists for writing blog posts. As things are, I ran into some roadblocks along the way.

My first plan of attack was the gatsby-remark-embed-gist plugin. I spent a good chunk of time trying to get this to work, but was only ever able to render the literal code block:

gist:Mikaelia/1234567#example-file.js.

By this time, I was investigating transitioning to MDX files.

As written in the docs:

MDX is an authorable format that lets you seamlessly write JSX in your Markdown documents. You can import components, such as interactive charts or alerts, and embed them within your content. This makes writing long-form content with components a blast 🚀.

Having the freedom to write JSX into my markdown sounded great, and it would open the door for writing more visual and potentially interactive content in the future.

In addition, I had recently come across react-gist. This package provides the user with a gist component. This would serve as a perfect use-case for a MDX file, and would solve my gist rendering problem.

Once I had gatsby-plugin-mdx set up properly, all I needed to do was import, and include my gist components wherever I needed them:

Easy!

Gotchas

Do not forget the quotes around your id string else your gist will not render
Please be aware that if you are using a frontmatter, you will need to include your import statement after the frontmatter.
If you are experiencing errors, be sure to try clearing your .cache and public folders by running `gatsby-clean.

Gists, Gatsby, and MDX

Thu, 25 Jun 2020 00:00:00 GMT

I really enjoy working with Github gists. They have a nice look without having to tinker with themes (such as with Prism), are highly readable, and provide out-of-the-box syntax highlighting and line numbering for numerous languages and formats.

I also like having all of my code snippets stored in one central place. Whenever I need to reference or update them again, it’s easy.

For these reasons, I wanted to use gists for writing blog posts. As things are, I ran into some roadblocks along the way.

My first plan of attack was the gatsby-remark-embed-gist plugin. I spent a good chunk of time trying to get this to work, but was only ever able to render the literal code block:

gist:Mikaelia/1234567#example-file.js.

By this time, I was investigating transitioning to MDX files.

As written in the docs:

MDX is an authorable format that lets you seamlessly write JSX in your Markdown documents. You can import components, such as interactive charts or alerts, and embed them within your content. This makes writing long-form content with components a blast 🚀.

Having the freedom to write JSX into my markdown sounded great, and it would open the door for writing more visual and potentially interactive content in the future.

Once I had gatsby-plugin-mdx set up properly, all I needed to do was import, and include my gist components wherever I needed them:

Easy!

Gotchas

Do not forget the quotes around your id string else your gist will not render
Please be aware that if you are using a frontmatter, you will need to include your import statement after the frontmatter.
If you are experiencing errors, be sure to try clearing your .cache and public folders by running `gatsby-clean.

Correcting `gatsby-plugin-mdx` Static HTML Build Error

Tue, 23 Jun 2020 00:00:00 GMT

I recently transitioned from Markdown files to MDX using this guide.

While everything seemed to be running smoothly in dev, on build I received the error:

Building static HTML failed for path "/blog/fixing-FOUC/"

See our docs page for more info on this error: https://gatsby.dev/debug-html

WebpackError: TypeError: Cannot read property 'mdx' of undefined

If you’re experiencing this error, you may very well have done what I did, and included your blog folder inside of your pages directory.

In this case, the GQL query for your individual post will fail because the post page is created twice on build — once manually by you, and then again automatically by the mdx plugin.

The mdx plugin will see the .mdx file in the pages folder, and create a page without a query slug. It is this that causes the query to fail and the error to display.

Correcting `gatsby-plugin-mdx` Static HTML Build Error

Tue, 23 Jun 2020 00:00:00 GMT

I recently transitioned from Markdown files to MDX using this guide.

While everything seemed to be running smoothly in dev, on build I received the error:

Building static HTML failed for path "/blog/fixing-FOUC/"

See our docs page for more info on this error: https://gatsby.dev/debug-html

WebpackError: TypeError: Cannot read property 'mdx' of undefined

If you’re experiencing this error, you may very well have done what I did, and included your blog folder inside of your pages directory.

In this case, the GQL query for your individual post will fail because the post page is created twice on build — once manually by you, and then again automatically by the mdx plugin.

The mdx plugin will see the .mdx file in the pages folder, and create a page without a query slug. It is this that causes the query to fail and the error to display.

Removing FOUC in a Netlify-deployed Gatsby Project

Sun, 07 Jun 2020 00:00:00 GMT

As I’ve been working more with Gatsby and styled-components, I’ve run across an issue with flashes of unstyled content showing on page load and refresh in an application deployed to Netlify. Squashing this required a bit of exploration.

Here are the two steps that eventually fixed my problem:

Install the gatsby-plugin-styled-components styled-components babel-plugin-styled-components plugins and update the gatsby-config.js file (example below). I had only imported styled-components library, not knowing the other packages were needed.

This corrected the majority of issues I was having on page refresh. However, the unstyled font flicker was a little tricker to fix. After some experimentation I finally discovered that the gatsby-plugin-typograpy package did the trick.

Install the gatsby-plugin-typography, react-typography and typography packages and update the gatsby-config.js (also below) in order to fix font issues.

This involves creating a src/utils folder, with a typography.js file. In order to use Google fonts, the typography file required some configurations.

Here’s mine:

Despite not setting the Bai Jamjuree font to either headerFontFamily or bodyFontFamily, I was able to use it elsewhere in my application.

Here’s my gatsby-config.js file:

Hope this helps!

Removing FOUC in a Netlify-deployed Gatsby Project

Sun, 07 Jun 2020 00:00:00 GMT

Here are the two steps that eventually fixed my problem:

Install the gatsby-plugin-styled-components styled-components babel-plugin-styled-components plugins and update the gatsby-config.js file (example below). I had only imported styled-components library, not knowing the other packages were needed.

Install the gatsby-plugin-typography, react-typography and typography packages and update the gatsby-config.js (also below) in order to fix font issues.

This involves creating a src/utils folder, with a typography.js file. In order to use Google fonts, the typography file required some configurations.

Here’s mine:

Despite not setting the Bai Jamjuree font to either headerFontFamily or bodyFontFamily, I was able to use it elsewhere in my application.

Here’s my gatsby-config.js file:

Hope this helps!

What Actually Happens When you Enter a URL

Sun, 05 Aug 2018 00:00:00 GMT

TL;DR: A lot!

Here’s a high-level overview:

To start, let’s look at the URL https://www.example.com

It contains:

A protocol — https
A domain name — www.example.com

Domain Names: IP Addresses in Disguise

What is a domain name? In the same way that you might query Google Maps with the name of a restaurant instead of its physical address, you’ll likely search for a website using its domain name rather than its IP address.

IP addresses are unique sets of numbers (e.g. 151.101.65.121) assigned to each network device, which help these machines identify each other and ensure that data and requests are routed to the correct destinations. Domain names, on the other hand, are the human-friendly, easy-to-remember aliases that refer to these numbers.

How does your browser translate a domain name into an IP address?

Cache check

Before your browser can send its request to the proper web server, it has to figure out which IP address corresponds to the domain name that you have entered.

First, your browser will check its cache(memory) to see if the IP address in question has been previously saved. If it has not, your OS cache will be searched, then your router cache, and finally your ISP (Internet Service Provider) cache will be examined. If the IP has not been stored in any of these locations, a DNS server (generally provided by your ISP) will proceed to resolve the domain name to its IP address.

DNS resolvers are part of the DNS (Domain Name System), which comprises a massive database of domain name and IP address mappings.

Anatomy of a Domain Name:

Let’s break down the domain name a little more. Domain names consist of multiple parts:

- The last dot-separated portion is called the top-level domain (.com, .online, .org etc.).

Each word-and-dot combination that precedes the top-level domain indicates a new level in the domain structure. In www.example.com, ‘example’ would be considered the second-level domain).
The left-most part of the domain name, (www) is referred to as the host name or subdomain.

Where are you?

To locate an IP address, the resolver begins by querying the root DNS server (represented by the invisible ‘.’ at the end of a domain name: www.example.com.←)

Root servers hold the locations of all of the top-level domain servers, which will be queried next, followed by the second-level servers.

After the second-level domain servers are queried, the DNS resolver will be directed to the authoritative name server, which will return the IP address of “www.example.com.” to the browser. The browser will store this address in its cache for a specified amount of time to speed lookup when that particular URL is called again.

Making a Connection

TCP/IP (Transmission Control Protocol/Internet Protocol) is a set of procedures and rules for regulating how data is broken up, and exchanged between a client (in this case, your browser) and a server (such as example.com’s). With an IP address, your browser will attempt to initiate a TCP connection with the indicated server in order to send and receive information.

Connection Security

In the beginning of this article, I mentioned that https:// was the protocol for www.example.com. HTTPS stands for Hyper Text Transfer Protocol Secure. It is the secure version of HTTP, which is the protocol that defines how messages are formatted and transmitted across the web, and what actions web servers and browsers should perform in response to various commands.

HTTPS increases the security of a connection via SSL(Secured Sockets Layer), a standard security protocol for establishing encrypted links between the client and server via the use of public and private keys. Without SSL, any computer on any other networks between you and the web server can access your connection. Firewalls also increase security by restricting traffic and preventing unwanted port connections.

Load Balancers

Another piece of technology that your request might encounter en route to a web server is a load balancer. Load balancers distribute requests across server systems to increase the reliability, efficiency, and availability of the queried application or website.

Web, Application, and Database Servers

Once your request has reached www.example.com’s web server, the web server serves up a HTML file to your browser.

In order to process dynamic content, such as a Javascript file, the web sever must communicate with an application server, which will run the dynamic content, translate the results into static HTML, and return it to the web server.

Databases store website and application data. If requests for such information (usernames, passwords etc.) occur, a query to the database will be made and the relevant data will be sent back to the web server, which will, finally, return the necessary static code to the browser for your viewing pleasure.

Your Site's RSS Feed

Webhooks

Consuming a Webhook

Webhooks vs APIs

What about WebSockets?

Conclusion

Debounce vs. Throttle

Debouncing

Throttling

requestAnimationFrame

Javascript's Function Argument Object

Arrow Functions and the rest Parameter

Gists, Gatsby, and MDX

Gotchas

Gists, Gatsby, and MDX

Gotchas

Correcting `gatsby-plugin-mdx` Static HTML Build Error

Correcting `gatsby-plugin-mdx` Static HTML Build Error

Removing FOUC in a Netlify-deployed Gatsby Project

Removing FOUC in a Netlify-deployed Gatsby Project

What Actually Happens When you Enter a URL

Domain Names: IP Addresses in Disguise

How does your browser translate a domain name into an IP address?

Cache check

Anatomy of a Domain Name:

Where are you?

Making a Connection

Connection Security

Load Balancers

Web, Application, and Database Servers

Arrow Functions and the `rest` Parameter