31–40 of 90 posts
We have just had an article hitting nearly the top on not to use JSON for config https://arp242.net/weblog/json_as_configuration_files-_pleas...
Earlier quoted context omitted.
Why not jq, then?
jq is a json parsing tool, no?
I don't think it would be very pretty since it's not designed for that use case, but the jq language is certainly powerful enough to allow it.
Some devs from my company just recently published https://jkcfg.github.io/ , building on lessons learned from many years of configuring Kubernetes. Since we are discussing JS for config management.
Tools like Zapier, Customer.io's webhooks, etc. allow integration with arbitrary APIs and have become a standard part of many marketing/sales stacks. These apps use things like Jinja, Mustache, or Liquid which are great for text but not JSON templates.
Curly braces as primary delimiters, not allowing trailing commas on final elements, and other features of JSON make generating it a real hassle.
Jsonnet is too complex to be that tool, but I'm glad people are working in the space.
Earlier quoted context omitted.
You're assuming that all code can be trusted. Jsonnet is much easier to make secure than JS, since it can be statically guaranteed to be safe and side-effect-free (e.g. can't access the file system). This permits evaluating arbitrary untrusted data, which can be a boon to systems like CI servers, databases, or even Kubernetes (think Helm charts).
He is producing JSON, just as you said. Not sure you understood him. He has a TS script that outputs JSON, which he is using as config.
He might trust his code, but I was highlighting reasons why this is not true everywhere, and indeed the ability to evaluate untrusted code can open up previously unavailable avenues. For example, storing server-side Jsonnet that can be safely evaluated by a multitenant backend.
Jsonnet is a functional lazy evaluated language that supports powerful referential concepts. Unfortunately the website sucks at getting this across.
JS on the other hand is an imperative programming language. If you say "use JS" you may as well say "use Python", the 2 are equivalent in this context and neither are in the same class as Jsonnet in terms of robustness and simplicity.
I didn't get it until I used it but after using it I don't think I would go back to test templating when it comes to dealing with JSON/things that are equivalent. i.e I would use Jsonnet to create JSON to convert to YAML rather than templating YAML directly. Same goes for generating objects directly in JS/Python/jq - yes it can be done, yes sometimes you can write a nice DSL but in most cases Jsonnet is going to allow you to write said DSL faster using functions and it's going to be simpler and less prone to errors.
This looks like a public version of gcl/borgcfg... But with JavaScript mixed in (so even worse, if that was possible)
Jsonnet does not have JavaScript, though. It's JavaScript-like , but not nearly as complex (e.g. no prototypes, classes, etc.).
From reading the website I see it actually was inspired by gcl/bcl for kubecfg, so hopefully they used some lessons learned!
Some devs from my company just recently published https://jkcfg.github.io/ , building on lessons learned from many years of configuring Kubernetes. Since we are discussing JS for config management.
There's already a relatively popular tool for JSON processing called jq, whose name in some languages already reads like "jk".
For people who doesn't know, GCL (Generic/Google Config Language) is a language that uses dynamic scope. You can define a `template` object with a variable defined as `external`. This way you can create similar objects by providing a concrete value for those `external`s at the time of instantiating.
The following paper was referenced in Google's borg paper and gives a good overview of the syntax.