feat: File-based SSR routes

[jaredcwhite]

In 2021, it's not enough to be a solely a static site generator. Major Jamstack frameworks are evolving (or have already) to support dynamic routes, often implemented as serverless functions. Increasingly the role of a traditional, separate "backend" is being questioned for many types of websites.

I'm not on the serverless train personally, but I've become convinced of the value of having a static site with choice dynamic routes to handle user presence, e-commerce, and live communication concerns.

In #269 back in April I wrote: "Not trying to compete directly with Sinatra/Rails/etc"

That's true insofar as I have no interest in directly building a Rack-based "backend" web framework.

However, I've done enough work behind the scenes at this point to validate the combination of Bridgetown + Roda. Roda is a revelation—it supports all the use cases of a "Sinatra" while being able to scale to compete with a "Rails". What Roda is missing however (IMO) is a compelling, out-of-the-box file-based routing and view layer configuration.

That's where we come in. 😎

In the prototype I've been calling "Bridgetown Arch", you can create single files right in src/_routes that combine Roda code at the top in a "front matter"-like manner with a resource-based view template below. Something like this:

~~~ruby
# src/_routes/example.md

r.is do
  # Index action
  r.get do
    render_with data: {
      layout: :page,
      title: I18n.t("titles.example"),
      current_time: Time.now,
    }
  end

  # Create action
  r.post do
    puts r.params[:something] # incoming form field!
    flash.info = "Created Sucessfully"
    r.redirect
  end
end
~~~

### Flash: {{ flash.info }}

Hello **folks**! The time is: {{ resource.data.current_time }}

<form action="{{ request.path }}" method="POST">
  {%= csrf_tag(request.path) %}
  <input name="something" />
  <input type="submit" value="Create" />
</form>

(Yes, this is a Markdown file + Serbea templating! Not saying you should write dynamic view templates in Markdown…but you can. 😄)

I also have file-based route placeholders working so you could save a file as: src/_routes/subfolder/[id]/[whatever].erb and it handles those parameters just as you would expect, similar to other frameworks like Next or SvelteKit.

I had originally intended to wrap this functionality into a standalone gem literally called bridgetown-arch, but upon further reflection I consider this an optional yet entirely valid aspect of core Bridgetown functionality going forward.

So just like the builder and pagination gems within core, I plan to create a new gem (perhaps called bridgetown-routes) which sites can opt into using which then adds this file-based dynamic routing—deployable on Render, Fly, or other forward-thinking hosting platforms.

Work done for this can also in some ways benefit backend Rails or other frameworks should people prefer those options.

This directly builds upon the work in #281 as well as addresses #123.

[jaredcwhite]

For the sake of industry context, here's the recommended approach for handling form submissions in Next.js: https://nextjs.org/blog/forms

As you can see, our example of handling forms is dramatically simpler and could take full advantage of the Pjax-style FE ecosystem Rails devs are already familiar with (Turbo, etc.). In fact, I've already worked on a prototype using CableCar responses via the upcoming version of CableReady which is just badass. 😎