This article provides a comprehensive guide to developing a design system for marketing landing pages using the Ruby on Rails framework. We'll look at the different components of a design system, how to integrate them into the Ruby on Rails framework using view_component libraries, and the benefits of using a design system for marketing landing pages. We'll also discuss how to leverage a Lookbook to create a visually appealing landing page experience. We'll provide an in-depth exploration of the different features of Ruby on Rails and how to use them to build a design system. Finally, we'll offer some tips and best practices for integrating design system components into your Ruby on Rails application. With this article, you will gain the knowledge you need to create an effective and visually appealing design system for your marketing landing pages.

Implementation of the Design System with View_component Libraries

A design system is a tool to simplify design creation as well as software development. Its creation for the Showmax platform was a true challenge and you can read more about it in Showmax Design System: The Precious. Our Precious introduces the roots of all the designs, including logos, icons, or foundations like colours, spacing, borders, and more. The design system also states which elements arise from the roots. And for each of the Showmax platforms we have a specific library including elements like buttons, containers, status messages, input fields, and others. Anybody creating a new design or developing it in the code can easily find the right element in the library and focus on the problem instead of redesigning the basics from scratch. To put the Design System into practice, we had to find a way to transfer the libraries from Figma to coders' screens.

Implementation in the Backend-Alpha team 

In my team (that is focused on user acquisition) we maintain and build upon those crucial first steps of a Showmax user's journey. Our team's jurisdiction is over what we call "the Landing Pages" and "the Secure Pages". The Landing Pages are a huge array of static HTML pages. They all link the user to our authorization service and eventually the authorization service links them to the payments journey. We refer to the auth and payments journey as "the Secure Pages".

In the marketing pages, the tech stack consists of the NextJS framework (a React based framework that enables server-side rendering and the generation of static websites). The secure pages are several standalone Ruby on Rails applications.

We knew from the very beginning that no matter what the design system's code would be written in, both the Marketing pages and the Secure pages would be using identical CSS. We needed to find a clever way to share this style code. The obstacle was the significant difference in environments between a modern next-js app written in typescript, bundled with Webpack and a few several-years-old Rails apps running Sprockets to bundle their assets.

Before I get into the code sharing, let's quickly talk about UI components and what form we think they are most effective in.

I would define UI components as simple functions or classes that spit out styled html. Nothing more. They should follow the single responsibility principle and be void of any business logic. Essentially they should be "dumb" and they shouldn't do much with their input other than displaying it however you tell them to display it i.e with various CSS class modifiers or simple arguments like “dark” or “light” to indicate what style the component should be.

If you're familiar with some of the React/Redux design patterns there is a concept of "container components" and "presentation components". Container components are all rendered higher in the state tree and are therefore closer to the data source. They make decisions about what will be rendered (some text string for example) while the presentation components will take that text string no matter what the content is and style it in the way that they're told to. If they take any arguments on initialization the arguments should only be about style, nothing else.

We were really only concerned with presentation components in this project and a vanilla Rails project leaves a lot to be desired in this department. If you want to stick with the default libraries you can split your views up into partials for instance, but partials don’t have a method signature so we can’t just glance at the file and know exactly what data is required to render a partial correctly. Furthermore, partials and views know too much about the controllers that render them. Because they have access to the controllers’ instance variables it's tempting to access this data in the partial. If you are accessing an instance variable in a partial, you tend to lose the reusability. The partial is now coupled to this controller action. If you want to reuse it, you need to make sure that same instance variable exists wherever else you need the partial.

In my opinion, the best way to easily add UI components to a Rails project without worrying about javascript is ViewComponent. It's fairly simple and easy to wrap your head around. You don’t need to think about “global state” or “redux” or  “hooks”. In the end you get a ViewComponent::Base class that simply allows you to write a ruby class that renders html.

Container components and higher-level business logic would be implemented as the UI Components would start to become used in production, with more context.

So we left them as open and flexible as possible.

For example, here is our Ruby CheckBox component:

#ruby#
ruby
# ruby class description
module BeDesignSystem
  class CheckboxComponent < ViewComponent::Base

    def initialize(label_text: nil, id: nil, name: nil, value: nil, checked: false, html_options: {})
      super
      @id = id
      @name = name
      @value = value
      @label_text = label_text
      @checked = checked
      @html_options = html_options.merge({ id: @id, class: 'smFormCheck_input' })
    end
  end
end

#ruby#
<% # the erb template for BeDesignSystem::CheckboxComponent %>
<label class="smFormCheck">
  <%= check_box_tag @name, @value, @checked, @html_options %>
  <span class="smFormCheck_label"><%= @label_text %></span>
</label>

And the related React component for the landing pages:

#typescript#
type CheckboxProps = {
  text: string;
  id?: string;
};

const Checkbox = ({ text, id }: CheckboxProps): JSX.Element => (
  <label htmlFor={id} className={styles.smFormCheck}>
    <input className={styles.smFormCheck_input} id={id} type="checkbox" />
    <span className={styles.smFormCheck_label}>{text}</span>
  </label>
);

export default Checkbox;

The important thing is that you can call these with whatever arguments you want but in the end the html structure is the same in both environments:

#html#
 <label for="check-id" class="smFormCheck">
    <input type="checkbox" name="name" id="check-id" value="value" class="smFormCheck_input" />
    <span class="smFormCheck_label">First checkbox</span>
