4 ms·

Agree, Haskell's works best when working with flat data structures. IHP also only supports one-level nesting depth, like this: post <- fetch postId

by _query 5y ago

Agree, Haskell's works best when working with flat data structures. IHP also only supports one-level nesting depth, like this: post <- fetch postId >>= fetchRelated #comments This is fine for simple form based CRUD apps. As you mentioned you're consuming the data with a JS frontend: For these cases we added a subsystem called DataSync to IHP. DataSync allows to use the IHP query builder directly from the JS side. This way we basically avoid needing to hand-write these nested graph API responses. Complex forms that depend on a lot of complex data can now be implemented using React components. Here's an example query call from the JS: const todos = await query('todos') .where('id', 'd94173ec-1d91-421e-8fdc-20a3161b7802') .or(where('id', '173ecd94-911d-1e42-dc8f-1b780320a316')) .fetch() This way the frontend can query data that it needs just in time. And also write records to the database without needing to manually writing API actions (thus avoid the data tree problem). You can find an example of this here: https://ihp.digitallyinduced.com/Guide/realtime-spas.html#building-a-realtime-spa-with-ihp-datasync https://ihp.digitallyinduced.com/Guide/realtime-spas.html#bu... For web apps that are fully consumed by a single page app, we're right now building IHP Backend, which provides the IHP tooling + the DataSync API in a way that is way simpler than full stack IHP. If you're curious, you can find a demo video here: https://youtu.be/-jj19fpkd2c https://youtu.be/-jj19fpkd2c

all2 5y ago
> Haskell's works best when working with flat data structures. Is this a language specific thing? Syntax? Underlying implementation of the language? Is it a missing abstraction in the language?
- jeremyjh 5y ago
  I'm reluctant to say that it is impossible, because there are so many clever things that have been done with Haskell's type system that I can barely understand how to use, much less how to design those systems (like Servant's typed URLs). But from a naive user point of view, I don't see how its remotely possible to develop Ecto-style (or ActiveRecord style) associations with selective eager pre-loading, and typed validations against arbitrary trees of data with such a strictly typed system. And I think I've looked at every SQL library for Haskell and none of them really approach it. I'm sure its possible to build something that compiles, but it would be so awful to use that you are better off with hand-written SQL where you need it, and N+1 stuff where you can get away with it.
  - all2 5y ago
    If I understand this correctly: you are saying that strict-typing prevents arbitrary depth record requests to be made to SQL because Haskell cannot represent an arbitrary tree of types... I presume that the accessors in Haskell would be 1-1 with SQL language requests, but the problem is that SQL queries are not typed? Or are dynamically typed? So, instead of a generic library for SQL queries, one would have to implement a library for a specific SQL DB structure?
    - jeremyjh 5y ago
      There are typed query libraries, like esqueleto which give you well typed and flexible query semantics, my complaint with it is that it just returns a tuple of lists, with a separate list for each type, you cannot return the data structured in a tree. So if you have a companies table joined to a contacts table, you'd get a two element tuple with a list of companies and a list of contacts, and then you have to iterate to do the joins and turn it into a JSON tree. And there is no help at all for wanting to take in a tree of JSON data, and turn it into updates to existing records and inserts for new records. You could have a library that to knows how to return a tree if you define a typeclass for the tree, but the only way I'd know to do it would be a separate tree data type for each result set. In Ecto you do have to define a structure that knows all the possible associations, but which associations you actually load in any given query is flexible, you can have associations that are not loaded eagerly for one query, and loaded eagerly in another. In Haskell I can't imagine doing that without two different tree structs, because there is nothing that would know how to take two differently typed result sets and make the same tree partially loaded.
      - ParetoOptimal 5y ago
        > So if you have a companies table joined to a contacts table, you'd get a two element tuple with a list of companies and a list of contacts, and then you have to iterate to do the joins and turn it into a JSON tree. Esqueleto has a function to avoid n+1's and return a map now: https://hackage.haskell.org/package/esqueleto-3.5.3.0/docs/Database-Esqueleto-Experimental.html#v:associateJoin https://hackage.haskell.org/package/esqueleto-3.5.3.0/docs/D... https://www.foxhound.systems/blog/grouping-query-results-haskell/ https://www.foxhound.systems/blog/grouping-query-results-has...
- ParetoOptimal 5y ago
  > Haskell's works best when working with flat data structures One if the things Haskell is best at is parsing and the resulting data structures are very nested. What is an example data structure you think Haskell would struggle with? What language wouldn't struggle with that example?

by _query 5y ago

all2 5y ago

> Haskell's works best when working with flat data structures. Is this a language specific thing? Syntax? Underlying implementation of the language? Is it a missing abstraction in the language?

jeremyjh 5y ago
I'm reluctant to say that it is impossible, because there are so many clever things that have been done with Haskell's type system that I can barely understand how to use, much less how to design those systems (like Servant's typed URLs). But from a naive user point of view, I don't see how its remotely possible to develop Ecto-style (or ActiveRecord style) associations with selective eager pre-loading, and typed validations against arbitrary trees of data with such a strictly typed system. And I think I've looked at every SQL library for Haskell and none of them really approach it. I'm sure its possible to build something that compiles, but it would be so awful to use that you are better off with hand-written SQL where you need it, and N+1 stuff where you can get away with it.
- all2 5y ago
  If I understand this correctly: you are saying that strict-typing prevents arbitrary depth record requests to be made to SQL because Haskell cannot represent an arbitrary tree of types... I presume that the accessors in Haskell would be 1-1 with SQL language requests, but the problem is that SQL queries are not typed? Or are dynamically typed? So, instead of a generic library for SQL queries, one would have to implement a library for a specific SQL DB structure?
  - jeremyjh 5y ago
    There are typed query libraries, like esqueleto which give you well typed and flexible query semantics, my complaint with it is that it just returns a tuple of lists, with a separate list for each type, you cannot return the data structured in a tree. So if you have a companies table joined to a contacts table, you'd get a two element tuple with a list of companies and a list of contacts, and then you have to iterate to do the joins and turn it into a JSON tree. And there is no help at all for wanting to take in a tree of JSON data, and turn it into updates to existing records and inserts for new records. You could have a library that to knows how to return a tree if you define a typeclass for the tree, but the only way I'd know to do it would be a separate tree data type for each result set. In Ecto you do have to define a structure that knows all the possible associations, but which associations you actually load in any given query is flexible, you can have associations that are not loaded eagerly for one query, and loaded eagerly in another. In Haskell I can't imagine doing that without two different tree structs, because there is nothing that would know how to take two differently typed result sets and make the same tree partially loaded.
    - ParetoOptimal 5y ago
      > So if you have a companies table joined to a contacts table, you'd get a two element tuple with a list of companies and a list of contacts, and then you have to iterate to do the joins and turn it into a JSON tree. Esqueleto has a function to avoid n+1's and return a map now: https://hackage.haskell.org/package/esqueleto-3.5.3.0/docs/Database-Esqueleto-Experimental.html#v:associateJoin https://hackage.haskell.org/package/esqueleto-3.5.3.0/docs/D... https://www.foxhound.systems/blog/grouping-query-results-haskell/ https://www.foxhound.systems/blog/grouping-query-results-has...
ParetoOptimal 5y ago
> Haskell's works best when working with flat data structures One if the things Haskell is best at is parsing and the resulting data structures are very nested. What is an example data structure you think Haskell would struggle with? What language wouldn't struggle with that example?