I want to build an application that would handle CRM, client database, time tracking etc.
The app would be sold to about 100 clients. The thing is that every one of clients will have slightly different needs i.e. they want to integrate app with their own accounting software or have added functionality only for them and in their instance, they want only those modules, that they are using.
I'll need to manage 100 different instances of the same app, so I want it to be easy. For example if I'd fix a bug for one instance I want it to be easy to propagate this bugfix to all other instances and if I create a module for one client I want to easily add it to another client's instance if he would want to.
What is the best way to do this in this situation?
I would be really thankful if someone would point me to the right direction ;)
Generally this is handled by making things data-driven. Everybody gets the same code, but with different feature-flags which enable/disable various bits of the application.
Feature flags can be driven in a database, config files, environment variables, etc depending on your needs.
Related
Is there an easy way to set up a database that's accessible to several people that can do all the things a single user would do?
I'm studying Database 101 and I am currently doing a project with four other people and we're having trouble meeting up and doing it so it would be great if we could do it from wherever.
When I say "easy way" I mean without having the super-ultra-deluxe-enterprise-edition of software.
Can it be done with a "local" Dropbox folder?
What you can do at zero cost is to have one project master.
Distribute a copy to each member. Each will have to do completely separate tasks, like one for designing a form, one for adjusting a report, one for some code module, one for another code module.
When done, in the evening or what you agree upon, you collect the different versions with a list of what objects has been changed or added. Import these in your master, and then distribute this to the members as the current revised working copy.
It takes some discipline, but that's all. And all masters you save as a zip given a filename including the date and time. This way, nothing can get lost.
I am starting work on a new project soon and was wondering whether to create multiple apps (pretty much copies of each other) or one single app (or utilize single sign on of some sort). Each 'app' will have its own domain.
The apps are pretty simple, people can sign up to the site and create a profile for their cat or dog. However, as some people have a cat and a dog, it would be nice to not have them sign up twice. Also, I think many users will want to extend to other pets too, such as rabbits, rats, ferrets, etc
It will be a Rails app, and so I wondered what my options are.
A single app would be easiest to maintain
Multiple apps could mean it is easier to 'split' the network i.e sell some of it (tho I doubt I'd do that)
But which would be most efficient? Would there be any problems with caching? Which makes most sense?
If you have any links or info on how to go about your preferred method, that would be appreciated too! But at this stage, I am mainly asking about which is the most logical way to go about it.
Less is always more, especially early on in a project.
I've learned to never split code bases until it's absolutely apparent that it must be done.
Making 2 apps means twice as much work in so many ways. Two bundle exec rails server to run, two bundle exec rspec to run, cd .., cd web_app1, cd web_app2 over and over.
You also have to deploy two apps.
So, make one app. Split it up later, if and when you need to.
If they are on the same subdomain, you can share cookies, and easily achieve SSO.
And there is no reason you can't use something like nginx to put them behind their entirely separate domains, as a deployment consideration.
If you were planning to have multiple domains with a separate application on each domain, you could have a "central" domain (or server) that can hold all shared resources (images, css, javascript, data etc) and provides the ability to load-balance and increase performance. It can be a lot of work connecting everything and keeping it all running so it depends on your situation.
I'm in the early stages of prototyping a Rails 3 application that will expose a public API. The site has three separate concerns which I am planning to split across three subdomains.
api.mysite.com
The publicly exposed API.
admin.mysite.com
The admin portal for creating blogs (using the public API).
x.mysite.com
The public blog site created at admin.mysite.com where x is the name of the blog. This too will make use of the public API.
All three will share domain objects. For example, you should be able to login to admin.mysite.com using an account you created on api.mysite.com or x.mysite.com.
Questions
Should I attempt to build one rails application to handle all three concerns or should I split this in multiple applications each handling a specific concern?
What are the Pros & Cons of each?
Does anyone have any insight into how some of the larger sites (basecamp, github, shopify) are organized?
Your question is fairly general so I'll try and answer in general terms. And the fact that you mention "larger sites" leads me to the conclusion that you're concerned about scaling.
In the beginning it is definitely going to be easier to build one application - especially since the domain is shared. You can do separate controllers for the various interfaces (api, html, etc) but with a shared back-end. This will reduce code duplication and the complexity of keeping 3 apps in sync. Also remember that you might change your mind about features based on user feedback and you want to be nimble enough to respond quickly.
The main benefit I can see of separating out three different deployables is that you can have an independent deploy schedule for each. For example, a bug fix in the api won't have to wait for admin to be ready to deploy. Or that you can have separate teams working in parallel.
If you're careful about what you keep in your session you'll be able to deploy multiple instances of your application on multiple servers, pointing at the same database (a.k.a. horizontal scaling). Each of these instances are identical to the others and a load balancer (either dedicated hardware or virtual) directs traffic between them. Eventually this approach runs out of steam when your database can't handle the load. At that point you can look at more caching, sharding, no-sql and all sorts of clever scaling techniques.
Most (but not all) larger sites end up doing some sort of horizontal scaling with some sharding of data.
All told, focus on getting a useful application to your users. If things take off you can worry about scaling. More applications fail because the user experience is awful rather than not being able to scale.
I am working on one big project. Now we need to add new functionality: scheduler managment.
It's not a main task of application, but it is quite complicated part of it.
Is it good idea to extract it as a separate application?
It will share some data (users and some other personalities) and it will use the same database.
The main reason I want to do it is to simplify main application.
I understand, that it is mayby too wide question. But maybe you can share your expirience of developing this kind of applications and maybe there are any articles I can read and world-wide best practices.
While others have mentioned some of the benefits of separating the applications, I'll touch on a couple of reasons why you might NOT want to separate the code.
You're going to need to maintain a single set of tests, especially if both applications are sharing the same database. If you don't do this, it's hard to predict when changing one application would break the other, especially if the applications start to need different things out of the database.
The two applications are obviously going to have a lot of overlap (users, for example). Separating into two applications could potentially force you to duplicate code, since rails by default has some pretty specific ideas about how a rails application should be structured. If your applications are sharing certain views, for example, what will you do to coordinate change in both applications when one application wants to modify the view?
Neither of these is insurmountable, but rails is easiest to develop when you follow rails conventions. As you begin to deviate, you end up having to do more work. Also, don't take either of these points as invalidating the other answers here, but merely counterpoints that you need to think about.
When you can use the functionality in other projects too, then I would separate it.
Maybe you can create a rails engine to share it easily between projects.
Consider asking yourself "What about re-usability?" Is the new scheduling functionality likely to be re-usable in another context with another application? If the answer is "yes," then perhaps making the scheduling management more modular in design will save you time in the future. If the answer is "no," then I would think you have more leeway in how tightly you integrate scheduling management with your existing app.
The practical difference here would be writing generalized scheduling management functionality that has assignable tables and methods upon which to act versus more 'hard coding' it with the data/code scheme of your 'onebig project.'
hth -
Perry
Adding management-tools into a web-app often complicate deployment, is my experience. Especially when the use of your application grows, and you need to performance-tune it, dragging along a huge "backend" may be problematic.
For sake of deploy-, scale- and test-ability, I prefer my applications to be small and focused. Sometimes it even pays off to have the entire admin-enviroment over REST-XML-services.
But as other answers point out: this is more a "it depends" solution. These are my €0.02.
I know there is a lot of talk about BPM these days and I am conscious that some may see it to be a craze rather than a fundamentally important piece of software.
As someone from what most would call 'The Business', I have been doing my best to learn about BPM to ensure we continue to make decisions that not only make sense to the business, but IT as well.
I have noticed while reading that mention is made to application workflow when sometimes discussing BPM. I hadn't given this much thought until recently.
Therefore, what is the difference? When would you use one and not the other?
BPM is about the process and improving it, which takes into account users and potentially more than one application,e.g. an ERP system may have more than one application to it, though there may be other uses of the term. Note that the process could be viewed without what applications or technologies are used.
Application workflow is how an application is used to go from a to b. Here it is a specific set of code that is used and what happens over the course of an application getting from a to b. In this case, the application is front and center rather than the process.
Does that provide an answer? Another way to think of it is that multiple application workflows can make up a system which is used in a process that can have BPM applied to it.
Late to the game, but workflow is to database as BPMS is to DBMS. (Convenient how the letters line up, huh?)
IOW, BPM(S) is traditionally meant to refer to a particular framework/application that allows you to manage business processes: defining them, storing them, versioning them, measuring them, etc. This is similar to how a DBMS manages databases.
Now, a workflow is a definition, much like a database is a definition. In the former case, it is a definition of operations/work (Fufill Order), steps thereof (Send Invoice) and rules/constraints on the work (If no stock, send notice). In the latter, similar case, it is a definition of data structure (CREATE TABLE) and constraints (InvoiceTotal must be > $0.00).
I think this is a potentially confusing subject, particular as some development environments use a type of process flow model to generate user facing applications (I'm thinking about Outsystems here, for example).
But, for me, the distinction is crystal clear. Application workflow, as people talk about it, refers to a user's path through an application, i.e. the pages they complete/visit, the data they enter, etc. on their way to completing a transaction of some sort. Application orkflow is a poor term for this though, I think application flow would be more meaningful.
BPM on other hand, is about modelling and executing a workflow process. By workflow, in this context, I mean a series of discrete steps (or tasks) that have to be completed (either programmatically or via human interaction) in a certain order to complete a process. These tasks can be implemented as individual application modules (each with their own "application workflow", see above). The job of the workflow engine is to make sure that these separate steps are assigned to the right people (of groups of people) in the right sequence, and that overall the process completes in an orderly way.
I don't think there's a clear answer to this at all. These are words, as opposed to theoretical concepts. If you add the word "checklist" into the mix - that just turns out to be a linear version of a process (but you can have conditionals in checklists - making them a workflow).
I am not sure how to help in reframing this question, but it's almost as if no answer can ever be possible. My own thoughts are at https://tallyfy.com/improving-efficiency-workflow-vs-business-process-management/