Shortly after I joined Algolia as a developer advocate, I knew I wanted to establish a place for the community to congregate and share their projects, questions and advice. There are a ton of platforms out there that can be used to host communities, and they tend to fall into two categories - real-time sync (like chat) and async (like forums). Because the community was already large, I felt that a chat platform like Discord or Gitter might be overwhelming and opted for a forum-like solution instead (which would also create content that's searchable from Google).

I looked at paid, closed-source options like AnswerHub and ForumBee and old-school solutions like phpBB and vBulletin, but none seemed to offer the power, flexibility and developer-friendliness of Discourse. Discourse is open source, written in Rails with Ember.js on the front-end. That made me confident I could modify it to meet our exact needs. Discourse's own forum is very active which made me confident I could get help if I needed it.

It took about a month to get Discourse up-and-running and make authentication tied to algolia.com via the SSO plugin. Adding additional plugins for moderation or look-and-feel customization was fairly straightforward, and I even created a plugin to make the forum content searchable with Algolia. To stay on top of answering questions and moderation, we used the Discourse API to publish new messages into our Slack. All-in-all I would say we were happy with Discourse - the only caveat would be that it's very helpful to have technical knowledge as well as Rails knowledge in order to get the most out of it.

17 upvotes·2 comments·444 views

Decision about JavaScript, Rails, Apollo, React

Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.

But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.

But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.

Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.

Decision at Shopify about GitHub, Rails

The core Shopify app has remained a Rails monolith, but we also have hundreds of other Rails apps across the organization. These are not microservices, but domain-specific apps: Shipping (talks with various shipping providers), Identity (single sign on across all Shopify stores), and App Store to name a few. Managing a hundred apps and keeping them up to date with security updates can be tough, so we've developed ServicesDB, an internal app that keeps track of all production services and helps developers to make sure that they don't miss anything important.

ServicesDB keeps a checklist for each app: ownership, uptime, logs, on-call rotation, exception reporting, and gem security updates. If there are problems with any of those, ServicesDB opens a GitHub issue and pings owners of the app to ask them to address it. ServicesDB also makes it easy to query the infrastructure and answer questions like, “How many apps are on Rails 4.2? How many apps are using an outdated version of gem X? Which apps are calling this service?”.

One of the challenges we've had to deal with as our product surface area has grown, is identifying and reproducing bugs. We use Sentry for exception monitoring, however, it's usually difficult to try to reproduce bugs. I first heard about FullStory from our friends over at Flexport (check out the Stack Story and you'll hear them mention it: https://stackshare.io/posts/how-flexport-builds-software-to-move-over-1-billion-dollars-in-merchandise). FullStory let's you record user sessions, and play them back to help you identify bugs and UX issues. You're even able to view the console errors live as they happen during the sessions!

We were pretty blown away at how comprehensive the product was at first, and it seems to be getting better every time I use it. Only complaint is that it's super expensive once you're in the hundreds of thousands of sessions so we had to stop trying to record logged out sessions, we only use it for auth'd sessions. We also started out using it via Segment but once we needed to watch out for the number of sessions we were recording we realized that it was impossible to restrict FullStory recordings on a per-page basis without ripping it out of Segment, so we ended up just using their JS snippet and putting that in the Rails views that we wanted to monitor closely.

The ability to share specific portions of sessions, speed them up, skip inactivity, and all sorts of other little features all add up to a really solid product that helps both our PMs and engineers improve our own product much quicker. I officially requested a Sentry + FullStory integration a while back https://twitter.com/yonasbe/status/871987738777616384, still waiting on this! #UserFeedbackAsAService#reproducing-bugs#sessionrecording#bug-squashing

Decision at Shopify about Redis, Memcached, MySQL, Rails

As is common in the Rails stack, since the very beginning, we've stayed with MySQL as a relational database, Memcached for key/value storage and Redis for queues and background jobs.

In 2014, we could no longer store all our data in a single MySQL instance - even by buying better hardware. We decided to use sharding and split all of Shopify into dozens of database partitions.

Sharding played nicely for us because Shopify merchants are isolated from each other and we were able to put a subset of merchants on a single shard. It would have been harder if our business assumed shared data between customers.

The sharding project bought us some time regarding database capacity, but as we soon found out, there was a huge single point of failure in our infrastructure. All those shards were still using a single Redis. At one point, the outage of that Redis took down all of Shopify, causing a major disruption we later called “Redismageddon”. This taught us an important lesson to avoid any resources that are shared across all of Shopify.

Over the years, we moved from shards to the concept of "pods". A pod is a fully isolated instance of Shopify with its own datastores like MySQL, Redis, memcached. A pod can be spawned in any region. This approach has helped us eliminate global outages. As of today, we have more than a hundred pods, and since moving to this architecture we haven't had any major outages that affected all of Shopify. An outage today only affects a single pod or region.

Decision at Shopify about Rails, Ruby

In 2004, Shopify’s CEO and founder, Tobi Lütke, was building out an e-commerce store for snowboarding products. Unsatisfied with the existing e-commerce products on the market, Tobi decided to build his own SaaS platform using Ruby on Rails.

At that time, Rails wasn't even 1.0 yet, and the only version of the framework was exchanged as a .zip archive by email. Tobi joined Rails creator David Heinemeier Hansson (DHH) and started contributing to Ruby on Rails while building Shopify.

Shopify is now one of the world's largest and oldest Rails apps. It’s never been rewritten and still uses the original codebase, though it has matured considerably over the past decade. All of Tobi’s original commits are still in the version control history.

The bet on Rails greatly shaped how we think at Shopify and empowered us to deliver product as fast as possible. While there are parts of the framework that sometimes make it harder to scale (e.g. ActiveRecord callbacks and code organization), many of us tend to agree with Tobi that Rails is what allowed Shopify to move from a garage startup to a public company.

StackShare Feed is built entirely with React, Glamorous, and Apollo. One of our objectives with the public launch of the Feed was to enable a Server-side rendered (SSR) experience for our organic search traffic. When you visit the StackShare Feed, and you aren't logged in, you are delivered the Trending feed experience. We use an in-house Node.js rendering microservice to generate this HTML. This microservice needs to run and serve requests independent of our Rails web app. Up until recently, we had a mono-repo with our Rails and React code living happily together and all served from the same web process. In order to deploy our SSR app into a Heroku environment, we needed to split out our front-end application into a separate repo in GitHub. The driving factor in this decision was mostly due to limitations imposed by Heroku specifically with how processes can't communicate with each other. A new SSR app was created in Heroku and linked directly to the frontend repo so it stays in-sync with changes.

Related to this, we need a way to "deploy" our frontend changes to various server environments without building & releasing the entire Ruby application. We built a hybrid Amazon S3Amazon CloudFront solution to host our Webpack bundles. A new CircleCI script builds the bundles and uploads them to S3. The final step in our rollout is to update some keys in Redis so our Rails app knows which bundles to serve. The result of these efforts were significant. Our frontend team now moves independently of our backend team, our build & release process takes only a few minutes, we are now using an edge CDN to serve JS assets, and we have pre-rendered React pages!

Our front-end team decided to use React Storybook for our primary React development environment. It allows us to write components in isolation without the need to fire up our Rails stack. When writing components in isolation; you can focus on styling, behaviour and prop design. It forces you to think about how your component is going to be used by others. React Storybook uses webpack and hot module reloading under the hood. This allows us to write components very quickly since it hot reloads in the browser as you code!

The knobs add-on is great for testing different edge cases for the component props. There is even an add-on that will auto-render and snapshot your components with every prop permutation allows by your defined knobs. These snapshots can then be part of your CI testing.

We have a step in our build process that publishes a static React Storybook site on our production server. This allows our entire team to interactively test components before they are integrated into larger features. Once we are happy with our components in isolation, we integrate them into connected feature components which are wired up to Apollo and GraphQL to provide the data and state.

There are heaps of React Storybook add-ons to checkout. If you aren't using it, you should be.

When starting a new company and building a new product w/ limited engineering we chose to optimize for expertise and rapid development, landing on Rails API, w/ AngularJS on the front.

The reality is that we're building a CRUD app, so we considered going w/ vanilla Rails MVC to optimize velocity early on (it may not be sexy, but it gets the job done). Instead, we opted to split the codebase to allow for a richer front-end experience, focus on skill specificity when hiring, and give us the flexibility to be consumed by multiple clients in the future.

We also considered .NET core or Node.js for the API layer, and React on the front-end, but our experiences dealing with mature Node APIs and the rapid-fire changes that comes with state management in React-land put us off, given our level of experience with those tools.

We're using GitHub and Trello to track issues and projects, and a plethora of other tools to help the operational team, like Zapier, MailChimp, Google Drive with some basic Vue.js & HTML5 apps for smaller internal-facing web projects.

Rails is great because "all the decisions are made for you", right? But I wouldn't be writing this decision if this were truly the case. ;-)

rails new and boilerplategenerators are nice, but you still have to spend some time adding your favorite gems, tools, formatting files to your standards, removing unused functionality, and configuring deploys. Only after all of this can you truly begin to code.

That’s why I made a shell script (yeah, Rails generators are overkill) that creates a new app from a boilerplate app I preconfigured. Everyone has different tastes and levels of seniority, so I am not sharing this app to the public. Just know that it has different Git branches that my shell script can choose: master (default config), devise, forms, worker, etc. It comes bundled with the tools listed in my personal stack.

All I have to do is run the script, follow the README, and 2 minutes later my app is running a hello world page on Heroku! I cannot stress how powerful it is to have a professional-grade application ready and deployed in 2 minutes. It feels like I’m cheating the system. These superpowers have proved invaluable for personal projects, hackathons and professional projects alike.