3 ms·

This tooling-first approach is basically what we're going for with http://www.hyperfiddle.net/ http://www.hyperfiddle.net/ – the requirements of the killer app

This tooling-first approach is basically what we're going for with http://www.hyperfiddle.net/ http://www.hyperfiddle.net/ – the requirements of the killer app are what drives the hypermedia API, the mechanics of which are extremely innovative and weird. One key difference is Hyperfiddle's I/O layer is decoupled from transport, it is not limited to http or client/server, which opens a whole spectrum of I/O configurations with different performance characteristics, including "ship the api definition over there so it can run near that secure database" like html/javascript layer apps are shipped over the wire. We think Hyperfiddle can emit Siren-compliant representations (or any other general purpose hypermedia mimetype), though Siren can not express the entire continuum of I/O and data ownership that Hyperfiddle's protocol can (and thus Hyperfiddle probably cannot be built directly on Siren – the tools must come first). We solve the caching problems with an immutable database (Datomic) which permits idealized caching of everything at every layer. If the constraint of an immutable database sounds like a dealbreaker today, it probably is; but it unlocks a whole new frontier of capabilities that apps ten and twenty years from now will require. Why are we designing new protocols for the requirements of yesterday?

Royalaid 8y ago
Just would like to say that being able to leverage an immutable DB at work is amazing, just give it a try and value (timestamp) and you can roll back to any point in the dbs history. Has saved so much heartache between debugging and undoing changes
- dustingetz 8y ago
  which database?
hermanradtke 8y ago
This is definitely interesting and I will spend some more time checking this out. This tooling looks more advanced than pretty much anything else out there, but from what I can tell it is a server-side driven approach. I have been trying to imagine what tooling that is client-side first looks like. It should not matter _how_ a server implements something, such as Siren, only that it properly follows the semantics of the Siren protocol.
- dustingetz 8y ago
  It can be server driven, but it doesn't have to be. It depends where the data is and what the permissible access patterns are and which process is responsible for enforcing them. These days the data that matters is in server-side databases with tightly controlled access patterns so it is pretty weird for the client to be in charge. Hyperfiddle's data protocols are sufficiently abstract to run anywhere in the continnuum of data ownership [1], but so far we've only bothered to implement the parts of it that matter to today-era businesses. Are we thinking about this the same way or have I missed the mark? [1] http://www.dustingetz.com/:urbit-continuum-of-data-ownership/ http://www.dustingetz.com/:urbit-continuum-of-data-ownership...
  - pdimitar 8y ago
    Wow, this is really interesting. Wish I worked on it! What tech and languages do you guys use? And are you hiring?

Royalaid 8y ago

Just would like to say that being able to leverage an immutable DB at work is amazing, just give it a try and value (timestamp) and you can roll back to any point in the dbs history. Has saved so much heartache between debugging and undoing changes

dustingetz 8y ago
which database?

hermanradtke 8y ago

This is definitely interesting and I will spend some more time checking this out. This tooling looks more advanced than pretty much anything else out there, but from what I can tell it is a server-side driven approach. I have been trying to imagine what tooling that is client-side first looks like. It should not matter _how_ a server implements something, such as Siren, only that it properly follows the semantics of the Siren protocol.

dustingetz 8y ago
It can be server driven, but it doesn't have to be. It depends where the data is and what the permissible access patterns are and which process is responsible for enforcing them. These days the data that matters is in server-side databases with tightly controlled access patterns so it is pretty weird for the client to be in charge. Hyperfiddle's data protocols are sufficiently abstract to run anywhere in the continnuum of data ownership [1], but so far we've only bothered to implement the parts of it that matter to today-era businesses. Are we thinking about this the same way or have I missed the mark? [1] http://www.dustingetz.com/:urbit-continuum-of-data-ownership/ http://www.dustingetz.com/:urbit-continuum-of-data-ownership...
- pdimitar 8y ago
  Wow, this is really interesting. Wish I worked on it! What tech and languages do you guys use? And are you hiring?