Hi

1. Build a custom UI
We build the ui for the actual application outside zeppelin, this is a
regular html, js application and makes ajax calls to a server to get the
data.

2. Code the actual processing logic in zeppelin
The server that the UI calls is a zeppelin server. We are leveraging the
paragraph in the notebook to capture the actual data processing logic and
we re-execute it each time we get a request from the UI via zeppelin API.
Our new UI becomes another consumer of the zeppelin server. We do not use
the notebook UI for reexecution.

+-------------+     +---------------------+
|zeppelin ui| --> | zeppelin server |
+-------------+     +---------------------+
                            ^
+--------------+       |
|Custom ui  | ------+
+ -------------+

Interaction between custom ui and z server is done via the z api. (jobs and
paragraphs)

Thanks
Apurba


On Wed, Jun 29, 2016 at 10:29 AM  moon soo Lee <m...@apache.org> wrote:

>Hi,
>
>Thanks for using Zeppelin and considering contributions!
>
>Helium application is designed to download and run user code inside of
>paragraph in a single (or few) clicks. Customizing Zeppelin UI is not in
>Helium's scope at the moment. So, using Zeppelin as a backend for your
>custom UI is valid approach for now.
>
>Feel free to create JIRA issue for individual items that you're trying to
>contribute. So community can see and discuss details of individual items.
>
>I think items in your suggested list are valuable. To me 1) and 2) is
>little bit unclear and if you can share more detail, that would be helpful.
>
>Thanks!
>moon
>
>On Tue, Jun 28, 2016 at 11:44 PM Apurba Nath <ap.n...@gmail.com> wrote:
>>Hi
>>
>>We love zeppelin and the ease with which we can use it, however building
applications on top of zeppelin poses a few issues as we are unable to
leverage our UI skills as we have to stay within the boundaries of
zeppelin.
>>
>>We looked at helium, but we thought it still has the same problems, an
alternate solution which has yielded us good benefits it to use zeppelin
notebook and server as backend and write the UI outside zeppelin. We then
use the paragraph and other apis to run the queries and show results in our
custom UI. This allows the UI to incorporate styles, themes and
visualizations which are more apt to the client needs and still use
zeppelin for the actual data crunching.
>>
>>tldr version
>>The steps that we follow are:
>>1. Build a custom UI
>>2. Code the actual processing logic in zeppelin and expose this as
notebook, for each of the relevant paragraphs take the paragraph id
>>3. UI calls the paragraph and job api to submit queries and retrieve the
results, the apis we mostly use are
>>run the relevant code with /api/notebook/job/{notebookId}/{paragraphId}
>>retrieve the results with
/api/notebook/{notebookId}/paragraph/{paragraphId} and parse the result.msg
object and display it in UI
>>4. We made some changes to get the paragraph id in the UI easier
>>5. We made some changes to return more than just status ok from job api,
we return a id with which the job status and results can be tracked which
is useful in our async responses.
>>
>>We can submit all these changes as a patch if the group feels it can be
of value.
>>
>>Thanks
>>Apurba

Reply via email to