Serverless Client App with job queueing using stub calls

question
1

I am about 2 hours into my “hangfire” journey from a fresh google search for .Net background job handler, so this idea may be way against the grain. I have a client app (which happens to be an OWIN console app–but disregard that fact for a moment) that I need to queue up long running, server based jobs. Hangfire, from the server perspective, is exactly what I want/need. Where I choked on a bone this morning is when I saw the job queueing api:

var jobId = BackgroundJob.Enqueue( () => LongComplicatedCodeFatTask() );

I see that I can simply omit the server from the client, but surely I am not alone in my thinking that “sharing code base between client and server” is not always a great idea. I am thinking about creating a “client API” codebase for my client where LongComplicatedCodeFatTask() is just an empty stub function. Am I asking for trouble with this scheme?

2

Answering my own question. That idea pretty much hit a brick wall. I did get my version of a “Hello World” going where my REST API enqued a job that was executed by my server console app. To do so, I created a .NET Standard assembly that both the REST API app and the server app referenced. I am bit nervous about the version# in the following:

{“Type”:“XYZ_Batch_Processing.AnalyticsFactory, XYZ-Batch-Processing, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null”,“Method”:“AnalyticsJob”,“ParameterTypes”:"[]",“Arguments”:"[]"}

Am I always going to have to keep my REST API & background server in sync assembly-version-wise?