Applications vs. Folders and Release Management

[DaveS]

I've been trying to understand the intended use of Applications vs. Folders in Caspio, and haven't come up with a "best practice."  My solution has multiple user categories from different businesses who interact with the same data in different ways.  I started by creating separate Caspio Applications for each class of user / set of functionality.  But there are some deficiencies in this approach - e.g., some duplication of App Parameters and some authentications shared across the applications.  

I'm using multiple Caspio Accounts for Dev / Test  / Prod and  also noted confusing behavior when I export / import Applications - e.g., I think relationships may be dropped if the tables are in different applications.  

Would love to hear thoughts on this or even have a live discussion if anyone else is wrestling with this and how it impacts release management.

[vidierre]

I think there is not fixed rule, these object can help you to give a structure to your work I can say how I use them, but it is my way, so may be that others have a different opinion.

I use Applications to group functionalities and business logic and tables/view nedded.
i.e. one application ("school") to handle all functions nedded to selct candidates to enroll in classes; one application used to show statistics; one application to handle logs and shared objects (tebles), etc. etc.
I also group into appplication all logic that require one type of authentication. So I have a "school" for candidates and students, one for teachers and so on.

Inside each application I use Folders to group datapages for their scope. i.e. Inside the "school" application I have a folder with all datapages for classes, another for recruitment and another to manage all parameters tables.

But this could not be the best way, is how I use them. I am very interested to know how others use them.

[DaveS]

Thanks, @vidierre,  

What you're doing sounds similar to what I'm doing.  I'm wondering if my life would be better if I consolidated everything into a single app.  Migrations would be easier (fewer exports and imports), and one list of App Parameters to manage.  It would take some rationalizing of the current setup, so I'm trying to decide if it's worth the effort...  Will share any new learnings on this thread.  

[vidierre]

@DaveS  reading your answer raised another thought to me. When I refer to Applications, it is referring to a set of "functionalities and business logic and tables/view" BUT also to a set of users. It means that, in my situation, App are not using shared elements and are self-consistent. So I never be faced with export/import issues for more than one app..

[DaveS]

@vidierre - that makes sense.  My solution is a collaboration platform, so different classes of users interact with the same data but have different access / permissions.

I'm currently doing a (fairly labor intensive) test where I'm consolidating several apps into a single App and it seems to be more efficient for migration purposes (partially because it's one export instead of 3, and partially because there seem to be fewer issues with replication of tables and triggers.  (I've got a lot of tables and a decent number of triggers... when they become replicated, you have to delete them one at a time... but you can only delete them if they aren't referenced in a trigger... so you've got to delete all the triggers first - also one at a time).  I'm chocking it up to learning

[Kronos]

Hi everyone, 

Just want to give my 2 cents for differentiating Applications and folders. It's just like how the Meta company has different social media platforms.

It's like their Facebook and Instagram App

Then the folders are more likely about:
Profile Folder (DPs: Following/Friends)
Security Folder (DPs: Change Password, Login Page)
Content Folder (DPs: Post Submission Form, Posts Page, Edit Post Page)

Its kind of a downplayed way of differentiating Apps and Folders. Technically they share some of the data but not every object in their app. Folders are just there to group DataPages. But based on your setup of having shared parameters, it might be alright to use folders but it is still best to separate them if they are different apps from each other.

[Kronos]

I've just checked their How To regarding their App and Folder description and I was almost right! I just missed the grouping of user groups haha

App:

An app allows you to group all the objects that are related to one project or process. This helps you organize and manage all your data, tables, DataPages (interfaces), authentication rules, styles, views, connections, and localizations.

Folder:

You can create folders to organize and group your DataPages by different user groups, for example: Admin, Business Owners, Public Users. This way, you can better manage your DataPages within an application and outline all the DataPages needed for each user type or scenario. There is no limit to the number of folders you can create, or the number of DataPages that can be included in each folder. However, you cannot create folders inside of other folders.

[DaveS]

Thanks, @Kronos.  My sense is that that is a "philosophy" of how to use folders and apps - and it's consistent with the way I thought about it when I started...  But I think there are also practical considerations that influence what works best.  

I've just finished consolidating 4 apps down to one app with 4 folders, and so far, I'm optimistic this is going to be a better solution for me.  Here's why:

1. I'm planning on doing frequent releases across Dev/Test/Prod.  Having 4 apps means 4 exports, 4 imports, and a lot of cleanup.
2. Importing the apps separately was causing strange problems for me - in particular, replication of tables and triggers.  Both tables and triggers can only be deleted one at a time, and that was a big time suck.  I was also seeing some weird behavior where - if two tables were in different apps and had a relationship - the relationship would seem to get lost on the migration and have to be manually recreated in the destination environment.  (To me, if I'm changing code in Test, it might as well be Dev!)
3. Post-migration there are a set of app parameters that need to be updated.  Doing those updates in 4 different apps was a lot of unnecessary clicks.  Even enabling data pages  post migration - something I can do once in a single app vs. four times.

 

I will share any new learnings - appreciate the feedback!