Change Request Lat/Long assignment to async using azure storage/functions

[mgmccarthy]

After a quick convo about IGeoCoder and Requests, @stevejgordon and I decided that b/c we're using an RPC call via a web service to retrieve lat/long at the point we create or update a Request, we should offload that operation asynchronously to azure storage, and let the web service call update the Request asynchronously.

This will allow the user to create/update the Request quickly w/out having to wait for the web service invocation to retrieve lat/long as they sit there watching the UI "spin".

This also does not combine a transactional resource (db) and a non-transaction resource (web service) in the same "logical" transaction of "creating/updating a Request"

@MisterJames @dpaquette thoughts?

[mgmccarthy]

@MisterJames @stevejgordon @dpaquette I have working code using a Hangfire job...

however, when going to write a WebJob for it (adding it to the Functions class under \WebJobs\AllReady.NotificationsWebJob project), since the methods in that class are all static, and I need access to both an IGeocoder instance as well as an AllReadyContext in order to update the lat/long I receive from the IGeocoder invocation, I'm not too sure how to handle it.

We could:

1. use poor man's DI and let the constructors create the instances we need for the call
2. find a way to use DI with WebJobs. Apparently, it IS possible: (http://www.jerriepelser.com/blog/dedependency-injection-with-autofac-and-webjobs/)

Just wanted to get people's feedback on if they're worked with webjobs using DI yet. If not, I can take a shot at it.

Thanks

[mgmccarthy]

cc @stevejgordon @dpaquette

after a quick chat with @MisterJames, he said moving to Service Locator would be okay for webjobs. That being said, even if we're using Service Locator, we still need to get an instance of AllReadyContext in the AllReady.NotificationsWebJob project in order to query the db for the Request, get the Request's lat/long based on Address, and then update the db with the lat/long.

If I'm not mistaken, we'll need to move AllReadyContext to a shared project in order for this to happen b/c we don't want a reference from AllReady.NotificationsWebJob back to the AllReady project.

I think we'll either rename AllReady.NotificationsWebJob to something more generic (AllReady.WebJobs) OR create a new project AllReady.IGeocoderWebJob (or something along those lines) that will hold the function for the operation I'm talking above.

Thoughts/feeback on either of these items?

[dpaquette]

@mgmccarthy Moving the DbContext to a shared project might cause some problems with migrations so I will need to investigate. I can't remember if that issue has been resolved or if the workaround was a good enough solution for us.

[mgmccarthy]

thanks for the help here @dpaquette.

I remember this being a real PIA in EF 6. We had to a write custom database initialization strategy for our project at work b/c of the shared context problem. I'm not too sure what the approach is for EF Core... are those initialization strategies still around, or have they been done away with altogether?

Either way, for these higher-level project organization questions as well as how it will impact our current build, I definitely need help/guidance here.

To move away from Hangfire running in the IIS process, we'd need to create a separate project for Hangfire to run as a windows service, and we're right back into the same boat... how to manage EF context's across multiple projects, so I feel like the problem is the same regardless of the technical solution we could choose to offload processing like this to an async op that is not somehow tied to IIS.

[mgmccarthy]

@dpaquette did you ever get a chance to check into how a shared EF 7 context would work (if it can work) across multiple projects in a single solution?

cc @stevejgordon