github.com/Racer159/jackal@v0.32.7-0.20240401174413-0bd2339e4f2e/adr/0019-decouple-transformation-library-from-jackal.md (about) 1 # 19. Decouple Transformation Library from Jackal 2 3 Date: 2023-05-28 4 5 ## Status 6 7 Pending 8 9 ## Context 10 11 We need a way to decouple transformations from Jackal. We know the Jackal transformation library is battle tested, hardened, and reliable. As Pepr takes admission responsibilities from the Jackal Agent, we need a way to synchronize the TypeScript with the Go code instead of maintaining two disparate libraries which will be expected to grow. 12 13 We considered: 14 15 - WASM 16 - gRPC 17 - REST 18 - Rewrite the code in TypeScript 19 20 #### WASM 21 22 **PROS** 23 24 - Shared codebase between TypeScript and Go 25 - Fast 26 - API Contract 27 - No network overhead 28 **CONS** 29 - New technology 30 - Requires new features in Pepr 31 32 #### gRPC 33 34 **PROS** 35 36 - Shared codebase between TypeScript and Go 37 - Fast 38 - API Contract 39 **CONS** 40 - Network overhead 41 - Pepr is considering adding a sidecar and we did not want potentially 3 containers in the Pepr Pod. 42 43 #### REST 44 45 **PROS** 46 47 - Shared codebase between TypeScript and Go 48 - Proven 49 - API Contract 50 **CONS** 51 - Network overhead 52 - Pepr is considering adding a sidecar and we did not want potentially 3 containers in the Pepr Pod. 53 54 #### Rewrite in TypeScript 55 56 **PROS** 57 58 - Low hanging fruit 59 **CONS** 60 - Two codebases to maintain 61 - TypeScript is not as battle tested as Go 62 63 ## Decision 64 65 We conformed around using WASM because we can leverage the battle tested transform library from Jackal without incurring network overhead cost from pod to pod or container to container communications. 66 67 ## Consequences 68 69 - Requires an Update to Pepr Core to package the WASM file because it is too large to fit in a ConfigMap 70 - This will require standardization around the objects that are passed from Pepr to the WASM functions to testability and maintainability.