Sander

The new Sander website share many similarities with the Squarehub application, but it also has some major that we'll try to cover in this section. Sander is also built with Rails & React using react-on-rails, so you can expect a similar architecture than Squarehub.

Front-end

The front-end is divided in two parts:

internal (as well as the login app): app used by Sander employees to create an ad
marketing: app seen by visitors looking for a new job

Rails

The backend is mainly used by the internal app (employees management, job offer creation…) but will also be consumed by the marketing app for the search tool.

Difference with Squarehub

The internal app is almost no different from Squarehub and uses the same tools (think of MUI 5 for example). The main difference takes place in the marketing app, as this one is entirely SSR (server-side rendered).

In our react-on-rails section, we've seen that a rails view will serve a react component this way:

<%= react_component("MarketingApp", props: @props) %>

For the marketing app of the Sander website, you'll find this:

<%= react_component("MarketingApp", props: @props, prerender: true) %>

The change is that we added the prerender: true property (which is false by default) and that will instruct react-on-rails to serve the component by the server.

Basically, it means that it's the server doing the job and not the client's browser anymore.

Server Side Rendering

First, let us understand what the client side rendering is, as it's the one we've always implicitly used.

In our specific architecture, the CSR means that when you request a page to the server, for example the login page, the back-end will respond to you with an HTML that is almost empty!

Actually, it contains no content at all (really bad for SEO as most crawlers will only look this response) but it contains the reference to the React app the client's browser will have to run.

There we go then, the browser notices it has some job to do, so it executes the React app which finally completes the DOM and renders your login page.

With SSR, the HTML in the response is already complete as the server executed the React app (which means your back-end server must be configured to run some javascript). Much better for SEO, crawlers can see you content now!

Production release

For Squarehub, it's the Github actions that handles the testing and the build of the application on Heroku.

For Sander, those actions are currently only used for testing.The build phase is automatic and handled by Heroku, regardless of the tests. This is not adviced and should be changed a few weeks before launching the new website.

My advice would be to complete the Github actions to make them handle the build like Squarehub, and disable the automatic build on Heroku.

I'll still show you how it works now though, first let's look at the pipeline:

Review apps are configured and should be ready to go
The Staging app is linked to main
The Production app is linked to main

Wait, both apps are linked to main? Yes!

When you push to the main branch, it:

Triggers github action (security check, linters & tests), but Heroku does not care about that
Builds the Staging application (again, regardless of the github action)

And that's it! So if you want to push to prod with this system, you just need to press the Promote to production button and Heroku will handle the release for you (no need to merge in another branch and run a script).

Again, while this behaviour is simpler it's not advised in this form. To make it complete you can either:

follow the same flow as Squarehub (advised)
implement the CI on Heroku (basicaly run the tests on Heroku and trash the github action)

I'd advise you to go for the first one for simplicity (I had some issue configuring Rspec with Elasticsearch on Heroku, so I abandonned the idea for Squarehub), even though the second solution would be much cleaner. Your choice!

Another good reason I'd keep the Squarehub way is that we have to run the bump-version script which also reloads the translations (safe protection in case we forgot to do it ourself).

Basic structure

Here is a sneak peak of the current architecture of the back-end data:

It's probably missing a JobApplications table, but you get the idea. If you want to have a more detailed view of all the tables, you probably want to see the schema.rb and study it.

SEO

This app will need to be tough on SEO, so it deserves its own section! As we've seen, SSR should already be a boost compared to Squarehub on that.

As the components will be pre-rendered, that means the initial HTTP response will contain the full DOM so that finally means that you can just add your <meta> tags in the component you want!

To help you for that, you could use a library like react-helmet.

Don't forget to translate them based on the language of the page, and you should be good to go.

If Atelier Design doesn't work on that, you will probably work with Maxime to define the new tags. If I were you, I'd inspect every page on the current website and confront every meta tags they have to get started!

Styling

For the internal app, super easy, same as Squarehub: MUI5.

For the marketing app, it's implementation will be different. We won't use any libraries but we'll write plain old CSS (or SCSS, to be fancier).

Each component-page (for example: About Us), can have its linked stylesheet file as shown above (layout/about-us.scss).

Mailing

Sander uses Postmark to send all its emails:

https://account.postmarkapp.com/servers/11003222/streamsaccount.postmarkapp.com

Let's have a look at a simple example from a mailer class:

require "postmark-rails/templated_mailer"

class UserMailer < ApplicationMailer
  include PostmarkRails::TemplatedMailerMixin
  default from: "[email protected]"

  def reset_password(user, reset_password_url)
    self.template_model = BASE_TEMPLATE_MODEL.merge(
      {
        action_url: reset_password_url,
        name: user.first_name
      }
    )
    mail to: user.email, postmark_template_alias: "password-reset"
  end
end

The syntax is a bit different than Mailchimp, but it follows the same idea.

The first difference is in the class itself, it must require "postmark-rails/templated_mailer"and include PostmarkRails::TemplatedMailerMixin for it to work.

It can also define a default from address directly in the mailer class.

Let's see the inside of a mailing function now, first thing is the self.template_model, which is basically the variables we will send to the template.

BASE_TEMPLATE_MODEL is defined in the parent class, ApplicationMailer, and contains all the default variable you'll probably always send to Postmark:

class ApplicationMailer < ActionMailer::Base
  default from: "[email protected]"
  layout "mailer"

  BASE_TEMPLATE_MODEL = {
    product_url: "https://www.wearesander.com/en/",
    product_name: "Sander & Partners",
    invite_sender_name: "Alex",
    company_name_value: "Sander & Partners",
    company_address_value: "Bd du Triomphe 174, 1160 Bruxelles"
  }.freeze
end

Then we actually send the email with the mail function and 2 arguments: the email & the name of the template on Postmark.

mail to: user.email, postmark_template_alias: "password-reset"

Here is where to find the templates in Postmark:

Last updated 2 years ago