4 ms·

Interesting, but the big gap here is for projects where your rails app is an API (using rails-api) only. We've been struggling with the best way to build an adm

Interesting, but the big gap here is for projects where your rails app is an API (using rails-api) only. We've been struggling with the best way to build an admin panel in this case - I'm reluctant to add asset pipeline etc to the rails app just for the admin panel, and I've also found the admin panels tend to use large amounts of RAM etc. The other solutions all have downsides - you can build admin APIs into the API and have a separate app call them, but it's more work. You could make a separate rails app which calls the same DB, but then you have to keep the model code in sync. Anybody found a good solution to this?

ZoFreX 12y ago
You could use a rails engine to share the same models between two rails applications. Depending on the size of the project though, you may find that the economy of sharing models is a false one - applications of sufficient size may benefit from having separate models for user and admin interactions (see also: Domain Driven Design).
spinlock 12y ago
fwiw, we use active-admin for our Ember front-end/Rails backend app. We don't have a lot of actions that our admins can take but it's been really nice to expose some of the account details for support tickets, etc...
nchuhoai 12y ago
The asset pipeline shouldn't really be an issue with precompilation, or am I wrong?
psychometry 12y ago
There's no reason you need to host the admin panel on the same server as your API. You can even add your admin tool to your existing repository and deploy that single repo to two different servers, one of which you mount the admin engine in and the other you don't.
1qaz2wsx3edc 12y ago
> I'm reluctant to add asset pipeline Consider using different/manifests layouts if you're concern is client-side. If it's compiling assets I think your concern is misplaced. > admin panels tend to use large amounts of RAM etc I don't think this is the case, or a huge concern depending on you're environment. Further, you could separate the apps into engines, they're great for this. TaskRabbit did a write up on this: http://tech.taskrabbit.com/blog/2014/02/11/rails-4-engines/ http://tech.taskrabbit.com/blog/2014/02/11/rails-4-engines/ Personally however, I've normally roll out the app as one piece with active-admin, generically speaking most apps have little admin-specific logic to them, for example, it's normally something like: "Do <x> for user(s)", "Approve <x> content", the type of operations you do can easily fit under the simplistic nature of what active-admin offers. This isn't a catch all however, some applications require more of an integrative approach, in which case it's development as normal, bits of functionality injected here and there so-to-speak.

ZoFreX 12y ago

You could use a rails engine to share the same models between two rails applications. Depending on the size of the project though, you may find that the economy of sharing models is a false one - applications of sufficient size may benefit from having separate models for user and admin interactions (see also: Domain Driven Design).

spinlock 12y ago

fwiw, we use active-admin for our Ember front-end/Rails backend app. We don't have a lot of actions that our admins can take but it's been really nice to expose some of the account details for support tickets, etc...

nchuhoai 12y ago

The asset pipeline shouldn't really be an issue with precompilation, or am I wrong?

psychometry 12y ago

There's no reason you need to host the admin panel on the same server as your API. You can even add your admin tool to your existing repository and deploy that single repo to two different servers, one of which you mount the admin engine in and the other you don't.

1qaz2wsx3edc 12y ago

> I'm reluctant to add asset pipeline Consider using different/manifests layouts if you're concern is client-side. If it's compiling assets I think your concern is misplaced. > admin panels tend to use large amounts of RAM etc I don't think this is the case, or a huge concern depending on you're environment. Further, you could separate the apps into engines, they're great for this. TaskRabbit did a write up on this: http://tech.taskrabbit.com/blog/2014/02/11/rails-4-engines/ http://tech.taskrabbit.com/blog/2014/02/11/rails-4-engines/ Personally however, I've normally roll out the app as one piece with active-admin, generically speaking most apps have little admin-specific logic to them, for example, it's normally something like: "Do <x> for user(s)", "Approve <x> content", the type of operations you do can easily fit under the simplistic nature of what active-admin offers. This isn't a catch all however, some applications require more of an integrative approach, in which case it's development as normal, bits of functionality injected here and there so-to-speak.