All this should be send to a task queue, triggered by a call to your REST API.
Good luck with purity.
All this should be send to a task queue, triggered by a call to your REST API.
Good luck with purity.
> Many examples in functional programming assume that you are always on the “happy path”. But to create a robust real world application you must deal with validation, logging, network and service errors, and other annoyances.
> So, how do you handle all this in a clean functional way?
> This talk will provide a brief introduction to this topic, using a fun and easy-to-understand railway analogy.
Functional programming keywords/shorthands: option/either/monads
Most of your counter example needs integration tests to test properly anyhow - not really a good point.
If you can give up encapsulation (which IMO isn't actually that useful in practice) and in return, your program becomes 95% functional, that seems like a really good tradeoff.
2. code that listens to the task queue for new jobs
3. code that fetches a file from the FTP server
4. code that converts the JSON file to a format appropriate for the root finding
5. code that performs the root finding
6. code that converts the result of (3) to a format appropriate for insertion into a table
7. code that inserts the result into a Postgres table
Steps 4, 5 and 6 seem easy enough to implement in a pure fashion.
"Functional Core, Imperative Shell" was just posted too, this is the perfect example of where that structure works: https://news.ycombinator.com/item?id=34860164