Open derrickmehaffy opened 4 years ago
What I have in mind is something like this:
Right now doing a curl on the API root gives the website
Instead of giving the website, one can instead return a list of supported endpoints with some special properties which would indicate if that endpoint should be displayed in Athena. One can do both a website and JSON output using the accepts
header or one can place the website in the root and the apis can start from https://api.canonn.tech/api/
Athena itself will run on https://canonn.tech the api itself will be on https://api.canonn.tech this is mainly due to limitations of Strapi not having a prefix option (it used to but was too broken so they removed it)
Until they re-add prefixes I can't do sub folder based proxying in Nginx, hence the split. Most likely what I will is create a model like navigation
to allow us to use the Strapi Admin panel to edit this in production as Strapi is node based meaning all changes to the file system also required node to restart meaning I could knock my production API offline to update (even though in this case it would be a few milliseconds)
I may place it on athena-navigation
in case we have any other specific Athena endpoints to create
That would be fine too.
All I need to know is what the structure needs to look like @SayakMukhopadhyay I can customize the response structure no matter how I build the model.
Structure and fields required is all I need
Right now, to start I need a few keys. So the structure of the response could be as such
[{
endpoint: '<some way to denote the endpoint url>',
title: '<some user friendly title for the endpoint>',
athena: true|false
},
{...},
...
]
I take it for nested menus we also need a parent/child relationship yeah?
Yeah, but I dont see where a nested menu would be feasible. I think all endpoints can be there own navigation element.
Or, instead of nested elements in the left hand nav bar, one can use tabs.
Tabs would also work too
In that case, having a children
key would suffice.
with the children just being an array of what specifically say types like: ["ap", "bm", "cs", ... ]
(Thinking in terms of apreports
, bmreports
, csreports
to construct the api queries)
Or an array of objects that lists out the short code and full title of the tab
An array of objects should be the way to go. One can flatten it if needed.
Alright that is what I shall do then. I'll get to work building the navigation model here this weekend
(I'll push it into our development server https://api.canonn.tech:2083)
So here is the example structure based on the model I created:
[
{
"id": 1,
"title": "Dashboard",
"endpoint": "/",
"enabled": true,
"tabs": [
{
"id": 1,
"title": "Test Tab",
"code": "test"
}
]
}
]
Dashboard is the root page in the website right? That would mean that its content would be different than that of the different sites right? In that case I think we should only have the sites in that response. Also the structure itself looks good but got a couple of questions:
enabled
code
and why doesn't the inner object have enabled
and outer object doesnt have code
?
To discuss with @SayakMukhopadhyay on structure but will need a publicly accessible to dynamically render the Athena Navigation and likewise the pages.