4 ms·
Reliability and composability are two reasons. With a blockchain architecture, the app can't go down unless the entire blockchain goes down. And apps can be bu
by everfree 4y ago
Reliability and composability are two reasons.
With a blockchain architecture, the app can't go down unless the entire blockchain goes down. And apps can be built piecemeal by many teams/hackers who add small bits of functionality here and there through standardized interfaces, rather than top-down by trusted agencies - "money legos".
- IanCal 4y agoComposability is the main one for me that's interesting. When serving data, I often use HTTP pulling from a Postgres DB. Both of those are massively over engineered for the problems I want to solve but I use them because: * They're already built so it's not my engineering time. * Others can interact with them easily. This is more strongly the case, and becoming more so over time, in crypto work. I can make something with key based auth that I can uniquely identify such that a user can prove they own it to integrate in my "real world" systems, while letting them sell it, trade it, auction it or whatever. To build this I do a starter tutorial, load a common library and publish. After I can just use already existing APIs for integration. That's it and it works because the data and APIs and Auth are all common and standardised now (either inherently for Auth or by convention for the data).
- gray_50 4y ago+1 on this answer. Put another way, it's a programmable settlement layer for the internet that anyone can access and is always online. Add in standardized interfaces and all applications built on it become easier to work with and extend.