</label>

So as a team of two, one working in React, the other in view_component, we would be able to share styles as long as we kept the html structured the same and used classes only as CSS selectors.

Which was easy to do for us as we already use the BEM model for our CSS. https://getbem.com/introduction/

The challenging part – Rails apps with Sprockets

If you're familiar with Rails, you might wonder why sharing CSS between Rails and any other web based framework would be worth writing a blog about. They both speak the universal language of Javascript and you can easily bundle CSS using a bundler like webpack! But this wasn't so easy for us because our Rails apps we were working with Sprockets. Sprockets is old fashioned and handles everything much differently than webpacker. Without webpacker we had no package.json or any way to consume npm modules in the Rails apps. 

So we couldn't create an npm module that would just allow the marketing pages and the secure pages to

#typescript#
import styles from "be_design_system/form_check.module.scss";


We needed a way to do that and feed the styles to Sprockets.

In one repo we wrote an npm package and a Ruby gem. We separated the ruby and javascript code at the top level into separate directories.

be_design_system is where we had our SCSS files

app is where our gem code is. It's a Rails engine, which helped us tremendously as Rails engines can contain a miniature sub Rails app in their test directory. This gives us the ability to run another engine called Lookbook (more on this later) where we can prototype, document, and show off our new UI components in real time as we develop them.

In the Ruby engine I was able to import the SCSS and process the files by sprockets:

#ruby#
 config.assets.paths   << File.expand_path('../../be_design_system', __dir__)


Sprockets can then just be used like this to include our assets:

#scss#
*= require be_design_system/form_check

#ruby#
spec.files         = `git ls-files -- '*.rb' '*.scss' '*.erb'`.split("\n")

We can exclude any non-npm packages from our final gem build. It was an unconventional way to cut out code duplication. While it did cause a mild headache in the beginning due to sprockets not being out of the box configured to consume SCSS module files i.e. “button.module.scss” The end result is quite nice. We have all our design system code relating to our team in one place and when we need to jump into the different worlds (e.g. TypeScript vs Ruby), we have this one place that helps make the context switching a little easier.

Now that we have made these UI components available to any of our Rails apps, they are still useful to anyone other than me and my teammate who built this with me. I know what they all look like but how does another team member really know if "Primary Button" will work for them in their project?

https://github.com/ViewComponent/lookbook

Lookbook started out as a pet project of Mark Perkins. If you are familiar with a component gallery called Story Book, this is very similar but much simpler.

When you create a new ViewComponent class you have the option to generate a "preview" file. These are just erb|slim|haml templates where we can render our components with test data. You can even set up a controller class to serve up these files with some data fetched over the http, for instance, or you can just use the controller to parse some fixture files to hydrate your preview classes.

What's so cool about lookbook is how little effort is required to get it working. Even for someone working without webpack. It doesn't need any fancy javascript (it works with or without js precompilers).

To get it up and running you only need to install the gem and navigate to localhost:3000/lookbook. If you already have some preview files, they will be there in all their glory:

You might have noticed that there is a source code button. There you can see the ruby / template that is rendering this preview. When you make changes to this ruby file, lookbook has a websockets connection setup that refetches this page (lookbook renders your component in an Iframe and that Iframe is dynamically refreshed).

What I find even more helpful is the html view. It's extremely handy to have a quick way of flipping back and forth between html and rendered html without all the clutter of chrome dev tools. Many of our components render various data-something attributes for data transfer between the server and the client. This allows you to quickly test that your changes are working properly and debug any weirdness.

So we have components, we have a way to share them and so far we've done all of this with sprockets as our js transpiler. What more could we want?

As you can see above we have blocks of code, a summary, and a little window where the button is rendered so you can see everything you need to render this component. Lookbook renders these by parsing button.md.erb so it's an erb-ified markdown doc. Enhancing this beyond just a basic markdown document actually gives you a ton of power. For instance, each one of these files (called a page) has a page, next_page, previous_page, and pages variable. This allows you to intricately reference and interlink them. You can use ruby to dynamically write docs.

#erb#
<%= 10.times do %>
  something repetitive
<% end =%>


So I hope you got something out of this article. If nothing else, just the curiosity to think about adding a design system to your project. Be sure to checkout Lookbook and ViewComponent

Using view_component for Design System Implementation in Rails Projects

Some time ago, along with the migration of the platform from an on-premises solution to AWS, we migrated almost all of our git repositories (one project, one repository) into one git repository (monorepository/monorepo) that contains everything. As Showmax is built on a microservices architecture, we had a lot of repositories so it was a dramatic change. In this post I'd like to capture in a few lines some of the pros and cons from my perspective as a Ruby backend developer.

To begin with, I would note that when the migration to monorepo was announced, I was skeptical about this change. My first experience with the monorepo approach was from about 13 years ago. Back then it was in SVN, which works a bit differently than git and the workflows were arguably worse. Simply, with SVN, the monorepo approach didn't work very well. Today, I can say that the change to a git monorepo doesn’t differ significantly from the one git repo per project approach. Let’s see the changes:

`git pull` takes a few seconds longer because the repository contains many more tags.

All IDE instances share one underlying source code repository, and so:

