Working on a project recently, wanted an easy modern frontend to work with, decoupled from our backend. To get things going quickly, decided to go with React, Redux.js, redux-saga, Bootstrap.

On the backend side, Go is a personal favourite, and wanted to minimize server overheads so went with a #serverless architecture leveraging AWS Lambda, AWS CloudFormation, Amazon DynamoDB, etc.

For IDE/tooling I tend to stick to the #JetBrains tools: WebStorm / Goland.

Obviously using Git, with GitLab private repo's for managing code/issues/etc.

I'm building a new process management tool. I decided to build with Rails as my backend, using Sidekiq for background jobs. I chose to work with these tools because I've worked with them before and know that they're able to get the job done. They may not be the sexiest tools, but they work and are reliable, which is what I was optimizing for. For data stores, I opted for PostgreSQL and Redis. Because I'm planning on offering dashboards, I wanted a SQL database instead of something like MongoDB that might work early on, but be difficult to use as soon as I want to facilitate aggregate queries.

On the front-end I'm using Vue.js and vuex in combination with #Turbolinks. In effect, I want to render most pages on the server side without key interactions being managed by Vue.js . This is the first project I'm working on where I've explicitly decided not to include jQuery . I have found React and Redux.js more confusing to setup. I appreciate the opinionated approach from the Vue.js community and that things just work together the way that I'd expect. To manage my javascript dependencies, I'm using Yarn .

For CSS frameworks, I'm using #Bulma.io. I really appreciate it's minimal nature and that there are no hard javascript dependencies. And to add a little spice, I'm using #font-awesome.

We had contemplated a long time which #JavascriptMvcFrameworks to use, React and React Native vs AngularJS and Apache Cordova in both web and mobile. Eventually we chose react over angular since it was quicker to learn, less code for simple apps and quicker integration of third party javascript modules. for the full MVC we added Redux.js for state management and redux-saga for async calls and logic. since we also have mobile app along with the web, we can shere logic and model between web and mobile.

We started rebuilding our dashboard components using React from AngularJS over 3 years ago and, in order to have predictable client-side state management we introduced Redux.js inside our stack because of the popularity it gained inside the JavaScript community; that said, the number of lines of codes needed to implement even the simplest form was unnecessarily high, from a simple form to a more complex component like our team management page.

By switching our state management to MobX we removed approximately 40% of our boilerplate code and simplified our front-end development flow, which in the ends allowed us to focus more into product features rather than architectural choices.

Choosing redux-saga for my async Redux.js middleware, for a React application, instead of the typical redux-thunk .

Redux-saga is much easier to test than Redux-thunk - it requires no module mocking at all. Converting from redux-thunk to redux-saga is easy enough, as you are only refactoring the action creators - not your redux store or your react components. I've linked a github repo that shows the same solution with both, including Jest tests.

Frontend choice was basically pre-ordained to be React. Seems like a strong choice on merits alone, plus I needed to learn it to stay current. I never liked Redux.js from the first time I tried to work with it, but a mate had recommended MobX and after watching a few videos I felt like I could fit the mental model of hit in my head. Using Material-UI which is a great timesaver and make sure I throw a few bucks their way every month via the open source collective.

Defaulted to Rails with PostgreSQL just because that's where my past strength as a dev had been. First prototype was in Go but was struggling a bit with the quality of libraries I needed so I went back to old faithful.

As soon as TypeScript was supported by default in Create React App I ported everything over. That combined with swagger code gen has given me really good type safety from the API boundary and above. I semi-regret the Go/Rails decision because I miss the type safety despite pain points with libraries.

I will probably look to flip back to Go gradually (probably via lambda) at a point where it makes sense for the business.

After splitting our monolith into a Rails API + a React Redux.js frontend app, it became a necessity to monitor frontend errors. Our frontend application is not your typical website, and features a lot of interesting SPA mechanics that need to be followed closely (many async flows, redux-saga , etc.) in addition to regular browser incompatibility issues. Rollbar kicks in so that we can monitor every bug that happens on our frontend, and aggregate this with almost 0 work. The number of occurrences and affected browsers on each occurence helps us understand the priority and severity of bugs even when our users don't tell us about them, so we can decide whether we need to fix this bug that was encountered by 1k users in less than a few days days VERSUS telling this SINGLE user to switch browsers because he's using a very outdated version that no one else uses. Now we also use Rollbar with Rails, Sidekiq and even AWS Lambda errors since the interface is quite convenient.

Back at early 2017 the confusion and controversy around the future of AngularJS was at full swing. Also, the Angular 2 looked quite restrictive (or prescriptive even) when we did the assessment what to choose for Katana. React came out on top because it's community looked healthier, future more solid. And as you all know, one decision leads to many others: Redux, redux-saga , Axios