We used CircleCI in conjunction with GitHub to achieve an integrated version control system continuous integration setup. CircleCI automatically runs our builds in a clean Docker container or virtual machine on every commit allowing us to stay on stop of any regressions as they arise. Additionally the notification system keeps our team up to date when issues do arise so we can get them fixed quickly. It even integrates with Slack to further reduce the friction in staying up to date with the status of our builds. With the automated deployment system once a build passes we can have it automatically deployed to our production environment so we can make sure our users always have the latest and greatest features.

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

Using Screenhero via Slack was getting to be pretty horrible. Video and sound quality was often times pretty bad and worst of all the service just wasn't reliable. We all had high hopes when the acquisition went through but ultimately, the product just didn't live up to expectations. We ended up trying Zoom after I had heard about it from some friends at other companies. We noticed the video/sound quality was better, and more importantly it was super reliable. The Slack integration was awesome (just type /zoom and it starts a call)

You can schedule recurring calls which is helpful. There's a G Suite (Google Calendar) integration which lets you add a Zoom call (w/dial in info + link to web/mobile) with the click of a button.

Meeting recordings (video and audio) are really nice, you get recordings stored in the cloud on the higher tier plans. One of our engineers, Jerome, actually built a cool little Slack integration using the Slack API and Zoom API so that every time a recording is processed, a link gets posted to the "event-recordings" channel. The iOS app is great too!

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!

When we rebooted our front-end stack earlier this year, we wanted to have a consolidated and friendly developer experience. Up to that point we were using Sass and BEM. There was a mix of HAML views, React components and Angular. Since our ongoing development was going to be exclusively in React, we wanted to shift to an inline styling library so the "wall of classnames" could be eliminated. The ever-shifting landscape of inline CSS libraries for React is sometimes difficult to navigate.

We decided to go with Glamorous for a few reasons:

1) Previous team experience with this library
2) We can write our styles in plain JavaScript (which brings many benefits)
3) It supports server-side rendering
4) It has great composition patterns

As you may or may not know, Glamorous has ceased active development and been mostly superseded by Emotion. We are planning to migrate to either Emotion or @styled-components in the near future, and I'll write another Stack Decision when we get there!

Earlier this year we decided to go "all-in" on GraphQL to provide our front-end API. We needed a stable client library to power our React app. We decided to use Apollo Client for a few reasons:

1) Stability
2) Maturity
3) Heaps of features
4) Great documentation (with use cases)
5) Support for server-side rendering
6) Allowed us to stop using Redux and Mobx

Overall we've had great success with this library, along with a few minor hiccups and work arounds, but no show stoppers. If you are coming from Redux.js land, it takes a bit of time to settle into a new way of thinking about how your data is fetched and flows through your React app. This part has been the biggest learning curve of anything to do with GraphQL.

One of the downsides to Apollo Client, once you build a larger application, (past the size of most of the documented use cases and sample apps) the state management tends to get distributed through various places; and not just components. Apollo Client has a state management feature that relies on a normalised local cache. Mastering the knowledge of how this works is key to getting the most out of the library and to architecting your component hierarchy properly.

For Stack Decisions I needed to add Markdown in the decision composer to give our users access to some general styling when writing their decisions. We used React & GraphQL on the #Frontend and Ruby & GraphQL on the backend.

Instead of using Showdown or another tool, We decided to parse the Markdown on the backend so we had more control over what we wanted to render in Markdown because we didn't want to enable all Markdown options, we also wanted to limit any malicious code or images to be embedded into the decisions and Markdown was a fairly large to import into our component so it was going to add a lot of kilobytes that we didn't need.

We also needed to style how the markdown looked, we are currently using Glamorous so I used that but we are planning to update this to Emotion at some stage as it has a fairly easy upgrade path rather than switching over to styled-components or one of the other cssInJs alternatives.

Also we used React-Mentions for tagging tools and topics in the decisions. Typing @ will let you tag a tool, and typing # will allow you to tag a topic.

The Markdown options that we chose to support are tags: a, code, u, b, em, pre, ul, ol, li.

If there are anymore tags you'd love to see added in the composer leave me a comment below and we will look into adding them.

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.

We used Zeplin and React Storybook together to speed up development and collaboration across the company when building Stack Decisions. #StackDecisionsLaunch

We used Zeplin to handoff designs and style guides from the design team to engineering. Because Zeplin automatically generates accurate specs, assets and code snippets from designs we were able to stay on the same page as a team and save time in development. Additionally the friction in communication between the design and development teams is greatly reduced as Zeplin will notify us when designs are updated.

We used React Storybook in a similar fashion to create a library of shared components. It allows us to organize our components into a library, view the different states of each component, and interactively develop and test components. Because React Storybook runs outside of our main application it allows us to develop UI components in isolation, which can improve component reuse, testability, and development speed. We were able to build quickly without having to worry about application-specific dependencies.

I eventually chose flake IDs, because IMO they are better-looking and easier to type.

Although they are meant for distributed systems at scale (think Twitter), for my feature I only cared about how nice they looked. As a bonus, because the first few bits are time-based, they "feel" like good old incremental IDs. #StackDecisionsLaunch