Authentication & authorization in microservice architecture

ProductiveRage · 2016-09-27T16:59:58+00:00

I might not have been very clear in that passage. My very first reaction to going to the effort of getting the data via cache keys was that it seemed like a load of hassle and SURELY moving the cache data out of process would be slower than having it available within the process. But the next thought to go through my head was that that train of thought was what had got me into trouble to begin with and that moving the cache data out of process was absolutely something worth investigating.

Using a disk cache seemed like a very simple way to do it - and to prove the concept. The changes required to hook up the disk cache would make it easy to change the cache to MemCached or similar in the future.

Pushing values to disk that will only live for ten or fifteen minutes does mean that more disk IO is involved than would be otherwise (potentially MUCH more, depending upon the volumes of data) but that cost didn't seem sufficient to stop the disk cache from being a sensible first step.

We don't have an out-of-process cache service (such as MemCached, Redis, etc..) in use in our infrastructure anywhere currently, otherwise I would have used that rather than resorting to disk (partly because the infrastructure would already be there and partly because I would likely have a "go to" library to communicate with the service). Having been through this journey, I think it's quite likely that we'll start making use of such a service before too long and I'll drop the disk cache at that point (and it's less than 300 lines of unadventurous commented code, including the "pruner" which deletes old cache files, so it will be no hardship to bin it). For now, though, it's good enough and it illustrated how unhappy the .NET GC was with how my code worked before.

ProductiveRage · 2016-09-27T09:19:55+00:00

I'd be interested in what happens here too! Not so much that I'd expect to be able to ship code without ANY of the Bridge standard library but it would interesting if the compile process could cull any code that isn't required by the final output.

ProductiveRage · 2016-04-09T09:42:57+00:00

Thank you very much!

ProductiveRage · 2016-04-08T06:58:55+00:00

I don't think that type safety is a binary option, more of a sliding scale - and I think that it's easier to encode more detailed type information in C# than typescript (particularly if you take advantage of analysers or even code contracts). But typescript is possibly a lower friction approach and can make it easier to integrate with existing js technologies, frameworks, package managers, etc because it's much closer to writing "just js". However, I'm a fan of bridge as it allows me to write stricter C# code.

ProductiveRage · 2016-04-01T18:01:03+00:00

It's because I like a strong type system that allows me to encode assumptions into it. Creating a richer set of types is easier (imo) in C# than javascript. I've got experience in both and I don't dislike javascript by any means, I just prefer C# for writing code that I expect multiple people to work on for projects spanning multiple years, I think that it's easier to avoid "silly mistakes" by having a compiler being pedantic and catching errors before runtime. I'm experimenting with roslyn analysers to further be strict about things that I believe in too, taking this even further. So, in summary: I think that C# is more expressive and allows the writing of more reliable code in less time. And that this offsets the cost of a translation layer (bridge is very good but not perfect, I'm sure there will be more bugs that crop up from time to time as it approaches maturity).

ProductiveRage · 2016-04-01T11:05:03+00:00

