Startups Using Redux in Boston

At Bevi the software team is structured to have shared responsibility over all the code. Each team member works on many parts of our stack including Web Ui (React), Mobile Applications (Android), Firmware (Arduino), and Backend (Java 8). We got weekly sprints and do code reviews using git on bitbucket.

Android – The Bevi smart water coolers have an android tablet that is the main interaction point with our end users. We update and push our apps regularly and we create seasonal animations that our customers love. The android tablet also functions as an IoT device that relays all events to our backend. We often have to dig deep in the android OS to ensure the uptime of our machines.

InfluxDB – A time series database that we use to store the history of all our machines and all service data. We store our data as events in an append-only way.

Java8 with dropwizard and guava – Used to handle streams of data coming from the machines and create derived streams to compute the status of consumables and flag any abnormal behavior. The data is continuously used to optimize the working of the Bevi and the user experience. We go pretty far in using a functional programming style in java.

Spring Boot – We field a number of microservices on top of Spring Boot. Its convention-over-configuration design allows us to focus on business logic rather than plumbing. We’re particularly looking forward to the Spring team’s upcoming first-class support for Kotlin, which we’ve been gradually introducing as a safe, expressive alternative to Java 8.

React + Redux – We’ve built a highly interactive and engaging front-end using React and Redux. The resulting code is modular, easy to reason about, flexible, and composable.

Kafka – We use Kafka as our primary message bus. Unlike most “big data” technologies, Kafka has allowed us to scale without imposing a notable increase in complexity. In fact, becuase its append-only architecture allows us to view topic contents long after the message has been “consumed”, Kafka allows us to significantly improve monitoring and visibility over more traditional message buses (JMS, AMQP). We’re looking forward to experimenting with Kafka Streams as a lightweight alternative to standalone stream processing frameworks such as Spark.

Zeppelin – We use Apache Zeppelin to query, aggregate, and visualize data across a number of heterogeneous data sources, including MySQL, ElasticSearch, and S3. We write ‘notebooks’ in Scala and SQL to drive Spark in creating these visualizations. These notebooks can be ad hoc or shared, versioned, and parameterized.

NiFi – We use NiFi as an orchestration layer to manage real-time data flows in a simple scaleable way. The framework provides us with the ability to easily monitor the progress of messages as they move through the processing pipeline and to replay messages should it be necessary.

React and Redux – The skeleton and nervous system of our in-browser code. The combination of one-way data binding and functional state transitions has made our products much easier to build (and, more importantly, debug).

Elixir – Our persistent services are written in Elixir, a relatively young functional language built on the Erlang VM. It’s got lots of features to recommend it — immutability, actor-based concurrency with crash supervision, hot upgrades and rollbacks, built-in clustering, etc — but the syntax is also downright comfy and very productive. Elixir’s been great to us in the last year we’ve had it in production.

AWS Lambda and Serverless Framework – Lambdas are an amazingly cost-efficient way to implement services or event handlers that don’t require low latency or long execution times. We’ve recently begun to move our dozen-or-so Lambdas into the Serverless Framework, which automates their deployment and configuration. And the ease of working with Serverless Framework makes it likely that we’ll build a bunch more features with it.

DynamoDB – While we use a combination of data persistence layers (Postgres, Firebase, and S3 also play a part), we began to experience growing pains with our most frequently-updated data. We moved this workload from Postgres to DynamoDB last fall, and we’ve not only seen a 30-40% reduction in operating cost, but our response time is much more predictable, and our peak-traffic performance is between three and twenty times better.

Redis – We’re using Redis as the basis of a stats collection system. In particular, its implementation of the HyperLogLog cardinality estimation algorithm means that we can keep as many unique counters (e.g., daily active users for each customer) as we like without worrying much about disk space or CPU time.

React/Redux – We use React for all new development, in combination with Redux for state management, and are actively converting existing features to it. The simplicity of React is more in parity with our Go back-end, and removes many of the frustrations our team has encountered with other technologies. We leverage Reselect for performance and composability, and find Enzyme to be a great testing utility.

AWS – The clypd platform runs entirely on AWS. We leverage VPCs to provide network isolation, EC2 to run our code and provide load balancing, S3 for backups, RDS to host databases, SQS for job queuing, and Redshift for heavy duty analytics. We have been thoughtful in how we set up security groups and instance profiles to follow a least-privilege model for both admins performing maintenance and our apps. We define the state of our infrastructure in Terraform, which allows for code review and dry-runs of infrastructure changes, along with maintaining history in git.

Go – Our team loves using Go to build software for the back-end. The safety and speed are a huge asset for rapid iteration. We’ve successfully leveraged many packages from the community, including Testify for unit test assertions and gorp for a minimal database abstraction layer.

GLPK – At its core, our product optimizes the buying and selling of television advertising. For that, we need technology that can grow and scale to accommodate larger and more complicated optimization problems. R has been crucial for the rapid prototyping of these mathematical problem abstractions but to actually solve them we leverage the Gnu Linear Programming Kit (GLPK). Both tools help us grow and refine the mathematical foundations of our product.