Skip to content

Critical L4 decision service improvements for active service #635

@serrynaimo

Description

@serrynaimo

Throughout testing I found the following limitations to be show-stoppers when it comes to deploying the decision service in larger production environments. In order of importance:

  • Return decision trace only with additional header setting (for performance, e.g. -x-jl4-trace: "full|partial") — 131dd4a
  • The decision service should ignore all #EVAL #ASSERT #CHECK etc used in a document. Those should be exclusively considered for IDE/other LSP use. Also to improve performance of decision service. — 00ea68b
  • YAML files with nested objects and arrays beyond one nesting depth should be supported by decision service
  • Boolean Minimization Implement Interactive Boolean Minimization for Query Relevance Reduction #638 (for consideration) — spec added: 0da26ad
  • Load and unload L4 files without service restart — already implemented: POST/PUT/DELETE endpoints + UUID loading (e330a8a)
  • A syntax to make a function available as evaluation API. My suggestion EXPORT identifier. That implies that multiple functions can be made available and it could be useful to allow EXPORT DEFAULT identifier per file as well. § scoping should still be considered. (and required if identifiers overlap) — complete: doc/done/EXPORT-SYNTAX-SPEC.md
  • IMPORTs must be working properly with the decision service for loaded files supporting only downstream folder structures. EXPORTs in imported files not loaded directly into the decision service should be available as well but somehow import scoped. (not to confuse with § scoping?) — 4e1c7cd
  • Performance must be considered a lot. I think ignoring # keywords will go a long way and also not compiling for debug, but it really needs to run super quick and with low resource usage even for thousands of loaded files. — 43c1ee1: 325x speedup
  • Great improvement: Require non-function arguments that are ASSUMEd to be passed in on evaluation. For now we can skip ASSUMEd function arguments as dynamically passing in code to run is a whole other problem. — spec work: 8f7a094

That should be good enough for now. Deeper rabbit holes like authentication we go into later ;)

Sub-issues

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions