Is Symbol enough stable for small and non-risk projects?

Technical Discussion
#1

I see a lot of conversations around Governance, Planning, Roadmap, etc etc. It seems that there is an overhead of communication that might turn the focus of people to unnecessary places.

I would like to know if Symbol is enough stable to start a Minimum Viable Product on top of it.

I’ve seen that there were different releases of Symbol, there were some that contained breaking changes and some that were more like a “soft fork”…? kind of at least.

The only thing that matters to me now is to know that if I start a product on top of Symbol, in a private network for example, will it be enough stable to me, as a developer, to keep working on top of Symbol without worrying about “hard forks”? Only applying soft-forks as they come, with the proper documentation and support.

If so, I consider the project stable enough to be used in non-risk projects, for experimentation and innovation.
If not, and you still think that you will need to apply breaking changes until Symbol is in the main net, then I consider Symbol to not be ready for small projects.

To be honest, I still see a room of improvement for the development and sysadmin experience. I know that Symbol isn’t released yet, but if I had better development and sysadmin experience, having small releases without breaking changes, for me then it’s not a problem if the latest release is at the end of year :slight_smile:

Keep working that hard folks!

I would say this question goes to @gevs @Jaguar0625 , which they seem to be more in charge of this topic.

4 Likes
#2

Hey! In short, yes, it’s completely possible to build an MVP on Symbol.

I’m building quite a few things on top of it with little issues. There are still hiccups that are expected with something that is in moving development, but we have been able to work around them with little troubles so far.

For example, here at IoDLT we have an IoT device that talks exclusively to Symbol for recording all sorts of information and device access control. We also are developing a pretty neat data marketplace / aggregation platform on Symbol, which is coming along nicely. Symbol so far as been very stable in running these applications - and I’d say I’ve abused it quite a bit :wink: So far, private networks have been running perfectly for my applications (after getting the hang of setting them up!).

It’s quite easy to get your own node up and running with docker for development. Larger scale networks are still a bit to get setup, but also are not impossible if you can config the node (some good configs exist, as such as the current testnet). Of course - you don’t even need to run your own node! You could just use one of the available networks, such as my devnet or the current testnet.

The JS / Typescript SDK is pretty stellar and is updated very frequently - perfect to use to build an MVP in Angular, React, or Vue, or a mobile hybrid framework like Ionic or React Native. You can use the patch file to alleviate any webpack issues.

The docs are quite amazing as well (kudos to @dgarcia360!) - everything there is well-written, includes code examples, and good explanations on the protocol.

Overall, there is more than enough to get started on a real application with Symbol - sure sysadmin does need some work, it took me a bit to get the hang of setting up a node, but it’s well on its way to getting there. Breaking updates are something that’s a bit natural at this stage, and it’s been agreed that it would be nice not to have them, as the servers have to be upgraded with it.

The only thing that matters to me now is to know that if I start a product on top of Symbol, in a private network for example, will it be enough stable to me, as a developer, to keep working on top of Symbol without worrying about “hard forks”? Only applying soft-forks as they come, with the proper documentation and support.

After public launch, this will probably be a focus. As a developer, this is probably the biggest inconvenience so far - but this is simply because the tech is still being perfected.

Just my perspective as someone who works everyday with Symbol, and wanted to show there is already so much you can do - hope you find it somewhat helpful!

2 Likes
#3

Hi @crackTheCode, you always so welcoming in the community! :smile:

I see all the benefits you are sharing, I would try to be more concrete about my concerns.

Meanwhile for a prototype or a Proof of Concept I don’t need stability because the goal of them are to see some evidence about the technology/business or whatever, for a Minimum Viable Product isn’t the same scenario.

What prevents me to start a MVP are changes like this https://github.com/nemtech/NIP/blob/master/NIPs/nip-0010.md proposed by @gimre (only 2 months ago).
I totally see the benefit of that NIP, it implied in Backwards compatibility the next:

As stated above, the changes are not backward compatible and will require new nemesis block in the testnet.

That makes the MVP non-viable in my scenario, meanwhile I don’t mind the overhead of applying soft-forks or similar non-breaking compatibility, we all assume that a project which doesn’t have a release yet, there will be changes, when having that huge breaking changes at protocol level… that’s not the same.

I would need to know if you see that there’s another breaking change at protocol level that will require a new nemesis block, and requiring to start a new chain, that it’s planned or you can say, it’s quite possible.

If it’s in API or SDK level, it’s not an issue. :slight_smile:

cc/ @gevs @Jaguar0625 @gimre

PD: I’m dying to start developing seriously on top of Symbol!! :weary:

2 Likes
#4

Hello there,

Always good to read that you are planning to use Symbol :ok_hand:

I would second @crackTheCode on that code is ready for integrations.

Note that there may be testnet network resets happening with finalization implementation as its a breaking consensus update.

One thing we had been doing with older networks is to re-use mosaic ids and generation hash. If that is possible with next protocol updates, we would do it.

One thing to note is that this is a testnet and it is more probable that it would see resets, I dont think this should disrupt your operations. We have build a new tech stack on top of server that barely changes with next updates (REST, SDKs, Buffers, …) to make this update process less disrupting for integrations.

1 Like
#5

I was considering using the private network for now, applying the incoming updates. I would like to be somehow sure that, I will be able to still use the next versions with easy upgrades instead of having to reset the private chain.

I totally agree that a testnet is volatile and I cannot rely on it. Plus, that’s not the purpose. But since seems like Symbol for private networks have been there for some time, I wanted to try it for an MVP.

#6

That is already incorporated in the current server version.

Finalization support will require changes at the protocol level. Upgrades between pre-public net versions will not be supported due to limited developer resources.

3 Likes
#7

I see, that was my expectation, that some protocol level changes were still needed.

I will wait until the first release then :+1:

1 Like