the connection target for the HttpClient should be the hostname and port of your solr instance.

IIRC /conf does not know about runmodes. 

You don't need to read all these properties manually, the HttpClientBuilder can do that for you if you use the proper methods (as shown in the screenshot). Also it seems that your solr URL looks like this: localhost:3128:URL/solr/...Which seems really odd to me. Please use the recommended way of Htt...

There might be reasons why a scheduler is mandated; it's definitely not a No-Go, but that decision needs to be driven by the project requirements. The same applies to AEM CS.

When you add the topic sitemap and search engines, I think that you might end up with implementing both approaches:* Use the selector-based approach to render a version for the search engines. It will also include a JS snippet, which switches to the "anchor-based approach" ("#") if a browser visits ...

https://www.site.com/page.id1.html is cacheable, but of course you have a cache copy per ID.https://www.site.com/page.html?id=1 is not cacheable on CDNS because of the query stringhttps://www.site.com/page.html?#id=1 is cacheable; you have also just 1 copy of the page.html in the CDN cache (as the d...

With your idea of merging the data on the backend: The problem is not necessarily that this is a hard task or takes a lot of time. It's rather that each of these requests cannot be cached, so you have additional latency and therefor impact on the enduser. Also this approach does not scale, because w...

I don't think that the suggestions for scheduler usage are fundamentally different than on AEM 6.x; an in both cases you need to be aware that each publish instance executes the scheduled job on its own. That means, that any if these jobs run outbound requests, each publish will send these outbound ...

 data-sly-use.model="com.allb2bsites.core.models.PageHeadModel"This code will try to instantiate the PageHeadModel interface, which does not work.  data-sly-use.page="com.adobe.cq.wcm.core.components.models.Page" lang="${page.language.toLowerCase}"data-sly-use.pwa="com.adobe.cq.wcm.core.components.m...

I am not a frontend architect, so I cannot give you good recommendations how to integrate that dynamic data into the resulting DOM. Probably depends quite a bit on the nature of the data you integrate and if they are simple key-value pairs or needs to include structure on its own.Of course if you do...