-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ontoportal global re-achitecture (2024) #457
Comments
Global
Do we need to separate the UI and API?Context/IssueIn brief, no we don't need to have them separated but it will take too much time and effort now to merge them into one code base, and the benefit is not worth the effort. In detail, The benefit of having a unique code base is that it makes everything simpler for developers in the projects, the deployment, and the development environment, which would be immensely easier. As there is a unique component to deploy, run, and develop. However, why did they come up with this decision in the beginning? I think maybe Rails could not render JSON at that time as the API mode was introduced in 2016 in version 5.0.0, as at that time (2013) they were at version 2.0.0. PropositionNowadays, Rails is a full-stack framework that can handle JSON as HTML, and we can still have a good separation of concerns if we organize well our codes into Modules. |
FrontendDo we need
|
BackendDo we need
|
Summary
This issue describes a roadmap and vision proposition for what needs to be updated in our current Architecture.
But first, to know why we need to change, I gave some points of the current existent issues and tried to guess why they were originally made as it is because of course people behind it taught about it and made their decision according to their time and needs at that time.
Global architecture feedbacks (Optional section)
* Do we need to separate the
UI
andAPI
?Frontend architecture feedbacks
* Do we need
ontologies_api_client
separated from the main UI code?* Do we need
MySQL
?* Do we need
Memcache
?Backend architecture feedbacks
* Do we need
ontologies_liked_data
separated from the mainAPI
code?* Do we need
NCBO_CRON
to be separated from the mainAPI
code?* How can we handle better our
Jobs
?* Do we need
ncbo_ontology_recommender
andncbo_annotator
separated from the mainAPI
code?* Do we need multiple
Redis
stores?* Do we index enough data with
SOLR
?* Can we make
Goo
work with different TripleStores?Action items
Goal
Simplifying our architecture implies making it easier to deploy, and maintain and allowing junior developers to iterate and develop more effectively.
Below is the targeted architecture of this proposal, and in contrast you can find here the current architecture state
Action items (still to be continued)
In order of application
ontologies_api_client
ontologies_api_client
ontologies_linked_data
andNCBO_CRON
ontologies_linked_data
andNCBO_CRON
The text was updated successfully, but these errors were encountered: