Shipbuilding as a Microservice Architecture

[robject]

Shipbuilding apps are monolithic, combining a user interface of some sort with something like a spreadsheet. In fact, a fast and easy way to build a shipbuilder app is to write a set of macros inside a spreadsheet.

Now take a step back and consider the program from a web-application point of view. In other words, the engine runs on a server, and a user interface communicates remotely with it, perhaps on a different machine entirely. Multiple UIs could talk with this engine -- a web application, or an iPad app, or an Android app, and so on.

The next layer: each service provided by the builder, including the UI, run in separate services running on a network. There's a controlling facade, a registration process, a heartbeat, or some set of organizational principles at work, so that the UI can use all of the active services.

 

[AnotherDilbert]

Are you trying to invent client-server?


Seriously, why do you need the server? We need next to no CPU and next to no data to design a ship, it must be easily done in JS on the client. I guess you might want to store the designs on the server?

 

[robject]

I'm trying to apply a microservice architecture.

Well, one service can serve a UI, and any number of services can compute pieces of ships. A cross-cutting service can manage stage effects. Another can calculate demand. Storage is another. Heck, combat could be its own service. Et cetera.

I'm talking really really micro services in some cases.

And as an exercise.

 

[Matt123]

Done and works well.

At the time I had in mind to create other micro-services to add functionality, including fleet building, HG combat and integrating it with with the Traveller Map service for movement. Sadly other stuff came up and took over, but the foundation and first service is there waiting for me when my time frees up.

Spreadsheets work well, I created and fine tuned my ship builder over several spreadsheets and originally wrote it in Perl before this version in Ruby. I also recreated T4 Pocket Empires spreadsheets to automate running a campaign.

http://www.travellerrpg.com/CotI/Discuss/showthread.php?t=21748

It took two spreadsheets in the end as one could not handle all the data, but it was fun

Back to micro-services, the key is to build on the imperfect solutions others have created, to create something that offers more. You can recreate the HG ship builder as a new online micro-service and the community will have the choice of two (three including the venerable HG Shipyard) but still no economic, fleet management or combat service.

 

[agorski]

Once you have a ship design on the server, you could have remote clients that replicate consoles on the ship. Piloting, navigation, engineering, etc. and actually operate the ship with a live crew.

 

[robject]

Done and works well.

Link? Github perhaps?

 

[Leitz]

Link? Github perhaps?

My ears perked up at the mention of Ruby! Would love to see the code.

To answer the "Why microservices vice spreadsheets?" question I'd say portability and division of labor. A spreadsheet is set in stone unless I get a new copy, which then might lose my old data. Robject and I might have different versions and passing them back and forth becomes a nightmare. One source that is OS agnostic works a lot better.

The other part is aggregating component services. Task A might need Service 3, 7, and 34 while Task B needs Services 21-68. Much easier than trying to build one spreadsheet that rules them all.

Looking forward to looking at this. I haven't gotten into microservices yet but need to.

 

[Matt123]

Link? Github perhaps?

In my signature. I completed it in 2014 and it has been used by a range of people since then.

I didn't want to deal with copyright issues (it's a hobby...) so used BitBucket which has free private accounts, meaning my code and HG tables are not published and advised MM of the service (per his permission criteria).