Startups Using React in Boston

Flask – we migrated to Flask from Django to increase the flexibility with which we build and manage our portfolio of workflow applications. We manage our own library of plugins and cookiecutters to enable efficient setup for new team members and team members picking up new projects.

React – we moved to React from Ractive as our JS framework for its performance, component oriented architecture, and server side rendering. React raises the level of abstraction in our front-end code base, making it more predictable and allowing our engineers to focus on building functionality versus wrestling with the framework.

AWS – as a healthcare IT company, we need to maintain a very high bar for our security and privacy infrastructure, given the high-stakes nature and stringent requirements of our large hospital system customer base. Our users rely on our ProviderMatch platform to match millions of patients to the right providers every year. AWS is our core cloud platform that allows us to accomplish this at scale.

ElasticSearch – our core patient-provider matching engine is enable by multi-faceted search. We have customized ES to our domain-specific data models, query types, and end user stories. ES recently migrated away from search as a core area of innovation (in lieu of analytics), so while we are investing in ways to optimize our utilization of ES, we also continue to keep an eye on the landscape of alternatives!

Slack – Slack is core to how our team communicates and gains critical insight into how our platform is performing. The ProviderMatch platform’s services are tightly integrated into Slack, and provide notifications and real-time performance insights that allow our team to stay on top of all platform activity.

Ruby on Rails – We use Rails for most of our services. It’s easy to read, easy to test, reasonably fast to learn, and opinionated in ways that we find helpful.

Elixir – We’re using Elixir for select services where high concurrency is important.

React – We are using React on new frontend features because it’s stateless paradigm makes for code that is easier to reason about and winds up with fewer bugs. It’s also nice to have a single framework across our services, so folks don’t have to learn an entirely new system every time they work on something different.

MariaDB – It seems like everyone is moving to NoSQL data stores, but we love SQL! It turns out that databases that have been around for several decades are very good at what they do — indexing, locking, transacting — and using this proven technology means we get a lot of DBMS features “for free” that NoSQL variants force you to build yourself. We do have a service at scale beyond what a single SQL database can support, and in that instance we are sharded across several database instances.

Docker – All new application servers that we build are containerized and thus entirely immutable. This eliminates an entire class of problems that arise when servers are otherwise left in an unexpected state. We never have to worry about rogue processes, old open ports, or artifacts on the file system impacting a newly-deployed set of code.