it gets more complicated to work on multiple tickets at the same time – you need to stash, shelve, or commit split changes (my colleague pointed out that there is a git-worktree command that could be used to manage multiple working trees in one repository. I personally never worked with this so perhaps I’ll write more about it in the future);

it is necessary to check if there isn't something unfinished in another IDE of another project.

Boundaries of big changes through several services are not obvious and are sometimes so large that when a merge request is created it needs to be split before the code review can start.

Merge requests can contain multiple services and so the code reviewer sees the feature as a whole package.

All changes through multiple services for a given feature can be seen in `git log`.

It only takes one pull for everything to be up-to-date.

Let’s have a practical example of the positive and negative scenarios of creating a merge request through multiple services and how to split a big merge request. This demonstration will be using only standard `git` commands. At the end of the article, I share a simpler solution that uses JetBrains products.

All examples are demonstrated on a simplified monorepository. To create the example repository and simulate the changes, I wrote a quick script mrsc.rb that you can use.

We will use a standard linux distribution with `git` and `tree` commands that should be already available to you. The `tree` command is used to visually display file structure.

#sh#
~$ uname -a
Linux 5.18.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.5-1 (2022-06-16) x86_64 GNU/Linux

#sh#
~$ git --version
git version 2.35.1

#sh#
~$ tree --version
tree v2.0.2 (c) 1996 - 2022 by Steve Baker, Thomas Moore, Francesc Rocher, Florian Sesser, Kyosuke Tokoro

First we create the structure of the future monorepo:

Then we create a git repository from it and stage the created structure:

#sh#
~/monorepo$ git init && git add . && git status && tree .
Initialized empty Git repository in ~/monorepo/.git/
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   gems/gem1/gem_file1.rb
	new file:   services/service0/app/app_file1.rb
	new file:   services/service0/service_file1.rb
	new file:   services/service1/app/app_file1.rb
	new file:   services/service1/service_file1.rb
	new file:   services/service2/app/app_file1.rb
	new file:   services/service2/service_file1.rb

.
├── gems
│   └── gem1
│       └── gem_file1.rb
└── services
    ├── service0
    │   ├── app
    │   │   └── app_file1.rb
    │   └── service_file1.rb
    ├── service1
    │   ├── app
    │   │   └── app_file1.rb
    │   └── service_file1.rb
    └── service2
        ├── app
        │   └── app_file1.rb
        └── service_file1.rb

9 directories, 7 files

Let’s commit changes and show the change in git:

#sh#
~/monorepo$ git commit -m "init example repo" && git log --stat
[master (root-commit) d96dc0d] init example repo
 7 files changed, 23 insertions(+)
 create mode 100644 gems/gem1/gem_file1.rb
 create mode 100644 services/service0/app/app_file1.rb
 create mode 100644 services/service0/service_file1.rb
 create mode 100644 services/service1/app/app_file1.rb
 create mode 100644 services/service1/service_file1.rb
 create mode 100644 services/service2/app/app_file1.rb
 create mode 100644 services/service2/service_file1.rb

commit d96dc0db07383d25c70414b97223747a98b94a35 (HEAD -> master)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Thu Jul 14 16:34:25 2022 +0200

    init example repo

 gems/gem1/gem_file1.rb             | 3 +++
 services/service0/app/app_file1.rb | 5 +++++
 services/service0/service_file1.rb | 5 +++++
 services/service1/app/app_file1.rb | 5 +++++
 services/service1/service_file1.rb | 1 +
 services/service2/app/app_file1.rb | 2 ++
 services/service2/service_file1.rb | 2 ++
 7 files changed, 23 insertions(+)

Now that we have the monorepository prepared, let’s demonstrate the advantage of the monorepo approach. In this example we will make a change across multiple services. Thanks to the monorepo approach, the code reviewer will have a better overview of what has changed across the whole architecture and how it works together.

First we create a feature branch, simulate the changes, stage, and commit:

#sh#
~/monorepo$ git checkout -b feature1
Switched to a new branch 'feature1'

#sh#
~/monorepo$ ruby ../mrsc.rb example1

#sh#
~/monorepo$ git add . && git status && tree .
On branch feature1
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   services/service0/app/app_file1.rb
	new file:   services/service0/app/app_file2.rb
	new file:   services/service2/app/app_file2.rb

.
├── gems
│   └── gem1
│       └── gem_file1.rb
└── services
    ├── service0
    │   ├── app
    │   │   ├── app_file1.rb
    │   │   └── app_file2.rb
    │   └── service_file1.rb
    ├── service1
    │   ├── app
    │   │   └── app_file1.rb
    │   └── service_file1.rb
    └── service2
        ├── app
        │   ├── app_file1.rb
        │   └── app_file2.rb
        └── service_file1.rb

9 directories, 9 files

#sh#
~/monorepo$ git commit -m "feature1" && git log --stat -n 1
[feature1 8913d49] feature1
 3 files changed, 10 insertions(+), 5 deletions(-)
 create mode 100644 services/service0/app/app_file2.rb
 create mode 100644 services/service2/app/app_file2.rb

commit 8913d49209d443e3f9a3b3584d52a8ce6a60ed4d (HEAD -> feature1)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Thu Jul 14 16:44:40 2022 +0200

    feature1

 services/service0/app/app_file1.rb | 8 +++-----
 services/service0/app/app_file2.rb | 4 ++++
 services/service2/app/app_file2.rb | 3 +++
 3 files changed, 10 insertions(+), 5 deletions(-)

