Our Blog

Photo by Rüdiger Stehn, cropped, CC BY-SA 2.0

Definition

Multi-tenant architecture allows one instance of an application to serve multiple customers/​organizations. Each customer/​organization is called a tenant. Each has its own apparent separate application and is not aware of the other tenants. The tenant has the ability to customize their own UI, users and groups, etc. Every tenant typically has these features:

View: Tenants can define the overall styling to their application.

Business rules: Tenant can define their own business rules and logic for their application.

Database schema: Tenant can define their own database schema (real or apparent) for the application. They can add/​remove database tables, rename database fields, etc.

Users and groups: Tenant can define their own rules to achieve data access control.

Types of multi-tenancy

There are 3 main types of multi-tenant architecture:

(1) Multi-tenancy with a single multi-tenant database: This is the simplest form of multi-tenancy. It uses single application instance and the single database instance to host the tenants and store/​retrieve the data. This architecture is highly scalable, and when more tenants are added the database is easily scaled up with more data storage. This architecture is low-cost due to shared resources. Operational complexity is high, especially during application design and setup.

(2) Multi-tenancy with one database per tenant: This is another type of multi-tenancy. It uses a single application instance and an individual database for each tenant. The scalability of this architecture may be lower and the cost higher than multi-tenancy with a single multi-tenant database because each database adds overhead. We can increase the scalability of this architecture by adding more database nodes but it depends on the workload. Operational complexity is low due to usage of individual databases.

(3) Standalone single-tenant app with single-tenant database: In this architecture...

The delicious yield of King Arthur Flour recipe Simply Perfect Pancakes

We have been pleased to have King Arthur Flour as a client for a few years. A year or so ago I started using some of their recipes, and their website has since become my go-to source for good baking recipes. I have used their flours a few times, but I am going to focus on their recipes in this post.

They have a ton of recipes. There are upwards of 30 recipes for different kinds of brownies alone. These include gluten free, fudge, raspberry, mint, you name it. The vast majority of recipes I’ve seen have at least a 4 star rating from the public. The recipes are organized into 9 major categories, which makes it easy to browse through recipes quickly.

Their customer service is amazing. Most recipes have several comments on them, and some have up to several hundred. Even with this many comments, if you leave criticism of the recipe, a KAF staff member will almost always answer with suggestions to make it work better. They also have a toll-free baker’s hotline, where you can call or email them with any baking questions, whether or not it’s related to their products!

Crazy Blonde Brownies made by me.

I have used several of their recipes, including a few different pizza doughs, brownies, and scones. Some recipes have had great tips I hadn’t seen before. For example, their recipe for scones has you freeze them before baking, which allows them to rise much higher. We’ve since used this in other biscuit recipes.

They also have a tips section on recipes, which suggest using different flours, adding ingredients, etc. for more variations on flavor and texture, including gluten-free or dairy-free alternatives.

Overall, my experience with their recipes has been great, and I recommend it to anyone looking for a good baking site. Take a look for yourself!

Photo by Dano, CC BY 2.0

A long while back we were helping out a client with a mysterious and serious problem: The PostgreSQL instance was showing gradual memory growth, each of the processes slowly ballooning memory across a few days until the system triggered the OOM (out of memory) killer. Database at that point kicks out all connections and restarts. Downtime is bad, yo.

Spoiler alert: It was a prepared SQL statements bug in Rails. Sometimes it’s fun to take you through all the hair-pulling that goes into debugging something like this, but instead this Friday I’m feeling preachy.

Of course there’s a few different directions you could go to work around a problem like this:

• Update your framework. If, of course, the fix has been released, or determined in the first place. And if your application doesn’t have any compatibility trouble preventing it from running on the updated version, or you feel comfortable back-patching the fix yourself. And if the Change Management Officer doesn’t try to string you up for wanting to update production willy nilly. (Not everyone works at a startup!) But do add it as a milestone. It should be one anyway.
• Take a different code path. Feature switches, like three-point seat belts and pocket breath mints, fall into the category of neat things that seem like a little burden until you really need them. In fact in this case, turning off prepared statements in unpatched Rails deployments is the recommended workaround. It’ll still take some testing, but is likely less risky than changing the framework code itself. It might also be a slight performance hit, but then so is a crashing database.
• Recycle your worker processes periodically. Simple. Readily doable. And usually entirely undisruptive. And thus I’m here advocating that you think about doing it occasionally as a matter of course.

