Since 2011 our frontend was in Django monolith. However, in 2016 we decide to separate #Frontend from Django for independent development and created the custom isomorphic app based on Node.js and React. Now we realized that not need all abilities of the server, and it is sufficient to generate a static site. Gatsby is suitable for our purposes. We can generate HTML from markdown and React views very simply. So, we are updating our frontend to Gatsby now, and maybe we will use Netlify for deployment soon. This will speed up the delivery of new features to production.
When Redash was created 5 years ago we chose AngularJS as our frontend framework, but as AngularJS was replaced by Angular 2 we had to make a new choice. We decided that we won't migrate to Angular, but to either React or Vue.js. Eventually we decided to migrate to React for the following reasons:
So far the gradual strategy pays off and in the last 3 major releases we already shipped React code in the Angular.js application.
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?”.
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.
We moved from Intercom to Crisp this April because the price-value ratio of Intercom was not satisfying anymore.
We paid ~140eur for the very basic features of Intercom - Messages Essential and Inbox Essential. This is enough for a chat and API access, but that's all. The price would go up as mkdev grows.
Now there are some features we really would love to have: like a Help Center and Bots, for example. All various advanced routing of messages. Or any other features that Intercom actually has, but sells them separately.
Even though it's very hard to properly calculate the price by looking at Pricing page of Intercom, my guess is that with simple Answer bot and Help Center integration our bill for Intercom could easily double or triple.
After doing a bit of research and looking for a better price-value ration we found Crisp.
Crisp gives us the same Chat features we had from Intercom, but then it adds really cool bot builder, various marketing automation utilities, Help Center that supports multiple languages already today (feature still missing in Intercom) - https://help.mkdev.me/en/, fancy MagicBrowse and LiveAssist, direct integration with Telegram and many more. Price? 95eur for all the features and unlimited operators. And no dependency on number of active users (Crisp founders directly say that charging for active users is bullshit and I can only agree with them).
We've been using Crisp not for too long and even though it's been pretty smooth so far - from integrating with our backend systems to creating a Help Center from scratch - it might be a bit too early to do any conclusions. mkdev co-founder Leo has things to say about the UX of Crisp and I am not really satisfied with Crisp's mobile app. But this is something to get used to, or something that will be improved by Crisp over time. And some aspects of Crisp UX/UI are much nicer than Intercom - for example, custom fields on clients are on very top, so we can quickly jump to admin page of a client in mkdev.me. In Intercom we had to do two clicks and scroll a lot to find this link.
To sum it up, if you are looking for a change from Intercom, give Crisp a try. It's way cheaper and doesn't have any major downsides if you are used to Intercom.