Uploaded image for project: 'Zeppelin'
  1. Zeppelin
  2. ZEPPELIN-4271

Vision: become the modern realtime webapp front end... AppStore... & Beyond



    • Type: Wish
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:


      In presenting a language-agnostic way edit and render interactive content (potentially end user-facing realtime) content... Zeppelin notebooks have the potential to replace (abstract) today's front end javascript frameworks all together. Django/Flask, Rails, and Laravel desperately need an easier way for backend programmers to render their content/ data. The fullstack skillset needed to maintain an API/backend layer and a realtime js front end framework (representing the transition from webapp templates {{}} to javascript documents) is just too wide and lacks standardization.

      I run my Django app in a Python env... I then activate that Python env in a Zeppelin notebook... giving my Zeppelin code complete access to my models and controller (MVC) of my app. AKA Zeppelin *is* already the front end (the V in MVC) for my app without the need for authentication or an API/SDK layer. I can rearrange the tiles in a responsive grid... show users tables of content... and render graphics. 

      Because the Python kernel/env is shared between my front end (zepl) and my backend (django)... this is essentially full-stack Python. However, this is not limited to Python, it would work with any language for which a Zeppelin interpreter has been written e.g. Ruby on Rails, Elixir, Graphql-based frameworks. The emergence of R Shiny & Python Plotly Dash front end frameworks serve as validation of this need.

      Although Zeppelin paragraphs can already be embedded. What is needed is logic layer support in the web-app frameworks like `djangorestframework's APIView` to bridge the gap between the V and the C in the MVC model. Something like `NotebookResponse` in addition to JsonResponse and TemplateResponse.

      This would turn Zeppelin into an `Application Browser` competitor to the `Webpage Browser`. Aka... Zepl (change it back to ZeppelinHub or at least brand ZeplHub) would become the iTunes/AppStore/HTML of it's day.

      Once this application building ecosystem takes off, introduce a Kafka-based OpenAPI network using OAuth2.0 authentication to enable applications to fluidly share data in an operating system manner... to become the new internet/ web-based OS that replaces layers 5-7 in the OSI model (everything above/ running on the HTTP protocol would be dictated by this realtime network).

      P.S. 1

      Additionally, Zeppelin's integration with pyspark could make Spark the default execution engine for Django querysets aka backend.

      P.S. 2

      I was surprised not to be able to change the Zeppelin window style (dark theme) from the 8080 UI. Making sure the ecosystem can customize this will be important for branding/ white labeling.

      P.S. 3

      Although you could maintain %reactjs, %angularjs, %vuejs, %bootstrap... webcomponents they would eventually morph into one ui component system.




            • Assignee:
              HashRocketSyntax Layne Sadler
            • Votes:
              1 Vote for this issue
              5 Start watching this issue


              • Created: