Wordpress subdirectory solution
Reasoning
For SEO reasons, it can (potentially) be beneficial for the coding app to be assigned to a subdirectory of the main (i.e. codetribe.com, codejika.com, etc.) websites (i.e. codetribe.com/app), instead of for example app.codetribe.com.
If that's the goal, then it would arguably make more sense and be less convoluted for the main website and landing pages to be built into the app's web framework, provided it supports SSR or SSG (in our case Next.js, hardcoded content or sourcing content from a headless CMS).
If, however, the decision is made to stick with Wordpress for the forseeable future, then there is no way to avoid a certain degree of complexity in the implementation. Especially if it's further stipulated that the Wordpress websites remain on managed wordpress hosting (Siteground) and the app remains on managed Jamstack hosting (Netlify). Not that I would recommend self-hosting or managing cloud infrastructure, that would be opening up a whole different can of worms and is by far the less desirable option for this project and the capacity of those involved.
Technical Solution
So since we are working within the confines of multiple managed hosting services and don't have access to a designated "router" (think nginx reverse proxy or a load balancer), we need to decide which one of our services (website or web app) should take over the role of "router" a.k.a. the single source of truth.
Siteground (and I would assume any managed wordpress service along with most managed hosting providers) does not provide access to Nginx vhost configuration. I will refrain from going into why but suffice it to say there are reasons. They use Nginx as a caching mechanism, with Apache running under the hood and a lot of apache htaccess functionality is not available if you have the Nginx cache enabled, which is of course recommended for performance reasons anyway.
Even if you were to disable the Nginx cache, you still can't configure URL rewrites to external URLs using just Apache. This only works for relative paths, and external URLs will be redirected instead of rewritten (so for example when you visit codetribe.com/app it will redirect you to app.codetribe.com ). This of course defeats the purpose of the entire exercise.
So TLDR; we can't use Wordpress on Siteground as the "router".
Meaning it has to be the web app. Luckily for us this isn't a problem. There are many ways to solve this issue (Netlify or Vercel level redirects configuration, next.js level config rewrites, Next.js middleware level rewrites, etc.).
Next.js middleware is very powerful and versatile. And since we need a versatile routing solution for v2 multi-tenancy (domain-level multi-tenancy and client-level multi-tenancy) anyway, it would make sense to combine all that routing logic into a single solution.
The Middleware
An initial working solution is already implemented on the main repo n branch in src/middleware.ts, though more work is needed. Some additional regex matching is also needed to avoid the performance overhead of calling the middleware function for every path.
https://nextjs.org/docs/api-reference/next.config.js/rewrites#incremental-adoption-of-nextjs
The Wordpress side of things
ToDo explain the modded plugin used, add some links, etc.
https://wordpress.org/plugins/multiple-domain/
http://wordpress.codetribe.ru/wp-admin/options-general.php
https://tools.siteground.com/filemanager?siteId=S3d6L1kzb0pKQT09
DNS
The domain's A Record needs to point to the "router", in our case the web app. Meaning in the case of codetribe.com, it would point to Netlify or whereever the web app is hosted. And the wordpress installation would need to run on a different domain or a subdomain, for example wordpress.codetribe.com
POC
A working proof of concept is already up and running on codetribe.ru
Are there are any downsides to this solution?
Maybe. Obviously, there is a very very slight performance impact when accessing Wordpress pages as everything is routed through Netlify edge functions. But Wordpress isn't fast to begin with and neither are managed wordpress hosters. So having some managed wordpress hoster act as the "router" instead would arguably be much slower in general and make requesting the web app very sluggish, and in our case it's just not possible anyway.