Fresh Collaborates at CBRE DevOps Hackathon
Recently, a few of our Sr. Front-End Developers joined the CBRE Market Builder team for the CBRE Global DevOps Hackathon 2016.
The hackathon was conducted over a single day competing against other 16 teams across the globe. At the end of the day, we had produced a prototype of Aleph, the real-time data visualization app of real-estate transactions.
Aside from the main objective of the hackathon, CBRE Market Builder and Fresh had our own goals in mind as we hacked:
- Evaluate new technologies to see if we can incorporate them back into our products
- Test integration of real-time data stream between back-end and front-end
- Forget about complicated production-ready setup and just get creative and have fun!
The CBRE Market Builder team guided the process, and we followed a set procedure during the hackathon:
- Talked about what we were going to do
- Sketched the architecture across the entire stack
- Broke up the project into discrete services, specified the API for each service, and assigned teams to each service
- Started the integration as soon as Gitlab was available
The Collaborative Stack Building
While the CBRE Market Builder team focused on building the entire back-end stack to generate and send fake data over WebSockets, the Fresh team created the entire front-end stack to visualize a stream of data in real-time.
I was amazed at how many stacks CBRE Market Builder was able to introduce in a single day, especially including new technologies they’ve never before used. Part of the hackathon was for all of us to learn something new in the mix of familiar technologies we use every day.
This collaborative stack building between the CBRE Market Builder team and our team came naturally, because this is exactly what we do on a day-to-day basis with CBRE. We take on separate tasks but work together to build something amazing.
Real-Time Data Stream Over WebSockets
The back-end of Aleph sends new transaction data to the front-end over WebSockets protocol. As data is received, front-end reflects the changes in UI components (Map, Bar Graph, and Leaderboard) without a page-refresh or constantly checking for new data over set time-interval. This real-time data stream can help achieve dynamic data visualization that morphs itself over time.
Learning vs. Building
And obviously, we wouldn’t find this a success if the design and user experience were terrible at the cost of just barely figuring out how to output raw data on the screen.
From the front-end perspective, how early and reliably we could receive the stream of data from the back-end was a crucial component. Obviously, the back-end team is simultaneously working on their part as they hack and iterate. On the other hand, they needed a front-end UI to quickly adapt to new changes in the API data structure, and we were often busy creating the front-end components and carefully merging each other’s changes.
So what could we have done better to unblock the other team?
We could have created staged environments where a stable version of the back-end was available to the front-end. We could have designated a middle full-stack developer who could quickly update code on both ends to maintain the bridge. But it’s difficult to know if this organizational strategy would have been too much during a hackathon, when it may be more efficient to just keep moving forward despite occasional blocks.
In the end, we all accomplished our main objectives, and our stretch goals can be met as we collaborate during future hackathons!