While the general architecture of LazyStack is language agnostic, our current implementation is not. LazyStack applications are .NET C# end-to-end. We have worked in many languages and like a lot of them. However, we really like Xamarin Forms for building mobile apps and .NET; which is fully open source, offers very complete libraries for almost anything you need to do, and is running on almost any platform (even Web Assembly now!).
We use .NET and C# on both the client and server to facilitate code sharing among them. From a security perspective it is also very important to calculate in the “comfort” and “reduced audit overhead” that working with .NET libraries provides. Using .NET libraries makes security audits of your library usage largely a check-box exercise. Microsoft takes security very seriously and the .NET libraries are generally a gold standard from a security perspective, at least compared to most other open-source libraries.
This is not true if you are working in something like Node.js where you could have hundreds (I’m not kidding here) of open-source libraries YOU have to certify for inclusion in your server-side stack. Just trying to track these libraries and their dependencies can be very time-consuming and error prone. In addition, you end up having to “pin” all the dependent versions and thus falling behind on available updates and thus throttling one of the most important benefits of using open-source libraries. This may not matter if you are just building a quick app to test market acceptance, but keep in mind that you are incurring technical debt that will be paid at some point if your application succeeds and must pass security audit later.
Please understand we are not ragging on Node.js, GO, Java, Python, Ruby or any other server-side lambda language runtime you may prefer, we are just pointing out the possible security related costs of using less well known open-source libraries in your stack. Just to make this point even more interesting; one of us were involved in a FinTech application stack using GO and it was a slam dunk technically even though we couldn’t run that code through a static code analyzer acceptable to the bank’s security audit team. We managed to get it through audit but there was a significant additional cost. This was not because GO was intrinsically hard to analyze, it was just new enough that the acceptable static code analyzers didn’t yet support it.
OK, but what about Java? Java has many trusted libraries that can be safely included in server side stacks and it is easy to argue that the Java ecosystem has lots to offer on the enterprise side. No doubt about it! I’d even go so far as to point folks to Blade, Dropwizard, Grails, GWT, Hibernate, JSF, JHipster, Play, Spark, Sprint, Struts, and Tapestry for efforts to make fielding application stacks simple.