build several variants for a single path

[id0Sch]

Background:
I currently run a gatsby site deployed on GCS and served via a custom backend (not Node.js), which is a requirement due to my company's product scale.
We use gatsby to build our marketing landing pages, specifically building a new page per layout, to reduce layout shift, display a pre-rendered skeleton, and such ( one of many reasons we started using gatsby).
As our needs evolved the need to test several layouts on the same traffic source whilst maintaining the same URL became critical.

We would like to keep the current build architecture that keeps each layout as a standalone build generated page like so:
pages/layout_a.js, pages/layout_b.js, pages/layout_c.js -> layout_a/index.html, layout_b/index.html, layout_c/index.html
but have our backend "decide" which one to serve when the user navigates to www.example.com

Currently, this can not be achieved using Gatsby since each generated page is "aware" of its pathname and will not load unless the current URL matches it.

I would like to help champion this feature addition to gatsby to help in any way necessary to make this happen!
Thanks!

[nibtime]

@id0Sch

So in your scenario there would exist Gatsby paths at /layout_a, /layout_b, and /layout_c, but not at / and when I am visiting / (www.example.com) you want to decide with some server-side logic (round-robin, random percentile, etc.) which variant to serve me, but it doesn't work, because Gatsby owns /?

Couldn't you place your Gatsby site under a path prefix, so / isn't owned by Gatsby and you can then do whatever you want at / Or maybe it's possible to opt-out the paths with gatsby-plugin-create-client-paths? Or am I getting your problem wrong?

[id0Sch]

@nibtime, unfortunately, it doesn't seem to work.
I've set up the routes like so ( its a proxy to createPage)

which correctly builds all SSR'd pages

but as gatsby's SPA logic kicks in, it tries to hydrate/render the first item that declared matchPath and the page gets messed up.
maybe I misconfigured something on my end, but after a couple of hours of tweaking and testing, I couldn't get it to work. so my feature request stands.

[nibtime]

@id0Sch thanks for putting in the work and trying it out.

So in this scenario, there is no page at lp/index.html, right? When I navigate to /lp, Gatsby shouldn't do anything and some server-side logic (e.g. by a cloud function) should kick in and redirect me to one of lp/default/index.html, lp/img/index.html, lp/min/index.html or lp/vid/index.html. But instead, Gatsby's SPA logic kicks in, and is attempting something on /lp because of matchPath, even though it shouldn't.

You would like to configure path patterns, so Gatsby wouldn't do anything on /lp, so even though it's within the same path prefix, certain path patterns can be completely excluded such that, e.g. a cloud function handles them and Gatsby does absolutely nothing?

Your feature request then would be something like "server-only" paths?

[id0Sch]

Yes, exactly.

[nibtime]

@id0Sch
In the docs, there is a section that mentions these "server-only routes". However, it's sort of like "we just like to mention at the very end, that this is theoretically possible, but it might involve arbitrary circumstance on your end" and comes without any example of how to set it up correctly whatsoever. I have absolutely no clue what I had to do concretely by just reading that.

So maybe this is just a documentation request after all. However, then there is at least 1 person to be found who uses this successfully in a production scenario, and then hopefully that person is kind enough to provide a walkthrough for implementing such "server-only routes" and commits that to the docs.

[id0Sch]

@nibtime
I have read this section multiple times because just like you - I had a hard time figuring out what's the takeaway.
IIRC it refers to a situation when the inner route is not built and is purely client side and you have to configure the server to serve the base index.html - just like any other SPA.

[jdesherlia]

I would love to see official support this in Gatsby, as Kyle seemed to allude to back in 2018 here. We have been struggling with proper A/B testing strategies for a while, and usually result to using Optimizely. This works ok for in-page tests, but for serving entirely unique pages per user on the same route, it falls pretty flat. There is also a LOT of overhead with optimizely as the Gatsby docs point out as well.

Extending creatPage to create variants that are intrinsically linked to a common route seems like the right direction, but I'm curious how we would inform Gatsby of which content to serve. Variants can be determined by a multitude of factors... Data from a service like clearbit, random percentage of traffic, even regional or language specific content could be considered a variant of a page. I would love to explore this more if anyone has ideas, as the need seems to come up a lot more often.

Currently we are looking at some sort of edge handler to handle this, but netlify edge handlers aren't GA yet and we don't have budget for something like Outsmartly, so kind of wandering aimlessly in the opposite direction of Optimizely at this point.