Reputation: 286
Would it be possible to leverage a design based on modular components running on an application server with Go platform?
Is there a limitation that makes this design impossible with Go?
Upvotes: 4
Views: 5427
Reputation: 441
For this purpose perfectly suites XATMI service concept, which makes separate executable binaries as stateless services. And the application server governs their IPC communications via middleware, manages process statues (keep all processes up and running), provides tools for process reloading, etc. As example I can mention Enduro/X ASG project(https://github.com/endurox-dev/endurox-go), which does all of these tasks. Also it provides distributed transaction processing framework.
Upvotes: 2
Reputation: 42431
In my understanding one of the main features of Go is that it neither needs an application server, nor that code can be added/loaded at runtime. Go is compiled and (almost) statically linked and the executable is ready to run.
While all this module at runtime seems convenient it has massive drawbacks, especially increasing deployment and dependency complexity.
I doubt that the Go community would regard a module system as "leverage".
Upvotes: 1
Reputation: 6394
There is nothing similar to application server that are available in Java or .NET But there is google AppEngine that supports Go
There is no way to load/unload code in Go like in Java or .NET
You can't compile go as library that you will load with another Go App.
Anyway you can create Application server with Go. It will have multiple processes and load/unload code by starting/stopping processes.
Also it may compile code on server by embedding some server specific code in module. e.g. such extra code may implement AppServer Inter Process Communication.
Upvotes: 3