location_history

README

Location History

  _                     _   _               _    _ _     _
 | |                   | | (_)             | |  | (_)   | |
 | |     ___   ___ __ _| |_ _  ___  _ __   | |__| |_ ___| |_ ___  _ __ _   _
 | |    / _ \ / __/ _` | __| |/ _ \| '_ \  |  __  | / __| __/ _ \| '__| | | |
 | |___| (_) | (_| (_| | |_| | (_) | | | | | |  | | \__ \ || (_) | |  | |_| |
 |______\___/ \___\__,_|\__|_|\___/|_| |_| |_|  |_|_|___/\__\___/|_|   \__, |
                                                                        __/ |
                                                                       |___/

in-memory location history server.

Table of Contents

• 🏎️ Getting Started

  • Prerequisites
  • Installation
  • Examples

• 💬 Discussion

• 🔥 Todo

• 👨‍💻 Credits

• 🆓 License

🏎️ Getting Started

Prerequisites

• Golang 1.15 or later.

Installation

go get -u github.com/ahmedkamals/location_history
cp .env.sample .env

Examples

make run

⚓ Git Hooks

In order to set up tests running on each commit do the following steps:

git config --local core.hooksPath .githooks

💬 Discussion

So the basic idea is using the concept of sliding or rotating window, and let's assume that we have a TTL of 60 seconds.

For every order we would have a slice of 60 placeholders which every value of the type slice would represent a second in the last minutes (but this is not efficient in terms of memory, we will find a better solution below).

Then we would have a ticker that ticks every second and increases a counter atomically, which you can guess that it would be used an index for the previous slice, and it would keep rotating over it, and once it visits a position it overrides whatever data inside.

There is a downside for this solution we rely on subsequent requests to delete the old data, so that means if we stopped getting requests, we might have a heritage of a memory that is full of ancient legacy locations.

One final not on this, retrieving data in reverse chronological order would be trickier, due to the circular rotation of the index.

                   Index
 <--- Older data    |
#-------------------x-------------------#
                    <--- Oldest data --

So an optimization we can do the following:

• Using a map instead of the slice, so we don't have to pre-allocated the memory and only insert data when necessary.
• Simulating the garbage collector, by applying the same mechanism of mark and sweep technique, so we only turn it on, when we detect a cool down in the requests, we sweep the "gold" data.

I did not finish the implementation, because I ran out of time.

🔥 Todo:

• Unit tests.
• Benchmarks.
• Performance optimization.
• Logging command execution.
• Refactoring.

👨‍💻 Credits

• ahmedkamals

🆓 LICENSE

Location History is released under MIT license, please refer to the LICENSE.md file.

Happy Coding 🙂