DEV Community: Drash Land

Ohhhhh. It's been a while. Rhum 2.1.0.rc-1 tho. It's Node compatible btw!

Drash Land — Wed, 05 Oct 2022 05:21:55 +0000

Back in April we wrote about the Rhum v2 release. Since then, we've been working on some pretty cool updates! One of them being the "Spy" test double. The bigger one being Node compatibility!

Now that Rhum is dependency free, you can use Rhum in Deno, Node, Bun (cause it's a thing now), and (for whatever reason) the browser. As always, we got your back with full documentation (see it at https://drash.land/rhum) -- showing you how to use the test doubles and their definitions. Example code blocks were improved to include Deno, Node - TypeScript (ESM syntax), Node - JavaScript (ESM syntax), and Node - CommonJS.

The Spy/Node stuff is still in release candidate mode. We don't expect to introduce breaking changes, but if any issues surface or any issues are posted on Rhum's repo, then we might have to think things through. Other than that, enjoy the Spy test double and using Rhum in Node :). Here's some convenience commands for you:

yarn add --dev @drashland/rhum

npm install --save-dev @drashland/rhum

Links

Rhum v2.x Full Documentation

GitHub Release

Rhum v2.0.0 Released!

Drash Land — Sun, 17 Apr 2022 15:46:51 +0000

Title says it all! We released Rhum v2.0.0 yesterday 🙂. Need test doubles? Rhum got you.

Release Summary
New Concepts
- Why the Test Double Definitions
- Our Experiences From Other Testing Libraries and Our Solution
Rhum's Future
- History: A Year in the Making
- Looking Forward

Release Summary

Basically, two things happened since v1:

We removed the test runner (no more testPlan, testSuite, testCase, and hooks). I know... we're sad about it too. However, Deno's test runner has improved and has features that Rhum sought to add when Deno lacked them.
We improved the mock and stub test double APIs and introduced two others: fakes and dummies. The spy test double is currently in the works and will be included in a future minor release.

This being said, Rhum is strictly a test double library. For those currently using Rhum and want to continue using Rhum (for test doubles), we have a Migration Guide to v2 page that you can use to ease the migration process.

Rhum has zero dependencies -- not even Deno Standard Modules, which means it can be released to the Node.js ecosystem (yes, we plan to do exactly this 🙂).

You can view the full documentation at Drash Land - Rhum and the actual release at Releases - drashland/rhum.

New Concepts

Concepts from v1 to v2 have drastically changed. Rhum v1 had one goal: to provide pretty test result outputs (discussed here).

Now, Rhum only provides test doubles and they follow specific definitions (stated below).

Why the Test Double Definitions

Rhum's test doubles follow the test double definitions from Gerard Meszaros (as stated by Martin Fowler). We made it this way to prevent confusion on what test double to use during a system under test (SUT) and to make it easier to ask yourself questions like the following when writing tests:

Should this be a fake?
Should I pass in a mock to this constructor?
Do I need to create an expectation on this service that I am testing?
Does this need to be stubbed?
Are we verifying behavior or state?

Our Experiences From Other Testing Libraries and Our Solution