We see that the change is small and ideal for one merge request. Let's assume the change has been reviewed and approved, and so we merge it into the master branch and delete the feature branch. Success, everyone is happy.

#sh#
~/monorepo$ git checkout master
Switched to branch 'master'

~/monorepo$ git merge feature1 && git branch -d feature1
Updating d96dc0d..8913d49
Fast-forward
 services/service0/app/app_file1.rb | 8 +++-----
 services/service0/app/app_file2.rb | 4 ++++
 services/service2/app/app_file2.rb | 3 +++
 3 files changed, 10 insertions(+), 5 deletions(-)
 create mode 100644 services/service0/app/app_file2.rb
 create mode 100644 services/service2/app/app_file2.rb

Deleted branch feature1 (was 8913d49).

For the second example, we will demonstrate a disadvantage of the monorepo approach. The starting steps are the same as in the previous example but the change is considerably larger than expected. Since each service is changed as a project in its own instance of the IDE, we may not even realize that it's so big until we actually create the merge request.

It’s very difficult to review big merge requests. Without a “pair code review session” with the one who created the merge request, it may sometimes be simply impossible to correctly understand the overall concept of the change.

In this example we will show how to revert the big commit and split it in a way that every impacted service can have its own merge request.

First we create a new git branch called feature2. Then we stage and create the big commit with all the changes.

#sh#
~/monorepo$ git checkout -b feature2
Switched to a new branch 'feature2'

#sh#
~/monorepo$ ruby ../mrsc.rb example2

#sh#
~/monorepo$ git add . && git status && tree .
On branch feature2
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   gems/gem1/gem_file1.rb
	modified:   services/service0/app/app_file1.rb
	deleted:    services/service0/app/app_file2.rb
	new file:   services/service0/app/app_file3.rb
	modified:   services/service1/app/app_file1.rb
	modified:   services/service2/app/app_file1.rb
	modified:   services/service2/app/app_file2.rb
	new file:   services/service2/lib/lib_file1.rb
	modified:   services/service2/service_file1.rb

.
├── gems
│   └── gem1
│       └── gem_file1.rb
└── services
    ├── service0
    │   ├── app
    │   │   ├── app_file1.rb
    │   │   └── app_file3.rb
    │   └── service_file1.rb
    ├── service1
    │   ├── app
    │   │   └── app_file1.rb
    │   └── service_file1.rb
    └── service2
        ├── app
        │   ├── app_file1.rb
        │   └── app_file2.rb
        ├── lib
        │   └── lib_file1.rb
        └── service_file1.rb

10 directories, 10 files

#sh#
~/monorepo$ git commit -m "feature2" && git log --stat -n 1
[feature2 b4077d1] feature2
 9 files changed, 130 insertions(+), 9 deletions(-)
 delete mode 100644 services/service0/app/app_file2.rb
 create mode 100644 services/service0/app/app_file3.rb
 create mode 100644 services/service2/lib/lib_file1.rb

commit b4077d1926a5729911fa9c85ad84f8b8c3442247 (HEAD -> feature2)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Fri Jul 15 13:42:26 2022 +0200

    feature2

 gems/gem1/gem_file1.rb             |  1 +
 services/service0/app/app_file1.rb | 26 ++++++++++++++++++++++++++
 services/service0/app/app_file2.rb |  4 ----
 services/service0/app/app_file3.rb | 13 +++++++++++++
 services/service1/app/app_file1.rb |  8 +++-----
 services/service2/app/app_file1.rb |  1 +
 services/service2/app/app_file2.rb | 45 +++++++++++++++++++++++++++++++++++++++++++++
 services/service2/lib/lib_file1.rb | 39 +++++++++++++++++++++++++++++++++++++++
 services/service2/service_file1.rb |  2 ++
 9 files changed, 130 insertions(+), 9 deletions(-)

#sh#
~/monorepo$ git status
On branch feature2
nothing to commit, working tree clean

In practice the change can often be even larger, however, for this demonstration it is enough. Every time I create a merge request, I look at it myself before assigning someone to review it for me, and in this case I would notice that it is just too big. It would be better to revert the commit and split it into multiple smaller merge requests. Now that we know what we want to achieve, let’s see how to do it.

First we need to "uncommit" the changes. This is done simply by setting the git HEAD reference to the previous commit with the `git reset` command. In our case we will use a soft reset, which will leave the changes from the last commit as that is exactly what we need. If we used a hard reset, the changes from the last commit would be removed from the working tree.

#sh#
~/monorepo$ git reset --soft HEAD^ && git status
On branch feature2
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   gems/gem1/gem_file1.rb
	modified:   services/service0/app/app_file1.rb
	deleted:    services/service0/app/app_file2.rb
	new file:   services/service0/app/app_file3.rb
	modified:   services/service1/app/app_file1.rb
	modified:   services/service2/app/app_file1.rb
	modified:   services/service2/app/app_file2.rb
	new file:   services/service2/lib/lib_file1.rb
	modified:   services/service2/service_file1.rb

