Running Headless

[mikecasas]

Is there some setting to run Oqtane with just the backend?

[hishamco]

Nothing can stop you to use Oqtane as Source of Data, this could be done via built-in APIs

[hishamco]

@sbwalker AFAIK Runtime is define in Clients.UI so if it's not deployed an exception will throw or we need to move the API in a proper place without introducing a breaking changes

[mikecasas]

Maybe handle it on the config.

[sbwalker]

@hishamco you are correct - the Runtime enum class in the Client project should be in the Shared project - as it is used in both the client and server.

[hishamco]

It's already in appsettings.json but we need it to be a strong type

[hishamco]

@hishamco you are correct - the Runtime enum class in the Client project should be in the Shared project - as it is used in both the client and server.

I will push a PR keeping in mind backward compatibility and no breaking changes

[sbwalker]

@mikecasas it would be helpful to know what are you trying to accomplish...

[sbwalker]

I should also mention that "running headless" usually means the ability to run a back-end services API without any specific client UI - this is why it is called "headless" because a client app is considered to be the "head". The initial discussion in this thread were focused on how you would configure Oqtane to run headless ( ie. just the server components ). In this model, in theory you could create a client front-end in Angular or React and still use the Oqtane back-end. The discussion then evolved to being how to deploy the client and server aspects of Oqtane in a physically separated model - which is not really related to "headless".

[mikecasas]

Just for "completeness" and to clarify what I was asking. I pushed the Oqtane Client to Github pages. It obviously didn't work because I did not have a backend, but at least the client "came up" and I was able to see the error messages.

In response to the other threads, I personally would trade off some of the "dynamic-ism", for better decoupling.

Way out there - I could see the the Oqtane.Server as a micro services or even a server less backend, where you can scale specific parts. The DAPR project (https://dapr.io/) is interesting with it's side car model. This could align with Oqtane's philosophy of not taking dependencies, but achieve nice features like pub-sub.

I know I said alot, but just my 2 cents.

[PizzaConsole]

This was the same topic I posted here: #697 I will close mine as well as given the current state of Oqtane it will not be possible and would possibly cause breaking changes now if we were to try and change it. For this I have begun work on my own framework to achieve this functionality.

[sbwalker]

It is not clear to me how it would cause breaking changes? I mentioned above that I am sure it would be possible to modify Oqtane to support a decoupled static site use case.

[PizzaConsole]

It was just my initial thought given how the resources are dynamically added into the _host.cshtml file. My assessment carries no weight, as I have not spent much time investigating it.

[mikecasas]

I'll close this, as it's gotten off topic.

[thabaum]

Good question, good topic. Thank you for the read.