If you’re going to use the model in several applications, I don’t know of a better way. We package the model, the generated classes and a set of services for basic access to the model in one jar. Then each app includes the jar and implements a set of business services.
Up to this point our apps are different enough that we don’t share business logic. But I could see that happening at some point and then we’ll build a business services jar and share that as well. We break our apps into two parts. One handles web api requests. It inserts entries in a task table and a worker job picks those up and processes them. Classic example is a file dropped in a google bucket. GCP creates a pub/sub notification to our manager app. It validates the bucket name, uses that to identify what kind of file has been uploaded and creates a task to process the upload. A few google api calls a select or two and one insert into a task table. A worker app, wakes up, queries the task table and acts on the file that was uploaded. If we need to scale we could run multiple workers and handle load by claiming tasks. Tony Tony Giaccone On Oct 2, 2019, at 5:09 AM, Rafael Bugajewski <raf...@juicycocktail.com> wrote: >> On Oct 2, 2019, at 12:23 AM, Tony Giaccone <t...@giaccone.org> wrote: >> >> The other thing that bites me from time to time, is that we have our data >> model classes in a separate jar file. When you make changes to that and >> build from the command line, the related builds don't pick up the change >> unless you install it in the local repository. Not a problem if I build >> from the root directory, but I don't always want to build everything. > > It’s essentially the same thing here. We have our model classes and other > common code in a separate JAR file that we can deploy across several > services. It’s a PITA, especially if you only need to introduce small changes > to test something out, but there’s no better way, or is there? > > Best, > Rafael