Now we have the working tree in its pre-commit state. The `HEAD^` part means we want to go back one commit. It's the same as `HEAD~1`. We can use `HEAD~2` or `HEAD~5` if we want to go back 2 or 5 commits respectively, or we can directly specify the commit hash we want to get to. This can be viewed using the `git reflog` command, which is a log of all the actions that have been performed in git.

#sh#
~/monorepo$ git reflog
8913d49 (HEAD -> feature2, master) HEAD@{0}: reset: moving to HEAD^
b4077d1 HEAD@{1}: commit: feature2
8913d49 (HEAD -> feature2, master) HEAD@{2}: checkout: moving from master to feature2
8913d49 (HEAD -> feature2, master) HEAD@{3}: merge feature1: Fast-forward
d96dc0d HEAD@{4}: checkout: moving from feature1 to master
8913d49 (HEAD -> feature2, master) HEAD@{5}: commit: feature1
d96dc0d HEAD@{6}: checkout: moving from master to feature1
d96dc0d HEAD@{7}: commit (initial): init example repo

In this example, the `git reset --soft HEAD^` command would have the same effect as `git reset --soft b4077d1`. Thanks to the `git reset` and `git reflog` commands, you basically don't have to worry about "screwing up" something in git, like a bad commit or merge, because you can get back to any previous state.

Let’s finally split the big merge request into, let's say, 3 merge requests, service0, service2, and service1 + gem1 because these two were closely related.

First, we `git stash` everything and find out the stash number.

#sh#
~/monorepo$ git stash push -m "feature2" && git stash list
Saved working directory and index state On feature2: feature2

stash@{0}: On feature2: feature2

The stash number is 0. Since we are in the feature2 branch, which is in the same state as the master, we can rename it to feature2_service0. We unstash the changes related to service0 using the `git restore` command and then we stage the changes:

#sh#
~/monorepo$ git branch -m "feature2_service0"

#sh#
~/monorepo$ git restore --source=stash@{0} -- services/service0 && git add . && git status
On branch feature2_service0
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   services/service0/app/app_file1.rb
	deleted:    services/service0/app/app_file2.rb
	new file:   services/service0/app/app_file3.rb

We then commit and update our big merge request with this change.

#sh#
~/monorepo$ git commit -m "feature2 for service0"
[feature2_service0 ea8057e] feature2 for service0
 3 files changed, 39 insertions(+), 4 deletions(-)
 delete mode 100644 services/service0/app/app_file2.rb
 create mode 100644 services/service0/app/app_file3.rb

Next, we create a branch and merge request for service1 + gem1 in the same way.

#sh#
~/monorepo$ git checkout master && git checkout -b feature2_service1_gem1
Switched to branch 'master'
Switched to a new branch 'feature2_service1_gem1'

#sh#
~/monorepo$ git restore --source=stash@{0} -- services/service1 gems/gem1 && git add . && git status
On branch feature2_service1_gem1
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   gems/gem1/gem_file1.rb
	modified:   services/service1/app/app_file1.rb

#sh#
~/monorepo$ git commit -m "feature2 for service1 and gem1"
[feature2_service1_gem1 aca2003] feature2 for service1 and gem1
 2 files changed, 4 insertions(+), 5 deletions(-)

Now we just need to make changes for service2.

#sh#
~/monorepo$ git checkout master && git checkout -b feature2_service2
Switched to branch 'master'
Switched to a new branch 'feature2_service2'

#sh#
~/monorepo$ git restore --source=stash@{0} -- services/service2 && git add . && git status && git commit -m "feature2 for service2"
On branch feature2_service1_gem1
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   services/service2/app/app_file1.rb
	modified:   services/service2/app/app_file2.rb
	new file:   services/service2/lib/lib_file1.rb
	modified:   services/service2/service_file1.rb

[feature2_service2 9e641ff] feature2 for service2
 4 files changed, 87 insertions(+)
 create mode 100644 services/service2/lib/lib_file1.rb

Finally, we delete the no longer needed stash (which is at position 0) and switch to the master.

#sh#
~/monorepo$ git stash drop 0 && git checkout master
Dropped refs/stash@{0} (1c0d783c065a2b45365102ad9c9b1b6719164a5c)

Switched to branch 'master'

Just to check that everything looks as it is supposed to:

~/monorepo$ git log --all --stat
commit 9e641ff098084dd329f8731ccf04a6db9cb293cf (feature2_service2)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Fri Jul 15 15:08:15 2022 +0200

    feature2 for service2

 services/service2/app/app_file1.rb |  1 +
 services/service2/app/app_file2.rb | 45 +++++++++++++++++++++++++++++++++++++++++++++
 services/service2/lib/lib_file1.rb | 39 +++++++++++++++++++++++++++++++++++++++
 services/service2/service_file1.rb |  2 ++
 4 files changed, 87 insertions(+)

commit aca20037700ab9e820fe2c2d1a53a241a2165287 (feature2_service1_gem1)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Fri Jul 15 14:36:41 2022 +0200

    feature2 for service1 and gem1

 gems/gem1/gem_file1.rb             | 1 +
 services/service1/app/app_file1.rb | 8 +++-----
 2 files changed, 4 insertions(+), 5 deletions(-)