We found that other testing libraries can create some overlap between test doubles. This makes it kind of difficult to know what test double to use, why to use it, and what you are verifying in tests. For example, some testing libraries only have the concept of mocking instead of spying, faking, or creating dummies. Furthermore, some testing libraries have mocks that can also be stubs using (Mocks Aren't Stubs). This can lead you to not testing anything if you're just stubbing everything in your tests.

From our experiences and knowing the test double definitions written on Martin Fowler's website (shoutout to Breno for showing us this along with more information from research on the differences!), we sought out to provide a solution for creating test doubles. Here we provide the problem and our solution.

Rhum's Future

History: A Year in the Making

It's been a little over a year since we last posted about Rhum v2. Since then, we had many internal discussions, thought about EOL'ing Rhum completely after the introduction of test groups/hooks in Deno, thought about making it agnostic to the runtime using it, thought about making a new test runner, started development, stopped development, wrote new plans and goals, etc. We couldn't really decide what to do with Rhum... and a year went by (time really flies)! Rhum has been the unit/integration testing backbone for all Drash Land modules and we didn't want to just throw it away. It wasn't until about a little over a week ago that Ed said he was going to write the Rhum v2 docs in our Discord. I didn't think he was serious, but I was game for it. Shortly after, we introduced the test doubles and prepped for release without looking back -- stopping development yet again. Now we're here... v2... and SUPER STOKED about it!

Looking Forward

As for Rhum's future, we will continue to develop it as a test double library. Soon, it will be officially available in the Node.js ecosystem with documentation that covers the following:

CJS
ESM (TypeScript)
ESM (JavaScript)

Stay tuned for that! We're pretty excited to spill Rhum into the Node.js ecosystem.

Thanks for reading and happy testing!

-- Eric

Now supporting Deno v1.8.3

Drash Land — Sat, 03 Apr 2021 15:30:25 +0000

Hi y'all! It's been a while. So we noticed a flaw in our development workflow. Basically, whenever Deno updated its versions, we felt we didn't need to keep up to date with them as our modules "just worked" without issues. It wasn't until we noticed that you could be using the latest Deno version and have our modules import older versions of the Deno Std library (yeah... you can see where this could be prone to issues). This being said, we're now keeping up to date with Deno. As a result, every time Deno updates, we update.

All Drash Land modules now support Deno v1.8.3 and use Deno Std 0.92.0.

Get them while they're hot at https://drash.land!

-Eric

Drash v1.3.0 Release Notes

Drash Land — Thu, 05 Nov 2020 14:33:29 +0000

Drash v1.3.0 was released! This release contains a few new features, performance improvements, and bug fixes. Here are some highlights:

New Features
- Front-end TypeScript Support
- Create React Apps
- Improved Templating System
- Virtual Paths
Performance Improvements

New Features

Front-end TypeScript Support

With the help of Drash's ServeTypeScript middleware, you can write front-end TypeScript. Yup, you read that correctly! Front-end TypeScript.

Here's how it works:

You give this middleware TypeScript files to compile when your Drash application starts up.
When your application is starting up, the middleware compiles the files into JavaScript and saves the JavaScript in memory -- ready to be used when your application is running.
When a request is made to a TypeScript file from your front-end, the middleware sends back the compiled JavaScript -- allowing your browser to execute it.

Since the TypeScript files are compiled and cached when your application starts up, your application stays quick to respond to requests.

Want to scale your front-end using TypeScript with a single tool? Check out the ServeTypeScript tutorial.

Create React Apps

Drash comes with a basic tool to help you quickly create a Drash application with everything working out of the box. In the past, we only supported one front-end framework: Vue. Now, you can create both Vue and React apps.

Want to build a Drash + React app? Get started with Drash's Create App script here.

Improved Templating System

Drash has been reworked to support template engine middleware. Specifically, its very own Tengine middleware. This piece of software allows your Drash application to render HTML pages with the template engine of YOUR choice. If you don't have a preference, it also comes with a default template engine called Jae and it's super easy to use.

Want to render HTML in an easy, scalable fashion? Check out the Tengine tutorials.

Virtual Paths

Virtual paths allow a project's file structure to be more flexible. It also helps prevent you from having to give users access to parts of your system just so you can serve static assets such as CSS and JS files. We want you to keep your application secure, so we have added virtual paths -- allowing you to control what URLs map to what folders in your project(s).

Want to add virtual paths to your Drash application? Check out the tutorial.

Performance Improvements

We realized during our time hammering on Drash that it slowed down when the number of resources (similar to controllers in the MVC pattern) increased. Each resource increased the size of the cache used for resource lookups. This also increased the time it took Drash to match a resource with a given request. We figured out where Drash's performance decreased and restructured the way it looks for resources. Now, Drash keeps its performance up when loaded with 1 resource or even 10,000 resources. For more information about this performance issue, you can check out the discussions on the GitHub pull request.

View the Drash project here.

More information on this release can be found at https://github.com/drashland/deno-drash/releases/tag/v1.3.0.

Want to contribute to the Drash Land projects? View our "Good First Issues" here.

Drash Middleware v0.6.0 Release Notes

Drash Land — Thu, 05 Nov 2020 14:30:49 +0000

Drash Middleware v0.6.0 was released! This release comes with two new tools for your Drash application. Here's what we've added:

Front-end TypeScript Support
Improved Templating System Support
Cookie Support For CSRF

Front-end TypeScript Support

Want to write your front-end using TypeScript? Now you can with ServeTypeScript!

ServeTypeScript is middleware that allows you to write front-end TypeScript. How does it work? Here's the workflow:

You give this middleware TypeScript files to compile when your Drash application starts up.
When your application is starting up, the middleware compiles the files into JavaScript and saves the JavaScript in memory -- ready to be used when your application is running.
When a request is made to a TypeScript file from your front-end, the middleware sends back the compiled JavaScript -- allowing your browser to execute it.

Since the TypeScript files are compiled and cached when your application starts up, your application stays quick to respond to requests.

Want to scale your front-end using TypeScript with a single tool? Check out the ServeTypeScript tutorial.

Improved Templating System Support

Want to power your Drash application with the template engine of your choice? Now you can with Tengine!

Tengine is middleware that allows you to tell your Drash application how it should render HTML; and you can use the template engine of YOUR choice. This means you can use it with Eta, Dinja, dejs, or any other Deno template engine framework that you love.

Don't have a template engine in mind to use? That's okay too! Tengine comes with a default template engine called Jae and getting started with it is super easy. At Drash Land, we're very documentation-driven, so we've written some tutorials for you to get started quickly.

Want to render HTML in an easy, scalable fashion? Check out the Tengine tutorials.

Cookie Support For CSRF

Protect your application with this middleware. Learn more about Drash's CSRF middleware here.

View the Drash Middleware project here.

More information on this release can be found at https://github.com/drashland/deno-drash-middleware/releases/tag/v0.6.0

Want to contribute to the Drash Land projects? View our "Good First Issues" here.

dmm v1.2.0 Release Notes

Drash Land — Thu, 05 Nov 2020 14:29:15 +0000

dmm v1.2.0 was released! This release contains improvements to the CLI. Here are some highlights:

Added support for nest.land modules
info command can now fetch info on multiple modules

Don't know what dmm is? Find out more at https://drash.land/dmm or read this short article.

View the dmm project here.

More information on this release can be found at https://github.com/drashland/dmm/releases/tag/v1.2.0.

Want to contribute to the Drash Land projects? View our "Good First Issues" here.

dmm - A Deno Module Manager

Drash Land — Wed, 04 Nov 2020 02:03:46 +0000

dmm (pronounced "dim") is a Deno module manager. It can update your deps.ts file, check if any of your dependencies are out of date, and give you information about any module in the Deno world. Managing your dependencies hasn't been easier.

How It Works

dmm reads the deps.ts file at the current working directory -- checking versioned import and export statements and checking to see if they can be updated. If any dependency can be updated, it lets you know which ones can be updated. If you want to update them, dmm will rewrite your deps.ts file so that your dependencies reflect their latest versions in just one simple command.

Want to manage your Deno dependencies in a simpler manner? Check out dmm!

Drash's Performance Improvements

Drash Land — Sat, 31 Oct 2020 06:29:49 +0000

Soon, Drash will perform faster than ever. Although this is still a work in progress, Drash's codebase is being reworked to handle the workload of a VERY LARGE application. As a result, your Drash apps will perform faster than they currently do.

What this means is, for a Drash server with thousands of resources, it can handle up to ~284k requests in 10 seconds (or ~28.4k req/sec). For example, if up to ~28.4k people visited a website powered by Drash at the same exact time, they would all see the website load within 1 second. Due to this, it shows Drash is more than capable of handling the load for small and VERY LARGE web applications, whilst maintaining great performance. You can follow the progress of Drash's performance improvements at https://github.com/drashland/deno-drash/pull/393.

Machine Details:

MacBook Pro (Mid 2015), 2.5 GHz Quad-Core Intel Core i7, 16 GB 1600 MHz DDR3

As always, keep developing with confidence, friends!

(Join the community at https://discord.gg/6XkVDE)

Rhum v2 Coming At Ya!

Drash Land — Thu, 29 Oct 2020 12:57:37 +0000

(Edit 2021-04-04: Release date changed to July 1, 2021)
(Edit 2022-04-17: Rhum v2 was released, but it's not what we state in this post. Read more about Rhum v2 here.)

Rhum is coming out with its very own CLI in its v2 release!

Why
Findings
Current CLI State
When
Follow

Why

During our time developing Rhum v1.x, we realized that maintaining Deno.test() under the hood was a bit difficult. It also convoluted the codebase when it came to managing hooks and outputting test results. Basically, it was not flexible and easy to maintain. With that in mind, we decided a Rhum CLI was the best way to move forward.

Findings

After a couple days of developing a prototype, we found that it was super flexible and the codebase was a lot cleaner than having Deno.test() under the hood. We were able to add subcommand options easily in the CLI such as ...

--filter-test-case="someTestCaseName"
--filter-test-suite="someTestSuiteName"
--ignore="dir|file"

... and output prettier test results:

If you look closely at the above screenshot, you will see that the Actual/Diff output shows exactly what file threw the assertion error and on what line. This makes debugging faster than sifting through an error stack trace message. Needless to say, we like this feature a lot :).

Current CLI State

The current state of the CLI can be seen by its current help menu:

Rhum v2.0.0 - A lightweight testing framework for Deno.

USAGE

    rhum [subcommand] [options] [directory|file]

SUBCOMMANDS

    make [file]
        Make a test file.

    test [options] [directory|file]
        Run tests by specifying a test directory or test file.

    help, --help
        Display the help menu.

    version, --version
        Display Rhum version.


OPTIONS

    Options are categorized by subcommand.

    test
        --filter-test-case
            Execute the matching test case in the file(s) being tested. This
            option cannot be used with --filter-test-suite.
        --filter-test-suite
            Execute the matching test suite in the file(s) being tested. This
            option cannot be used with --filter-test-case.
        --ignore
            Ignore a set of directories or files.


EXAMPLE USAGE

    Execute the matching test case in the file(s) being tested.
        rhum test --filter-test-case="my test case" test_file.ts
        rhum test --filter-test-case="my test case" some_dir/

    Execute the matching test case in the file(s) being tested.
        rhum test --filter-test-suite="my test suite" test_file.ts
        rhum test --filter-test-suite="my test suite" some_dir/

    Execute all tests, but ignore directories/files.
        rhum test --ignore=./tests/data tests/
        rhum test --ignore=./tests/data,./tests/ignore tests/
        rhum test --ignore=./tests/test_1.ts tests/
        rhum test --ignore=./tests/test_1.ts,./tests/test_2.ts tests/

    Make a test file at /my/project/tests/my_test.ts
        rhum make /my/project/tests/my_test.ts

    Display the help menu.
        rhum help

    Display the Rhum version.
        rhum version

When

Rhum v2 is set to be released on January 1, 2021. We figured this date gives us enough time to:

add more validation features such as .lastCalledWith() and .lastReturned()
make the CLI feature-rich and user-friendly;
document new features;
write tutorials; and
write extensive tests.

Follow

Want to keep up to date with the latest Rhum v2 progress? Join the Drash Land discord at https://discord.gg/6XkVDE, or simply follow the pinned GitHub issue below:

https://github.com/drashland/rhum/issues/75

Thanks for reading and keep developing with confidence, friends.

Drash - A Unique Framework

Drash Land — Tue, 14 Jul 2020 17:26:13 +0000

Hey, my name is Edward Bebbington. I am one of the maintainers for Drash Land and all of its projects. Here, I am going to talk about what makes Drash different and how it stands out when compared to other frameworks.

What Makes Drash Different?
- Syntax
- Resources
Drash Compared To Other Frameworks
- Deno Frameworks
- Node Frameworks
Drash's Goals

What Makes Drash Different?

With so many frameworks already released in the Deno community, it can be hard to differentiate all of them. There are many that resemble popular frameworks like ExpressJS and Koa. Drash, on the other hand, is different. It doesn't resemble any of the Node frameworks and some might say it's the complete opposite of Express.

Deno was built to fix design mistakes and avoid certain things that Node used. One of those things is NPM. With this in mind, Drash sought to be different as well through its syntax and use of HTTP resources.

Syntax

You may notice Drash's syntax to be different than what you're used to using and seeing. Drash is very different than Node and Deno frameworks in terms of its syntax. Where Deno is different than Node, Drash aims to be different than Express or Koa. Unlike other frameworks, Drash utilizes resources and a full class-based system. This means it doesn't use app.get((req, res)). Instead, it uses this.request and this.response inside of the resource class, which is where your "routes" (aka paths) are also defined. As a result, this follows the MDN specs of HTTP Resources.

Furthermore, Drash takes a namespace approach with all of its data members being exposed under the Drash namespace. This is very different in terms of how a web application might be built inside of Node and Deno. Drash is a true object-oriented framework with the MDN as a backbone.

Resources

If you are familiar with Express, Laravel, or generally the MVC architecture, you might be familiar to routes and controllers. In Drash, a resource defines both in the same class. The resource is a class that handles requests for the HTTP verbs (e.g., GET, POST, DELETE, PUT) with each verb being its own request handler inside of the class. On top of this, the paths (or routes if it's easier) that a resource should handle are defined in that same class. An example of a resource is below:

// File: users_resource.ts

import { Drash } from "https://deno.land/x/drash/mod.ts";

export class UsersResource extends Drash.Http.Resource {

  static paths = ["/users", "/user:id"];

  public GET() {
    const userId = this.request.getUrlQueryParam("id");
    if (!userId) {
        this.response.body = "Return all users";
        return this.response
    }
    this.response.body = "The user";
    return this.response.body;
  }

}

And plugging the resource into your server is super simple:

import { Drash } from "https://deno.land/x/drash/mod.ts";
import { UsersResource } from "./users_resource.ts";

const server = new Drash.Http.Server({
  resources: [UserResource] // The UsersResource will now be registered in the server
});

server.run({
  hostname: "localhost",
  port: 1667
});

Drash Compared To Other Frameworks

You've probably figured out by now that Drash isn't like existing Node and Deno frameworks. So what truly makes Drash stand out from Express, Oak, MandarineTS, or any other framework listed under Deno's Third Party Modules (search for "framework" when looking at the Third Party Modules)?

Well, let's compare Drash to Node and Deno frameworks.

Deno Frameworks

Some well-known frameworks in the Deno community are Oak (similar to Express), MandarineTS (decorator framework), and Opine (similar to Express).

There are plenty of frameworks that are similar (or close to being an exact port) to Express. It can feel a little overwhelming. What makes Drash stand out is Drash isn't like Express. Drash is unique. Like I mentioned above, Drash has reasons for certain implementations. The problem with Deno frameworks is that most of them are similar -- taking Express and Koa as inspiration. Whilst it's good to have a variety of frameworks, it's also good that each one is different to cater to different people's preferences.

Node Frameworks

Drash isn't like any Node framework. It's something new and unique.

Drash's Goals

Drash aims to be different and unique -- helping people develop software with confidence through a clean and easy-to-use syntax. There were many problems for Drash in the early stages of its development (around 2018-2019). This was due to it trying to be similar to Express. What Drash has become has solved these problems and was introduced as a unique alternative to the Deno community.

I hope this was insightful. With there being many frameworks for Deno, it can be hard to differentiate all of them in a quick and clear way. Although this article doesn't go into detail about other frameworks, I hope this article helps you understand Drash more.

-- Edward

Want to start developing using Drash? Check out its documentation pages here!

Want to know why Drash was built? One of the founders of Drash wrote an article about it here.

Why We Built Drash

Drash Land — Sat, 11 Jul 2020 12:50:15 +0000

Hi, my name is Eric Crooks. I'm one of the founders of Drash. In this article, I talk about what Drash is and why I decided to build it with one of my colleagues. Before diving into this article, know that all statements made are by me and all opinions are my own.

What is Drash?
Why was Drash built?
- Problem 1: Syntax
- Problem 2: Debugging
- Solutions to the problems

What is Drash?

Drash is a REST microframework for Deno's HTTP server. It has zero dependencies outside of Deno's Standard Modules. It is designed to help you build your projects quickly -- APIs, SPAs, etc.

Why was Drash built?

Before Deno, I used Node and Express. Express was great, but I found issues with the development experience. Mainly, I had issues with the syntax and the time it took to debug issues. More code meant an exponential increase in duplicated code and debugging time. I wasn't a fan of that fact.

Problem 1: Syntax

Take a look at the code below. You might be familiar with the syntax.

app.get('/', function (req, res) {
  res.send('GET request received')
})

app.post('/', function (req, res) {
  res.send('POST request received')
})

app.put('/', function (req, res) {
  res.send('PUT request received')
})

app.delete('/', function (req, res) {
  res.send('DELETE request received')
})

This syntax is great for small applications. It's not so great for larger applications. I found that a large Express application comes at cost. That cost is the degradation of the developer's experience when writing code. The above code looks great, is easy to write, and helps you get started quickly. However, look at how much code is duplicated.

The req and res objects are passed in multiple times for each route you define
The / route is defined multiple times
The app object is used multiple times

This led me to ask myself the following:

Why can't the callback function that is passed into the route handler have the req and res objects readily available using this.req and this.res?
Why do I have to keep using app.?
Why do I have to define the / route one time for each HTTP method?

I'm lazy and don't want to have to write something multiple times if I don't have to. What I wanted was something like this:

app.route('/')
  .get(() => {
    this.res.send('GET request received')
  })
  .post(() => {
    this.res.send('POST request received')
  })
  .put(() => {
    this.res.send('PUT request received')
  })
  .delete(() => {
    this.res.send('DELETE request received')
  })

That syntax looks much better in my opinion and it's easy to write. You take the app object, define a route, and define the allowed HTTP methods for that route.

Problem 2: Debugging

In a larger Express application, your filesystem might be split up so that your front-end and back-end are organized in a way to help you identify where code lives. For example, your filesystem might look like the following:

app/
|-- assets/
|   |-- js/
|       |-- api.js
|       |-- another-js-file.js
|
|-- views/
|   |-- index.html
|   |-- another-view-file.html
|
|-- src/
|   |-- controllers/
|   |   |-- home-controller.js
|   |   |-- user-controller.js
|   |   |-- order-controller.js
|   |
|   |-- services/
|   |   |-- user-service.js
|   |   |-- order-service.js
|   |
|   |-- routes.js
|
|-- app.js
|-- package.json

Let's take the above example code and see why debugging is an issue with it. Inside of api.js, we see the following code and there's an issue with it:

axios.get("/users/1")
  .then((response) => {
    // code to handle the response
  })
  .catch((error) => {
    // code to handle the error
  });

For some reason, the back-end isn't returning what's expected. So let's take a look at the back-end. All we know is /users/1 is the route we need to start with. So let's go to our routes.js file and see what controller is mapped to the route. We see the following:

app.get('/users/:id', UserControllerGet);
app.post('/users/:id', UserControllerPost);
app.put('/users/:id', UserControllerPut);
app.delete('/users/:id', UserControllerDelete);

Ok, now we know that the UserControllerGet function is mapped to the GET /users/:id route. This looks promising because /users/:id matches the front-end's API call to /users/1. Let's go to the UserControllerGet:

function UserControllerGet(req, res) {
  res.send(userService.getUserDetails(req.params));
}

Now we're at the UserControllerGet function and see that the response being created comes from userService.getUserDetails(). So let's go to that file. Actually, let's not. This is too much sifting through code just to figure out where issues are occurring.

This debugging process led me to ask myself the following:

Do I have to go through this process every time I debug something? I have to look at the front-end API call, match the route to one of the routes defined in the routes file, and then go from there?
Why can't I just assume /users/* maps to a single UserController file and look in that file?

What I wanted was to remove the routes file completely and have:

// File: user-controller.js

app.route("/users/:id")
  .get(() => {
    this.res.send(userService.getUserDetails(req.params));
  })
  .post(() => {
    // POST code
  })
  .put(() => {
    // PUT code
  })
  .delete(() => {
    // DELETE code
  })

Again, you take the app object, define a route, and define the allowed HTTP methods for that route -- all in a single file.

So, how would I solve the syntax issues? How would I solve the debugging issues? Should I rewrite my code to make it work the way I want to? I mean, Express is unopinionated, so I could do that, but why not just create something that makes more sense? Why go with controllers? Why can't we go with resource-based logic? Some frameworks (e.g., Laravel) use resources and they kind of make sense. I had so many questions and in the end I decided to plan out a new framework with my colleague: Drash.

Solution to the problems

Instead of having app.get(), I figured it'd make sense to have a class with HTTP verbs ...

export class MyController {

  public GET() { ... }

  public POST() { ... }

  public PUT() { ... }

  public DELETE() { ... }
}

... and then you'd plug this into your application in some way. I wasn't sure at the time, but I figured it'd look something like:

import { MyController } from "/path/to/my_controller.ts";

const app = new App({
  controllers: [MyController]
})

What about the route definitions? Where do those go? I figured it'd be best to have the controller be in charge of the routes clients can use to target the controller. Like so:

export class MyController {

  public paths = [
    "/my-controller",
    "/my-controller/:some_param"
  ];

  public GET() { ... }

  public POST() { ... }

  public PUT() { ... }

  public DELETE() { ... }
}

With "resources" in the back of my mind and its definition, I figured the controller should just be named a resource. This is how they do it in Tonic (the PHP microframework). Everything in Tonic is a resource. Resources are PHP classes; and resources define their own paths. So now we have something like this:

export class MyResource {

  public paths = [
    "/my-resource",
    "/my-resource/:some_param"
  ];

  public GET() { ... }

  public POST() { ... }

  public PUT() { ... }

  public DELETE() { ... }
}

This looks great! Also, it solves the debugging issue. If I had a front-end that called /my-resource/something, I would already know to go MyResource because the URI should be mapped to a MyResource resource. Same thing goes for a /users API call. /users should map to a UsersResource.

What about the req and res objects? I figured it'd be best to instantiate a resource class and pass in the req and res objects in its constructor. That would give all of the resource class' methods access to the req and res objects without having to pass them in like in Express. This would also mean a BaseResource class would need to be used so that the resource classes that developers define wouldn't require the constructor. So, now we have something like this:

// File: base_resource.ts

export class BaseResource {
  public resource;
  public response;
  constructor(request, response) {
    this.request = request;
    this.response = response;
  }
}

// File: my_resource.ts

import { BaseResource } from "/path/to/base_resource.ts";

export class MyResource extends BaseResource {

  public paths = [
    "/my-resource",
    "/my-resource/:some_param"
  ];

  public GET() {
    this.request.doSomething();
    this.response.doSomething();
  }

  public POST() { ... }

  public PUT() { ... }

  public DELETE() { ... }
}

You might notice the change of the req and res names to request and response. I believe we should be explicit in our code so that newcomers don't question things like variable names.

After a few months of developing around the definition of resources with the syntax being the first thing considered (for a better developer experience), Drash was born. Originally, it was developed with an Express-like syntax, but maintaining that was a nightmare. This was especially true when trying to handle this.request and this.response in chained functions. So, Drash was forced to be different, and I think that's ok because most of its logic is backed by definitions in the MDN.

Hope you enjoyed reading this! I figured it'd be nice to give some insight into Drash.

-- Eric

New Drash Tutorial Videos!

Drash Land — Sat, 11 Jul 2020 01:55:48 +0000

Today, Edward and Eric made videos on serving static paths and handling application/x-www-form-urlencoded request bodies in Drash. Have a look!

Don't know what Drash is? Drash is a REST microframework for Deno's HTTP server. Start your journey here: https://drash.land

DEV Community: Drash Land

Ohhhhh. It's been a while. Rhum 2.1.0.rc-1 tho. It's Node compatible btw!

Rhum v2.0.0 Released!

Table of Contents

Release Summary

New Concepts

Why the Test Double Definitions

Our Experiences From Other Testing Libraries and Our Solution

Rhum's Future

History: A Year in the Making

Looking Forward

Now supporting Deno v1.8.3

Drash v1.3.0 Release Notes

New Features

Front-end TypeScript Support

Create React Apps

Improved Templating System

Virtual Paths

Performance Improvements

Drash Middleware v0.6.0 Release Notes

Front-end TypeScript Support

Improved Templating System Support

Cookie Support For CSRF

dmm v1.2.0 Release Notes

dmm - A Deno Module Manager

How It Works

Drash's Performance Improvements

Rhum v2 Coming At Ya!

Table of Contents

Why

Findings

Current CLI State

When

Follow

Drash - A Unique Framework

Table of Contents

What Makes Drash Different?

Syntax

Resources

Drash Compared To Other Frameworks

Deno Frameworks

Node Frameworks

Drash's Goals

Why We Built Drash

Table of Contents

What is Drash?

Why was Drash built?

Problem 1: Syntax

Problem 2: Debugging

Solution to the problems

New Drash Tutorial Videos!

Serving Static Paths

Handling URL Encoded Bodies