So why would anyone want to put a lot of data into a browser? Well, for a lot of the same reasons that edge computing and distributed computing have become so popular. You get the data a lot closer to the user, and you don’t have to pay for the compute.
This sounds great, but as I found out during this conversation, it’s not as easy as it might seem. There are a lot of trade-offs that need to be evaluated when moving data and analytics to the client.
Nick Rabinowitz, Senior Staff Software Engineer at Foursquare, has a ton of experience with this, so he volunteered his time to help us understand more about it.
If you are not familiar with the Apache Arrow data format, it might be worth checking out. Apache Arrow defines a language-independent columnar memory format for flat and hierarchical data, organized for efficient analytic operations on modern hardware like CPUs and GPUs.
Related podcast episodes
In Conversation
Front-End Engineering and Foursquare Studio
Daniel: Nick, welcome to the podcast. Would you introduce yourself and your role as senior staff engineer at Foursquare?
Nick: I started at Foursquare about two years ago, coming in as part of a company called Unfolded, which focused on geospatial analytics. Unfolded had a lot of analytical capabilities, and Foursquare has a great deal of geospatial data — you put those together and you can make some amazing products. I’m a full-stack engineer at Foursquare, working on both the back end and the front end, and I lead several projects including the hex tile project, mostly around Foursquare Studio, our flagship analytics product.
Why Put Big Data in the Browser
Daniel: Why would we want to put a lot of data in a browser-based application?
Nick: I’ve been mostly a front-end engineer for approaching 25 years. When I started, you could barely do anything in the browser other than display a web page, and I’ve been working iteratively on projects that put more and more into the browser. You get a much better user experience when the data processing happens really close to the user — when I make a query or change a filter, if I have to wait for a long round trip to a server, it’s tedious. In Foursquare Studio, one of the main purposes is exploratory data analysis — a really iterative process — and the faster and more fluid that interaction is, the easier it is to come to insights.
Daniel: Do you think of browser processing as edge computing?
Nick: I do. As an engineer, I have an ulterior motive — the more things happen in the browser, the more I don’t need them to happen on my own servers, which I don’t have to pay for. I think of browser-based applications as almost the extreme end of edge computing. The closest I can get to the user is the computer they’re actually working on. So you move the data and the processing all the way to your computer, while still having the affordances of a distributed application — collaboration, large-scale data processing.
Backend Decisions: Tiling, Streaming, SQL
Daniel: What decisions do we need to make on the back end to get a lot of data into the browser?
Nick: I think of software engineering as a set of evaluations of trade-offs. The most obvious constraint: if a data set is too large to fit in the memory of your browser, you need to put it on the back end across many machines. There’s also the question of where you can process the fastest, leveraging backend libraries and parallel processing. One huge benefit of tiling is that you’re only bringing the data you really need into the front end — each tile is like a mini data set. Streaming works similarly — you only see the data at your current point in the stream. Foursquare Studio is built on top of the open source project Kepler.gl, which loads everything right in your browser, and when you attach a backend you have to think about how to get the data back and forth while making it feel the same.
Choosing Where in the Pipeline to Process
Daniel: How do you think about which decisions to make at which level?
Nick: I think of it as a pipeline from the back end to the front end, and at every stage you have a different set of affordances and constraints. If I’m doing a lot of data processing, can I do it once, offline, and reuse the result? Building a tile set is a good example — the building is the expensive part, but once it’s built I can use it again and again. Conversely, if I’m going to be rebuilding and rebuilding, maybe a tile set is the wrong approach and I should use something more like a SQL query. When you’re just adding things up, you can do a lot on the fly — it works really well for additive data. But something like counting unique values always requires access to the raw row-level data, so it’s really hard to build a tile set for that.
Serializing Data and the Arrow Format
Daniel: Can you explain serialization?
Nick: Anytime you get data from one part of the system to another, you pick a format to send over the wire. Depending on what you pick, the cost of serialization and deserialization can be very high — one of the most expensive things you can do is turn data into JSON and then get it back out in the next system. One thing I find really exciting, and we use a lot in Foursquare Studio, is data formats like Arrow. The whole concept of Arrow is that the memory format is the same from system to system and language to language — you don’t have to serialize and deserialize, you just pass these chunks of memory around and the next system knows how to interpret them.
Nick: The ideal — and we’re not quite there in our own system — is that you can take those bytes and move them from the back end to the front end and then directly into the GPU or a web worker, with very minimal cost. There’s also a database called DuckDB that uses Arrow natively, so you have an entire database system you can run on the front end or the back end without paying that expensive serialization cost. The end user doesn’t say “I want this system because you use Arrow,” but they do benefit — they see that the system is faster and more fluid.
Front-End Clients and JavaScript vs the GPU
Daniel: What kinds of clients can work with big data?
Nick: The hardest thing about being a front-end developer is that you never know exactly what machine your code will run on. With data analysis applications we can make assumptions — mostly desktop or laptop computers, a limited set of browsers — because a data analyst is unlikely to do their analysis on a phone. One thing I think about a lot is whether a piece of functionality can work on both the front end and the back end. If I want to buffer a polygon, doing it on the front end is fast and I don’t pay for it, but to support mobile clients it’s great to be able to do it on the back end too. The H3 library is a good example — we built it in C, a really portable language, so we can transpile it to JavaScript and run it either in a web client or on the back end.
Daniel: What can the GPU do versus JavaScript?
Nick: A GPU is really good at rendering. We leverage it a lot for rendering the map using an open source library called deck.gl. You can also do some data processing in the GPU — aggregation, for example — but the problem is it’s hard to get that data back out. In a full-fledged data application you’re also rendering charts next to the map, so most of the more complicated data processing still happens in JavaScript because it needs to be available to the rest of the application. Map projection is great for the GPU, because nothing else needs to know which pixel goes where — but filtering data ahead of time, if you do it on the GPU, you can’t easily use it elsewhere.
Two Kinds of Users
Daniel: What about two kinds of users — the one doing analytics and the one viewing the results?
Nick: We have this exactly in Foursquare Studio. We have creators doing the analysis and making maps, and consumers who might not have any facility with data analysis but want to see the results. We make different versions of the same map — one fully featured with all the bells and whistles, and one much more static, baked into a published version that’s faster to load and more available for a mobile user. For the published map I can do most of the computation on the back end at the time of publishing rather than at the time of consumption, which gives the consumer something fast and snappy at the cost of less interactivity.
What Makes the Difference in User Experience
Daniel: What do you think makes the biggest difference in user experience?
Nick: Engineers tend to think of performance as easily measurable — how many milliseconds did it take. But in the UI there’s much more going on. If I click a button and can’t use the application for 10 seconds, it’s great that it took 10 instead of 20, but if I can’t even scroll, that’s really painful. So not blocking the user is one issue. I think of experiential performance — users are much more willing to wait if they can see progress happening, ideally a progress bar. It’s the same as being at an auto repair shop: if they never tell you what’s going on, that’s frustrating. Managing user expectations is a really important part of this — a slider implies things will change as you slide, while a button followed by a spinner tells you something slightly longer has to happen.
Daniel: Is any of this unique to geospatial?
Nick: A lot of it is not — many problems in data visualization are very similar. What’s more unique to geospatial is that mapping applications have similar user interfaces and concepts people expect, and there’s a lot of ecosystem you can leverage, like the availability of base maps. There are data visualization applications now moving into mapping without giving you sufficient context — without a good base map — and it’s a subpar experience. We used H3 as one of the pillars of Studio, and not just because hexagons look great — they look good because a massive amount of our brain is dedicated to visual processing, and we can understand at a low level that a hexagon-based grid gives you better fidelity than a square grid.
