Closed jde closed 8 years ago
From the front end perspective this is good since xenia interface allows us more flexibility and less entrypoints
I think we should follow xenia's way of organizing code
cmd/ sponge/ -> command line tool to import data (ETL) sponged/ -> API to get data into the system (what we call pillar now)
About the packages, not so sure. Maybe it makes sense to have them in /internal/ask as they are not packages that other part of the system use.
@impronunciable, would it be valuable to you to have the xenia aggregation pipelines in ask? We could package the /query/ and/or /exec/ endpoints into the executable.
if we are moving and deploying this functionality separately then +1 on what @gabelula has stated. But using ask probably as the base name for these binaries. We will also want an internal package called ask to provide the support needed for these binaries.
Yes, we are deploying ask separately.
We are adding a package ask in /internal/ask/
After discussing offline, the working idea is to create three internals packages for the three distinct data types that make up ask:
internals/ask/form
internals/ask/form_submission
internals/ask/form_gallery
Created a branch on shelf for the migration: https://github.com/coralproject/shelf/commit/b3b256825169d67db732129ffd304efd18c3124e
We are moving away from the Pillar architecture. The Ask apis are a great candidate to move first. They are separated into their own handler, model and service files. Also, Ask is still in active development so the move can benefit from ongoing QA.
Ask functionality is limited to three datatypes and the surrounding code:
All functionality surrounding these features should be moved into the xenia repo. During this process significant refactoring of the architecture should occur.
(Edited to removed question answered below)