Currently building a career page on our website and was wondering how you would approach this specific use case.
We manage our open job positions and applications in an external tool that offers an API. The goal is to display all jobs as a list with some basic data on the career page. Then on click of one of the job listings, we want to open the job detail page. There the user can see all the info that we stored. Each job should get an own page.
Now we came up with different approaches:
Using something like Make.com to create a webhook and on each page load make a request which then triggers the automation before returning a response. The response would then contain the jobs data and which we could use to build the front-end for the user. Downside:
• A lot of requests could reach API limits in the tool
• Data needs to be stored in a cache
• Layout needs to build by hand not with the Webflow designer
• Does not solve the job detail page yet Upside:
• Data is not stored in two locations
• No one can mess up updating data inside of Webflow
Creating a CMS collection of “jobs”. Then creating an automation for each action (create a job, update a job, delete a job) that syncs the data from the tool to the Webflow CMS. From here we could just use a normal collection list and a template for the job detail page. Downside:
• Having the data in two locations
• You need 3 automations (3 triggers) for each action that is done in the tool
• Synching opens error possibilities when moving data from A to B and one error can throw of the sync completely Upside:
• Easier and faster to set up
• Use of default designer functionality
• Enables you to add custom fields to the CMS that are not part of the tool
I’d be really happy to get some tips of you guys. This is the first use of an external API to fetch data and display it on our page. If you have any thoughts on this or additional ideas, let me know!
The sync approach (2) is easiest and cleanest for the purposes of SEO and Webflow utility. It’s fine to have duplicate data as long as;
You have a single source of truth ( no two-way reconciliation headaches )
You have the ability to wipe and rebuild from your SSoT to your proxy data stores like the CMS
There is also an approach 3 which is a reverse proxy that;
Captures a request to /job-posts/*
Takes a Webflow-build template page as the structure and styling
Retrieves the related record
Builds the content-hydrated page and caches it
Returns the result
Handles 404s, etc.
Handles sitemaps, canonicals, etc.
I prefer this as a more industrial strength solution as it’s a true system hybridization, and it has no CMS limits… a million records is fine. However it’s a more substantial build.
I think the one-way sync from the tool to the CMS is not a problem. When it comes to wiping the data stores I don’t know how I would approach this. How would you do something like that?
The third option also sounds interesting. We are always fans of building scalable and reusable systems. Is there some tutorial somewhere on how to pull of something like you propose? I’d be really interested to learn this.
Manually, in the designer. The point is to be able to rebuild your synced copy fully.
I’ve never taught anyone before, it’s pretty much basic systems engineering and development work. You should be able to find tutorials on the basics and from there it’s figuring out and building the system you need.
