GEO Map Index (Application Production Log)
Admits the process of turning a framework and a growing list of components into an application. A progression of evolution equivalent to the fish growing into the monkey typing on the keyboard. I figured it was a good moment for me to articulate the developer growth and point in time Iāve found myself in.
I truly enjoy the interactive capabilities that are rolling out for this framework, Dash Leaflet and the interactive nature of Plotly graphs was the hook for me wanting to learn this language. To a point of where I wanted to contribute. For which Iām most excited about building the Dash Excalidraw and the Dash Pannellum components.
On the onset of something new and interactive, I created a structured video sharing how to build components ~2 weeks ago, and started focusing on large scale systems outside the scope of focused component development.
furthermore, Iāve found myself wanting to create an application to extend both the Dash Excalidraw and Dash Pannellum from component to a production environment.
Iāve already achieved some success, with the introduction of building out a Geo Guesser Game
Future goals for this Pannellum (Panorama Project) include:
Upload your own panorama Images
Create your own Geo Guesser Games
Create your own panorama tours
Dash Excalidraw
With the current and next major updateās being focused on extending Dash Excalidraw into supporting a database and api endpoints that can retrieve / save notebooks.
For example, user can save a notebook to be public or private, collaborative or view only mode. You can search through all public notebooks, book mark the useful notebooks view stats or rate the knowledge they offer.
The api endpoints associated with this project include:
Admin Portal:
Stats & Analytics Page:
With many bugs still being worked out one of the major issues being how to take a components state in this instance the dash excalidraw components serializedData
which is a prop that represents the current canvas of the dash excalidraw component. When images are added to the component and canvas they are visible via this prop (Images being base 64 ) -files all aspects within the canvas are seen in that prop in the format of:
{
'type': 'excalidraw',
'version': 2,
'source': 'https://dash.geomapindex.com/freeform',
'elements': [
{
'id': 'hpMiMK0EU80vTSpwpFmvP',
'type': 'image',
'x': 421.9203125,
'y': 222.59765625,
'width': 395.175,
'height': 396,
'angle': 0,
'strokeColor': 'transparent',
'backgroundColor': 'transparent',
'fillStyle': 'hachure',
'strokeWidth': 1,
'strokeStyle': 'solid',
'roughness': 1,
'opacity': 100,
'groupIds': [
],
'roundness': None,
'seed': 1973622649,
'version': 4,
'versionNonce': 1362742711,
'isDeleted': False,
'boundElements': None,
'updated': 1731903643735,
'link': None,
'locked': False,
'status': 'pending',
'fileId': 'f1795dd487343b9f682fc37200bcf2d3224dc285',
'scale': [
1,
1
]
}
],
'appState': {
'gridSize': None,
'viewBackgroundColor': '#ffffff'
},
'files': {
'f1795dd487343b9f682fc37200bcf2d3224dc285': {
'mimeType': 'image/png',
'id': 'f1795dd487343b9f682fc37200bcf2d3224dc285',
'dataURL': 'data:image/png;base64,
'created': 1731903643252,
'lastRetrieved': 1731903643252
}
}
}
So my issue is transferring the load of a canvas size with the load the workers that make up the dash applicationās and the wsgi:server can handle. Nothing breaks if their isnāt a POST or PUT associated with the context between applications. When my upload callback that handles retrieving that serializedData
itās goal is to send to the Notebook data to the API after the user is done creating / drawing on the notebook canvas, which it can doā¦ most of the timeā¦ dependent on the size of the POST being made. āApparentlyā, base 64 images are 30% larger than their original .png .jpg .gif .svg but they have the benefit of being capable of being sent and received by the API.
So with this understanding the component and system Iāve built works well for allowing users to add pictures, move them around and draw within the Dash application. But the moment you want to send it to the Django backend everything breaks.
So currently, Iām at an assessment point. How do I manage the sending of larger data packages to the API without breakage. My next approach in a resolution would be to break the canvas apart. Already the canvas and serializedData
are tricky, as its practically a .js ->json ->python ->json ->API->Storage->json->python->json->.js which is a mouth fool of CustomJSONDecoderās and custom_pprintās moving packing and unpacking data to stages between both applications.
The working based on the format is my best approach Iāve found so far, allow it to operate as normal extract, then in a point in time in the extensive process take all the files from the data:
'files': {
'f1795dd487343b9f682fc37200bcf2d3224dc285': {
'mimeType': 'image/png',
'id': 'f1795dd487343b9f682fc37200bcf2d3224dc285',
'dataURL': 'data:image/png;base64,
'created': 1731903643252,
'lastRetrieved': 1731903643252
}
So it break apart the serializedData
extract files in a temporary dash storage, send the remaining serializedData
excluding the base 64 images to the POST endpoint or PUT endpoint. Loop through the remaining temporary files in storage and Post them individually to the API one at a time to make the builders not overload. Then after all is said and doneā¦ stitch all it together and rebuild for the long term Django Postrgress storage. Which will be used for the GET endpointsā¦
Stoping pointā¦
Extensive, complicated, over the top. As a developer Iām going to put this aside and think about the list of bugs I have left to address:
Pip