# Polkadot Parachain Omni-Node: Gathering Ideas and Feedback **URL:** \ **Category:** Ecosystem\ **Tags:** node\ **Created:** [May 10, 2024, 2:52pm UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823 "2024-05-10T14:52:49Z")\ **Posts on this page:** 1\ **Showing post:** 9
**Author:** ![kianenigma](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/kianenigma/32/6153_2.png) [@kianenigma](https://forum.polkadot.network/u/kianenigma)\ **Post date:** [May 15, 2024, 5:06pm UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/9 "2024-05-15T17:06:36Z")
> [@crystalin](#): > > The challenge with the simplified builder is that upgrading will bring undetected changes (some of them breaking components compatiblity) which might be “ok” in a dev environment but could be problematic otherwise. Yeah, this is the problem with abstraction as usual. I would argue that teams that can afford the cost should maintain a full node software crate, and in return they will remain informed of more such changes. > [@wil](#): > > - The code to process the call is heavier than would be desired inside of the runtime > - The processing is better when native (becoming less of a concern as performance improves) Both of these are valid arguments, but you should be aware that both basically break the assumption of forkelss upgrade in some cases. in that, those RPCs that you put inside the Node/Native side will either have to be static, or else their upgrade process will be difficult as they are not part of the WASM blob. Have you considered @xlc’s suggestion as noted [here](https://forum.polkadot.network/t/stabilizing-polkadot/7175/6)? Can you point me to which of [your RPCs](https://github.dev/frequency-chain/frequency/tree/main/node) are entirely handled within the node side? > [@wil](#): > > I don’t think it invalidates having an omni-node for most use cases. Assuming no modifications to the node are operational, things like custom RPCs and such could still be available via a custom node while many/most node operators use an omni-node. Indeed, I find your examples interesting use-cases, but it is arguably fair to expect teams that want to do some extensive customization to use a full node template code base, so all of that would be outside the scope of the omni-node. --- _[View the full topic](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823)._