Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I've been using Symfony for close to 2 years now, so far, each project I build is deployed specifically for each client (i.e one client, one codebase, one db).
Lets say I have a Project Management app that I want to deploy for many clients. Assuming the clients will go with whatever features I build into the system, if I deploy a different codebase (therefore, a different db) for each client, here are the problems I foresee:
Pushing bug fixes and upgrades will be painful. I need to push it to every repository that I have deployed. It won't scale well if I have 50 clients using that same app.
Management is painful. How do I build an admin system for myself where I can pull ALL the projects into one HTML table? After all, each client has their own database, right? For me to do anything meaningful with all the records of all my clients, I need a way to look through all their databases at one go, which.. I don't think Symfony allows. (I'm not sure)
User account issues. If a user happens to work for multiple companies, all of them using my Project Management app, that user has to sign up multiple times. (I know this can be circumvented if I use oauth, but I'm trying not to go there if I can)
Here are the solutions I have thought up and tried to a certain extent.
Solution 1
One database and one codebase for ALL my clients. Projects will go under one table, Invoices go under one table, all marked by their own client_id. Users can be assigned to Projects so there is no need to sign up multiple times.
This is not that hard to create. But, what happens if different clients need different columns for their Invoices? My Invoice table will keep expanding (with different fields that different clients want), and each row can potentially contain many null fields. Not to mention, my Invoice entity will grow in file size, and I will have to update the database schema every time a new customization comes in.
Solution 2
One database where each client has their own table prefix. So for Client A, I could use clientA_projects, clientA_invoices, clientA_configuration etc.
This is ideal if each client wants to customize their fields. But, does this mean I need to create new entity and form classes for each new client that comes into the system? It looks like with this solution, I need to update the database schema with every new client I get.
Currently, I am experimenting with schema-less databases (mongo and couch), hoping that without needing to specify the table schema upfront, I can implement Solution 1 without hassle. But I'm still experimenting, and there are ways to go before I dare to deploy a production-ready app, being unfamiliar with the issues of mongo and couch with Symfony.
So, this is where I am stuck at. Being a self-trained programmer, I feel I have a lot of holes in my knowledge that requires filling (as opposed to someone from a CS background). There aren't many places on the web talking about Symfony 2 and multi-tenancy (maybe I'm looking for the wrong thing). If anyone of can point me to a clearer direction, maybe best practices, example projects, I will really appreciate it!
Btw, I plan to execute this in the latest version of Symfony (2.3.2 at this moment).
Thanks in advance guys.
I'm also using Symfony2 for similar amount of time (since one of BETAs) and I advise you to go with solution #1. If you are going SaaS you can't give out code to clients for the reasons you wrote (problems with updates / upgrades mainly). The whole hassle will be on the user management - which user has access to which data, belongs to which group, company and so on. All other things if done properly will be coded the same user-agnostic way. What should you do with different requirements for different companies? Make such features configurable. You can implement this on various levels:
simple entity attributes: have an attributes field in each table and save everything as JSON, YAML or other dynamic-structurable content,
general configuration: have one place where entity base configuration is stored (in the means I wrote above) and allow users to manage new features from there, all changes are propagated to simple entities,
implement something what I call Entity Parameters Pattern - design database tables which would contain parameter types, parameter values and relation to other entities on different levels and then make generic configurable parameter types which can be applied to any place with predefined meaning. For example "preferred_season" being a parameter of type "choice_string" containing configuration "spring,summer,autumn,winter" and when attached to given entity would always render a <select> field with choices and save selected value with relation to both entity and parameter type.
Also the solution #1 has one unbeatable advantage - it could handle more that one company even if you wanted to give out the code at the end. You'd just need to mask the ability to add more. :)
This question is tagged Symfony2 but it really shouldn't. It doesn't matter what framework you're using, you should abstract your application design from code and then use frameworks as a mere tool for doing the job smoothly. I'd like to say that even taking previous sentence into account, I'm absolutely in love with Symfony2. :)
I know this is an older question but can be usefull for others.
I agree with #Tomasz and solution #1 with one database – all tenants in one database. The biggest problem here is proper database design to solve further security issues: access for resources must be controlled by application to prevent unauthorized access between tenants. On the other side we have ease implementation as we are implementing single application with only one database.
Nice article about Symfony2 and moving to SaaS model:
http://www.browserlondon.com/blog/2015/01/moving-to-a-saas-model-with-symfony2/
Also "must read" article about designing database in SaaS platform - patterns that are platform independent:
http://labs.octivi.com/database-design-in-saas-platforms/
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Greetings,
I would really love to hear about your broad knowledge about application design on this one!
I'm new to Phalcon, and now building my first MySQL & RESTful-API based application with it, but encountering some challenges along the way.
First, about my application design, the concept is as follows:
An API as a core for the application, wrapped by a "UI shell" of pages and views that utilize it.
The API is supposed to be composed of a set of Phalcon models that represent the DB and business logic, and over them, a component that acts as a layer that makes those models accessible as "HTTP services" - generally by translating requests to model names, and the HTTP verb to the appropriate model action (e.g: GET => $account->find()/findFirst(), PUT => $account->update([params]), etc.).
I was sure that the Phalcon models are gonna rid me of having to write most of my SQL, however, soon I came across some pretty common scenarios that the models couldn't handle the way I would expect:
You have entities like messages for example, and you wish to query them using a column of some other, related entity (like the FIRST NAME of the user that owns those messages). A model can't do this in a single operation.
I want to show a list of messages, each attached with the details of the user that sent it. In Phalcon, the first thought that comes to mind is taking advantage of the model relations feature, but thinking further I came to realize that will perform a full query for every message rendered, which is a disaster performance-wise, rather than retrieving them all together with their user details in some single, JOINed query.
I want to show a list of users, each with a total messages count. Found no other way to achieve that rather than a full query that includes a COUNT() field & GROUP BY or a sub-query.
I tried to look up such use cases and others, for most of them there hasn't seemed to be any elegant solution.
The Point:
What I want to achieve is a API-based architecture that makes sense, scalable and easily customizable to real world scenarios (being able to handle obvious situations like demonstrated above).
What would you do in Phalcon to handle the problems I encounter?
What do you think about the design concept I took? Is it somewhat standard and makes sense?
Most importantly, how would you design a full & flexible API without repeating cumbersome SQL queries everywhere, if at all?
Do you have any references or examples of known companies' approach on this?
That's a big question and any help will be huge!
Thanks!
Dor.
Little disclaimer first: There's no straightforward answer for this question(s), so Stackoverflow isn't the place for them. But since you have put it nicely I'll try to help :)
Almost any modern CMS API has a very similar approach that is very successful and flexible, you can follow their guidelines to implement your own API. I'd recommend storageroom and contentful documentation pages, they have a series of gotchas and patterns that I've successfully added to my own projects eventually.
Phalcon is a good choice for a RESTfull API and a proof of that is the PhalconEye project, a cms built using Phalcon. Once you have designed your API, go check the PhalconEye source code to get some samples on how to implement such things with Phalcon.
Good luck!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm trying to understand advanced PHP OOP principles, having programmed procedural Php for years. I wondered if there is a rule of thumb for how best to group functions in to classes and how to plan which classes to abstract / extend? If not, could you recommend any advanced reading that might help.
I have read a few (self-defined) 'advanced' OOP tutorials. The examples have taught me the basics for how to create very loosely coupled objects with very minimal attributes defined in heavily abstracted classes. I've also read other (bad) tutorials which basically turn functions in to methods and encapsulate them in classes - and I know they are not written well so don't want to emulate them.
However, I'm not clear how to decide which classes to build my project around - I'm not sure if I should think first about the macro features of an application or about the frequently carried out actions.
Take for example a website in which:
- Users can sign up and have different privileges depending on user
levels
- Users can edit their user details, upload photos, sign up to a mailing list and join groups with other users
- Admins can create new sections in the site within 5 different module areas
- Users can post articles and comments within these different distinct sections
1) If admins can create a sections within 5 different module areas (single, double and triple level blogs, forum, poll) should I think in terms of 1 class per module?
OR 2) should I generate a new 'class' for every new section an admin creates?
OR 3) Users are the central focus of the entire site - Users interact with the modules and the sections - so do I create a large user class containing insert, edit, delete methods?
Following on from that, where is best to put the methods?
a) I'm going to need to freuently use an SQL insert clause - I'll need to insert to the user table when someone signs up, insert to the groups table when someone makes or joins a group, or posts an article, comment or IM - so I'll use a method like the following... but should this be nested inside all of the other classes, or repeated in each of the module classes?
// runs a sql query
public function runQuery($qry) {
$result = $this->mysqli->query($qry);
return $result;
}
Likewise things like emailing the user multiple times - when they sign up to activate their account, when they join a mailing list, if they forget their password... So I imagine I would need a method for that.
As you can see, I'm confused as to to which class I should I put my methods in, and which classes to build my site around.
I'm fairly sure that I shouldn't need to think through 'all' my features before I start, as that wouldn't work well with an Agile development environment where users might suggest new features, so I'm hoping there is a relatively simple bit of guidance you might be able to offer me.
This is just one of many examples of sites I've previously coded procedurally and now want to start thinking about in OOP terms, so any pointers would be hugely appreciated!
Thanks
It's very difficult to come with proper solution without understanding what do you really want. When you are facing a problem/feature request you have to design application. Everything depends on feature/issue.
There are many different solutions, and each one is good for specific case. I cannot answer your question without deep understanding what do you want to tackle. The only think that I can advice :
- KISS - Keep it simple Stupid
- SOLID Principles, especially Single Responsibility Rule - each class should be responsible for only one thing. For example if you have User object, you should have at least three classes. UserEntity or UserDomain - simple representation of object, Repository/Storage for that user that brings you the basic operations on given user (CRUD - Create,Read,Update,Delete), and then you should have a module,service that handles the interactions, (for example between different users). The less one class know the better.
The good way to start is reading at least a little bit about design patterns, SOLID, maybe about DDD (Domain Driven Design). Also I can suggest watching CleanCoders. Uncle bob has very good (in my opinion) video tutorials about software development.
I used to say, that if you want to do something correctly, you have to do it twice. At first approach you don't know what you can expect, you cannot come with best solution without deep understanding what you're facing.
When I'm writing a piece of code, for example a class, I'm always writing it at least two times. Almost each part of class is refactored during development in order to remove duplicated code, improve perfomance. It's very rare when developer comes with perfect solution at first time.
I'm looking for the best way (or easiest way) to manage multiple instances of a PHP web application, that share the same code base.
Let me break it down for you:
Our domain is hosting multiple instances of the application, each with their own settings files and database.
http://mydomain.com
|
|------/customer1/
|
|------/customer2/
|
|------/customer3/ + custom features
Let's say that customer 1 & 2 purchased the application (that we host for them), and they have the base model of that application. (ie. not customized)
However, customer 3 wants feature X or Y, so we code that feature for him and add that to the application.
But whenever there is an update to the code base (ie. a security fix in the core classes of the framework) all three customers should get an update of the base code!
What would be the best way of managing this sort of setup? Manually uploading all files using FTP is a pain, and it's not possible to merge code.
Using Git is perhaps a solution, but how would I go around and do it? Create separate repositories per customer? What if we grow to over one-hundred customers?
Any insight are welcome, including why we should or should not use such a setup. (but remember that we'll be the ones hosting the application for our customers)
I remember doing this years ago so you will have to take into account i'm now a little rusty at this.
I built a standalone framework, which combined all includes into ONE .php file. Any frameworks that used that, would do a PULL request and if the md5 of their framework matched the framework on the central server then no update was needed. Otherwise it would download the new framework over https and replace it's own copy. This created an automatic update system that was PULLED to all other apps that used it.
A major problem to this is, if you cause say a syntax error and you upload that to the central server, it will get pulled to all others and break them! You will be best to use a cron job to make the pull request that does NOT use the framework so the broken framework won't break it from doing a pull request to FIX the syntax error in the framework. This at least adds the ability to automatically fix itself as well once you fix the syntax error on the central server. However, having a staging server to test each update really is very important in this case.
That is only the basics of course as if you have say images that the framework uses they will also need to get pulled over, as well as any SQL updates and so forth.
You must regorisly test this before uploading to the central server in order to prevent mass errors! Not ideal! Unit testing, staging server, small and simple updates but more often (large updates have more potential to go wrong, and more to undo if it does go wrong) will all help mitigate the risk.
You will also have to structure the framework VERY VERY VERY VERY VERY well from the beginning to make it as flexible as possible when planning on having many different sites use it. If you design it wrong in the beginning it may be next to impossible to redesign further down the road. For example it may be wise to use PDO for database access, allowing all the applications the ability to use different databases while your classes etc will still no know how to interact with the database (regardless of if it's mysql or oracle), though, i would advise at least sticking to one if you can.
Design wise, you are best to look at other language frameworks and see how they do what they do. You must stick to good design principles, use design patterns only where applicable, and take note of MVC!
Further Reading...
http://en.wikipedia.org/wiki/Software_design_pattern
http://www.ipipan.gda.pl/~marek/objects/TOA/oobasics/oobasics.html
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
http://www.phpframeworks.com/
This is no easy task, so be warned.
You mixed two separate different tasks in one question
Development and support of diverged code
Deploy of code from (any) SCM to live systems
Answer on 1-st question (for any modern) SCM is branching and merge branches (each customer have own branch, into which you merge needed parts from you single development-branch, or /better/ with "branch-per-task" you merge task-branch in all needed targets, avoiding cherry-picking)
Answer on 2-nd question is "Build-tools", which can interact with your SCM (you have to write more details later for more detailed answer)
Make your custom features modular. Use a similar architecture to WordPress/Joomla which have plugins or extensions. This allows your customers to easily have separate feature sets but all share the same base code.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
For the past weeks I can't stop thinking about the architecture of a CMS I have to develop shortly. First of all I want to answer to the possible first questions that you could ask me.
Q: Have you read the similar questions on StackOverflow?
A: Yes, I have. Unfortunately none applies to what I have to ask.
Q: Why would you want to code another CMS???
A: Well, this is a bit of a long answer. Long story short: it has to be closed-source and it has to meet the requirements I need (it won't be 100% a CMS, it's a much more delicate subject - any project developed with it will be somewhere between 60-70% CMS and the rest will be custom code for that project's specific needs)
Tools of the trade:
PHP
Zend Framework (my personal choice; I'm very familiar with it and I won't change it for this task whatsoever)
What I need this "CMS" to be
Developer oriented
Since it won't be a pure 100% CMS it has to be developer oriented - easy to maintain, easy to develop against (more like the feeling when developing on an enterprise level framework)
User/Editor oriented
While working on a project like this one, any programmer might find himself going in a wrong way and not thinking the person who'll work as an editor using this CMS is not in fact a very technical person. This is the part where conflicts happen - if it's not simple to use, yet powerful enough, you will have a lot of problems to deal with.
i18n & l10
I'm almost certain it will be kind of a difficult task to code something both developer and user oriented and if I won't achieve this, I would like to give more importance to the developer instead of the editor. I am aware it's not a good deal to ignore the actual user of the software, but this CMS has to be fast to develop against.
Possible architecture patterns
1. General object
The first architectural design that got me thinking was the following:
I define a general object. The user/admin goes in the administration area and defines the data object he needs. Easy one.
The object page (for example) has a title field, a body field and a slug. It was just defined by the user and now he can create content based on this "data structure". Seems pretty neat, but I still didn't solve some of this architecture's problems.
How will those dynamic objects will be stored in the database? Should I use a dataTypes table, an objects table and link them many to many via objectProperties table?
Or maybe should I serialize them and store everything in the objects table?
Should I give the user the possibility to create new dataType properties and add them to its objects?
How will I i18n all of this?
Isn't too complicated to force the user to define its own data structures?
Will it be too messy if it will have a lot of data structures defined, multiple languages? Would it be still manageable?
2. Extreme developer oriented - scaffold data structures
Today I found myself thinking about this possibility. It would be pretty neat to define the data structure of an object in a yaml or ini file and then scaffold it's database table, model and CRUD. Also mention it's relations to other "data structure" objects to get the right CRUD implementation (think about page data structure and category data structure, for example).
Unfortunately this made me also think about several possible problems.
Will I be able to code such a scaffolding tool on top of Zend Framework? (which is known to be lacking scaffolding if we except the 2 or 3 suggestions made by the community, like this one)
Is too stupid to create 2 tables for each object so I can internationalize it?
Would it be too strict on the user if he can't define new data structures without the programmer?
Conclusion
I'm still very confused on how to approach this subject and what architecture to choose. At this very moment both are pretty challenging in terms of development.
My questions are pretty straight-forward.
If you would have to choose one of this approaches, which would it be and why?
Can you maybe suggest a more interesting pattern to follow, considering my needs?
Just some general advice, if you are really trying to manage free-form content then I would stay away from relational databases for storing your data and go with an XML solution. A relational database has too much structure for something that is purely content oriented. Think of a home page... You have info displayed like: welcome notice, about us, who we are. That doesn't really map well to a table / collection of tables especially when you start adding / removing some of those items. Something with a defined structure, like stack overflow, does map well to a relation datbase however.
Take a look at Day CMS, Apache Sling, Java Content Repository for some ideas.
http://www.day.com/day/en.html
http://sling.apache.org/site/index.html
http://en.wikipedia.org/wiki/Content_repository_API_for_Java
From my point of view more options are always a problem. Users are mostly ignorant, when it comes to complex systems. Therefore I'd stick with the developer-oriented solution. Developer will decide what kind of content can be displayed. Optionally I would allow some kind of "open" content - for power users, allowing complex CSS/HTML/JS. Complex content like photo galleries, user profiles, etc. should not be designed by BFUs.
So to sum up - main feature - creating pages that can be dropped anywhere in the structure (that should be very flexible). If they want user profiles, you can create a new type of page. But at the end of the day, BFUs can do anything with enough time. It depends on the price/time scale. If they can pay for it and need it fast, they will make you create a new user profile page type, taht will be easy to fill. If they are kinda poor, they'll choose to setup all by themselves using normal page and WYSIWYG :D
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I’m working on a project and have developed the high level user requirements for what the system must do. This project is a php web application built on the CodeIgniter framework. Now I’m trying to take those requirements and break them down further into controllers/actions. What is the best way to do this?
I was thinking of creating a word document with a table that would have four columns. Column one would be the the name of the controller, column two would have the actions, column three would have the name of the view that is specific to the action, and the fourth column would show which users had access to that action. Does this sound like a good idea?
I like the interface first approach to building an application, but realistically, I need to know what views I need before I can create a prototype interface.
Could anyone help me out with how to plan the app and any documentation that might help?
Your breakdown is a good idea, but it's really the second step.
here's what I'd do:
take your requirements, and turn them into a series of scenarios ("use cases", "user stories").
Pick one, and sketch, like on paper, the basics of the user interface you'd want if you were to have the Good Code Fairy deliver the perfect system to you.
separately go through the scenario, and underline all the nouns in the story; those are probably domain objects. Underline all the verbs in a different color. Each verb is a method of one of those domain objects. (In fact the domain object will be the object of the verb. Cool, huh?)
Figure out how you would implement that user interface using those domain objects.
Build it
Show it to your customer, who will invariably say "I like it but"
Put the changes and things you learned inot your requirements, and repeat until the check clears.
Peter Coad wrote what I still think is really the best beginners book on this: Java Design: Building Better Apps and Applets. It's oriented to Java, but the design part is universal.
Your domain objects are the model, the display of your data is (roughly speaking) the view, and the code attached to actions is the controller.
On Use Cases
The "right way" to do use cases or user stories is subject to immense discussion and religious warfare. There are zillions of options, from Cockburn's somewhat complex form, to notes scribbled on index cards.
For the kind of application you're describing, I do two things: I try to keep them to 25 words or less, and I think about the SMART acronym.
Twenty-five words or less helps keep them small. Doing a few small stories is preferable to spending weeks on a big one.
SMART stands for "Specific, Measurable, Agreement with Responsibilities and Tests." (Or at least that's how I interpret it. There are other versions.)
Specific, you have to be comfortable you know what's being asked.
Measurable, you have to have some way of testing or some kind of statement of what will be acceptable
Agreement, because it needs to be something you and the customer can both agree satisfies a need — in other words, the "meeting of minds" of a contract
with Responsibilities, you have to know what you're being given, what the customer or user is responsible for providing, and what you are
and Tests, in other words, you should have an effective procedure that gives you the answer "it is acceptable" or "it's not acceptable."
The form I use has the pattern
User in a particular role
does something
resulting in some benefit
So, in your example, I would write
Administrator (who?)
lists all FAQs (does what?)
to review them for updates. (why?)
The "resulting in some benefit" part is something I emphasize and a lot of other people don't, or don't even mention. It helps a lot later if you need to prioritize them.
The "test" part is a description of an acceptance test: you're answering the question "Is this done?" So the acceptance test might be
A logged in administrator selects "list FAQ". All known FAQs are listed in correct format.
Ideally, you'd set this up so some tool, like expect or a gui test tool, can run this automatically, but especially in a small projects you may end up testing by hand. You want automated testing, because as you build the system, you want to do regression tests; that is, you want to repeat your tests to make sure nothing has been broken by a later change.
What you do is you work user-centered.
You make rough mockups of the screens (use Balsamiq or something), and show them to your client/stakeholder, and walk them through it (as if they were using it). Get them to agree.
Then you code the thing (I'm sure you can figure that part out)
Then you show to your client again (have them actually use it in detail), and agree on changes.
Now you finish it
Good luck!