5 ms·

There is some good stuff in here, but it misses the biggest pain point developers face when trying to make a robust hypermedia API: tooling. There is a lack of

There is some good stuff in here, but it misses the biggest pain point developers face when trying to make a robust hypermedia API: tooling. There is a lack of tooling on the server side and almost no tooling on the client side. The amount of effort required to serve a RESTful API requires a lot of upfront investment. Then convincing the client developers to take advantage of the hypermedia affordances requires a lot of time and energy. If one does manage to convince them, the client tooling requires even more upfront investment. The only attempt at client tooling I have seen is the work done by Mike Amundsen. One thing GraphQL got right was focusing on the client tooling. If the client developers are bought in to the protocol/specification then the server developers will naturally come along. The reverse has not been true in my case. This opinion is based on my experience building hypermedia APIs, consuming hypermedia APIs and helping with the HAL hypermedia spec.

dustingetz 8y ago
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?
vasilakisfil 8y ago
Hi, author here. That was one person publication so tough to come up with tooling as well :) I think we just wanted to show that it is possible to come up with a different (better we think) architecture other than REST and that's a big thing I think. Relevant answer: https://news.ycombinator.com/item?id=18425581 https://news.ycombinator.com/item?id=18425581

dustingetz 8y ago

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?

vasilakisfil 8y ago

Hi, author here. That was one person publication so tough to come up with tooling as well :) I think we just wanted to show that it is possible to come up with a different (better we think) architecture other than REST and that's a big thing I think. Relevant answer: https://news.ycombinator.com/item?id=18425581 https://news.ycombinator.com/item?id=18425581