Dynamic routing on HS (pages)

[RMarinov]

Hello community.

Our company investigates the oportunity to move portion of the frontend pages on HubSpot(HS). 

More specifically the most visited once.

I have to find the best way to transfer 44,000 on HS and this number may vary in time.

I think of two approaches:

1) We have to create 44,000 pages. Doing this manually would be a lot of work. Moreover when we have new companies and some of the old companies go away from  the list, we have to update - maully. This is really bad approach.

And of course the page limits on HS - Up to: 10,000 landing pages and 10,000 website pages

44K is much higher than 10K allowed.

2) I've been thinking to utilize dynamic routes (if it is possible on HS).
The idea is to have route like this my-hs-site.com/company/:company-name

This is a basic routing feature on othere server technologies. 
I would have one page, single layout and only the data would be different for different company. The data would be fetched from API via AJAX request. The company for which the data would be fetched is determined by the route parameter :company-name.

This way we occupy only one page and fit into the limits (10,000) .

So,

Does HS provide dynamic routes?
If not, any other ideas to implement what we want on HS?

[dennisedson]

Hey @RMarinov 

Welcome to the Community!

This is looking pretty react-y 😛

Here is some documentation on building with js frameworks

HubDB might be an option as well.  I say might because a table can have a maximum of 10k rows, but you can have many tables. 

@kierana is a freaking wizard with react and might have some additional thoughts on this.

[kierana]

Hey @dennisedson @RMarinov,

Without understanding the use-case - do all of these 44k pages share the same templates?  This can be done on hubspot, with a bit of extra work.

Bit of a brain dump...

1) HubDB dynamic pages - You're going to need to partition your data due the HubDB table limits. You can multi-level HubDB tables (https://designers.hubspot.com/how-to-build-multilevel-dynamic-templates) this comes with limits on data (e.g. if your top-level page is the Industry of the comapny so /companies/{industry}/{company-name} then as you're using HubDB you're going to be limited to 10k per industry. With HubDB limits (10k rows, max 1000 tables) you can have up to 10m rows. Make sure you choose a partition with as even of a distribution as possible.

2) React SPA application - As you mentioned - this may be an option, however, you're still going to need somewhere to store the data. If this data is generated by an external script / you don't mind if it isn't editable through the HubSpot CMS you can generate some static JSON files (storing them in the Hubspot file manager or design manager: https://knowledge.hubspot.com/cos-general/upload-your-site-assets-to-file-manager)  and load them via a React application running on the home.html template. One thing you may know when setting up a SPA is that when using a pushstate/history navigation if the user reloads the page they're going to get a 404 as the page doesn't exist on the server. You can mitigate this by using Hubspot Proxy redirects, see below:

This isn't perfect, as Hubspot sets the canonical to the original page. You may be able to override this via a theme though.

3) Build a SPA, upload to Hubspot file manager (rename index.html to something else though) and setup a Proxy Redirect to redirect/proxy all URL's back to the static files - simply /hfs/{portalId}/folder/home.html would be the URL you want to redirect TO. You'd still need to pull the data from an API, but with this method you've got a SPA with URLs which work. 

If the database is populated via an external script (maybe you crawl for the data, or just generate from an API) - then a way to work within the limits in a scalable fashion could be to use a consistent hashing function. You'd first have the script create, say 50 HubDB tables (up to 500k rows) and use the consistent hashing fn on the company name. This will give you the HubDB table to insert the data into. You would then use this same function in the client to find which table to query against the HubDB GET API (https://developers.hubspot.com/docs/api/cms/hubdb)

[RMarinov]

Hello @kierana , @dennisedson  and thanks for the sophisticated answers.

The most reasonable approach, seems to me, in our case is to use something like React SPA application.

Thereby bypassing the HS limits, be it DB, Redirects or number of pages limit. 

Althoug I don't quite understand some of your concersn, for example, you say:

however, you're still going to need somewhere to store the data...

I mean to store what? Yes the page Markup, JS, CSS etc, not a problem. But data no. My idea is to have the data fetched dynamically from external API. Please forget about the data cache from my original post 😉 its not an option anymore.

One thing you may know when setting up a SPA is that when using a pushstate/history navigation if the user reloads the page they're going to get a 404 as the page doesn't exist on the server. You can mitigate this by using Hubspot Proxy redirects, see below: ...

I've been thining utilizing react-router-dom, which would handle the history states form me.

Iam not familiar though how React - HS integration can best happen. Some docs/guidelines on this topic?

Can we use React components (like react router) or to write ES2015 code, or even ESX on HS?
I would imagine having path like this /companies/:company-name being handled by a single page. 
The page would have static content (data independent) NavBar, text, tooltips, whatever which would be the same for any company. And data-dependent components which would render company data(which undergoes change frequently).

The data component would receive a prop, that is the path fragment holding the company name e.g. "Apple" or "Google".
Based on this prop the component would issue fetch request to dynamically obtain the data for the specified company and render content based on the response/body.
I think this is more or less common approach in SAP. 
I am concerned about SEO and SAP. Moder search engine bots should be able to index dynamically rendered(client site rendered) pages, and in the same time we see other SSR frameworks (like Nextjs) appealing to use them just because SSR is much better for SEO. Other folks(even Google specialists) say that their bots would see the pages just as the browser see them, but if the page content heavily depends on JS , then the indexing would potentially happen later in time. And in general they recommend SSR as best for SEO.