Some time ago I published a blog post in which I described an object with which elements could be stored in a 2D grid. The type which turned out to be the SpatialMap<T> worked quite well, and due to the binary searches used to locate elements reasonably fast. The biggest limitation of the data type however was the limitation that both the X and Y axis could only contain unique values. The implication of this was that if there were three points which were positioned as being a triangle while aligned on both the X and Y axis, only one or two of these could be inserted in the object, depending on the insertion order.

After working on realtime data processing logic for hundreds of hours I have identified a few tips and tricks which drastically help simplify the development of these tools. There is an inherent difficulty with regard to realtime data processing, which is that operations need to be executed on single data packets, while incorporating contextual data from the past.

Although realtime data processing initially might look more difficult than batch based processing, this doesn’t need to be true. Having a realtime pipeline would allow one to process batches of data, while having a batch based pipeline would not allow realtime processing.

In this post I’ll document a few architectural tips and tricks to make realtime data processing look less daunting.

Every now and then I have to deal with an issue where I want to pass props down to a component, handle updates to them, but at the same time want to hide the internal implementation details.

In order to collect a timestamp using React I have long been searching for components which could help me to do so. There are various libraries available, but ironically none of them help me more than the browsers built in datetime-local input type.

So I went and implemented this input type, however, there were some complications regarding data updates, especially when changing the date. I have written out a fairly basic but nice working component with which I can collect a datetime.

While developing a realtime feature within a React Native app I discovered a specific quirk within the React Native Navigation library which leaves components mounted, even after the active route has changed. Based on the documentation I believe this has been an intentional design decision, though I couldn’t find any specifics about this.

The issue manifested itself when working with a GraphQL subscription which kept receiving data even after one navigated away from the page (component). This resulted in an unnecessary CPU and memory drain and impacted performance of the application. As stated within the Apollo GraphQL documentation, the useSusbcription hook should automatically unsubscribe once the component is unloaded.