Ok excellent. Got it. After reading many posts, docs, Logic features, WF API/Webhooks, etc I figured this would be the answer.
I might do the gap-filling myself and keep WF as the base platform bc WF is a super easy and great platform as a page manager / build goes. And, I would just have to document all the other systems / hacks I would have to implement for my friend so he knows in the future how to maintain all the moving parts (backend services and database, embedded JS code into each WF page, etc).
In fact, I’ve already built the AWS Lambda functions and API Gateway to do some additional work for his site (talking to other sites APIs, writing that data into WF database, creating another database to hold training event data that isn’t really needed to be stored in WFflow, etc).
But, yes, everything you said is exactly what I thought I was going to be facing. Which is fine, I can make it work via the escape hatch of “custom code embeds on WF pages, using their WebHooks, using their API” but I agree it’s far from completely seamless and sadly cannot be completely native within WebFlow.
I really do love WebFlow as a site management tool and page editor / builder, I just started learning it last month for his project and after the hard work of ramping up on exactly how it all works the more I like it.
Truth is, as I was sketching out designs last night on how to best make this is as easy for him to manage going forward after I complete the build, it seems to me some effort into some custom WF components along with my page embeds could fill all the gaps along with my backend. And still make it fairly easy for him to adjust / add pages / users / etc… I had to deep dive into making Dragula work in WF and FullCalendar for his site already so the more I learn about how to extend WF the more likely I will just stay here.
But, we’ll see where we land after I finish my analysis…