As part of the engagement team at Hootsuite, we use React as part of our front-end framework for everything from the streams that users see when they log on to dashboard to the new Assignment Manager. Testing is crucial to ensure that our code will work correctly when it has the right inputs, or will fail gracefully when it doesn’t. One of the many challenges of front-end testing is that with increasingly complex frameworks like React, thorough tests are needed to ensure that components render correctly, receive the right props, and update properly. Such tests are often difficult to implement, maintain, and understand. While React offers a ReactTestUtils library, the library is very basic in terms of ease of testing and manipulating the React component’s output. We went as far as writing our own test utils but it simply did not provide the extensive coverage needed.
While working at Hootsuite, I’ve had the pleasure of working in-depth with React to build our newest features for the dashboard. For example, I was tasked with building a component to show a horizontal list of items that adapted to the changing window size. Based on the window width, my component would show a dynamic amount of items and tell the user how many of those items were hidden if any. It’d be a fairly simple task if the amount of items was static, but but since the number of items is dynamic, I had to calculate how many to display each time the window size changed.
More specifically, the amount of items in the list should change depending on the size of the container. The last item in the list should show how many hidden items there are in the list if all the items didn’t fit (i.e +3).
At Hootsuite, we are moving from in-place deployments with statically provisioned hosts to running Docker containers on an orchestration platform. This platform manages the running containers and handles scaling and failure recovery. Transitioning to Docker will allow us to build microservices more quickly and with reduced operational overhead. We’ve chosen Marathon and Mesos as our orchestration platform (other options were Docker Swarm, Kubernetes, ECS, and Nomad).
You aren’t truly ready for a career in Big Data until you have everyone in the room cringing from the endless jargon you are throwing at them. Everyone in tech is always trying to out-impress one another with their impressive grasp of technical jargon.
How will Rhys and Noah contribute over the next two months?
Noah has joined our Android team, and Rhys has joined our Publishing team. Both will pair with a training guide, go through our onboarding program, participate in all aspects of software engineering as a team, work out loud, participate in Guild meetings, demonstrate their work at our Wednesday All Hands, write a blog post, and that’s just the beginning 🙂
The biggest idea in frontend development today is DOM as a function of state. It’s a game-changing concept that proved particularly effective for Hootsuite streams, which are essentially a function of social network data and a user’s interaction with that data.
Today, Hootsuite streams are built in React and use Flummox to manage application state. But that’s just an implementation detail – the core of our product lies in the way we organize our data and the functions that transform it into views. In this article, I’ll be presenting a glimpse of the application state driving Hootsuite Streams and more generally, things to consider when designing global state trees for functional frontends such as React.
Transitioning from a monolithic application to a set of microservices can help increase performance and scalability, but it can also drastically increase complexity. Layers of inter-service network calls for add latency and an increasing risk of failure where previously only local function calls existed.
Jim is a Senior Engineer on Hootsuite’s Platform team. When he’s not working on building a rapidly expanding collection of Scala/Akka micro services, he likes cycling and writing/playing music. Follow him on Twitter @jimriecken.
“It’s 10:00PM, do you know where your microservices are?”
During our SOA transition at Hootsuite, we have noticed that visibility into our service relationships, dependencies and status is paramount to keeping our team, our build pipeline and application running smoothly.
In this presentation I’d like to share with you an API we baked into our Service Oriented Architecture that enables us to explore our applications service dependency graph in real time.
Can you guess what these two scenarios have in common?
Imagine seeing Google or Facebook working on ways to provide internet connectivity to remote regions, and then launching project Seed—an off-the-grid web server that solves the same problem on a smaller scale.