Raindeer is an event-driven framework using the dynamic features and latest async improvements in Ruby + some weird ideas, to build a new breed of web application. Each Raindeer component can be used individually in your exisiting application, or all together as a cohesive framework. Deer to be different.
See: 🎬 Video Overview of Raindeer
LowType introduces the concept of "type expressions", allowing you to add inline types in your code, only when you need them. LowType is an elegant type checking system with the most minimal DSL possible. It looks like if Ruby had native types; def method(var: String).
LowLoop is an asynchronous event-driven server that ties into LowEvent to create and send events from the request layer right through to the application and data layers. Finally you can see and track events through every step of your application.
LowEvent represents events of all kinds; Raindeer uses RequestEvent, RouteEvent, RenderEvent and ResponseEvent. Plus you can extend with your own event types. Events can be observed with Observers.
The RainRouter accepts RequestEvents and directs the request to the appropriate observers. Simply add observe 'path/:id' to a LowNode and now it will be called every time a request is made to this route.
LowNodes are the flexible building blocks of your application. They can respond to a route request, or they can be called by another node. They can render a return value, or they can create an event. They are designed to be specific enough to observe events and return values, but generic enough to be split up to represent a complex application with its own patterns and structure. Nodes can render HTML/JSON directly from the Ruby class (via RBX, similar to JSX) and render other nodes into the output using Raindeer's special Antlers syntax; <html><{ ChildNode }></html>.
LowData follows the repository pattern with a twist; Data Expressions. A data expression like Users[:username] + Posts[:title, :body] builds a SQL query to OUTER JOIN the Users table into the Posts table and results in a list of posts with the user's username in each row.
Raindeer glues Low components together with a router, observers, pipelines and client-side integrations. It's decoupled and event-driven in a way that's deceptively simple whilst enabling scalable architectures.
Anything that just "is how it is" can be made simpler. It can take a lot of time to find a way how but it's worth it. Having grown up dumb; we should really care about people learning new things. People shouldn't have to learn much and one way to do this is by removing things:
- Namespaces - Lexical scopes can be confusing and the
::syntax just doesn't look right. They are optional (and still used internally by Raindeer) - Heredoc - Multi-line HTML can be written directly inside a Ruby class via RBX. See LowLoad
- MVC - Arbitrary files in arbitrary locations called in an arbitrary order. Just
observean event in a node and render output, or call more code
Developers will use patterns applicable to their application that are different to the framework's. This results in a tension between highly rigid framework patterns (MVC) and an application's. We shouldn't fight this but provide compositional entities and events that glue the application together. Raindeer uses LowNode to intercept the "request and response" layer then gets out of the way and let's the application structure itself from there.
Your files should just work out of the box. No one ever asked for a build step and it takes you out of your flow.
No build steps can internally create issues:
| Problem | Solution |
|---|---|
| Extra runtime processing | Process once on "Class Load" and clean up at the end of the application's boot stage |
| Less isolation between concerns | With extra effort we can still isolate these "mixed" concerns internally |
Methods and classes should be compositional, so that you can understand their hidden complexity by drilling down into them as they go, rather than calling one magic method that does a bunch of side quests. APIs should be less magical and more compositional.
A perfect example is the has_many helper method provided by various ORMs. This method adds "association" methods to a model, then hides the fact that databases do joins on tables. You will have to do a JOIN on a table eventually, so it's better to represent tables as being merged together from the start. There has to be a more compositional way that exposes the database structure while letting you query that structure easily. Raindeer uses LowData to represent table structure compositionally:
class PostsData < LowData
def all
Users[:username] + Posts[:title, :body]
end
endℹ️ This data expression generates SQL to OUTER JOIN the user table with the posts table and results in a list of posts with the user's username included in each row.
- Clone Raindeer Template
- Run
bundle install - Run
rain server - Visit http://127.0.0.1:4133/
Soon we'll have a rain new :app_name generator command. Could that future be you? It's currently stubbed.
Join us in the raindeer tag on the Ruby Users Forum.
Raindeer needs developer contributions around:
- Database layer - SQL generation, performance, migrations
- Deployment layer - Credential management, authentication
- Tooling - CLI, Static-site generation
- Performance testing and fixing
If you have a love for human-written code that's easy to understand then please consider making a contribution.