commit ea8057e50de93c7ae8defdee0d4b0841f4d1dc3d (feature2_service0)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Fri Jul 15 14:31:11 2022 +0200

    feature2 for service0

 services/service0/app/app_file1.rb | 26 ++++++++++++++++++++++++++
 services/service0/app/app_file2.rb |  4 ----
 services/service0/app/app_file3.rb | 13 +++++++++++++
 3 files changed, 39 insertions(+), 4 deletions(-)

commit 8913d49209d443e3f9a3b3584d52a8ce6a60ed4d (HEAD -> master)
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Thu Jul 14 16:44:40 2022 +0200

    feature1

 services/service0/app/app_file1.rb | 8 +++-----
 services/service0/app/app_file2.rb | 4 ++++
 services/service2/app/app_file2.rb | 3 +++
 3 files changed, 10 insertions(+), 5 deletions(-)

commit d96dc0db07383d25c70414b97223747a98b94a35
Author: Jan Zlamal <jan.zlamal@showmax.com>
Date:   Thu Jul 14 16:34:25 2022 +0200

    init example repo

 gems/gem1/gem_file1.rb             | 3 +++
 services/service0/app/app_file1.rb | 5 +++++
 services/service0/service_file1.rb | 5 +++++
 services/service1/app/app_file1.rb | 5 +++++
 services/service1/service_file1.rb | 1 +
 services/service2/app/app_file1.rb | 2 ++
 services/service2/service_file1.rb | 2 ++
 7 files changed, 23 insertions(+)

In the end, switching to a monorepo approach was not a big change. One just needs to keep an eye on a few things. I only ran into the situation where I needed to split a large merge request once and it was related to renaming a payment method in all the services that use it. If you analyze the feature a bit in the beginning, you're very likely to break it down into smaller merge requests that make sense on the first try.

The ability to make merge requests across multiple services seems great to me. As the person doing the code review, this gives me a lot more insight than having separate merge requests for individual services, and perhaps with more time delays. Often I don’t have a full understanding of what exactly my colleagues are working on and so seeing the changes as a whole gives more context.

At Showmax, the vast majority of Ruby developers use Rubymine, which simplifies many operations, especially by making them easier to understand than the terminal.

For me, it's a great tool that saves a lot of time in many areas, including the situation of splitting up large changes. In a git window, in local changes, you can create a shelf from selected files and folders and then unshelve it at any time to any change list. You can also use Git to work on several features simultaneously, which is radically shorter than a pure terminal and git procedure. Nevertheless, it is good to know both because it may come in handy in the future.

Over time, the number of requests to our Backend teams increased and the size of the teams grew at the same pace. How did we keep our effective delivery and agile mode of work despite dramatic scaling? One of our backend teams, the BE-Alpha team, shares how they have addressed the issues coming with fast growth by reorganizing into multiple cross-functional teams.

We are a bunch of skilled engineers who love working on Web Applications and APIs. Over the years, we managed to build an international team of 12. We have colleagues coming from the USA, Slovakia, Ukraine, Kyrgyzstan, and Russia. As half of the team isn’t from the Czech Republic, English is our everyday language.

The Backend Alpha team is not the only Backend team at Showmax. The Backend Bravo team is technologically similar to us, we have shared libraries and technologies we use, and historically we used to be just one backend team. As that original backend team grew, we had to split, although we still work closely together.

The BE-Alpha team consists of software engineers, QA testers, and a team leader. We are a technical team and we sync on daily stand ups. However, as the team grew we had to find a more efficient way to give people focus, plan new work, and assign responsibilities for individual parts of our applications. Enter cross-functional teams, a concept similar to “tribes” and “squads” you may be familiar with from other companies.

The tribes model is a way to scale agile development to a larger organization. The main goal is to eliminate silos, empowering each tribe to create software without depending on other departments. The way we applied these principles to our BE-Alpha team was by splitting the engineering capacity and combining them with other roles into multiple cross-functional teams.

The teams are cross-functional as they consist of product managers, software engineers (2-4 per team), QA, UX designers, and data scientists. Most of their work is AB tested in order to find the most efficient solutions.

In total we have 4 cross-functional teams, with each team being led by a product manager. The cross-functional team is self-organizing, they consult their priorities together in (ir)regular meetings, and have a shared focused vision on the part of the product they are responsible for. The teams we currently have are:

The CFTs are supplemented by one more subteam within our BE-Alpha team, a team we call the “platform team” based on the concepts from Team Topologies. While the 4 cross-functional teams are “Stream-aligned”, the platform team doesn’t have a dedicated product manager and focuses more on internal work but also steps in to help the CFTs in case special assistance is needed.

Our work is focused around systems that support user acquisition. At Showmax, that primarily means the marketing pages, full-stack authentication web application and payment gateway, and related payment APIs.

The payments on the Showmax platform are fully controlled by our team. As such, we maintain an API that stores billing information, such as what products are available where at what price, and user subscription status information. Another important API service is the payment gateway API, which we extend regularly as we integrate with new payment providers, and partner with telecommunication providers to provide data bundles.

The APIs are written in Ruby and use the grape framework. People who work as API engineers usually don’t need to touch our full-stack applications that integrate with these APIs, but sometimes it’s necessary.

The full-stack applications are built with the Ruby on Rails framework. Yes, we love Ruby! Static HTML is rendered by these apps, with a bit of JavaScript sprinkling in the interactivity here and there. As a full stack Rails engineer, you should also be able to work with HTML, CSS, and JavaScript.