The usual way to get worker processes to recycle gracefully is to send a SIGHUP signal to the application master process. At that point each worker...

Designing for the web means more than just creating beautiful websites — whether it’s a marketing site, an ecommerce platform, or a large-scale web application, thoughtful design means better, more intuitive user experiences. The design process provides a roadmap for developers and a shared set of expectations for the clients of what the final product will be.

If you’ve contracted End Point for design work, or you’re considering it, this post will show you all the steps as we go from an initial concept to a polished design that’s ready for development. You’ll also learn the basic vocabulary of deliverables and some of the tools involved in the process.

Phase I: Discovery

Every new app, website, or product starts with an idea. The initial phase of design work means clarifying that idea — defining its boundaries and goals. Thorough research and investigation are critical for setting the path to success. We interview our clients’ staff, stakeholders, and users to get a comprehensive picture of the current marketplace, discover any pain points in existing workflows, and learn what we can do to make things better. We also take an in-depth look at existing content and, with the client, decide what should stay, what should go, and what needs to be updated or refreshed.

At the end of this process, we provide our clients with a new sitemap, interview transcripts, and a detailed strategy document. Depending on the client’s needs, we may also produce user flow diagrams, user personas, taxonomies, and a content migration plan.

Phase II: Sketching and Wireframing

Once the research materials have been gathered, content has been analyzed, and a design strategy is in place, we make sketches, diagrams, and rough mockups so that everyone involved in the project can start to see the overall form of the final product. At this stage, concerns about font, color, or graphics are mostly off the table — we’re focused on how the parts of the application fit together to create a great...

Overview

Active Storage is a new feature of Ruby on Rails 5.2 that provides functionality to upload files to the cloud, currently Amazon Web Services, Google Cloud, Microsoft Azure.

This gem attaches pointers to uploaded files to the Active Record object. It uploads the file asynchronously which reduces app server overhead, and it also doesn’t require adding a background job explicitly. Active Storage by default uses Active Job to upload the files.

Features of Active Storage

Mirror Service: This allows synchronization of the file between multiple cloud storage services. For example we have this config/storage.yml:

development:
  service: Mirror
  primary: amazon
  mirrors:
    - azure
    - google

The Mirror service first uploads files to Amazon S3. After that it pushes to Azure and Google Cloud. When we remove the file then first it removes it from Amazon S3 and after that it removes it from Azure and Google Cloud. This service is very helpful when we are migrating from one cloud to another.

Direct Uploads: Active Storage comes with a JavaScript library activestorage.js. By using this library we can upload files from the front-end browser to cloud storage directly. Some events that are provided by the activestorage.js library are direct-upload:start, direct-upload:initialize, and direct-upload:progress.

Asynchronous Upload: Active Storage uploads files asynchronously to the cloud. It doesn’t require adding any background job to upload files asynchronously. It uses Active Job to upload files to the cloud.

Installation

In Rails versions before 5.2, add the following to your Gemfile:

gem 'activestorage', github: 'rails/activestorage'

In Rails 5.2 active store comes by default.

To install into your application:

rails activestorage:install

This generates two tables active_storage_blobs and active_storage_attachments.

Then run:

rails db:migrate

Suppose we have model User and we need to upload the profile picture of that user.

class User < ApplicationRecord...

I recently wrote about Vue in Ecommerce and pointed to a handful of references to get started. Today, I’ll talk about using vue-router in a small ecommerce application, combined with vuex-persist for state storage.

I forked this Vue Shop on GitHub from Matheus Azzi. It was a great starting point for to see how basic component organization and state management might look in a Vue ecommerce application, but it is a single page ecommerce app with no separate page for a product detail, checkout, or static pages, so here I go into some details on routing and persistence in a Vue ecommerce application.

Vue Router

In looking through the documentation, I don’t see a great elevator pitch on what it is that Vue Router does. If you are new to routing, it’s a tool to map the URL request to the Vue component. Since I’m coming from the Rails perspective, I’m quite familiar with the Ruby on Rails routing from URL pattern matching, constraints, resources to Ruby on Rails controllers and actions. Vue routing via vue-router has some similar elements.

