4 ms·

I agree, the biggest pain point I've identified in my tool is the actual configuration. It's okay for simple definitions, but as the number of endpoints grow, i

by adnanh 9y ago

I agree, the biggest pain point I've identified in my tool is the actual configuration. It's okay for simple definitions, but as the number of endpoints grow, it becomes messy. I started work on a CLI tool that would be responsible for managing the hooks.json file, but I haven't had enough time to devote to it. (My wife, my daughter and my daily job currently occupy most of my time...)

neuland 9y ago
The only part that made me comment was the rules definitions. I will gladly write key/value type config in JSON or YAML or whatever. But, writing the rules logic in it would be a big pain, because it is not easy to see what deeply nested and and or statements mean. JSON is definitely nice for the time vs. effort balance; you've effectively got the users writing AST directly. And, building tooling to make it easier to write and manage is good. I've had a couple of projects recently where I was writing a parser. And, there is a lot of tooling to make it easier: lex/flex, yacc/bison, PEG-style tools like Python's Parsimonious [0]. (I'm sure there are similar libraries in JavaScript) Defining the grammar is a bit arcane, but the only other thing you write is the interpreter, which you already have a version of (just with a different AST format). In any case, the project/service is really cool! [0] https://github.com/erikrose/parsimonious https://github.com/erikrose/parsimonious
neuland 9y ago
The only part that made me comment was the rules definitions. I will gladly write key/value type config in JSON or YAML or whatever. But, writing the rules logic in it would be a big pain, because it is not easy to see what deeply nested and and or statements mean. JSON is definitely nice for the time vs. effort balance; you've effectively got the users writing AST directly. And, building tooling to make it easier to write and manage is good. I've had a couple of projects recently where I was writing a parser. And, there is a lot of tooling to make it easier: lex/flex, yacc/bison, PEG-style tools like Python's Parsimonious [0]. (I'm sure there are similar libraries in JavaScript) Defining the grammar is a bit arcane, but the only other thing you write is the interpreter, which you already have a version of (just with a different AST format). In any case, the project/service is really cool! [0] https://github.com/erikrose/parsimonious https://github.com/erikrose/parsimonious
ziikutv 9y ago
I would suggest some sort of a generator instead of creating CLI as if you have many endpoints, this will be a chore. As an example: We worked on something similar for a school project in Python, where you would simply write classes for each things, which would then create a JSON file. In your case, might not be what you want if you do not want to tie to a single language though.

by adnanh 9y ago

neuland 9y ago

The only part that made me comment was the rules definitions. I will gladly write key/value type config in JSON or YAML or whatever. But, writing the rules logic in it would be a big pain, because it is not easy to see what deeply nested and and or statements mean. JSON is definitely nice for the time vs. effort balance; you've effectively got the users writing AST directly. And, building tooling to make it easier to write and manage is good. I've had a couple of projects recently where I was writing a parser. And, there is a lot of tooling to make it easier: lex/flex, yacc/bison, PEG-style tools like Python's Parsimonious [0]. (I'm sure there are similar libraries in JavaScript) Defining the grammar is a bit arcane, but the only other thing you write is the interpreter, which you already have a version of (just with a different AST format). In any case, the project/service is really cool! [0] https://github.com/erikrose/parsimonious https://github.com/erikrose/parsimonious

neuland 9y ago

ziikutv 9y ago

I would suggest some sort of a generator instead of creating CLI as if you have many endpoints, this will be a chore. As an example: We worked on something similar for a school project in Python, where you would simply write classes for each things, which would then create a JSON file. In your case, might not be what you want if you do not want to tie to a single language though.