From the user acquisition point of view, it makes sense for our team to also develop and maintain the infrastructure of marketing landing pages, example. Running on the Jamstack architecture (using Next.js, a React based framework), we have a frontend engineer in our backend team who maintains those pages.

The BE-Alpha team is growing constantly, so join us! There are many areas you can enjoy. You’ll be especially happy with us if you like to create products that end users directly interact with, if you like working with databases and love creating REST APIs, or if you like working in the Jamstack space!

We are hiring remotely in the whole EU so if you are eager to join us, check out the list of open positions, or send us an email at geeks@showmax.com and let’s talk!

Cross-Functionality in One of our Backend Teams

We gotta be honest. Even though at Showmax we are maintaining one platform for our customers and thus we pay significant attention to code quality, refactoring and staying up-to-date with the latest technologies, the frontend part of our full-stack applications built with the Ruby on Rails framework has been neglected. The main reason? Fear of the modern JavaScript world.

A couple of years back there was a meme about a new “best” JavaScript framework being released every month. The frontend tooling was evolving quickly, too, and while today we have great build tools such as rollup, es_build, parcel and vite, when Rails 5.1 introduced webpacker (a way to use webpack easily in Rails apps), as mainly backend-focused engineers we really weren’t rushing to use it. As such, here we are – running Ruby on Rails 6 and 7 applications that still use sprockets as the way to bundle and build production assets.

With Rails 7, the default frontend approach has changed to import-maps but a traditional javascript bundling approach is available too. Most importantly, the webpacker project has been retired. Now that the scary webpacker is out of the way, it opens a new opportunity to start modernizing our frontend tooling.

Recently, Vite.js has emerged as a very popular next generation frontend tooling, and rightfully so. The Vite 3 announcement highlights the impact Vite has had on the current ecosystem, with the Laravel PHP framework using it by default and the vite-ruby gem also highlighted. In this article, we are going to look at how and why to take the first baby steps of introducing Vite into an application where the frontend is fully handled by sprockets.

Let’s revisit the question of why we should even be introducing Vite into our applications.

For starters, it’s a modern frontend tooling and eventually we will be able to replace sprockets with it fully.

Second, thanks to the vite-ruby gem, it’s easy to integrate (as we will see in a moment).

Third, just by introducing vite-ruby into our application and updating a simple configuration file, we can immediately start enjoying a live reload of our server-side rendered application upon any file change.

Finally, Vite and sprockets can coexist without issues which opens up the opportunity of migrating our frontend to Vite in multiple phases.

Are you sold on the idea? Then let’s see how to do it.

Integrating Vite into our Rails applications that use sprockets is very easy to do thanks to the vite-ruby gem. Before we start, let’s check the dependencies:

- Ruby 2.7
- Node.js ^14.18.0 || >=16.0.0


If your environment meets the minimum requirements, you shouldn’t run into any issues during Vite installation.

Let’s get to installing vite-ruby as the first step. Add vite_rails to your Gemfile:

Then install the gem. Run in your terminal:

Vite-ruby automatically installed Vite into our application, congratulations! So what has changed? Let’s see by running git status.

  modified:   .gitignore
  modified:   Gemfile
  modified:   Gemfile.lock
  new file:   Procfile.dev
  new file:   app/frontend/entrypoints/application.js
  new file:   bin/vite
  modified:   config/initializers/content_security_policy.rb
  new file:   config/vite.json
  new file:   package-lock.json
  new file:   package.json
  new file:   vite.config.ts


The interesting parts are the new app/frontend directory and the file application.js in it, which contains basic examples of how to work with ruby-vite. Also, the content_security_policy has changed to allow hot reloading of our files. But we don’t need to worry about that – baby steps, remember? The package.json file was created because our server-side rendered application really wasn’t using any npm packages up until now. Also, take note of the configuration files vite.config.ts and config/vite.json, as we will be working with them later.

If you are using .erb files, the vite-ruby tag helpers should be automatically injected into your application.html.erb file. We were using slim and the tags were not injected by default, so we needed to add them manually. Vite-ruby brings 3 new vite helpers: vite_javascript_tag, vite_typescript_tag, and vite_stylesheet_tag. These helpers enable you to create bundles that are parallel to your sprocket bundles so that you can migrate your frontend gradually.

In the why section, we put “live-reload” as one of the motivations for adding Vite to our application. In order to enable that we need to use another helper - vite_client_tag. In fact, we can just use this one helper to our application.html.slim file and forget about the others if we don’t want to start bundling javascript and css via Vite yet.

At this point, we are still not finished. While hot reloading is now working for the assets managed by Vite, we need to deal with live reload on change for sprockets assets as well as ruby files. Luckily Vite’s extensions ecosystem is rich and simple so we can just set up the vite-plugin-full-reload library to do the work for us.

And as the README says, configure the plugin in the vite.config.ts file. The README recommends setting up reload on changes to config/routes.rb and app/views/**/*. For our use case, we decided to reload on any change to any file within the app folder:

 FullReload(['config/routes.rb', 'app/**/*'], { delay: 100 }),


We can always adjust this setting if needed. Now that everything is ready, let’s run our server. We need to run 2 servers: the Vite server to enable the live reload and our standard rails server. In one terminal window run:

