Greenstone

Overview

Greenstone is currently a prototype/proof of concept for a future version of Redstone.dart or for a completely different project, if the vision doesn't fit the expectations of the current user base.

Motivations

As of the current principal maintainer of Redstone, I find it difficult to reason about the code and it is also very hard to modify existing code because of the strong usage of Mirrors (reflection). This makes it very hard to find out why things that should happen don't happen (or vice versa).

I believe that using code generation will make the coder easier to maintain, easier to debug, and even faster.

I am since a long time a user of Redstone, and I really enjoy the syntax and its usage philosophy. My goal is to make a new version of Redstone, or a project similar to it, but easier to maintain. To do so, I will try to create something as close as possible to the original APIs, however, if changing the APIs make it easier to reason about/maintain, I will strongly consider doing so.

Here's a list of the things I thought should be in this new version, with a small explanation of how I think it should work.

Features

• Generate Routing Based on annotations
• Support annotations on classes and functions
• Handler functions should have their parameters type as domain types
• Handler functions should have their parameters injected, deserialized
• Handler functions should have access to the request object
• Support interceptors/call chain
• Support plugin system

Routing:

Should take into account:

• parameters deserialization (see deserialization)
• call chain built for each handler, with the matching interceptors added to the chain (see call chain)
• delegate to groups/functions annotated with the matching annotations

Deserialization

Functions and classes annotated to be handlers/handlers groups should be passed deserialized values as their parameters. This should support:

• Basic types (num, String, etc)
• dynamic
• Object
• throw error when function is a parameter (or handle it, if so, how?)
• List
• Map
• Complex objects with a deserialization function (or a Decoder)

Call chain

• An interceptor should be able to inspect and manipulate the Request as well as the Response during the request
• An interceptor should be able to prevent further interceptors/handlers to run (via an abort mechanism)