I’m wondering if anyone has a solve for Production and Staging environments in using apostrophe-headless.
I currently have 2 separate deployments of my ‘api’ and I’m using mongo commands to sync the dbs on publish. While this technically solves the issue, it’s a bit heavy and I’d like for my users to be able to publish to production without involving dev. I played a bit with apostrophe-workflow, but it doesn’t seem to play well with apostrophe-headless. Any suggestions or thoughts would be greatly appreciated.
I’m not sure how headless comes into this picture, exactly; it sounds like your issue is more that you want to use what you call “staging” as what some of our clients call “preprod” - a server where you build production content and run the production code, but don’t have actual production traffic - and then push all the content to the production server at once after some sort of approvals process. The fact that the content can be accessed via apostrophe-headless is somewhat of a separate concern.
In most cases, we tell clients that if they really need a “safe place to play” with building new content before it goes live, they should use apostrophe-workflow so they don’t need separate “preprod” and “prod” servers.
Ah, but here is where headless does become an issue as you point out: It sounds like there are some issues with using headless and workflow together. That is not entirely surprising where the “write” APIs of headless are concerned, but I would not expect any issues with the “read” APIs.
Perhaps you can elaborate on the specific problems you are having with that combination and open github issues on the apostrophe-headless module about them?
Hey, thanks for responding so quickly. You are correct about the pre-prod notion. My ‘staging’ env is used mainly for content review. It may boil down to the fact that I am retrieving page data via apostrophe-headless using slug. It’s a branch I created to solve the 1:1 express to apostrophe lookup. As far as I can tell, retrieving a page by slug returns the page regardless of its workflow state and I am unsure how to retrieve workflow ‘versions’ of a page. I wouldn’t mind writing the necessary code to integrate the two, I would just want to better understand the way workflow retrieves pieces. Ideally I’d like to retrieve a page that meets slug and workflow-state conditions so that there could be different versions of each page in different environments. I want my content team to be able to move content from staging to production on their own.
In a completely different direction… I see the subdomain solution. I haven’t had time to go in that direction yet, but if headless would respect that configuration, I could see that working.