Our great sponsors
-
Great little writeup ! After mangling YAML, HCL, JSON for years as an ops engineer, I have come to the same realisation. In fact, I have put this into practice in production pipelines by using: jkcfg[1] for the last couple of years. Two data points: 1. Zero developer support contract rate around YAML syntax and templating issues 2. High number of contributions in our private typescript configuration library from developers. Using typescript as an ops frontend has made operations a lot more approachable to folks.
Recently I took what learnt in the last 2 years using jkcfg/typescript and taken it to Deno in form of an opinionated port of jkcfg called: dxcfg[2]. Its early days, but I would bet on Deno/typescript for future ops configuration.
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
I have used TypeScript for config in a few projects, with node-config[1], and it’s substantially better IME than JSON/YAML/etc. Yeah it’s unconventional to write configs in a general purpose language, and I understand why that would be undesirable. But having configs validated at compile time is great at preventing bugs.
I’m not sure I’d recommend node-config (it was chosen by a past team). Its magic undermines the confidence in type safety provided by choosing TypeScript in the first place. But it does give some good baseline conventions one can apply without all the magic.
-
Anyone have experiences to share about Dhall (https://dhall-lang.org)?
On their homepage they call it a "programmable configuration language that you can think of as: JSON + functions + types + imports"
-
eps
Our endpoint system (eps) that manages and secures the communication between different actors in the IRIS connect ecosystem. Think of it as a distributed service mesh router as well as a decentralized message broker. Still evolving, use with caution. (by iris-connect)
I think parsing YAML or JSON into typed structures is the easier way to go. I e.g. do that in Golang using a little form validation and coercion library I've written. The end result is a nested, strongly typed data structure. Here's an example: https://github.com/iris-connect/eps/blob/master/settings.go (the accompanying form validation configuration: https://github.com/iris-connect/eps/blob/master/forms/settin...)
In my experience, a lot of the validation needs to be done at runtime anyway as type checking alone won't allow you to e.g. validate if a string is a valid regular expression. Also, I think using TypeScript for configuration requires you to compile & interpret the configuration file in order to check it and obtain the data values. Not sure if I like that as it requires bundling the Typescript compiler with your program.
-
This could be solved by having some kind of sandbox (https://github.com/patriksimek/vm2), but I agree it complicates it.
It would be cool if tsc had a flag —sandboxed or similar that does not allow any sideeffects (fs access, output, forking, net requests, etc)
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
I'm pretty sure Deno just uses the open source TypeScript compiler: https://github.com/denoland/deno/tree/main/cli/tsc
-
My case involved generics (similar to [0], except I don’t recall why but the `length` property wasn’t appropriate in my use case), and after reading the crazy workarounds people came up with in a related issue[1] I gave up on trying to be too precise in TS. Its type system is still very, very useful, but not as a means of specifying exact constraints—running code (with all corresponding drawbacks) would be required to validate given structure.
-
protobuf may very well be total overkill. What you wanted to do was strongly type your configuration. What you get is a complete RPC layer.
This might not even be warranted when inter-process communication is a primary concern. After all, there's nothing inherently wrong with using whatever data transfer mechanism your standard lib provides.
It's not just protobuf though. Almost every data format for serializing structured data suffers from pushing a jungle on you when all you asked for was a banana.
The least invasive format I know of is FlatBuffers[0]. Doesn't push RPC on you. Allows you to parse a message even if you do not know this specific message's data structure in advance (like JSON).
-
The Rust implementation has it as an experimental extension (https://github.com/facebookexperimental/starlark-rust/blob/m...)
-
2. Protobuf per se is just a serialization system, it does not push RPC "Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler." [0]. It can be used in combination with RPC systems, but does not have to.
-
No type support but I find jsonnet [0] pretty useful when you have tons of configuration files.
[0] - https://jsonnet.org/
-
I've really come to prefer json5 as a config format: https://json5.org/
It's basically Json with comments, trailing commas, and unquoted object keys (and some other minor things).
Much nicer than real json as a config format, but still simple and declarative, not requiring an interpreter or being turing-complete.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
