2 sites... 1 DB?
Hello all! It's been a while since i was here, but i am back!
So today I would like to get some opinions on a project I am working on. So here we go...
What would be the best way to architect 2/3 sites (one comsumer, one business, one godmode/admin - maybe) running off one DB?
One solution i have come up with is to have an API, which dones all the leg work, then the sites - and eventually mobile apps could use that to deal with data. I assume this would need to be token based auth so its secure, and i think Chris has a great video covering this.
An other would be to edit a connection string, but i dont know if you can do that in Rails, i know you can in .NET which is why i thought about it.
Any one else have a better solution? All help or suggestions would be much appreciated thanks :)
Alan
Heya Alan,
I think the api route is the way to go for this one... as you said, this method would allow all the various apps to access the data how they need to and be independent of one another. Without more specifics though it's kind of hard to offer too solid of an answer - but my gut says API would be the least headache :)
There are a bunch of ways you could tackle this. One of the neater ones is actually with ActiveResource where you can treat a remote Rails app as if it were in the database (for the most part). It got extracted to its own gem that still seems maintained. It's pretty slick if you use it, but you gotta follow the Rails conventions which not everyone wants to do.
Another option could be building 3 separate Rails apps that all use the same database server and database. Each one could then point to that and consume it as if they were inside the same Rails app. You would share your model files across the apps migrations would be accessible to each one of them. Basically for this you'd just simply share the model files and the database.yml between apps. That's about it. This is probably the easiest option, but you'll have to be aware of some of the annoyances of copying over validations for a model into every app. You could of course extract the models to a gem you share and require that gem in each app as well. Or as a git submodule so you wouldn't have to mess with gem updates.
And of course, the custom API for this is the last option. You'd hit that API from your apps instead of the database. It could be the sole place connected to the db to control any changes and the other apps could consume content from it. They might have their own ancillary databases to store extra stuff in that the others would never need. This one is probably the most work of them all, but could give you the most flexibility between them all.
The good thing is you can definitely start easy here with 3 separate apps that connect to the same db and as you grow migrate your way into an additional API service if you want. I would definitely start simple with this at first and start expanding it as you need.
Great information Chris! I completely forgot about sharing the database, we used to do this with Joomla sites and was great for simple applications, but a nightmare with anything more complex... however using a gem to manage some of those annoyances is really clever!
I've been curious how to approach exposing an API for an already established rails app, and maybe what considerations to take when you're in Alan's shoes, where exposing an API will be desirable in the future, but for now, there's no need to spend the energy on it...
Oh the good old Joomla days! I tried to experiment with that and Drupal a bit and never could quite wrap my head around them.
You guys should both check out ActiveResource sometime btw. It's like the best API implementation you can get between Rails apps because of how seamless it ends up being. That's one that I always wished had turned into more of a thing, but at the very least it can make for a fanastic influence for the way you design your API clients.
This API thing actually came up recently with GoRails because as I was building Hatch I was like man, it'd sure be nice if you were automatically signed in because you were logged into your GoRails account...I never did end up doing anything with it, but it's certainly something I would like to address in the future. It would be similar to what Alan needs to do.
knew i could trust asking in here!
yeah an API would have been my first option as it sems the most logical, however now you have mentioned ActiveResource i think i will have a look at that :)
basically i need to have them running off the same DB, but i want to keep the sites seperate so each site can be updated without effecting each other.
thanks for all the infor Chris, and Jacob. :)
I was going through my bookmarks and came across this site I had found awhile back:
http://www.ostinelli.net/setting-multiple-databases-rails-definitive-guide/
While it's the opposite of what you're looking for Alan, it does provide some pretty interesting ideas on managing multiple databases for one site, which should roughly translate into managing multiple sites with one db.
Thanks for the info on ActiveResources Chris, I haven't got to deep dive yet, but so far it does look pretty slick and might be just the solution for a few small projects I have coming up this summer. So I can't wait to get some time to dig into it more!
As always, thank you for sharing your knowledge Chris! I know I wouldn't be anywhere near where I am today without your services! \m/
