I'm still sort of new to CakePHP, and I've presently created and deployed one (rather complex) application using it. It has full user and group support and I took the time to get the access tables working and everything.
Now, I'm creating a separate application. I initially just created a brand new CakePHP installation, but I later realized that I wanted to authenticate users based on my first app. They currently use different data sources. I understand that there are a couple of ways this could be accomplished, with various pros and cons. Do I:
Keep them separate, add a data source to my extension application, and port my user authentication code over?
Keep them separate, process logins with the first application, and somehow share that data with the second using a communication protocol?
Combine them into a single data source and accept the added complexity in my app?
Something entirely different?
I'm using CakePHP to create both sites, which will be running on the same host/hostname, and connecting to the same MySQL server. Users are always stored/created on the main application, and just need to be passively accessed by the second app.
Honestly it sounds to me like you could bring them together with ease. Your reasons for keeping them separate sound to me like you could just keep them separate pieces of the one program.
For example the application I work on for a living does many of these things. Users can register, they also have access to a calendar of events, job postings, recent news, and about 25 other modules. They are just different parts of the program.
You could have one application that has a route like /users/register which the users controller takes care of registration. Then you can have another part of your application that routes to /calendar/.... where the calendar controller will take care of the calendar logic. If you need separate calendars for students and faculty you could have routes like /faculty/calendar/1 and /student/calendar/1 which would route to different parts of your calendar controller.
It's all about modularising your application, so that you can easily maintain code that is logically grouped together. You don't have to separate them so much so that they are two different applications.
I think you will avoid many headaches in the long run.
If it makes you feel better about my opinion the software I work on that I was talking about is an enterprise solution that deals with (literally) millions of documents per day, and hundreds of thousands of users per week on the government level.
Related
We are developing an application for our customer that helps businesses to effectively plan and track their business changes.
Our application has three core elements, creating initiatives, capture their impacts and defining their actions.
One of the requirement in our product is for the stakeholders of these initiatives to be able to communicate with each other on these initiatives. So be able to like the initiatives, put comments, mention other users, notify each other when an action was taken and so on.
We are evaluating GetStream for this requirement and trying to understand if it best fits into our requirement or not.
We have spent enough time reading the GetStream REST documentation, the core concepts of how feeds and activities are designed. From initial understanding it looks as if the activities are tightly coupled to a user's feed or timeline vs what we need is to be able to add activities against the Initiatives and have multiple users communicate on the same initiative.
Our frontend is built in ReactJs, we have spent about 2-3 days evaluating react-activity-feed package.
We need help to understand if GetStream best fits to our model or not.
Appreciate all the help. Looking forward to a response.
This is a use case that Stream feeds are well fitted for. They are very customizable. It sounds like if you're using React then you'll need to ask us to make one of your groups global read or read/write. This will decouple the feed from being tied to one user and anyone can read or write to it. Email me at support#getstream with your AppID and the feed group which you'd like to change, along with whether you'd like to be read or read/write when the time comes and I can do this for you.
Best,
Stephen
Recently, the company I work for has given me the task of unifying 2 angularjs apps into one.
While I'm trying to wrap my head around it, here are the details:
- The two apps share quite a bit of common logic
- One of the apps (main one) is public facing, the other is made for a specific customer.
- Each app currently uses it's own database, this is because the customer's app is more complex and requires more data.
- Some of the common logic of the public app is being overwritten by the customer app due to the nature of it.
As an example, the login page is pretty simple in "public" but would have an extra layer of validating a registration code in "customer" and fetching the right data from the DB for this code.
I am trying to figure out how to I unify them both into 1 app, while having the ability to throttle between app modes or something similar
There is a way to tackle this using DDD (Domain Driven Design). Make a clear cut of the domain for both apps. For instance, if you encounter 2 user models in 2 different domains, as this is the case, you want to differentiate between the two of them.
Where this won't give you a framework to structure your application, it will provide a clear mindset on how to structure your application and correctly naming and identifying your contexts, domain and models.
Having clear domains should make a clear cut on which models can access X resources in the database.
Throttling is also an option, but I would only do it this way if I wouldn't have to maintain one of the versions. If the development branches only towards one, deprecating the other, then it is a reasonable solution, but maintaining 2 development branches this way is very painful.
I have a Spring application which supports a single customer.
I would like to extend this application to support multiple customers where each customers database is stored in a separate database. The schema for the database is the same for each customer, and the same DAOs and business logic should remain the same.
How would I accomplish this with Spring/JPA? Would I need to have multiple persistence contexts and wire in an appropriate entity manager factory based upon the currently logged in user? Are there any examples of implementing something similar to this?
I would advice against running separate database under a single application. If a redesign of the data model to incorporate multiple customers is not an option, why don't you run multiple instances of your application server/web container, one for each customer? As otherwise you'll have to deal with the drawbacks of having a shared platform and isolated databases.
With multiple customer databases and a single application your code will become more complex, you can't guarantee that customer data is fully isolated (e.g. due to a bug in the application a customer is shown the wrong data, so there's not much benefit in isolating each customer) and you'll have the nightmare of maintaining each customer database. Also, by having different databases you can virtually guarantee that someone pointy-haired is going to ask for some bespoke functionality for customer A while leaving customer B's functionality untouched, because "... it will be easy, as we've got different databases...", forgetting that the application is shared.
If you really, really want to have separate databases for particular customers, this would be the way to go — define separate persistence units with the same entity definitions, but different entity manager factory configurations.
To me it sounds more like a need to redesign the database structure. I'm guessing that the application has been written for only one client in mind and it turned out that more appeared on the horizon, so, hey, let's do something about it, and fast! Aren't you trying to copy-paste, but in a bigger scale? You'll going to have a lot of redundancy with JPA if you want to have a few databases with the same structure: for example, everything what's defined inside the mapping-file (queries, entity relationship mappings, etc.) is defined per persistence unit — you'll have to repeat these definitions and keep them all synchronized.
I'll stop here, as it is merely guesswork, for the lack of broader description.
Here's my problem. I built a web app, and naturally kept the data in a database which describes that app's domain. Afterwords, I built another web app for the same organization, and used a seperate database to describe that app's domain and store data... and naturally a couple more projects came up and for each app I've isolated it's data to a single database. Deveolpment wise, I think it's ok, as I can maintain changes to the data structure and data at the app's database.
Considering these apps belong to the same organization, there tends to be plenty of data replicated between them, like department names, job titles, shop names, etc. Most of these tables hold the same data, but are not exactly the same in each database, and are not always used by all of the apps. Changes to this data, though, needs to be changed at all the apps (sometimes in a diferent ways) creating a growing management "hassle".
So I've been think of a way to get some syncronization between the data. I want an easier management - update at one app (or a central app) and update all the databases as needed by each app - and also a better way to share data between apps (like maybe mash up data from differnt apps in a new app to alow specific analysis). Most of the data I'm refering to is used as contraints more than being core domain concept, describing the organization rather than describing a particular domain.
I'm looking for opinions on some ways to get this done.
My first idea was to grab comun data structures, like the department names' table i mentioned, and stick'em in a core database. Any updates to the data would be done at this database, through a dedicated web app, and I'd apply some sort of Observer or Publisher / Suscriber Pattern for these changes - on changes the app would notify observing apps (through there dedicated webservice) that the changes occured and allow for the app to grab the new data and use it as it needs. GUIDs could be user as a reference to identify the same data throughout the apps. Also, I could build web services for read and search operations that don't need to be in a specific app's database, but could be useful to it.
A second idea would be that each app manage it's own data, and the apps could observe one another. A change in one could notify others that share the same data structure that the change occurred. I could still use some GUIDs and even build services on any of the apps. I think this would also be less excessive in terms of duplication of data, but might be harder to manage as each app would eventually be coupled to other apps, and I would some how have to distribute responsabilities as to which app controls what information.
I'm really curious as to something of this genre of data distibuition and syncing would work and even be recomended. Opions and other ideas are more than welcome!
What you describe here is a typical case for a "Master Data Management" system. EAI vendors (Oracle, TIBCO, IBM) offer such products. They resemble your first solution, being centralised databases with synchronization processes, detecting changes in external data sources, grabbing the changes and synchronizing data out to other external databases. They also provide a user interface to change master data directly.
MDM software are expensive, but you can implement a custom solution which will be - at least initially - cheaper than purchasing one. Both of your solutions make technical sense but there is a difference in their manageability.
The first one is better, if you can dedicate a responsible person/organization to take care of it and the business owners of your services can agree on making changes via this new centralised system.
The second solution shares the responsibility between the service owners. The hard task here is to identify the owner of each type of information (business object).
I cannot advise a solution without a deeper knowledge of your systems and organizations, but I hope I could give some ideas.
I have a few questions about the architecture of a subscription service I am about to embark on and I am looking for some feedback on how best to set it up.
I won’t have a large amount of customers as Basecamp, maybe a few hundred and was wondering what would be a solid architecture for setting up the customer sites. I’m running SQL Server and .NET on a dedicated machine. Should create a new database for each customer as to have control and isolation of data or keep them all in one database?
I am also thinking of creating a sub-domain for each customer as well so modifications can be made to each site as needed. The customer URLs would look like this:
https://customer1.foobar.com
https://customer2.foobar.com
I am going to have the ability to ‘plug-in’ reports that will be uploaded to the site so each customer can customize as needed. Off the top of my head this necessitates having each sub domain on its own code-base for the uploading of these reports.
So on the main site the customer would sign up for their new subscription and I would programmatically create a new directory for the customer from the main code base and then create a sub domain pointing to the new directory for the customer and then finally their database.
Does this sound about right? Am I on the right track? How do other such sites accomplish the same thing?
Thanks for letting me bend your ear for a bit on this.
From a maintenance perspective, having a virtual directory for each customer scares me. Having done something similar, I would create separate domain pointers as you are intimating. Then you can check the referral headers to see what should be displayed. I would probably create one main site template and dynamically brand it for each customer. You can still create separate folders for customer specific reports or if you really need custom pages unique to that customer. I just wouldn't make each their own site.
The advantage of separate sites (including databases) is that the fate on one client isn't bound to all others. It'd be easier to upgrade (trial) to a sub-set before deploying to everyone else. The big issue here, as Scot points out, is time. You'd want to have things as automated as possible (and well tested), etc. It's also easy when a client leaves. You can always just back-up their database and send it to them (for example).
Auto-provisioning new sites and databases isn't easy, and the account that does that will need plenty of privileges - so your security testing will need to be better than usual.
A multi-tenancy approach is good for minimizing your time but you do have to be careful, you don't want customers data getting mixed up.
One approach that will work, within the one app (and database), is to make use of HttpHandlers (MVC framework, perhaps) so that some sort of client identifier is in part of the URL - but the folder doesn't have to physically exist (or virtually in the IIS sense). That way you don't have to worry about getting folder permission correct; but you do have to be careful about correctly identifying clients, their ids, and making sure clients can't make calls that use an id that isn't theirs.
https://www.foobar.com/[clientid]/subscriptions
The advantage of this is it's relatively straight forward: everything is in the application, and you don't have to worry about adding new DNS records, setting directory and/or database permissions, etc.