I have two tasks both using rails:
To make an inventory app to help employees keep track of inventory
To make a website for the company for customers to visit and gain a bit of knowledge about our product
My plan is to have the inventory app for each branch of the company to have a domain like this:
branch1.example.com
branch2.example.com
branch3.example.com
and for the customer-facing website to simply be www.example.com
My question is, should I make two separate rails apps, one for the inventory app and one for the customer-facing website? Or would it be easier to manage the two as a single combined app? The two apps would not be likely to share much code.
And if I were to split my apps, how would I be able to host both of my apps using a single domain as seen above (with the use of subdomains) with heroku?
Thanks!
Well, there's not really one right answer, but being experience with rails, I would recommend one app.
If you split there will be many times you'll have to copy and paste common code (becomes unmanagable). Plus you'll deal with either a shared database or multiple databases.
Not splitting, you can use a wildcard domain and access the current subdomain via request.subdomain to easily do whatever logic needs to happen per subdomain. Also you will only need to create the Product model once.
In short, all the mentioned requirements sound tightly coupled enough that one app would be easiest.
Related
I am new to Mautik and therefore need a guidance on the same.
Where should we setup mautik... on some folder or on sub domain to main site or a separate domain? How does the landing pages and forms gets its URL? Can it be embedded on another site on another domain or is it required to be hosted where mautik is hosted?
Moreover does single installation of mautik can be used for two or more different businesses site... which are not relevant.. and mainly a different customer for a marketing company? Or is it better to install mautik per business?
Can we track interactions from mobile app too using mautik?
First thing, I expect you are talking about Mautic and not Mautik.
You are free to choose whatever type of hosting you want, personally I Like to use independent container(could be lightweight) however I have seen people hosting on shared hosting as well.
If you are hosting on say example.com the landing page url will be example.com/landing-page same goes for all elements of mautic.
Yes forms can be embedded on other websites with a completely different domain. say example-something-else.com, you will need to put your tracking script on other site's head to make it work better. I for example check out this small tutorial https://tutorialsjoint.com/mautic-wordpress-integration/ it shows how you can use it in wordpress.
No it is not required that wherever you want to use mautic form should be on same host or domain.
However I recommend to use subdomain if usually just to save the hassle of buying a new domain and keeping the landing page urls more relevant. https://www.youtube.com/watch?v=K8lWaCabH1w this video shows how tracking works, it'll help you understand little better. Also here's official documentation: https://docs.mautic.org/en/contacts/manage-contacts/contact-monitoring.
You can use use one instance to manage multiple businesses I know people who are doing it but when the number of contacts, segments, campaigns, form, emails, landing pages grow with time it becomes a hassle to keep it clean. You can use category and a specific naming convention to keep them organized. But in a good way i will recommend to keep different instances in long run.
I am not sure about mobile apps but ideally it should be possible using tracking script or tracking pixel, perhaps you will need to turn off CORS restrictions.
I hope it was helpful.
Cheers!
No, you must use a VPS with Devian or Ubuntu, In a shared hosting it can cause problems. If you send many emails.
Landing pages can be made in html and pasted or edited in Mautic.
To use it in more sites you must create a user for each one, with their respective different email.
I'm building a report app in Rails for a current desktop app. The app is kind of pos/accounting.
So at the moment there are different clients with the desktop app installed at shop or office. Each one has its own mysql database.
I am now planning how to setup the server, most probably heroku.
Given that I will keep the databases for each client separated, I'm trying to understand the best path to follow.
Another thing to consider is that there will be different version of the app, i.e. restaurant, bar, shop etc.. Different versions will use the same database. I'll just need to change some controller and view. Most probably I'll handle this using namespace.
For a client(company) multiple users will have access to the app.
The solution I thought is to create a database table company and add a column company to users table.
Things that could change from a client to another:
call different images from assets such as logo
there might be custom views or even controller if a client requests some customization
use different database
domain possibly, but that's not that important wouldn't a be a big deal to use the same
Then based on user.company show a different logo or any other required image, render a view instead of another, at login connect to the proper database.
I don't know yet how to implement it, right now I'm still evaluating the best approach to follow. But this way maintenance/updates would be easy to manage even if maybe performance will be a bit lower and code harder to understand with possible customizations all together but that's acceptable.
Is this a reasonable solution or should I consider something different? Am I missing something important to consider?
I am beginning work on a new Rails project that is based on the premise of allowing users to create their own "sites." Each "site" would be a subdomain of the root domain (we'll use example.com). So if user Foo wants to create his own site at bar.example.com, each page request to a bar.example.com page would require fetching the a row in a sites table based on the subdomain.
My question is not how to code a multisite app, I think I have a pretty good grasp on that. My question is, from a scalability and performance perspective, would it be better to simply generate a new rails project for each site a user creates? Or is it ok run all sites out of one rails app. If numbers are necessary, let's assume I have 1 million users, each with a maximum of 5 sites, with each site bringing in around 1,000 hits a day.
I realize this is kind of a broad question, and mostly depends on my implementation of either method to reach a feasible solution, but any suggestions in terms of the best way to write this, including optimizing the DB, etc. would be appreciated.
It would be exponentially easier to have 1 rails app with millions of subdomains compared to millions of rails apps.
Check out this railscast for how to start with subdomains: http://railscasts.com/episodes/221-subdomains-in-rails-3
I wouldn't ever consider doing something like this with multiple Rails projects, because of the need to maintain all the code. By keeping it centralized, you can change the functionality of everybody's sites at once.
I think you might also run into memory issues by having all of those copies of Rails instantiated, too.
#Solomon is right. Heroku.com is using same concept for it's users to demonstrate users' applications.
I'm about to finish building a simple subscription based support ticket Web app. I'm setting up authorization. But since this it's going to be my very own Web app that I'm going to deploy I'm wondering about this.
Do you create a separate database per account opened?
Let's say you have this support ticket Web app. You have ONE and ONLY ONE account owner. Account owner can setup agents that can respond to support tickets. Also, there are customer roles that open support tickets.
So as you can see the database will contain users, support tickets and more.
What is the best way to go?
1) Create one database for the whole application? That way every time somebody signs up, everything is added to the same database with the other tickets and users data and everything else or...
2) Everytime someone signs up, create a separate database per account subscription.
I'm thinking that maybe option number 2 would be a best choice for security and data integrity purposes. If so, how have you gone about tackling this issue?
It sounds like what you want is Multitenancy:
Multitenancy refers to a principle in software architecture where a
single instance of the software runs on a server, serving multiple
client organizations (tenants). Multitenancy is contrasted with a
multi-instance architecture where separate software instances (or
hardware systems) are set up for different client organizations. With
a multitenant architecture, a software application is designed to
virtually partition its data and configuration, and each client
organization works with a customized virtual application instance.
- Wikipedia article on Multitenancy
This article while a little dated is the general idea of how I would go about doing it. Simple Rails Multi-Tenancy. It's clean and efficient and saves you from writing code that you don't need to.
You should go for option #1. Number 2 is (almost (there are probably cases where it is good, but I can't find one at the moment)) never an option.
You are right in security purposes (well, in a sense), but it also creates a lot of other problems that you will have to think about.
Having a different database for each user means that for each request (remember, HTTP is state-less) you will have to open up a new connection to the database, do whatever needs to be done and then close the connection again, instead of using the connection pooling that is in Rails. This affects the performance a great deal.
Administration will be a hassle the more databases you have. Also, having multiple databases on a server do require more resources than just a bigger database.
You would have to circumvent the entire connection handling in Rails since there it is usually one database per application. It is easy to change the database for specific models, but it adds additional places where things can go wrong.
Rails do have good functionality for scoping and handling of separating data within the same database, just for that kind of use-case that you are mentioning.
I was wondering if somebody has some insight on this issue.
A little background:
We've been using Rails to migrate from an old dBase and Visual Basic based system
to build internal company IntrAnet that does things like label printing,
invetory control, shipping, etc - basically an ERP
The Dilemma
Right now we need to replace an old customer-facing website that was done in Java, that
would connect to our internal system for our clients to use. We want to be able to pull information like inventory, order placement, account statements from our internal system and expose it to site live. The reason is that we take orders on the website, through fax & phone and sometimes we have walk-ins. So sometimes (very rarely thou) even a short delay in inventory update on our old Java site causes us to put an order on backorder, because we sell the same item to 2 customers within half an hour. It's usually fixed within one day but we want to avoid this in the future.
Actual Question
Does anyone have any suggestion on how to accomplish this in a better
way?
Here are three options that I see:
a) Build a separate Rails app on a web server, that will connect to the same DB that our internal app connects to.
+++ Pluses:Live data - same thing that our internal apps see, i.e. orders are created in real time, inventory is depleted right away
--- Minuses: Potential security risk, duplication of code - i.e. I need to duplicate all the controllers, models, views, etc. that deal with orders.
b) Build a separate Rails app on a web server, that will connect to a different DB from our internal app.
+++ Pluses: Less security exposure.
--- Minuses:Extra effort to sync web DB and internal DB (or using a web service like REST-API), extra code to handle inventory depletion and order # creation, duplication of code - i.e. I need to duplicate all the controllers, models, views, etc. that deal with orders.
c) Expose internal app to the web
+++ Pluses: all the problems from above eliminated. This is much "DRY"er method.
--- Minuses: A lot more security headaches. More complicated login systems - one for web & one for internal users using LDAP.
So any thoughts? Anyone had similar problem to solve? Please keep in mind that our company has limited resources - namely one developer that is dedicated to this. So this has to be one of those "right" and "smart" solutions, not "throw money/people/resources at this" solutions.
Thank you.
I would probably create separate controllers for the public site and use ActiveResource to pull data from you internal application. Take a look at
http://blog.rubybestpractices.com/posts/gregory/rails_modularity_1.html
http://api.rubyonrails.org/classes/ActiveResource/Base.html
Edit - fixed link and added api link
I would go for a. You should be able to create the controllers so that they are re-usable.
Internal users are as likely to duplicate data as external users.
It's likely that a public UI and an internal, for-the-staff, UI will need to be different. The data needs to be consistent so I would put quite a bit of effort into ensuring that there is exactly one, definitive database. So: one database two UIs?
Have a "service" layer that both UIs can use. If this was Java I would be pretty confident of getting the services done quickly. I wonder how easy it is in Ruby/Rails.
The best outcome would be that your existing Customer Java UI can be adapted to use the Rails service layer.
Assuming you trust your programmers to not accidentally expose things in the wrong place, the 'right' solution seems to me to have a single application, but two different sets of controllers and views, one for internal use, and one for public-facing. This will give you djna's idea of one database, two UIs.
As you say having two separate databases is going to involve a lot of duplication, as well as the problem of replication.
It doesn't make sense to me to have two totally separate apps using the same database; the ActiveRecord part of a Rails app is an abstraction of the database in Ruby code, therefore having two abstractions for a single database seems a bit wrong.
You can also then have common business rules in your models, to avoid code duplication across the two versions of the site.
If you don't completely trust your programmers, then Mike's ActiveResource approach is pretty good - it would make it a lot harder to expose things by accident (although ActiveResource is a lot less flexible and feature rich than ActiveRecord)
What version of Rails are you using? Since version 2.3 Rails Engines is included, this allows to share common code (models/views/controllers) in a Rails plugin.
See the Railscast for a short introduction.
I use it too. I have developed three applications for different clients, but with all the shared code in a plugin.