Section
Code architecture; specifically, how beans work.
Problem
Right now, all of the various classes are very tightly bundled together -- things depend directly on ExhibitQueryBean, which directly hits PostgreSQL, and (will shortly, at time of writing) on S3Bean, which directly hits S3. This makes substituting in other methods of storing data (different databases, etc.) difficult without extensive modification to the codebase.
Solution
Define interfaces and autowire those in instead; then people could load whichever implementation they want with configuration options. It would make the backend much more adaptable, and much easier to fit into existing setups.
Additional notes
Let's avoid reinventing JPA, though, please?
Section
Code architecture; specifically, how beans work.
Problem
Right now, all of the various classes are very tightly bundled together -- things depend directly on
ExhibitQueryBean, which directly hits PostgreSQL, and (will shortly, at time of writing) onS3Bean, which directly hits S3. This makes substituting in other methods of storing data (different databases, etc.) difficult without extensive modification to the codebase.Solution
Define interfaces and autowire those in instead; then people could load whichever implementation they want with configuration options. It would make the backend much more adaptable, and much easier to fit into existing setups.
Additional notes
Let's avoid reinventing JPA, though, please?