Quick and dirty decoupled CiviCRM with cron and export/import?

Question

Working with an architecture of Drupal 8 running Open Social, and Backdrop running CiviCRM. Currently both virtual hosts on the same server, with separate mysql databases. The key issue: after tearing up and throwing out several architectures, I am months behind and need to get a demonstration site up and running yesterday, with a functional 1.0 ready as soon as possible—weeks, not months. The snag: I'm new to nearly every component here, with a background in a dozen CMSes and a few CRMs, but not these.

Have been consuming a firehose of information, and nearly every step has a dozen prerequisites that could take a week each. For example: a new member joining the organization needs a user account in both Drupal and Backdrop, with Backdrop integration to CiviCRM. It seems the "standard" method is to do this with API calls, but I'm new to the API and the three techniques the docs tell me I can use. Would be fine if this were January, but not in August.

Problem 2: whatever I build now is likely to be rapidly obsolesced. When CiviCRM is official for D8, we might decide to consolidate under one roof. Or I might be convinced by the increased security of CiviProxy and segregate the full Civi db behind a VPN. (Skipping it for now, I don't have time to learn what's not available yet.)

My question: are there quick and dirty techniques I can use to bypass the more expert methods? For example: export and import I can learn quickly, so if I write a single abstracted function, I can write data to a local file and use a cron trigger to read it into the other side. Boom, I can move data back and forth without resorting to a custom API script for each function. Nearly everything one site does will need to be reflected in the other; I need the simplest way of doing this.

I'm guessing I'll still need APIs for some activities, i.e., logging into the D8 site should be a single sign-on for both sites. (No idea how to do that. Help requested.) And I'm still totally unclear what UI will live where—that is, do I build members-only content in Backdrop, or do I use D8 views to pull in CiviCRM data and present there only? Again—the fastest and simplest is best, even if ugly; there will be time to retool later.

Suggestions? Many thanks, I'm drowning here.

Answer 1

I think I have a partial answer—or at least, a tool that's looking good.

Answering Demerit's comment: both the Backdrop/CiviCRM and D8/Open Social sites are going to have public pages. My original assumption was that D8 would be primary site, with CiviCRM information fed into it—but the last few days of deeper dives into CiviCRM indicates that so much functionality is available there "for free" that I'm likely to make that the primary site, with a secondary community.mydomain.org domain for the social networking aspects. There's just a ton of stuff I thought I would have to custom-build which someone has already included in core.

Still the case that I need a new user/CiviCRM account to create its equivalent on D8, and that single sign-on would be nice. Both domains are subdomains of mydomain.org, so I can tackle that with cookies, but since I have to do account creation anyway, a more elegant approach that allows new domains to be used would be nice (we currently own four). This YouTube video on data integration led me to Pentaho, which looks excellent both for its abstraction capabilities handling any dataset, as well as its scripting interface. Not seeing much point in going through the trouble of learning and implementing SAML if I can do it all in one package. (And for the initial release, there are few methods I could use to avoid all of this—i.e., creating a hash on the primary site that someone has to use to create an account on the second manually, and suggesting they log into both with the "remember me" checkbox turned on.)