im working on a webapp and im being creative on the approach. it might be considered over-complicated (because it is), but im just trying something out. its entirely possible this approach wont work long term. i see it as there is one-way-to-find-out. i dont reccomend this approach. just sharing what im trying/investigating.
how it will be architected: https://positive-intentions.com/blog/decentralised-architecture
some benefits of the approach: https://positive-intentions.com/blog/statics-as-a-chat-app-infrastructure
i find that module federation and microfronends to generally be discouraged when i see posts, but it i think it works for me in my approach. im optimisic about the approach and the benefits and so i wanted to share details.
when i serve the federated modules, i can also host the storybook statics so i think this could be a good way to document the modules in isolation.
cryptography modules - https://cryptography.positive-intentions.com/?path=%2Fdocs%2Fcryptography-introduction--docs
p2p framework - https://p2p.positive-intentions.com/?path=%2Fdocs%2Fe2e-tests-connectionstatus--docs
this way, i can create microfrontends that consume these modules. i can then share the functionality between apps. the following apps are using a different codebase from each other (there is a distinction between these apps in open and close source). sharing those dependencies could help make it easier to roll out updates to core mechanics.
p2p chat - https://chat.positive-intentions.com/
p2p file transfer - https://file.positive-intentions.com/
the functionality also works when i create an android build with Tauri. this could also lead to it being easier to create new apps that could use the modules created.
im sure there will be some distinct test/maintainance overhead, but depending on how its architected i think it could work and make it easier to improve on the current implementation.
everything about the project is far from finished. it could be see as this is a complicated way to do what npm does, but i think this approach allows for a greater flexibility by being able to separating open and close source code for the web. (of course as javascript, it will always be "source code available". especially in the age of AI, im sure its possible to reverse-engineer it like never before.)
