Pathom Updates 12

Hello everyone! It’s been a while since we had a Pathom Update post, so let’s catch up on what’s been happening since the last one!

Pathom Viz

Pathom Viz got some love! Let’s see the updates.

Proportional resize panels

A long-standing issue for me was the resize handlers around all the app. In the past, they were based on absolute pixel sizes, which is terrible when we resize the app because some panels might just completely collapse.

Now that’s changed, and all the sizes are based on percentages, this way as you resize the full window, the panels will keep the proportional sizes.

Improvements to connect via URL

Now when connecting via URL you can send custom headers. This will enable the usage passing an API token to authenticate your calls.

Pathom 3 query settings

I have added two new checkboxes when connecting to a Pathom 3 client. You can toggle if you want lenient mode active, or/and if you want to include or not the trace data.

Pathom 3 entity data on query history

A new feature for Pathom 3, now you can see in the query history the entity data used in that request.

Record Entity data on query history

The query history now remembers both the query and the entity data used, so you can come back to a past query in a click.

Parallel Processor

The parallel processor is here!

In Pathom 3, the parallel processor leverages the planner and have an implementation that’s much simpler than the Pathom 2 counterpart, resulting in an algorithm that requires fewer resources.

The parallel processor is an extension of the async processor. You can find details on how to use the parallel processor at https://pathom3.wsscode.com/docs/async/#parallel-process.

Benchmarks

It’s been a while since we have some performance comparisons, last time Pathom 3 was in very early stages, and lacking features makes it easier to go faster. Now that Pathom 3 is close to feature complete, how is it performing? Let’s find out!

Single read

As I did last time, the first benchmark measures the time to do the minimal work to get some result of Pathom. It’s a query with a single attribute, which requires a single resolver call to realize.

[:x]

Before moving on, let’s understand what the bars represent, from left to right:

• p3-serial-cp: Pathom 3 serial parser, using a persistent plan cache. This means that the planning part of the operation is already pre-cached. It’s common for APIs to make the same queries over and over, this provides the opportunity to cache this step, and you may expect a high cache hit rate on this plan cache. They are based on the query and the available data.
• p3-serial: Pathom 3 serial, without any pre-cache. Remember that even if there is no pre-cache, Pathom will make a request level plan cache anyway. When there is a collection in the process, the plan is cached and re-utilized between the collection items.
• p3-async-cp Pathom 3 using async processor with cached plan
• p3-async Pathom 3 using async processor
• p3-parallel-cp Pathom 3 using parallel processor with cached plan
• p3-parallel Pathom 3 using parallel processor
• p2-serial: Pathom 2 using the serial parser and reader2.
• p2-async: Pathom 2 using the async parser and async-reader2.
• p2-parallel: Pathom 2 using the parallel parser and parallel-reader.

Complex read

This example demonstrates a case where a single attribute requires a complex chain of resolvers to get fulfilled.

[:h]

In this example, we can see the cache plan was even more effective, which makes sense given this requires the generation of many nodes while previous was a plan with a single node.

Here is what the process of :h looks like in this example:

Sequence of 1000 items

In this example, we will look at how long it takes for Pathom to process a collection with 1000 items in it, a simple resolver call on each.

[{:items-1000 [:x]}]

In this, we can see that Pathom 3 gets about four times faster for raw sequence processing when compared to Pathom 2 serial.

Sequence of 1000 items in batch

Sample as the previous, but now with batched value processing.

[{:items-1000 [:x-batch]}]

Same similar gains in batching.

Nesting 10 > 10 > 10

Testing nesting, 3 levels down, 10 items per level.

[{:items-10
  [:x
   {:items-10
    [:y
     {:items-10
      [:x]}]}]}]

Nesting 100 > 10, batch head

Nesting with batching, the batch occurring at the top.

[{:items-100
  [:x-batch
   {:items-10
    [:y]}]}]

Nesting 100 > 10, batch tail

Nesting with batching, the batch occurring at tail items.

[{:items-100
  [:y
   {:items-10
    [:x-batch]}]}]

Sequence of 100 items, batch with 200ms delay

[{:items-100
  [(:x-batch {:delay 200})]}]

This is a good example of how when some resolvers are costly, the noticeable overhead gets reduced.

Nesting 10 > 10, batch with 20ms delay

[{:items-10
  [{:items-10
    [(:x-batch {:delay 20})]}]}]

Complex read structure

This example is closer to what a complex user request looks like. Where parts are independent and the parallel features can give a real boost in the speed:

[{:>/profile-info
  [:customer/name
   :customer/birthday
   :customer/genre
   :account/status]}
 {:>/purchases
  [{:customer/purchases
    [:purchase/vendor
     :purchase/amount
     :purchase/category]}]}
 {:>/account-info
  [:account/status
   :account/status-history
   :account/onboarding-date
   :account/balance
   :account/balance-future]}
 {:>/chargebacks
  [{:customer/chargebacks
    [:chargeback/date
     :chargeback/status]}]}
 {:>/credit-cards
  [{:account/credit-cards
    [:credit-card/masked-number
     :credit-card/status]}]}
 {:>/boletos
  [{:customer/boletos
    [:boleto/number
     :boleto/paid?]}]}
 {:>/mgm
  [{:customer/referrals
    [:customer/name]}]}
 {:>/phones
  [{:customer/phones
    [:phone/id
     :phone/number]}]}]

As we can see, the parallel processors shine here, Pathom 3 being the fastest. Its also worth to note that the Pathom 3 implementation uses significantly fewer resources than the Pathom 2 due to the new parallel implementation.

I think it’s interesting to see the trace of the parallel process vs the serial in this case:

Here you can find the full sources for these benchmarks: https://gist.github.com/wilkerlucio/f2a52d032101a5c436045e621e331b4c

Pathom 3 GraphQL

Pathom 3 GraphQL got an official release!

If you want to integrate some GraphQL source into your Pathom system, check it out at https://github.com/wilkerlucio/pathom3-graphql.

Follow closer

If you like to know in more details about my projects check my open Roam database where you can see development details almost daily.

Support my work

I'm currently an independent developer and I spent quite a lot of my personal time doing open-source work. If my work is valuable for you or your company, please consider supporting my work though Patreon, this way you can help me have more available time to keep doing this work. Thanks!

Current supporters

And here I like to give a thanks to my current supporters: