[mpweiher]

Nice.

But also a workaround, right? Because it's not actually declarative, it's APIs that are made to look declarative-ish.

So there's several layers of mismatch, for example most of the active ingredients being strings, meaning you're coding mostly in the string-language embedded into JS.

We do that a lot.

Probably time to start looking at our workarounds (and Macros are another workaround) and figure out what we are actually trying to do.

[jopsen]

> But also a workaround, right? Because it's not actually declarative, it's APIs that are made to look declarative-ish.

I'm not entirely sure what you mean...

In an ideal world "API" would be a keyword, similar to how "class" is a keyword for declaring/defining classes. Example:

    API MyApi {
      constructor(defaultName) {
        this.defaultName = defaultName;
      }
    
      /** some description */
      method: get
      route:  /hello-world
      scopes: some-permission-string || other-permission-string
      {
        let name = request.query.name;
        if (!name) {
          name = this.defaultName;
        }
        response.send('hello ' + name);
      }
    
    }
    module.exports = MyApi;  // similar to how you would export a class in JS

I think something _like_ this will be doable using rust macros in the future (if not already on nightly).

Whilst my JS code, where I create an API object and call API.declare(...) for each route isn't as neat as having an "API" keyword and code-generation for said keyword, it's pretty close.

I just write the API.declare(...) as something that collects arguments, and then those can be instantiated multiple times... Similar to how a class can be instantiated multiple times.

I do similar things for loading components that depend on each other: declare dependencies, define function for loading using said dependencies -- then have some library code construct a function that loads any desired component with maximum concurrency (by analysing the DAG).