2

Rails で管理 Web アプリを作成しています。実際には関係のないさまざまな実装の詳細があるため、このアプリをサポートするデータベースには、別の別の Web サイトをサポートするために必要なすべてのコンテンツが含まれます。2 つの明白なオプションがあるようです。

  1. 何らかの方法で同じデータベースから読み取り専用で読み取る Web アプリを構築します。
  2. 元のアプリに RESTful API を追加し、API からコンテンツを取得するような方法で 2 番目のサイトを構築します。

私の質問は次のとおりです。これらのオプションのいずれかが実行可能ですか? もしそうなら、どちらがより良い選択肢のように思えますか? Rails、Sinatra、またはその他の Rack ベースの Web フレームワークは、この種のプロジェクトに特に適していますか? (Rails よりも軽量に見えるため、Sinatra に傾倒しています。Rails の経験がうまく引き継がれると思います。)

ありがとう！

4

1 に答える 1

3

Both of those are workable and I have employed both in the past, but I'd go with the API approach.

Quick disclaimer: one thing that's not clear is how different these apps are in function. For example, I can imagine the old one being a CRUD app that works on individual records and the new one being a reporting app that does big complicated aggregation queries. That makes the shared DB (maybe) more attractive because the overlap in how you access the data is so small. I'm assuming below that's not the case.

Anyway, the API approach. First, the bad:

  • One more dependency (the old app). When it breaks, it takes down both apps.
  • One more hop to get data, so higher latency.
  • Working with existing code is less fun than writing new code. Just is.

But on the other hand, the good:

  • Much more resilient to schema changes. Your "old" app's API can have tests, and you can muck with the database to your heart's content (in the context of the old app) and just keep your API to its spec. Your new app won't know the difference, which is good. Abstraction FTW. This the opposite side of the "one more dependency" coin.

  • Same point, but from different angle: in the we-share-the-database approach, your schema + all of SQL is effectively your API, and it has two clients, the old app and the new. Unless your two apps are doing very different things with the same data, there's no way that's the best API. It's too poorly defined.

  • The DB admin/instrumentation is better. Let's say you mess up some query and hose your database. Which app was it? Where are these queries coming from? Basically, the fewer things that can interact with your DB, the better. Related: optimize your read queries in one place, not two.

  • If you used RESTful routes in your existing app for the non-API actions, I'm guessing your API needs will have a huge overlap with your existing controller code. It may be a matter of just converting your data to JSON instead of passing it to a view. Rails makes it very easy to use an action to respond to both API and user-driven requests. So that's a big DRY win if it's applicable.

  • What happens if you find out you do want some writability in your new app? Or at least access to some field your old app doesn't care about (maybe you added it with a script)? In the shared DB approach, it's just gross. With the other, it's just a matter of extending the API a bit.

Basically, the only way I'd go for the shared DB approach is that I hated the old code and wanted to start fresh. That's understandable (and I've done exactly that), but it's not the architecturally soundest option.

A third option to consider is sharing code between the two apps. For example, you could gem up the model code. Now your API is really some Ruby classes that know how to talk to your database. Going even further, you could write a Sinatra app and mount it inside of the existing Rails app and reuse big sections it. Then just work out the routing so that they look like separate apps to the outside world. Whether that's practical obviously depends on your specifics.

In terms of specific technologies, both Sinatra and Rails are fine choices. I tend towards Rails for bigger projects and Sinatra for smaller ones, but that's just me. Do what feels good.

于 2012-07-17T06:19:02.910 に答える