The chapter "Application" (the one mentioning generic web applications) was meant as describing what services do from an outside perspective.
Internals may very well vary, but emphasizing on this structure removes a few problems (mostly state) and enables some performance optimizations (said laziness for external data).
To be honest, I did not yet write any meaningful application.
Mostly reinventing the wheel for educational purposes.
Haskell is just my hobby, as opposed to my job which is a GNU/Linux sysadmin.
The sysadmin background kind of taught me to just take already existing components and stick them together.
In sysadmin world this means sticking tools together with shell-scripts.
In Haskell world this means taking libraries like async or conduit and libraries for parsing the application specific protocols (HTTP, JSON) and sticking them together which, due to purely functional nature of those libraries is actually pretty easy.
I also mostly use Haskell itself for parsing (Parsec), so there is little I know in that respect.
However once again my sysadmin background helps out here: CLI-tools mostly take a stream of input on stdin and map it to something else on stdout.
If you write your "business logic" in a way that it takes a continuous stream of events and responds to each one using a response and a state-change then you can use it in any environment you like, as long as you can map something (HTTP requests, UDP packets, messages on unix-sockets, Websockets messages,.…) to that event stream.
Do not hesitate to ask for clarification, I'm pretty lousy in communicating my thoughts.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What framework do you use for your "generic web applications"?
The chapter "Application" (the one mentioning generic web applications) was meant as describing what services do from an outside perspective.
Internals may very well vary, but emphasizing on this structure removes a few problems (mostly state) and enables some performance optimizations (said laziness for external data).
To be honest, I did not yet write any meaningful application.
Mostly reinventing the wheel for educational purposes.
Haskell is just my hobby, as opposed to my job which is a GNU/Linux sysadmin.
The sysadmin background kind of taught me to just take already existing components and stick them together.
In sysadmin world this means sticking tools together with shell-scripts.
In Haskell world this means taking libraries like async or conduit and libraries for parsing the application specific protocols (HTTP, JSON) and sticking them together which, due to purely functional nature of those libraries is actually pretty easy.
I also mostly use Haskell itself for parsing (Parsec), so there is little I know in that respect.
However once again my sysadmin background helps out here: CLI-tools mostly take a stream of input on stdin and map it to something else on stdout.
If you write your "business logic" in a way that it takes a continuous stream of events and responds to each one using a response and a state-change then you can use it in any environment you like, as long as you can map something (HTTP requests, UDP packets, messages on unix-sockets, Websockets messages,.…) to that event stream.
Do not hesitate to ask for clarification, I'm pretty lousy in communicating my thoughts.