When you create a basic Vue application via vue-cli, you are given the option to include vue-router:

vue init webpack myapp

? Project name myapp
? Project description A Vue.js project
? Author Steph <steph@endpoint.com>
? Vue build standalone
? Install vue-router? (Y/n) 

If you select Yes here, the main differences you’ll see are that an application with vue-router installed will call <router-view/> to render the view for the current router, instead of a <HelloWorld/> component, and that a vue-router app will include src/router/index.js with basic routing configuration to your <HelloWorld/> component.

Without Routing

// App.vue without vue-router
<template>
  <div id="app">
    <img src="./assets/logo.png">
    <HelloWorld/>
  </div>
</template>

<script>
import HelloWorld from './components/HelloWorld'

export default {
  name: 'App',
  components: {
    HelloWorld
  }
}
</script>

With Routing

// App.vue with vue-router...

I speak the domain specific language of ecommerce, Ruby on Rails, JavaScript, and jQuery. Lately, I’ve been getting up to speed on Vue.js. I’ve been working on writing a small ecommerce site using Vue.js, because for me, creating an application addressing familiar paradigm in a new technology is a great way to learn.

Vue.js, initially released about 3 years ago, is a lightweight JS framework that can be adopted incrementally. In the case of my small example site, Vue.js serves the frontend shop content and connects to a decoupled backend that can be run on any platform of choice. On my path to get up to speed on Vue, I found great resources that I wanted to write about before I get into the details of my ecommerce app. Here they are:

• First, I started with the Vue.js documentation. The documentation is great as a starting point to understand some of the terminology. I often don’t love the documentation that comes with technologies, but I found the Essentials section in the Vue documentation to be a great launching point.
• After I worked through some of the Vue.js documentation, I did a simple search for “vue jsfiddle” and experimented with a few of those fiddles. Having come from a jQuery background (with mustache), I was familiar with how templating and logic inside a template might work, but less familiar with the vue instance and binding, so I targeted jsfiddles with this in mind.
• Next, I looked for resources with Vue + ecommerce specifically. Here’s where I found some good stuff:
  • Scotch.io Course on Vue + Ecommerce: This online course has a great amount of overlap with the main documentation of Vue, but some of the examples are ecommerce specific, which serves as a good introduction.
  • Vue + Third Party Integration for Ecommerce: This Medium article talks about integrating third party tools used with Vue (Stripe, AWS S3, Heroku) to build an ecommerce site. While this post doesn’t go into the nitty gritty details of a Vue application, it does provide many code...

Hi there! I’m Steph, the original creator and not-very-good maintainer of Piggybak, a modular ecommerce platform written in Ruby on Rails. With the help of End Point, I created Piggybak after building a custom Ruby on Rails ecommerce application for one of our clients here at End Point.

My goal with Piggybak was to create a lightweight, modular ecommerce platform in the form of a Ruby on Rails gem that could be combined with other Ruby on Rails gems for quick setup. Over the years, End Point has had much success working in Interchange, an ecommerce framework written in Perl. The web stack has evolved greatly over the years, as has the capacity for modularity and the ability to decouple front-end and back-end architecture.

Fast forward about 4 years after Piggybak was released, and we’ve decided to retire it. Not only did I leave the maintenance up to End Point after I left to work as an in-house software engineer for the last couple of years, but I was also in a position to evaluate using Piggybak as the base for a custom solution.

While I think there are some great Ruby on Rails gems to help support your ecommerce application (see below), one of the main things I realized was that the modularity in Piggybak often doesn’t suit the needs for the target audience of custom Ruby on Rails ecommerce platforms.

These days, here’s my oversimplified categorization of those looking for ecommerce solutions, divided into two audiences:

Audience #1: Boilerplate Saas with Theme Customization
Those sellers where boilerplate ecommerce solutions work, with simple product and variant modeling. Shopify, Magento, BigCommerce, WooCommerce can be decent popular options for that audience, but there are so many other options out there.

Audience #2: Custom Ecommerce in Ruby on Rails
Companies going this route have custom enough needs where a small team can develop and maintain a custom solution, using Ruby on Rails efficiently that don’t require them to depend on a pre-existing data...