wire-all-the-things-lambda-days-2023.pdf
0 likes563 views
The document discusses the challenges and solutions related to data model generators in large applications, particularly focusing on encoding and decoding processes within a graph structure. It highlights manual wiring of components and modifying patterns for improved efficiency while avoiding complex type classes and effect libraries. The proposed approach simplifies dependency management and promotes maintainability through a registry-based function system.
![> ObjectArray [ObjectStr "stocks",ObjectInt 1]
> ObjectArray [
ObjectStr “stocks",
ObjectInt 1,
ObjectBool False
]
> ObjectArray [
ObjectArray [
ObjectStr “stocks",
ObjectInt 1
],
ObjectBool False,
ObjectStr “john"
]
Bad idea: Data.Generics](https://image.slidesharecdn.com/wire-all-the-things-lambda-days-2023-230608094818-f1d96713/85/wire-all-the-things-lambda-days-2023-pdf-13-320.jpg)
wire-all-the-things-lambda-days-2023.pdf
- 1. Wire all the things! Eric Torreborre
- 2. Encoders / decoders for a data model
- 3. Generators for a data model
- 6. What do they have in common? They form a graph Each node in the graph has a type The graph is in general acyclic It is useful to modify the graph • mock a component • evolve the data model • generate data differently
- 8. Protocol definition on the blockchain Immutable FTW
- 9. The only thing that doesn’t change is change itself New commands Better protocols Faster commands Deprecated commands etc…
- 10. What if we want to compress the parameters in V2? Transaction Signer Metadata Command NewChannel … Execute Contract Function Parameters
- 11. Bad idea: Data.Generics Use a newtype?
- 13. > ObjectArray [ObjectStr "stocks",ObjectInt 1] > ObjectArray [ ObjectStr “stocks", ObjectInt 1, ObjectBool False ] > ObjectArray [ ObjectArray [ ObjectStr “stocks", ObjectInt 1 ], ObjectBool False, ObjectStr “john" ] Bad idea: Data.Generics
- 14. Back to manual instances?
- 16. Manually: wiring
- 18. Can we make it easier? function application everywhere!
- 19. Better! Compact and incremental definitions functions in a list automated function application
- 20. TH to the rescue
- 22. Data generation
- 23. Data generation
- 24. Bad idea: typeclasses Applicative = fun But what happens when there’s a new field?
- 25. Bad idea: typeclasses I want transactions with no SendKey I want to force the contract version to be 2 I want distinct Signers etc…
- 26. Better idea: manually Ok, but can we make it easier?
- 27. Let’s extend the data model let’s add a Maybe and a list
- 29. TH for the boilerplate
- 30. I want transactions with no SendKey Super powers
- 31. I want transactions with no SendKey Super powers
- 32. I want to force the contract version to be 2 Super powers
- 33. I want to force the contract version to be 2 Super powers
- 34. Special care needs to be taken for recursive values! (see registry-hedgehog-aeson) Recursive data types
- 35. Applications
- 37. Bad idea: use typeclasses classes define interfaces instances define implementations constraints define dependencies
- 39. Bad idea n.2: use an effect library tedious, hard to navigate… Reify all operations (from https://github.com/hasura/eff)
- 40. Need to know about: Algebra, Carrier, type level operations etc… Write interpreters (from https://github.com/fused-effects/fused-effects) Bad idea n.2: use an effect library
- 41. (from https://github.com/thma/PolysemyCleanArchitecture) How to replace just `runInputConst`? Stack interpreters For a more in-depth review: https://abailly.github.io/slides/heureux-les-simples.html Bad idea n.2: use an effect library
- 42. Bad idea n.3: ReaderT Application FrontEnd Transaction Processor Event Listener ValueStore Sql Logger Tracer Http Cryptography
- 43. Better idea: manually Define components record of functions ~ interface dependencies ~ parameters constructor function ~ implementation
- 44. Manually: wiring Simpler than effects but still hard to wire / rewire
- 45. Using a registry
- 46. Profit! Modify dependencies No other change required!
- 47. Profit! Inject mocks for testing Changes are composable g f
- 48. Profit! Select the configuration at start-up We can make that code very declarative and flexible
- 50. Where’s the catch? YOU DON’T HAVE TO USE TYPECLASSES TO WIRE YOUR CODE. YOU JUST CREATE FUNCTIONS AND PUT THEM IN A REGISTRY. THEN YOU INVOKE THE INSTANCE YOU NEED BY PASSING ITS TYPE. AND IF YOU WANT TO INJECT ANOTHER INSTANCE ITS EASY YOU CAN JUST PUT ANOTHER FUNCTION ON TOP OF THE LIST. YOU CAN EVEN ADD IT ONLY TO A SUB PART OF THE GRAPH. YOU LEARN THIS TECHNIQUE ONCE AND APPLY IT TO MANY CONTEXTS: APPLICATION WIRING, ENCODERS / DECODERS, DATA GENERATION. MOST MODIFICATIONS ARE LOCAL AND YOU DON’T HAVE TO CHANGE THE WIRING CODE, WHICH MAKES IT IDEAL FOR MAINTENANCE. ON GITH
- 51. Type errors forget a dependency
- 52. Type errors add a polymorphic function
- 53. Type errors forget to use ‘add’
- 55. ReaderT IO to bind them all
- 56. Thank you! (And wire all the things with https://github.com/etorreborre/registry…)