yenta
yenta

Reputation: 1372

Calling ServiceStack v3 and v4 services from the same upstream code

I am facing the following scenario and would appreciate some advice on how best to iterate forward:

My team is responsible for a Web Service written on ServiceStack v3. This service is responsible for aggregating data from several other v3 web services for use in a SPA.

We are running into a situation where we are limited by the implementation of a downstream service - this particular service abstracts away data access and queries that return large result sets occasionally timeout.

We would like to rewrite this service to add pagination. The best solution (for us) would be to leverage AutoQuery from ServiceStack v4. However this would require upstream code being able to reference ServiceStack packages in 2 versions (is this possible?). We could also add pagination to the existing service, but it uses an internal data framework that is not that easy to change and we have a high chance of breaking.

Any ideas?

Upvotes: 1

Views: 50

Answers (1)

Joel Harkes
Joel Harkes

Reputation: 11661

Yes, you can load in 2 versions of a dll inside your application. No, not while developing (only runtime) but I'm pretty sure this will lead to big problems in code execution (it wont be able to find the right class-version run-time).

Your question is also answered here: Using multiple versions of the same DLL

A better solution would be is to split your application into a v4 and v3 part using app domains also talked about in this question.

Original problem?

your original problem is you have old v3 services where you want to add pagination for performance issues?

  • Solution could be to add it in the v3 parts but this might break the services and they have to be tested?
  • You could migrate 3 to 4 (i'm not sure if this would fix your problem). I've found this is still very do-able.
  • Create your own wrapper services using redis caching (adv: no changing in the original code)
  • Build in a caching mechanic client-side/intermediary so you don't need to wait on the long api call.
  • migrate to autoquery. (I have no experience here)

Roadmap

I think you'd do good researching some of these options. I think your case there is not one perfect solution, there is only pros and cons.

To you to decide which risks to take.

Upvotes: 1

Related Questions