Open localhost:3000 and then enjoy the live reload every time you make a change in any of your application files!

Do you want to see how we take the next step? Reach out, we are hiring!

Adding Vite to a Sprockets-Based Rails Application

Join us and build a streaming platform used by millions. 

We’re excited to witness the recently announced partnership between Showmax, Sky and NBCU coming to life here in Prague. Following the recent announcement of our partnership; that will bring some of the world’s best content and technology to streaming customers across sub-Saharan Africa, Sky are hiring developers to make it happen.

You might know Sky for TV. But we’re more than that. We’re a tech business. We’re broadband and broadcasting, streaming and sports, mobile and magic. And we’re proud to be part of the Comcast NBCUniversal family, creating incredible technology and entertainment that connect millions of people to the moments and experiences that matter most. 

We’ve already rolled out NBCUniversal’s streaming platform Peacock to our European audiences. Now you have the opportunity to work on an exciting new venture powered by Peacock’s leading, globally scaled technology. 

Millions of customers use our apps and we have always been looking to improve by pushing the boundaries in our products and services providing every one of our customers experiences they love.

We are looking for a strong Java Developer who would like to help develop our latest large scale CMS project for Sky OTT International.  Working in an Agile environment, this role will suit an experienced Java Developer who wants to broaden their skill set in an international multilingual CMS application.

Deliver excellent quality software using agile techniques

Assist in developing application deployment, monitoring and automated control artifacts

Strive for continuous improvement – be able to improve existing practices and techniques from within the team with enthusiasm

Assist in the development the CMS application using Java and Spring

Unit, Functional and Performance test code for robustness including edge cases, usability and general reliability. 

Assist in the maintenance and support of the AWS infrastructure, Postgresql Database and Object Caching layers

Actively help the team improve our automated test systems

Extensive experience creating quality Java based applications

Having worked on live high-volume websites

Proficiency in at least one Continuous Integration tool (ideally Jenkins)

Experience in automated testing frameworks

Ability to use a wide variety of open source technologies and cloud services such as AWS

Strong understanding of Spring and Spring Boot

Extensive experience with Agile Principles

Exposure to Content Management and Content Distribution Networks

Knowledge of Unix/Linux and scripting languages (Bash, etc.)

Working in an international environment on an impactful globally scaled technology in cross-functional team with an agile approach 

Open and healthy working culture where we care about people as much as about stability of the code  

Hybrid work, combining working from our office to be closer to the team and working from home 

Work life balance thanks to flexible working hours

Generous free day scheme providing 25 days of holidays + 5 days of on-demand leave (sick days)

Ergonomic office and kitchen full of tasty snacks 

Contribution to Multisport Card or Benefit Card 

Events, meetups, hackathons in the office or elsewhere
 

The Showmax Backend-Alpha team (BE-Alpha for short) focuses on user acquisition. Starting with landing pages and continuing through signup and subscription management, we are responsible for applications serving both the frontend and backend of these journeys and most of the related API services.

We are an international technical team. You can find full-stack developers (Ruby on Rails), developers focused on building APIs (Ruby), and one frontend engineer (Typescript, Next.js). The quality of our work is assured thanks to dedicated QA testers who are also part of our team. 

Our team cooperates with product managers in the planning phase, participates in architectural decisions, and enjoys 24/7 visibility into the platform state thanks to our monitoring and other devops principles. The best part? We see the results of our work quickly.And if you prefer fully- remote work, you are also in luck as some of the people already work remote full-time.

3321859667.mp4

BE-Alpha and BE-Bravo used to be one backend team. We still have a joint standup on Wednesdays and our team members sometimes cooperate together. However, as the team grew, we had to split our daily standups and planning. 

Moreover, as the team grew further we had to find a more efficient way to give the team focus, plan new work, and assign responsibilities for individual parts of our applications. The solution was cross-functional teams, a team that consists of a product manager, software engineers, QA, data analysts, and UX/designers.

This team’s focus is on optimizing landing pages and the beginning of the main onboarding user journeys. Frontend and full-stack engineers are part of this CFT.

Team focused on delivering new marketing/discount campaigns with its own challenges in terms of unique user journeys, exceptions and limitations in terms of availability, and overall architectural challenges such as tracking the users navigation within the flows. The engineers work on APIs and full-stack applications.

The team is focused on maintaining the core billing functionality (APIs) and related user journeys (full-stack), looking for ways to optimize the user experience and deliver new billing related features. The engineers work on APIs and full-stack applications. 

This team is primarily responsible for integrating with various 3rd party payment providers. The projects often bring unique offers to our customers such as data bundles in cooperation with telecommunication providers. The engineers work mainly on APIs.

About the team

How we work

Cross-Functional Teams

Visible features

Integrations

Join the team

Java Developer Content Management System

Read our blog posts #backend

Using view_component for Design System Implementation in Rails Projects

Backend Developer’s Guide to Monorepos

Cross-Functionality in One of our Backend Teams

Adding Vite to a Sprockets-Based Rails Application

Using view_component for Design System Implementation in Rails Projects

Backend Developer’s Guide to Monorepos

Cross-Functionality in One of our Backend Teams

Adding Vite to a Sprockets-Based Rails Application

Check out our other teams