Roadmap/Production ready

[wdichler]

New Feature Proposal

Add a roadmap.

Description

As the version number 0.* describes, the library is not production ready? I would like to know what features are needed to make the library useful in production. What is the target timeframe for 1.*?

Background

The library, framework is the final piece of my architecture. My company projects are now organized for micro frontends. But the deployment work as usual as monolith. Piral for Blazor Server would close the final gap. I would like to dynamically upgrade/deploy a pillet whithout to restart the complete application.

Discussion

Because it's not easy to integrate/replace this library in existing/huge projects. The decision to use it must be well ellaborated.

Pro:

• Open Source, MIT
• Company Backed
• Unique for Blazor Server
• ...

Cons:

• Many MIT projects switch(ed) later to a company license with paywalls.
• Huge impact on architecture
• Difficult to detect possible problems on integration
• ...

[FlorianRappl]

Yes, it's a good point about the roadmap. We'll definitely hit 1.0 this year, but I cannot promise when exactly. I guess from a puristic point of view we are close, but it depends if we add a full hybrid mode within 1.0 or for later.

We now have (at least, i.e., that we are aware of / in close contact with) 3 customers who use Piral.Blazor.Server. One of them is very close to production. Every time they detect some issue we try to close it very fast; in any case it seems to plateau right now which means from a stability point of view we are confident to be 1.0 ready very soon.

Regarding the license; of course we won't be able to convince you / have all the answers for the future - but what I can tell you is that we don't plan on any license change or whatsoever. Our main product is consulting services (hire / contact us if you want to go through a potential migration from monolithic to distributed architecture) as well as software products for distributed frontends (such as the Piral Cloud - a leading micro frontend discovery service that plays nicely with our - as well as other - open-source libraries for micro frontends).

I'll add roadmap to the docs with the 0.5 release.

[wdichler]

Thank you for the fast and detailed response.
One question to the feed service, in the documentation there is following description:

Strictly speaking, a feed service is not necessary. You could use anything from a hardcoded list to a dynamically updated JSON file for getting to know where your pilets are.

Are there some examples for this offline replacements of the cloud feed 😉. As i understand this so far, the pilets can e.g. deployed to a private nuget feed. And the configuration, which pilets to use can configured in a dynamically changeable json file. The cloud service add additional functionality, e.g feature flags,.. and a more user friendly ui to manage the microfront ends. But functionally, they are the same?

[FlorianRappl]

But functionally, they are the same?

Well, we offer a Docker image - so you can just run it everywhere (e.g., on-premise - aka "offline").

Sure, you can also just have a JSON describing the MFs to be used, as well as a NuGet feed to actually get the MF packages (+maybe the same or other NuGet feeds for the dependencies). Functionality is pretty much the same, except that you will have a much harder time deploying + there won't be any live updates (so you'd need to restart the server or integrate something else - e.g., by polling the static JSON file) as easily as with a feed service; which naturally has events to be broadcasted.