You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wanted to share some thoughts on the purplship web app, the way we envisioned it and its current limitations for distribution and customization.
I built the purplship dashboard as we know it today as a UI companion of the purplship-server. Meaning that the goal was to offer an interface that helps visualize, control and orchestrate the shipment operations done on the purplship API and was not intended for end-users. That said, I believe that as features were added, the line between the dashboard and a shipping app intended for shipping operation teams became blurry.
The consequences are that we find ourselves in a position where many users are asking for certain features and information to be hidden or displayed in the dashboard to suit the end-users they have in mind.
Considering the fact that the shipping API has multiple use cases for marketplace, e-commerce, ERP, TMS, OMS...,
we even found ourselves sometimes with contradicting/opposed requests.
Added to that, the dashboard can be quite demanding in terms of development time and spending too much time on it meant slowing down the pace on the core API which is the primary purplship value proposition.
Interesting facts, some users are even solely interested in the headless shipping API and would prefer a light deployable service that handles carrier connections and requests. 😬
So we came to the realization that the purplship dashboard as it is today is very limiting when it comes to allowing any interested users to fork and tailor it to their needs. But also opt-out when it's not a requirement. 😎
The direction we will be taking is to turn the dashboard into a standalone single-page app using Nextjs. 🤔
This means that:
the dashboard will be packaged and deployed separately
anyone will be able to use it as a shipping app foundation, fork and customize to better suit application domain needs
though suggestions and feedback are always welcome, we will only focus on features that are relevant to you the owner of the purplship instance
It is a proven approach that many other projects follow such as elasticsearch/kibana, saleor/saleor-dashboard to list a few use to decouple the dashboard from the core project's API.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi everyone,
Wanted to share some thoughts on the purplship web app, the way we envisioned it and its current limitations for distribution and customization.
I built the purplship dashboard as we know it today as a UI companion of the purplship-server. Meaning that the goal was to offer an interface that helps visualize, control and orchestrate the shipment operations done on the purplship API and was not intended for end-users. That said, I believe that as features were added, the line between the dashboard and a shipping app intended for shipping operation teams became blurry.
The consequences are that we find ourselves in a position where many users are asking for certain features and information to be hidden or displayed in the dashboard to suit the end-users they have in mind.
Considering the fact that the shipping API has multiple use cases for marketplace, e-commerce, ERP, TMS, OMS...,
we even found ourselves sometimes with contradicting/opposed requests.
Added to that, the dashboard can be quite demanding in terms of development time and spending too much time on it meant slowing down the pace on the core API which is the primary purplship value proposition.
Interesting facts, some users are even solely interested in the headless shipping API and would prefer a light deployable service that handles carrier connections and requests. 😬
So we came to the realization that the purplship dashboard as it is today is very limiting when it comes to allowing any interested users to fork and tailor it to their needs. But also opt-out when it's not a requirement. 😎
The direction we will be taking is to turn the dashboard into a standalone single-page app using Nextjs. 🤔
This means that:
It is a proven approach that many other projects follow such as elasticsearch/kibana, saleor/saleor-dashboard to list a few use to decouple the dashboard from the core project's API.
Please provide any feedback, comments or ideas. 😄
Daniel K
Beta Was this translation helpful? Give feedback.
All reactions