6 ms·

In web, IO is heavily intertwined with business logic and mutation. In fact most of the computation is done via the database. Database code is mutation heavy an

In web, IO is heavily intertwined with business logic and mutation. In fact most of the computation is done via the database. Database code is mutation heavy and offloaded as IO away from the web application. The web application is in fact just a thin routing layer. It is not a one off case.

lmm 3y ago
> In web, IO is heavily intertwined with business logic and mutation. In fact most of the computation is done via the database. Database code is mutation heavy and offloaded as IO away from the web application. The web application is in fact just a thin routing layer. That's one way of writing a web service. It's not the only or even "normal" way - IME it's much more common to have the database act as a dumb CRUD key/value store, and put logic in the application layer (indeed many web services use a pure key/value store rather than a "database" as such). You're right that if your logic is in the database, and it's an ACID-style "mutate the current state of the world" database then you can't really use pure functional techiques. The only solution to that is to not do that.
- corethree 3y ago
  >That's one way of writing a web service. It's not the only or even "normal" way - IME it's much more common to have the database act as a dumb CRUD key/value store, and put logic in the application layer (indeed many web services use a pure key/value store rather than a "database" as such). Wrong. The normal way is SQL. Web applications are suppose to be written in ways as nonblocking as possible. As much logic that can be pushed to the database as possible. That is the way to go. This reduces round trip time by a huge amount. The pure key/value store is non-standard, but it is a way to do it. Not the traditional way and not the majority way either. Many of the major web application frameworks assume SQL as the underlying database not mongo or some other key value db. >You're right that if your logic is in the database, and it's an ACID-style "mutate the current state of the world" database then you can't really use pure functional techniques. The only solution to that is to not do that. Not only am I right. It's the main way things are done on the web. The functional layer is largely just code generation: Pure Functions with http requests as input and SQL code as output. This is the core model.
  - lmm 3y ago
    > Wrong. The normal way is SQL. The normal way is SQL. Web applications are suppose to be written in ways as nonblocking as possible. As much logic that can be pushed to the database as possible. That is the way to go. This reduces round trip time by a huge amount. No it isn't. Most popular web frameworks expect to be used with an ORM and will autogenerate CRUD queries, while providing minimal if any support for more complex queries with logic in them. > Many of the major web application frameworks assume SQL as the underlying database not mongo or some other key value db. They do, but they use those SQL databases like a key value store - read/write by primary key most of the time, with occasional relationships but nothing fancier than that (e.g. no aggregations).
    - corethree 3y ago
      >No it isn't. Most popular web frameworks expect to be used with an ORM and will autogenerate CRUD queries, while providing minimal if any support for more complex queries with logic in them. Or a query builder. Whether you use the ORM or query builder to build the queries or you manual build it is up to you. That's exactly my point. These queries aren't "autogenerated" you're writing a query in your web application with primitives decided by the framework and the ORM and then it's getting compiled into a SQL query with SQL primitives that's it. It's the same thing. I don't know what you're negating here, you're basically regurgitating exactly what I said. >They do, but they use those SQL databases like a key value store - read/write by primary key most of the time, with occasional relationships but nothing fancier than that (e.g. no aggregations). Wrong. A SQL database is more like an array. Things are stored in memory one after the other. That is the default. You can then choose an index, and have pointers to sections of the array that can make it havethe speed of your typical hash map or n-ary search tree. There is a huge amount of logic being thrown into IO.
      - lmm 3y ago
        > I don't know what you're negating here You said "As much logic that can be pushed to the database as possible" and that's simply not true. The normal, mainstream way (like it or not) is to use the database as a dumb store and have the business logic in the application layer. > A SQL database is more like an array. Things are stored in memory one after the other. That is the default. You can then choose an index, and have pointers to sections of the array that can make it havethe speed of your typical hash map or n-ary search tree. There is a huge amount of logic being thrown into IO. None of that is business logic. It's implementation details at best.

lmm 3y ago

> In web, IO is heavily intertwined with business logic and mutation. In fact most of the computation is done via the database. Database code is mutation heavy and offloaded as IO away from the web application. The web application is in fact just a thin routing layer. That's one way of writing a web service. It's not the only or even "normal" way - IME it's much more common to have the database act as a dumb CRUD key/value store, and put logic in the application layer (indeed many web services use a pure key/value store rather than a "database" as such). You're right that if your logic is in the database, and it's an ACID-style "mutate the current state of the world" database then you can't really use pure functional techiques. The only solution to that is to not do that.

corethree 3y ago
>That's one way of writing a web service. It's not the only or even "normal" way - IME it's much more common to have the database act as a dumb CRUD key/value store, and put logic in the application layer (indeed many web services use a pure key/value store rather than a "database" as such). Wrong. The normal way is SQL. Web applications are suppose to be written in ways as nonblocking as possible. As much logic that can be pushed to the database as possible. That is the way to go. This reduces round trip time by a huge amount. The pure key/value store is non-standard, but it is a way to do it. Not the traditional way and not the majority way either. Many of the major web application frameworks assume SQL as the underlying database not mongo or some other key value db. >You're right that if your logic is in the database, and it's an ACID-style "mutate the current state of the world" database then you can't really use pure functional techniques. The only solution to that is to not do that. Not only am I right. It's the main way things are done on the web. The functional layer is largely just code generation: Pure Functions with http requests as input and SQL code as output. This is the core model.
- lmm 3y ago
  > Wrong. The normal way is SQL. The normal way is SQL. Web applications are suppose to be written in ways as nonblocking as possible. As much logic that can be pushed to the database as possible. That is the way to go. This reduces round trip time by a huge amount. No it isn't. Most popular web frameworks expect to be used with an ORM and will autogenerate CRUD queries, while providing minimal if any support for more complex queries with logic in them. > Many of the major web application frameworks assume SQL as the underlying database not mongo or some other key value db. They do, but they use those SQL databases like a key value store - read/write by primary key most of the time, with occasional relationships but nothing fancier than that (e.g. no aggregations).
  - corethree 3y ago
    >No it isn't. Most popular web frameworks expect to be used with an ORM and will autogenerate CRUD queries, while providing minimal if any support for more complex queries with logic in them. Or a query builder. Whether you use the ORM or query builder to build the queries or you manual build it is up to you. That's exactly my point. These queries aren't "autogenerated" you're writing a query in your web application with primitives decided by the framework and the ORM and then it's getting compiled into a SQL query with SQL primitives that's it. It's the same thing. I don't know what you're negating here, you're basically regurgitating exactly what I said. >They do, but they use those SQL databases like a key value store - read/write by primary key most of the time, with occasional relationships but nothing fancier than that (e.g. no aggregations). Wrong. A SQL database is more like an array. Things are stored in memory one after the other. That is the default. You can then choose an index, and have pointers to sections of the array that can make it havethe speed of your typical hash map or n-ary search tree. There is a huge amount of logic being thrown into IO.
    - lmm 3y ago
      > I don't know what you're negating here You said "As much logic that can be pushed to the database as possible" and that's simply not true. The normal, mainstream way (like it or not) is to use the database as a dumb store and have the business logic in the application layer. > A SQL database is more like an array. Things are stored in memory one after the other. That is the default. You can then choose an index, and have pointers to sections of the array that can make it havethe speed of your typical hash map or n-ary search tree. There is a huge amount of logic being thrown into IO. None of that is business logic. It's implementation details at best.