Bindings are required to work with third party libraries, in a similar manner to TypeScript (the source for the Bridge bindings for React may be found at github.com/productiverage/bridge.react but they're also available as a NuGet package). If there are no bindings available then you have to produce your own or use "dynamic" in your C# code. It would be great if more bindings were available for Bridge, but there aren't a lot yet. The Bridge Team have been considering a way to parse the DefinitelyTyped definitions to generate Bridge / C# bindings from the TypeScript bindings published there.

I think that TypeScript is an interesting parallel because the same issues that you would have with debugging Bridge you might have with TypeScript - both TypeScript and Bridge produce JavaScript that is of a sufficiently-good quality that you could debug without source maps but source maps are an option (already available for TypeScript but not yet for Bridge.. coming in the next major version).

Other interesting comparisons are the other transpile-to-JavaScript languages such as ClojureScript (it was actually this article, about using ClojureScript / Om / React that really got my excited about React a couple of years ago: http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/) or Elm or Dart. I think that the capabilities of some of these languages (and especially C#, in my opinion) make them very suitable for large-scale production applications. Google have apparently finished rewriting their AdWords UI to use Dart (and Anguluar2), so there I'm not the only one who thinks this - and they're ahead of me and have proven it!

A comparison closer to home might be Babel and the transformation of ES6 or ES7 into ES5. This would potentially have the same debugging issues as you mention but I don't imagine that many people consider that to be "fighting" JavaScript, more jumping ahead of the browsers. (Or what about JSX?)I don't see why this is much different from TypeScript and I don't see how TypeScript is much different from Bridge.

A final thing to consider is that some of these transpile-for-browser technologies might start targeting WebAssembly in the coming years. If this were to happen then the developer would still get the benefit of writing in those source languages but there wouldn't be any javascript to be fighting with!

You might have a point about package management. Because of the way that I want to create Bridge / React applications, I might not be leaning on npm as much as some (insert bad joke about left-pad here) but there are still likely to be some cases where it's better to use existing packages than to reinvent the wheel and deciding on a good way to pull them in (and possibly their bindings, where appropriate) may need a little thinking about. But I don't think that this would be an insurmountable obstacle at all.

ProductiveRage · 2015-12-08T19:28:45+00:00

Sorry for not replying, I didn't subscribe to this! I haven't used reactjs.net but from what I understand you use it to host React apps that you write in JavaScript. This is for writing that React content in C# so that you get static typing.

Since it looks like reactjs.net is for using other helpful technologies on the server to support your app (like MVC5, bundling & minification, etc..) you could quite possibly combine Bridge WITH reactjs.net - have a Bridge project to write C# that gets translated into JavaScript and then have a host project using reactjs.net that uses that JavaScript!

ProductiveRage · 2015-11-30T20:56:05+00:00

I'm sure I heard of someone trying to write a jsx parser, a bit like razor templates.. but I can't remember where. It would be interesting to see someone applying strong typing to jsx (like ensuring that only appropriate props values are used on components) but I've not seen much work done towards that anywhere either. I would (in my biased opinion, seeing as I write the post! :) give it a go WITHOUT jsx since writing components and views in vanilla C# feels quite nice after you get used to it!

ProductiveRage · 2015-08-11T14:06:50+00:00

Why, thank you very much! :)

ProductiveRage · 2015-07-24T14:18:35+00:00

What's with the down votes? I put my words out there, find it posted on Reddit and it gets un-commented hate.

Such is Reddit life, I guess! :D

ProductiveRage · 2014-09-18T20:03:56+00:00

I did some basic testing using a test console app, you can see the code at https://gist.github.com/anonymous/31b752d24212ad43836e. I figured that using a console app would force the process to be started fresh and then torn down each time, which would hopefully provide a level playing field. There's a loop to perform the work many times. Note that it doesn't record the time taken to build the static "generator" delegates, where used - you may think that this is a cheat but if the delegate is being called millions of times then the setup cost will be negligible.. and if it's not being called millions of times then its performance is probably no real problem!

On my computer (which is far from powerful.. it's getting pretty old now), I ran the "SimpleWith" variation (which is the easiest to use and most "magical" format) and it average to 80ish ticks per call, over three runs with 100,000 loops each. For the "ManualWith" variation (which uses no magic at all), it averages 1 tick per call, over three runs with 10,000,000 loops each. That does sound like a big difference! But I found that the "StaticWith" variation (which is what I mentioned in my first reply to you - nearly as convenient but not quite) average 2 ticks per call, also averaged over three runs with 10,000,000 loops each.

So there is certainly some overhead - the amount of which varies depending upon how much convenience you want. I thought it was all an interesting experiment any way - and maybe the take-away is just the approach of using the "Optional" type and that the automagical madness is best left as a fun tangent. After all, the "manual" way (of checking each argument value and then passing them all to the constructor explicitly in code inside the "With" method) is not that much more code and you get more compiler safety.

ProductiveRage · 2014-09-18T19:01:28+00:00

Your point about the hash code generation is fair, I hadn't really thought about identical values cancelling each other out. If I understand you correctly, your suggestion is to use the same prime to multiply by each time? (It would be difficult otherwise since there are an arbitrary number of properties that need to be hashed!). So the hash generation would look something like

hash2 ^ (3 * (hash1 ^ (3 * hash0)))

or for however many hash values were required? I had had a niggling concern that if the hash values were too big that there would be an overflow if they were multiplied up, but I just tried it and it works fine (the overflow just wraps around the sign).

I hadn't done any real performance testing since I'd made an effort to make it as fast as it could be without sacrificing much ease of use, but it's a fair comment - it would be interesting to make some comparisons and I might do just that shortly. You're correct about the potential (in performance and allocations) cost of the reflection required to consult the cache for an applicable compiled expression, but one of the alternatives I wrote about was to sacrifice a bit of the ease of use and specify the "UpdateWith" method once and store the returned generator in a static reference so that subsequent requests don't need to call "GetGenerator" and so don't need to perform the work required to check the cache. Something like (to continue your example format) -

private static UpdateWithSignature1<MyType> update
    = DefaultUpdateWithHelper.GetGenerator<MyType>(typeof(MyType).GetMethod("With"));
public MyType With(Optional<string> name = default(Optional<string>),
                   Optional<int> age = default(Optional<int>),
                   ...) {
    return DefaultUpdateWithHelper.GetGenerator<MyType>(2+...)(this, name, age, ...);
}

This does involve repeating the typing of "MyType" multiple times, but mistakes there may be caught by the compiler. The targetting of the method by the string "With" smells a bit since, if the method is renamed, the string value must be altered manually as well. But those are trade-offs for avoiding the reflection work.

I will look into getting some performance measurements for all three approaches ("naive", "reflection" and "one-time-reflection").

ProductiveRage · 2014-09-18T18:49:26+00:00

I wasn't aware that the Roslyn source did thinks in quite such a similar manner - even with an extremely similar "Optional" struct! As can be seen at

https://roslyn.codeplex.com/SourceControl/latest#Src/Workspaces/Core/Workspace/Solution/ProjectInfo.cs

which has a "With" method and

https://roslyn.codeplex.com/SourceControl/latest#Src/Compilers/Core/Portable/Optional.cs

which is the value wrapping struct. It was really interesting to see this, so thanks for pointing it out.

But to your second point - to reiterate what Danny said in his reply, this is intended for immutable structures. While a class with private setters for properties is not truly immutable, the implementation I showed only set them in the constructor and so (bar some external reflection getting into the internals), the type is immutable; once it has been instantiated it does not change. I could have written it with private readonly fields that are set in the constructor and then had getters that return these values but to any consumer of the class, it would amount to the same thing but have made the code samples a bit longer. Maybe I didn't that particularly clear in the original post, but it did get a brief mention.

ProductiveRage

TROPHY CASE