How difficult is it to port traditional web applications to Holochain?

Technical Discussion Getting Started
#1

Holochain: Reinventing Applications makes the following claim:

[Holochain] is rather like a decentralized Ruby on Rails, a toolkit that produces stand-alone programs but for serverless high-profile applications .

That’s implying that Holochain apps won’t look radically different (in code) from traditional apps.

Does/will this hold true?

I wonder how hard it would be to make something like Lemmy (pure Rust Reddit-like) work as a Holochain app. Would it basically be a rewrite or could a lot of code remain the same? And would it be tenable to try support both the holochain and http connectivity layers indefinitely?

#2

Relevant:

As you can see, defining protocols is quite easy and completely abstracted away from other infrastructure tasks. The only thing we need to care about is writing the code that is useful for our app.

Notice if you run one terminal with the -quic flag, and one without, the latter peer can’t play PingPong with the former, because it doesn’t have QUIC support enabled. In a more realistic scenario, you would leverage all remote peer addresses you have available to have more chances to speak within an underlying transport protocol that both understand. Neat right?!

An important part of an application is its maintainability. In p2p applications, communication is at the heart of the application logic. An example of this is having powerful and simple ways to manage protocol changes.

#3

I think that if you’ve got a disciplined separation of concerns between UI, application logic, and storage/validation logic, it should be straightforward-ish. To test our hypothesis, we’re trying to create a Holochain backend implementation for Real World, “the mother of all demo apps”. It’s a Medium clone with zillions of fontend and backend implementations. If we can pull it off, that’ll be pretty cool. But then — Real World is extremely disciplined about its layer separations, and other more real-worldy apps are a bit muddy :wink:

The only thing you’d really be swapping is the storage layer. And hopefully that’s where all your validation code is too, because Holochain expects you to provide functions that validate each data write (that’s how it allows you to maintain data integrity in a P2P network).

In swapping the storage layer, though, there are some consequences that might ripple up through other parts of your app’s design:

  • Authentication/authorisation: there are no logins, and personal user data is stored by the user themselves and accessed through a special API.
  • Eventual consistency: there are already opportunities for the database server and the users’s GUI to get out of sync, so web devs should already be familiar with strategies for dealing with this. But in Holochain the database ‘server’ is actually tens, hundreds, or thousands of individual nodes, each with their own perspective on things. So you’ll need to handle consistency issues in your storage layer, not just between storage and UI.
  • Data design: On the DHT there are no tables and no queries (yet). That means you may have to design your data model slightly differently to get performance. Maybe full-text search is no longer possible, or maybe it’s slow, or maybe you have to build your own full-text search engine on top of Holochain.
2 Likes
#4

I would add a couple more tips to @pauldaoust 's post above.

  1. GraphQL: Paul notes that there are no tables, but there is a relational model (in the form of a graph DB) that can be crawled/queried. It turns out that the relational description model of GraphQL, which is being used more and more as a kind of middleware relational abstraction between front and back ends can map well to Holochain entries & links. We were able to port Hylo’s community tools over to Holochain with minimal changes to the front end, precisely because their GraphQL layer made it easy to map queries to Holochain.
  2. Importance of “Pagination” of Queries: With centralized systems, we’re used to grabbing a lot of data that we don’t necessarily need because it’s all local and just inflates the data package size a bit. However, on Holochain, since NOT all the data is local, if you make your social feed page load up an infinite history, then you glut the network with tons of queries that the user may not even scroll down to see. Most performance-minded sites use this kind of pagination approach, where you must scroll or click to see newer/older items, which it loads on demand. This is especially important on a distribute database to prevent every UI from flooding the network with unnecessary get requests.
2 Likes
#5

Oh yeah, good point, esp re: pagination. I’m still not sure I know what we can do that about, as pagination in a P2P system is hard to do. However! Pagination is always somewhat ‘eventually consistent’, since new data may have been written to page 1 while you’re reading page 2, which bumps every record down when you go and load page 3. You even see this showing up in certain database systems, like ElasticSearch (I won’t bore you with the details, but you can’t do pagination and aggregations at the same time).

2 Likes