Rails & engines - best practice/architecture query

Rails
1

Hi all,

I want my app to have an HTML5 front end, and a JSON API. Would it be
overkill to split these up into separate engines?

So, I’d have a core Rails app (with Devise for auth), the controllers
for
the HTML and JSON front ends as 2 separate Rails engines.
Also, would all of my models belong to the core app, or would I have
ANOTHER engine with the models in?

thanks,
Paul.

2

On Fri, May 2, 2014 at 5:37 AM, Paul O. [email protected] wrote:

Hi all,

I want my app to have an HTML5 front end, and a JSON API. Would it be
overkill to split these up into separate engines?

Yes. You don’t need an engine for every front end.

What could make sense is to build the core backend of your application
as a service with an API, a la rails-api
(GitHub - rails-api/rails-api: Rails for API only applications) which would take RESTful
requests and respond with JSON. A user-facing web site (delivering
HTML5++) could be built alongside, not necessarily as an engine, but
it could be an engine, especially if it is doing more than the
back-end RESTful app/service is doing.

But making a separate engine just to deliver JSON seems redundant to me.

So, I’d have a core Rails app (with Devise for auth), the controllers for
the HTML and JSON front ends as 2 separate Rails engines.
Also, would all of my models belong to the core app, or would I have ANOTHER
engine with the models in?

If you can architect your application into separate logical services,
which have little interaction with each other, that makes a good set
of engines.

If you are just starting out with this application and it is meant for
eventual deployment (as opposed to something more of a learning
exercise) then I’d suggest you forgo the engines at this point, and
see how your app develops, and how it reacts under development and
use. On the other hand, if you really understand the application’s
domain and how users interact with it, go ahead and architect out the
various services as engines.